Cisco Networking Academy Program

CCNP 3: Multilayer Switching
Companion Guide
Second Edition

Wayne Lewis, Ph.D. Cisco Networking Academy Program

Cisco Press 800 East 96th Street Indianapolis, Indiana 46240 USA
www.ciscopress.com

ii

Cisco Networking Academy Program

CCNP 3: Multilayer Switching Companion Guide
Second Edition
Cisco Systems, Inc. Cisco Networking Academy Program Copyright © 2005 Cisco Systems, Inc. Published by: Cisco Press 800 East 96th Street Indianapolis, Indiana 46240 USA All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, or by any information storage and retrieval system, without written permission from the publisher, except for the inclusion of brief quotations in a review. Printed in the United States of America 1 2 3 4 5 6 7 8 9 0 Library of Congress Cataloging-in-Publication Number: 2003114385 ISBN: 1-58713-143-9

Trademark Acknowledgments
All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Cisco Press or Cisco Systems, Inc. cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.

Warning and Disclaimer
This book is designed to provide information about the Cisco Networking Academy Program CCNP 3: Multilayer Switching course. Every effort has been made to make this book as complete and accurate as possible, but no warranty or fitness is implied. The information is provided on an “as is” basis. The author, Cisco Press, and Cisco Systems, Inc. shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or from the use of the disks or programs that might accompany it. The opinions expressed in this book belong to the author and are not necessarily those of Cisco Systems, Inc.

This book is part of the Cisco Networking Academy® Program series from Cisco Press. The products in this series support and complement the Cisco Networking Academy Program curriculum. If you are using this book outside the Networking Academy program, then you are not preparing with a Cisco trained and authorized Networking Academy provider. For information on the Cisco Networking Academy Program or to locate a Networking Academy, please visit www.cisco.com/edu.

Corporate and Government Sales
Cisco Press offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales. For more information please contact: U.S. Corporate and Government Sales 1-800-382-3419 corpsales@pearsontechgroup.com For sales outside the United States please contact: International Sales international@pearsoned.com

iii

Feedback Information
At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book is crafted with care and precision, undergoing rigorous development that involves the unique expertise of members of the professional technical community. Reader feedback is a natural continuation of this process. If you have any comments on how we could improve the quality of this book, or otherwise alter it to better suit your needs, you can contact us through e-mail at feedback@ciscopress.com. Please be sure to include the book title and ISBN in your message. We greatly appreciate your assistance. Publisher John Wait Editor-in-Chief Executive Editor Cisco Representative Cisco Press Program Manager Production Manager Senior Development Editor Project Editor Copy Editor Technical Editors Book/Cover Designer Compositor Indexer John Kane Mary Beth Ray Anthony Wolfenden Nannette M. Noble Patrick Kanouse Christopher Cleveland Marc Fowler Gayle Johnson Mark Gallo, Stanford M. Wong, Jim Yoshida Louisa Adair Octal Publishing, Inc. Larry Sweazy

iv

About the Author
Wayne Lewis is the Cisco Academy manager for the Pacific Center for Advanced Technology Training, based at Honolulu Community College. Since 1998, he has taught routing and switching, remote access, troubleshooting, network security, and wireless networking to instructors from universities, colleges, and high schools in Australia, Canada, Central America, China, Hong Kong, Indonesia, Japan, Mexico, Singapore, South America, Taiwan, and the United States, both onsite and at Honolulu Community College. Before teaching computer networking, Wayne began teaching math at age 20 at Wichita State University, followed by the University of Hawaii and Honolulu Community College. He received a Ph.D. in math from the University of Hawaii in 1992. He works as a contractor for Cisco Systems, developing curriculum for the Cisco Networking Academy Program. He enjoys surfing the North Shore of Oahu when he’s not distracted by work.

v

About the Technical Reviewers
Mark Gallo is a technical manager with America Online, where he leads a group of engineers responsible for the design and deployment of the domestic corporate intranet. His network certifications include Cisco CCNP and Cisco CCDP. He has led several engineering groups responsible for designing and implementing enterprise LANs and international IP networks. He has a bachelor of science in electrical engineering from the University of Pittsburgh. He resides in northern Virginia with his wife, Betsy, and son, Paul. Stanford M. Wong, CCIE No. 8038, CCAI, MCSE, received his bachelor of science electrical engineering from the University of Hawaii and his master of business administration from the University of Phoenix. He is the owner and founder of Complete Network Solutions Corporation (CNSC). He is responsible for providing global enterprise networking solutions to the U.S. Government and commercial customers. He has 20 years in the networking industry; recently his work has focused on MPLS, VPN, and VoIP technologies. In addition, he instructs CCNP Cisco Networking Academy courses at Honolulu Community College. Jim Yoshida, CCDA, CCNP, is the Cisco Networking Academy Program main contact and a CCNA and CCNP instructor at Hawaii Community College. He has more than 20 years of teaching experience and has been involved with the Cisco Networking Academy Program since 1998. In addition to being responsible for overseeing the Cisco Networking Academy Program and conducting classes, he has worked closely with members of the Cisco World Wide Education team on CCNP curriculum development.

vi

Overview
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxii Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9 Chapter 10 Campus Networks and Design Models. . . . . . . . . . . . . . . . . . . . . .3 VLANs and VTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 Spanning Tree Protocol (STP) . . . . . . . . . . . . . . . . . . . . . . . . . . .153 Inter-VLAN Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .259 Multilayer Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .341 Cisco AVVID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .385 Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .483 Monitoring and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .545 Transparent LAN Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .649

Appendix A Check Your Understanding Answer Key. . . . . . . . . . . . . . . . . . .677 Appendix B Gigabit Ethernet and 10 Gigabit Ethernet Standards and Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .701 Appendix C Using the Catalyst Operating System. . . . . . . . . . . . . . . . . . . . .709 Glossary 735 Index 755

vii

Table of Contents
Foreword Introduction Chapter 1 xxii xxiv

Campus Networks and Design Models . . . . . . . . . . . . . . . . . . . . . 3 Overview of a Campus Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Traditional Campus Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Issues with Traditional Campus Network Designs . . . . . . . . . . . . . . .5 Traditional 80/20 Rule of Network Traffic. . . . . . . . . . . . . . . . . . . . . .7 The New 20/80 Rule of Network Traffic . . . . . . . . . . . . . . . . . . . . . . .8 Key Requirements of the Evolving Campus Structure . . . . . . . . . . . .9 Evolving Campus Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 Key Characteristics of Various Switching Technologies . . . . . . . . . . . .11 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Layer 2 Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 Layer 3 Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Layer 4 Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 Multilayer Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 Multicast. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 Hierarchical Design Model for Campus Networks . . . . . . . . . . . . . .20 Building-Block Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 The Switch Block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Scaling the Switch Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 Building the Core Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 Layer 2 and Layer 3 Backbone Scaling . . . . . . . . . . . . . . . . . . . . . . .29 Advantages of the Building-Block Approach . . . . . . . . . . . . . . . . . .31 Small Campus Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34 Medium Campus Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34 Large Campus Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 Basic Configuration of the Switch. . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 Cabling the Switch Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 Connecting to the Console Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 Connecting to an Ethernet Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 Clearing a Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 Setting a Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44 Naming the Switch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 Configuring the Switch for Remote Access . . . . . . . . . . . . . . . . . . . .46

viii

Identifying Individual Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48 Defining Port Speed and Line Mode on a Switch . . . . . . . . . . . . . . .50 Important IOS Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 Command-Line Recall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 Using the Help Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54 Password Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 Setting an Idle Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57 Verifying Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57 Backup and Restoration of a Configuration Using a TFTP Server . .58 HTTP Access to the Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60 Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63 Chapter 2 VLANs and VTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 VLAN Basics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 Describe a VLAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 Motivation for VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70 VLANs and Network Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 VLANs and Broadcast Distribution . . . . . . . . . . . . . . . . . . . . . . . . . .73 VLANs and Bandwidth Utilization . . . . . . . . . . . . . . . . . . . . . . . . . .74 VLANs Versus Router Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75 Wrong Motives for Implementing VLANs . . . . . . . . . . . . . . . . . . . .76 VLAN Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 Understanding Switch ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78 Router ACLs and VLAN Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 Configuring Router ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81 Configuring VLAN Maps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83 Using VLAN Maps with Router ACLs . . . . . . . . . . . . . . . . . . . . . . .88 Applying Router ACLs and VLAN Maps on VLANs . . . . . . . . . . . .90 VLAN Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92 VLAN Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93 End-to-End VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94 Local VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95 Establishing VLAN Memberships . . . . . . . . . . . . . . . . . . . . . . . . . . .96 Port-Based VLAN Membership. . . . . . . . . . . . . . . . . . . . . . . . . . . . .96 Dynamic VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98

ix

Configuring VLANs and VMPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100 Configuring Static VLANs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100 Verifying VLAN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 Deleting VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 VMPS Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103 VMPS Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . .105 Access Links and Trunk Links. . . . . . . . . . . . . . . . . . . . . . . . . . . . .109 VLAN Trunking and Dynamic Trunking Protocol . . . . . . . . . . . . . . .111 Trunking Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111 Configuring a VLAN Trunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112 Removing VLANs from a Trunk . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Basics of Dynamic Trunking Protocol . . . . . . . . . . . . . . . . . . . . . . .114 DTP Trunk and Access Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . .116 DTP Combinations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117 Verifying DTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120 VLAN Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122 VLAN Frame Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123 Inter-Switch Link (ISL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123 The IEEE 802.1Q Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125 The IEEE 802.10 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126 LAN Emulation (LANE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 VLAN Trunking Protocol (VTP). . . . . . . . . . . . . . . . . . . . . . . . . . . . .128 VTP Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128 VTP Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129 VTP Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131 Adding a Switch to a VTP Domain . . . . . . . . . . . . . . . . . . . . . . . . .133 VTP Advertisements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134 VTP Configuration and VTP Pruning . . . . . . . . . . . . . . . . . . . . . . . . .138 Basic Configuration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138 Configuring the VTP Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139 Configuring the VTP Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140 Configuring the VTP Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 Verifying VTP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142 Default Behavior of a Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143 Configuring VTP Pruning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144 Verifying VTP Pruning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146 Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148

x

Chapter 3

Spanning Tree Protocol (STP) . . . . . . . . . . . . . . . . . . . . . . . . . . .153 STP Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154 STP Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154 Broadcast Loops. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154 Bridge Table Corruption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156 Bridge Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158 Path Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159 Port ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160 STP Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161 STP Decisions and BPDU Exchanges . . . . . . . . . . . . . . . . . . . . . . .162 Three Steps of STP Convergence. . . . . . . . . . . . . . . . . . . . . . . . . . .163 Electing the Root Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164 Electing Root Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165 Electing Designated Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166 STP States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168 STP Timers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171 BPDU Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .174 Topology Changes and STP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176 STP Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177 Delay in STP Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177 PortFast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178 UplinkFast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .180 BackboneFast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182 802.1w Rapid STP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185 RSTP States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .186 RSTP Port Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .187 RSTP Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190 RSTP BPDU Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194 Evolution of Spanning Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195 PVST (Per-VLAN Spanning Tree), PVST+, and Mono Spanning Tree Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195 Enhanced PVST+. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198 MST (802.1s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .199 Load Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201 Switchport Tuning Using BPDU Guard. . . . . . . . . . . . . . . . . . . . . .203 Switchport Tuning Using Root Guard . . . . . . . . . . . . . . . . . . . . . . .205 STP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207 Default STP Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207 Enabling and Disabling STP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208 Modifying the Root Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208

xi

Setting the Priority for Ports and VLANs . . . . . . . . . . . . . . . . . . . .210 Setting the Port Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212 Configuring Switch Priority of a VLAN . . . . . . . . . . . . . . . . . . . . .213 Modifying Default Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214 Tuning, Verifying, and Troubleshooting STP . . . . . . . . . . . . . . . . . . .216 Configuring PortFast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .216 Configuring UplinkFast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217 Configuring BackboneFast. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .218 Configuring BPDU Guard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .219 Configuring Root Guard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220 Configuring Load Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221 Verifying STP, RSTP, and MSTP Configuration . . . . . . . . . . . . . . .225 RSTP and MSTP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226 Default RSTP and MSTP Configuration . . . . . . . . . . . . . . . . . . . . .226 RSTP and MSTP Configuration Guidelines . . . . . . . . . . . . . . . . . .227 Enabling RSTP and MSTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228 Configuring the MST Root Switch . . . . . . . . . . . . . . . . . . . . . . . . .230 Configuring MST Switch Priority . . . . . . . . . . . . . . . . . . . . . . . . . .232 Configuring MST Path Cost. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232 Configuring MST Port Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . .234 Configuring MSTP Timers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235 Configuring Maximum Hop Count . . . . . . . . . . . . . . . . . . . . . . . . .237 EtherChannel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237 EtherChannel Explained . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238 Frame Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .240 EtherChannel Methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241 Port Aggregation Protocol (PAgP) . . . . . . . . . . . . . . . . . . . . . . . . . .242 Link Aggregation Control Protocol (LACP) . . . . . . . . . . . . . . . . . .244 Modifying Port Cost for EtherChannel Groups . . . . . . . . . . . . . . . .245 EtherChannel Configuration Guidelines . . . . . . . . . . . . . . . . . . . . .245 Configuring Fast EtherChannel . . . . . . . . . . . . . . . . . . . . . . . . . . . .249 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250 Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .254 Chapter 4 Inter-VLAN Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Methods of Inter-VLAN Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . .259 Key Components of Inter-VLAN Routing. . . . . . . . . . . . . . . . . . . .259 Comparison of Layer 2 and Layer 3 Operations in the Core . . . . . .262 Inter-VLAN Routing Performance and Scalability Issues. . . . . . . .263

xii

Roles of the Different Types of VLANs. . . . . . . . . . . . . . . . . . . . . .265 Route Switch Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269 Router-on-a-Stick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .271 When to Use the Router-on-a-Stick Design. . . . . . . . . . . . . . . . . . .272 Cisco Layer 3 Feature Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .273 Configuring Inter-VLAN Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . .274 Configuring Inter-VLAN Routing in a Switched Network . . . . . . .274 Configuring Inter-VLAN Routing Via the Switch Virtual Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .274 Configuring Inter-VLAN Routing Via the Routed Port . . . . . . . . . .275 Configuring Routing Between an External Router and an Internal Route Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .276 Configuring the Router for the Native VLAN . . . . . . . . . . . . . . . . .277 Configuring Router-on-a-Stick. . . . . . . . . . . . . . . . . . . . . . . . . . . . .279 Verifying the Inter-VLAN Routing Configuration. . . . . . . . . . . . . .282 Troubleshooting Inter-VLAN Routing. . . . . . . . . . . . . . . . . . . . . . .286 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .287 Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .288 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289 Chapter 5 Multilayer Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293 Multilayer Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .294 MLS Hardware and Software Requirements . . . . . . . . . . . . . . . . . .294 MLS Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .296 MLS Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297 MLS Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .300 Cisco Express Forwarding (CEF) . . . . . . . . . . . . . . . . . . . . . . . . . . . .303 Comparing MLS and CEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .303 CEF Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .308 CEF Forwarding Information Base . . . . . . . . . . . . . . . . . . . . . . . . .309 CEF Adjacency Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311 Packet Flow for Layer 2 and Layer 3 Forwarding Decisions. . . . . .311 Additional Benefits of CEF-Based Forwarding . . . . . . . . . . . . . . . .313 MLS and CEF Configuration Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . .315 MLS-RP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315 MLS-SE Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .317 Configuring MLS Optional Parameters . . . . . . . . . . . . . . . . . . . . . .318 MLS Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .320 MLS Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326 CEF Configuration and Verification . . . . . . . . . . . . . . . . . . . . . . . . .331

xiii

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334 Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .335 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .337 Chapter 6 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 Implementing Module Redundancy in a Multilayer Switched Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .342 Implementing Redundant Supervisor Engines in Catalyst Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .342 Implementing Redundant Supervisor Uplink Modules in Catalyst Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .344 Implementing Redundant Distributed Forwarding Cards in Catalyst Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347 Implementing Redundant Power Supplies . . . . . . . . . . . . . . . . . . . .348 Implementing Router Redundancy in a Switched Network . . . . . . . .349 Router Redundancy Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . .350 ICMP Router Discovery Protocol (IRDP) . . . . . . . . . . . . . . . . . . . .352 Hot Standby Router Protocol (HSRP) . . . . . . . . . . . . . . . . . . . . . . .352 Virtual Router Redundancy Protocol (VRRP) . . . . . . . . . . . . . . . . .355 Gateway Load Balancing Protocol (GLBP). . . . . . . . . . . . . . . . . . .356 Single Router Mode (SRM) Redundancy . . . . . . . . . . . . . . . . . . . .360 Server Load Balancing (SLB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .361 HSRP Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .363 The Virtual Router MAC Address . . . . . . . . . . . . . . . . . . . . . . . . . .366 HSRP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .368 HSRP States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .369 HSRP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .369 How HSRP Addresses Redundancy Issues . . . . . . . . . . . . . . . . . . .371 HSRP Standby Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .372 HSRP Standby Preempt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .373 HSRP Hello Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .373 HSRP Interface Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .375 Verify HSRP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .376 HSRP over Trunk Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .377 Troubleshooting HSRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .378 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .379 Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .380 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .381

xiv

Chapter 7

Cisco AVVID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .385 Introduction to Cisco AVVID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .386 Examining the Cisco AVVID Framework . . . . . . . . . . . . . . . . . . . .386 Cisco AVVID Network Infrastructure . . . . . . . . . . . . . . . . . . . . . . .388 Cisco AVVID Intelligent Network Services. . . . . . . . . . . . . . . . . . .391 High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .393 Cisco AVVID Network Solutions . . . . . . . . . . . . . . . . . . . . . . . . . .395 Cisco AVVID Network Implementation Example . . . . . . . . . . . . . .401 Legacy Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .403 Examining Multicast in a Multilayer Switched Network . . . . . . . . . .406 Multicast Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .406 Multicast Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .408 Layer 3 Multicast Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . .409 Layer 2 Multicast Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . .411 IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .412 IGMP Version 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .412 IGMP Version 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .415 IGMP Version 1 and Version 2 Interoperability . . . . . . . . . . . . . . . .417 IGMP Version 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .418 IGMP Snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .419 CGMP Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .422 Routing Multicast Traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .424 Distribution Trees. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .425 Managing Delivery of Multicast Packets . . . . . . . . . . . . . . . . . . . . .428 Reverse Path Forwarding (RPF). . . . . . . . . . . . . . . . . . . . . . . . . . . .430 Multicast Routing Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .432 Dense-Mode Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . .432 Distance Vector Multicast Routing Protocol . . . . . . . . . . . . . . . . . .433 Protocol-Independent Multicast Dense Mode . . . . . . . . . . . . . . . . .433 Multicast Open Shortest Path First . . . . . . . . . . . . . . . . . . . . . . . . .434 Sparse Mode Routing Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . .434 Core-Based Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .435 PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .436 Configure IP Multicast Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . .437 Verify PIM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .438 Configure Auto-RP (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .439 Optional IP Multicast Routing Tasks . . . . . . . . . . . . . . . . . . . . . . . .441 Cisco IP Telephony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .444 Introducing the Cisco IP Telephony Solution . . . . . . . . . . . . . . . . .445 Cisco IP Telephony Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .450

xv

Single-Site Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .450 Multiple Sites with Independent Call Processing . . . . . . . . . . . . . .451 Multiple Sites with Distributed Call Processing . . . . . . . . . . . . . . .452 Multisite IP WAN with Centralized Call Processing . . . . . . . . . . . .454 Voice Quality Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .455 Common Voice Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .455 Implementing QoS for Voice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .457 QoS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .458 Trust Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .459 Traffic Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .461 Traffic Classification at Layer 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . .462 Traffic Classification at Layer 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . .463 Summary Recommendations for QoS Implementation . . . . . . . . . .464 Network Design Issues for Voice. . . . . . . . . . . . . . . . . . . . . . . . . . . . .465 IP Phone Physical Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . .465 Power/Protection Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .465 Power to IP Phones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .466 Infrastructure Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .467 High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .467 IP Addressing and Management . . . . . . . . . . . . . . . . . . . . . . . . . . .468 Implementing IP Telephony with Auxiliary VLANs . . . . . . . . . . . .470 Voice VLAN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .470 Connecting to the Network with Auxiliary VLANs. . . . . . . . . . . . .471 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .472 Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .475 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .479 Chapter 8 Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 Quality of Service Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . .484 Quality of Service Defined. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .484 Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .485 Delay or Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .485 Delay Variation or Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .486 Network Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .486 Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .487 Quality of Service Requirements for Data . . . . . . . . . . . . . . . . . . . .487 Quality of Service Requirements for Voice . . . . . . . . . . . . . . . . . . .488 Quality of Service Requirements for Video . . . . . . . . . . . . . . . . . . .488

xvi

Quality of Service Mechanisms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .490 Best-Effort Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .490 Integrated Services Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .491 Differentiated Services Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . .492 Traffic Marking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .492 Modular QoS Command-Line Interface (MQC) . . . . . . . . . . . . . . .495 Using the class-map Command to Define Traffic Classes . . . . . . . .495 Defining the QoS Policy Using the Policy Map. . . . . . . . . . . . . . . .497 Applying the Policy to an Interface Using the Service Policy. . . . .499 Classification at the Access Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . .499 Trusting the CoS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .499 Configuring CoS Trust Using the IOS . . . . . . . . . . . . . . . . . . . . . . .500 Assigning CoS on a Per-Port Basis . . . . . . . . . . . . . . . . . . . . . . . . .501 Rewriting the CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .501 Using a MAC ACL to Assign a DSCP Value . . . . . . . . . . . . . . . . . .502 Configuring DSCP Using a MAC ACL . . . . . . . . . . . . . . . . . . . . . .504 Using an IP ACL to Define the DSCP or Precedence . . . . . . . . . . .507 Policing and Marking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .509 Individual Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .509 Aggregate Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .510 Token Bucket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .511 Classification and Policing Using Committed Access Rate (CAR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .512 Configuring the Policed DSCP Map . . . . . . . . . . . . . . . . . . . . . . . .512 Configuring Classification Using CAR . . . . . . . . . . . . . . . . . . . . . .514 Configuring Policing Using CAR . . . . . . . . . . . . . . . . . . . . . . . . . .515 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .516 FIFO Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .516 Weighted Fair Queuing (WFQ) . . . . . . . . . . . . . . . . . . . . . . . . . . . .516 WFQ and IP Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .518 Class-Based Weighted Fair Queuing (CBWFQ) . . . . . . . . . . . . . . .519 Configuring CBWFQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .520 CBWFQ Bandwidth Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . .522 Congestion Avoidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .522 Weighted Random Early Detection (WRED) . . . . . . . . . . . . . . . . .523 Configuring WRED on a Physical Interface . . . . . . . . . . . . . . . . . .524 Verifying WRED Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . .525 Configuring WRED with CBWFQ . . . . . . . . . . . . . . . . . . . . . . . . .525 Low Latency Queuing (LLQ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .526 Configuring LLQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .527

xvii

Traffic Shaping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .528 Generic Traffic Shaping (GTS) . . . . . . . . . . . . . . . . . . . . . . . . . . . .529 Configuring GTS for an Interface . . . . . . . . . . . . . . . . . . . . . . . . . .530 GTS for Frame Relay Networks . . . . . . . . . . . . . . . . . . . . . . . . . . .531 Configuring GTS for Frame Relay Networks . . . . . . . . . . . . . . . . .532 Verifying GTS Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .532 QoS Using Low-Speed Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .533 Link Efficiency Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .534 Link Fragmentation and Interleaving (LFI) . . . . . . . . . . . . . . . . . . .534 Link Fragmentation and Interleaving (LFI): Multilink PPP . . . . . .535 Compressed Real-Time Protocol (CRTP) . . . . . . . . . . . . . . . . . . . .536 Configuring CRTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .537 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .538 Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .539 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .541 Chapter 9 Monitoring and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545 Monitoring Switched Network Performance with SPAN and VSPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .545 Monitoring with SPAN on a Port Basis . . . . . . . . . . . . . . . . . . . . . .546 SPAN Interaction with Other Features. . . . . . . . . . . . . . . . . . . . . . .548 SPAN Configuration Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . .549 Configuring SPAN Sessions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .550 VSPAN—SPAN Using VLANs as Monitored Source. . . . . . . . . . .552 RSPAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .555 RSPAN Reflector Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .556 RSPAN Interaction with Other Features . . . . . . . . . . . . . . . . . . . . .557 RSPAN and RSPAN VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .557 Configuring RSPAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .558 Configuring RSPAN to Filter Trunks for Specific VLAN Traffic . .562 Network Analysis Modules and Switch Fabric Modules. . . . . . . . . . .564 The Network Analysis Module . . . . . . . . . . . . . . . . . . . . . . . . . . . .566 Using the NAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .567 Benefits of Deploying a NAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . .569 NAM Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .569 Increasing Switching Fabric in Catalyst 6500 Series Switches . . . .570 Configuring the Switch Fabric Module . . . . . . . . . . . . . . . . . . . . . .572 Monitoring the Switch Fabric Module. . . . . . . . . . . . . . . . . . . . . . .572

xviii

Basic Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .575 Access Control Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .575 Basic Security Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .577 Physical Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .577 Connecting to the Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .579 Out-of-Band Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .579 In-Band Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .581 Basic Password Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .582 Securing Remote Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .585 Remote Management Security Options . . . . . . . . . . . . . . . . . . . . . .585 Advanced Username Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .585 Encrypting Communications Using Secure Shell . . . . . . . . . . . . . .587 Encryption Key Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .589 Using VLANs to Restrict Remote Management . . . . . . . . . . . . . . .591 Securing the Web Management Interface . . . . . . . . . . . . . . . . . . . .592 Using Access Lists to Restrict Remote Management . . . . . . . . . . .593 Additional Remote Management Session Options . . . . . . . . . . . . .595 Configuring, Verifying, and Troubleshooting SSH Server. . . . . . . .596 Securing User Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .598 Using Port Security, Protected Ports, and Private VLANs. . . . . . . .598 Using Access Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .600 Router ACLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .602 Port ACLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .604 VLAN ACLs and VLAN Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . .604 Configuring and Verifying Port Security . . . . . . . . . . . . . . . . . . . . .607 Configuring and Verifying Protected Ports . . . . . . . . . . . . . . . . . . .609 Configuring and Verifying Access Lists. . . . . . . . . . . . . . . . . . . . . .610 Authentication, Authorization, and Accounting (AAA) . . . . . . . . . . .614 TACACS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .615 RADIUS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .616 Cisco Secure Access Control Server (ACS). . . . . . . . . . . . . . . . . . .618 Configuring AAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .619 Configuring TACACS+ and RADIUS Clients . . . . . . . . . . . . . . . . .620 Configuring AAA Authentication . . . . . . . . . . . . . . . . . . . . . . . . . .621 Configuring AAA Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . .625 Configuring AAA Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . .630 IEEE 802.1x Port-Based Authentication . . . . . . . . . . . . . . . . . . . . . . .634 Authentication Initiation and Message Exchange . . . . . . . . . . . . . .635 Ports in Authorized and Unauthorized States . . . . . . . . . . . . . . . . .637 Supported Topologies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .638

xix

802.1x Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . .639 Configuring 802.1x Port-Based Authentication . . . . . . . . . . . . . . . .640 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .643 Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .644 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .645 Chapter 10 Transparent LAN Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649 Ethernet Solutions for Transparent LAN Services (TLS) . . . . . . . . . .649 Same Network, New Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . .649 VLAN Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .651 Intermetro LAN Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .652 Interservice POP Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . .653 Metro Segmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .654 Introducing Transparent LAN Services Architecture . . . . . . . . . . . . .655 Metro Ethernet Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .655 IP+Optical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .656 Point-to-Point Dedicated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .657 Point-to-Multipoint Shared . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .658 Role of QoS in TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .659 Examining Fiber-Optic Transports . . . . . . . . . . . . . . . . . . . . . . . . . . .660 Defining SONET and SDH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .660 Applications for SONET/SDH. . . . . . . . . . . . . . . . . . . . . . . . . . . . .664 Implementing SONET/SDH Within a Metropolitan Network. . . . .664 Defining Dynamic Packet Transport (DPT) . . . . . . . . . . . . . . . . . . .665 Defining CWDM and DWDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . .666 Implementing DWDM Over a MAN . . . . . . . . . . . . . . . . . . . . . . . .667 10 Gigabit Ethernet Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . .669 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .671 Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .672 Check Your Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .672 Appendix A Check Your Understanding Answer Key . . . . . . . . . . . . . . . . . . 677 Appendix B Gigabit Ethernet and 10 Gigabit Ethernet Standards and Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701 Appendix C Using the Catalyst Operating System . . . . . . . . . . . . . . . . . . . . 709 Glossary 735 Index 755

xx

Cisco Systems Networking Icon Legend
Cisco Systems, Inc. uses a standardized set of icons to represent devices in network topology illustrations. The following icon legend shows the most commonly used icons you will encounter throughout this book.

Access Server Token Ring

PC

Laptop

Web Server

Cache Engine

Local Multilayer Director Switch Feature Card (MSFC)

Small Hub Token Ring File Server

Distributed Director Route/Switch Processor Multilayer Switch

Gateway

V

Firewall

POTS Phone

IP Phone

NetRanger

PIX Firewall

Router

Voice-Enabled Router

Database

Bridge Cisco Storage Router

Modem Hub
Cisco CallManager Optical Services Router

PL
Switch ATM Switch Wireless Access Port
MGX 8240

M
MGX 8260 Optical Transport

Wireless Connection

Printer Network Cloud Cisco SoftPhone

ONS Device

EtherClient

VPN Concentrator

TransPath

Optical Cross-Connect

Ethernet Connection

Serial Connection

Circuit-Switched Connection

xxi

Command Syntax Conventions
The conventions used to present command syntax in this book are the same conventions used in the Cisco IOS software Command Reference. The Command Reference describes these conventions as follows:
■ ■ ■ ■ ■ ■

Bold indicates commands and keywords that are entered exactly as shown. Italic indicates arguments for which you supply values. Vertical bars (|) separate alternative, mutually exclusive elements. Square brackets ([ ]) indicate an optional element. Braces ({ }) indicate a required choice. Braces within brackets ([{ }]) indicate a required choice within an optional element.

xxii

Foreword
Throughout the world, the Internet has offered tremendous new opportunities for individuals and their employers. Companies and other organizations are seeing dramatic increases in productivity by investing in robust networking capabilities. Some studies have shown measurable productivity improvements in entire economies. The promise of enhanced efficiency, profitability, and standard of living is real and growing. Such productivity gains aren’t achieved by simply purchasing networking equipment. Skilled professionals are needed to plan, design, install, deploy, configure, operate, maintain, and troubleshoot today’s networks. Network managers must ensure that they have planned for network security and continued operation. They need to design for the required performance level in their organization. They must implement new capabilities as the demands of their organization, and its reliance on the network, expand. To meet the many educational needs of the internetworking community, Cisco Systems established the Cisco Networking Academy Program. The Networking Academy is a comprehensive learning program that provides students with the Internet technology skills that are essential in a global economy. The Networking Academy integrates face-to-face teaching, web-based content, online assessment, student performance tracking, hands-on labs, instructor training and support, and preparation for industry-standard certifications. The Networking Academy continually raises the bar on blended learning and educational processes. The Internet-based assessment and instructor support systems are some of the most extensive and validated systems ever developed, including a 24/7 customer service system for Networking Academy instructors. Through community feedback and electronic assessment, the Networking Academy adapts the curriculum to improve outcomes and student achievement. The Cisco Global Learning Network infrastructure designed for the Networking Academy delivers a rich, interactive, personalized curriculum to students worldwide. The Internet has the power to change how people work, live, play, and learn, and the Cisco Networking Academy Program is at the forefront of this transformation. This Cisco Press book is one in a series of best-selling companion titles for the Cisco Networking Academy Program. Designed by Cisco Worldwide Education and Cisco Press, these books provide integrated support for the online learning content that is made available to Academies all over the world. These Cisco Press books are the only books authorized for the Networking Academy by Cisco Systems. They provide print and CD-ROM materials that ensure the greatest possible learning experience for Networking Academy students. I hope you are successful as you embark on your learning path with Cisco Systems and the Internet. I also hope that you will choose to continue your learning after you complete the Networking Academy curriculum. In addition to its Cisco Networking Academy Program titles, Cisco Press publishes an extensive list of networking technology and certification

xxiii

publications that provide a wide range of resources. Cisco Systems has also established a network of professional training companies—the Cisco Learning Partners—that provide a full range of Cisco training courses. They offer training in many formats, including e-learning, self-paced, and instructor-led classes. Their instructors are Cisco-certified, and Cisco creates their materials. When you are ready, please visit the Learning & Events area at Cisco.com to learn about all the educational support that Cisco and its partners have to offer. Thank you for choosing this book and the Cisco Networking Academy Program. The Cisco Networking Academy Team Cisco Systems, Inc.

xxiv

Introduction
This companion guide is designed as a desk reference to supplement your classroom and laboratory experience with version 3 of the CCNP 3 course in the Cisco Networking Academy Program. CCNP 3: Multilayer Switching is the third of four courses leading to the Cisco Certified Network Professional certification. CCNP 3 teaches you how to design, configure, maintain, and scale multilayer switched networks. You will learn to use VLANs, STP, VTP, inter-VLAN routing, redundancy, QoS, and security on Catalyst switches. While taking the course, use this companion guide to help you prepare for the Building Cisco Multilayer Switched Networks (BCMSN) 642-811 BCMSN exam, which is one of the four required exams to obtain the CCNP certification.

This Book’s Goal
The goal of this book is to build on the switching concepts you learned while studying for the CCNA exam and to teach you the foundations of advanced switching concepts. The topics are designed to prepare you to pass the Building Cisco Multilayer Switched Networks (BCMSN) exam (642-811 BCMSN). The Building Cisco Multilayer Switched Networks exam is a qualifying exam for the CCNP, CCDP, and CCIP certifications. The 642-811 BCMSN exam tests materials covered under the new Building Cisco Multilayer Switched Networks course and exam objectives. The exam certifies that the successful candidate has the knowledge and skills necessary to use multilayer switching to implement campus networks with Catalyst switches. The exam covers campus network design, STP, VTP, inter-VLAN routing, redundancy techniques, basic Cisco IP BCMSN Telephony, QoS, and security. The key methodologies used in this book are to help you discover the exam topics you need to review in more depth, to help you fully understand and remember those details, and to help you prove to yourself that you have retained your knowledge of those topics. This book does not try to help you pass by memorization; it helps you truly learn and understand the topics. This book focuses on introducing techniques and technology for enabling WAN solutions. To fully benefit from this book, you should be familiar with general networking terms and concepts and should have basic knowledge of the following:
■ ■ ■

Basic Cisco router and Catalyst switch operation and configuration TCP/IP operation and configuration VLANs, STP, VTP, and inter-VLAN routing

xxv

This Book’s Audience
This book has a few different audiences. First, it is intended for students who are interested in multilayer switching technologies. In particular, it is targeted toward students in the Cisco Networking Academy Program CCNP 3: Multilayer Switching course. In the classroom, this book serves as a supplement to the online curriculum. This book is also appropriate for corporate training faculty and staff members, as well as general users. This book is also useful for network administrators who are responsible for implementing and troubleshooting enterprise Cisco routers and router configuration. Furthermore, it is valuable for anyone who is interested in learning advanced switching concepts and passing the Building Cisco Multilayer Switched Networks (BCMSN) exam (642-811 BCMSN).

This Book’s Features
Many of this book’s features help facilitate a full understanding of the topics covered in this book:

Objectives—Each chapter starts with a list of objectives that you should have mastered by the end of the chapter. The objectives reference the key concepts covered in the chapter. Figures, examples, tables, and scenarios—This book contains figures, examples, and tables that help explain theories, concepts, commands, and setup sequences that reinforce concepts and help you visualize the content covered in the chapter. In addition, the specific scenarios provide real-life situations that detail the problem and its solution. Chapter summaries—At the end of each chapter is a summary of the concepts covered in the chapter. It provides a synopsis of the chapter and serves as a study aid. Key terms—Each chapter includes a list of defined key terms that are covered in the chapter. The key terms appear in color throughout the chapter where they are used in context. The definitions of these terms serve as a study aid. In addition, the key terms reinforce the concepts introduced in the chapter and help you understand the chapter material before you move on to new concepts. Check Your Understanding questions and answers—Review questions, presented at the end of each chapter, serve as a self-assessment tool. They reinforce the concepts introduced in the chapter and help test your understanding before you move on to a new chapter. An answer key to all the questions is provided in Appendix A, “Check Your Understanding Answer Key.”

xxvi

Certification exam practice questions—To further assess your understanding, you will find on the companion CD-ROM a test bank of questions exclusive to Cisco Press that covers the full range of exam topics published by Cisco Systems for the CCNP BCMSN # 642-811 exam. The robust test engine is powered by Boson Software, Inc. Skill-building activities—Throughout the book are references to additional skillbuilding activities to connect theory with practice. You can easily spot these activities by the following icons:
Interactive Media Activities

Interactive Media Activities included on the companion CD are hands-on drag-anddrop, fill-in-the-blank, and matching exercises that help you master basic networking concepts.

Lab Activity

The collection of lab activities developed for the course can be found in the Cisco Networking Academy Program CCNP 3: Multilayer Switching Lab Companion Guide, Second Edition.

How This Book Is Organized
Although you could read this book cover to cover, it is designed to be flexible and to allow you to easily move between chapters and sections of chapters to cover just the material you need to work with more. If you do intend to read all the chapters, the order in which they are presented is the ideal sequence. This book also contains three appendixes. The following list summarizes the topics of this book’s elements:

Chapter 1, “Campus Networks and Design Models”—Good design is the key to the operation and maintenance of a multilayer switched network. Campus networks can be described in terms of component building blocks. Campus network design includes correct placement of Layer 2, Layer 3, and multilayer devices in a campus network. Basic network management command-line operations with Catalyst switches are introduced. Chapter 2, “VLANs and VTP”— This chapter explores the role of VLANs and VLAN protocols in modern campus networks. You learn how to configure VLANs on Catalyst switches. Trunk encapsulation types are discussed as well as trunk negotiation with DTP. You learn how to understand and use VLAN management tools, such as VLAN Trunking Protocol (VTP).

xxvii

Chapter 3, “Spanning Tree Protocol (STP)”—IEEE 802.1D specifies Spanning Tree Protocol. STP uses a number of variables to calculate the shortest-path tree for a Layer 2 switched network. You learn what these variables are and how STP is affected by them. Cisco enhanced the 802.1D standard with the PortFast, UplinkFast, and BackboneFast extensions. A brief history of STP leading to the present is given. Vendor-neutral RSTP and MST are introduced. Load sharing with EtherChannel is also described. Chapter 4, “Inter-VLAN Routing”—Inter-VLAN routing can be configured with various physical and logical topologies. A router with several physical LAN interfaces can route between distinct connected VLANs. A router connected to a switch via an ISL or IEEE 802.1Q trunk can route between VLANs. A multilayer switch can route between VLANs without the intervention of a router. Finally, Catalyst multilayer switch ports can be configured as Layer 3 ports (router interfaces), in which case they do not participate in any VLANs. On chassis-based Catalyst switches, inter-VLAN routing is performed by a number of different line cards and daughter cards, depending on the platform. Chapter 5, “Multilayer Switching”—Two methods of multilayer switching, also known as wire-speed routing, have been employed by Catalyst switches in the past. Cisco’s MLS was used for several years before CEF was invented. MLS operation and configuration are discussed in this chapter. CEF is now a standard feature on Catalyst switches and Cisco routers. It provides a method for wire-speed routing by using dedicated ASICs and two data structures (adjacency table and FIB). Chapter 6, “Redundancy”—Redundancy in network design is critical to organizations being able to maintain services to customers and internal users. Redundancy, resiliency, and availability are all terms used to describe a network’s ability to deliver services even when devices or interfaces fail. The goal is to reach the “five nines” of redundancy—maintaining uptime of 99.999%, during which the network is continuously operating. Redundancy is explored in the following cases: — Router redundancy with IRDP, HSRP, VRRP, and GLBP — Redundant uplinks in Catalyst switches — Power module redundancy in chassis-based Catalyst switches — Supervisor engine redundancy in Catalyst 6500 switches with SRM — Server redundancy via SLB

Chapter 7, “Cisco AVVID”—Architecture for Voice, Video, and Integrated Data (AVVID) is Cisco’s hardware and software solution for the integration of voice, video, and data. AVVID has largely been driven by IP telephony and the push to be an industry leader in the migration to an IP-based world of communication. This chapter touches on the various aspects of AVVID in general and IP telephony in particular. Whenever

xxviii

IP telephony is discussed, QoS is brought into the conversation, because QoS smoothes the integration of voice, video, and data; without QoS, IP telephony on an Internet scale would never be realized. QoS and its role in AVVID is introduced. Multicasting allows for sending data from one source to many receivers without burdening hosts or network devices that do not need to receive the traffic. Multicast traffic optimizes bandwidth utilization by using only the links necessary to get the traffic from the source to the destination. This chapter explains multicasting from scratch and builds to discussing the three major function areas for multicast protocols: between hosts and routers, between routers and switches, and between routers.

Chapter 8, “Quality of Service”—QoS lets network engineers prescriptively optimize traffic utilization on network links. The primary force behind the growing dependence on QoS is the integration of voice, video, and data on IP networks. Service providers also use QoS to provide various classes of service to their customers. Cisco divides QoS subject matter into the following six areas: — Classification — Congestion management — Congestion avoidance — Policing and shaping — Signaling — Link efficiency mechanisms QoS models fall under either the IntServ model or the DiffServ model. This chapter deals almost entirely with the DiffServ model, which is by far the most common model used in real-world QoS implementations.

Chapter 9, “Monitoring and Security”—Monitoring refers to any software or hardware technology that lets the network engineer monitor network traffic. SPAN, VSPAN, and RSPAN are software technologies used on Catalyst switches for traffic monitoring. The network analysis module for the Catalyst 6500 is a dedicated link card used as a LAN monitoring tool. Security is just as important in a switched network as it is in any other part of an enterprise or campus network. Cisco has a growing list of technologies available on Catalyst switches to ensure the integrity and confidentiality of data traversing the switched network. This chapter explores the most common network security options deployed in switched networks. The content in this chapter roughly falls under the categories of SPAN technologies, basic Catalyst switch security options, securing remote management of Catalyst switches, and securing user access via ACLs, AAA, and 802.1X authentication.

xxix

Chapter 10, “Transparent LAN Services”—Transparent LAN services are employed in metropolitan-area networks to provide geographically remote Ethernet service, VLAN sanctity over MANs, and integration with various high-speed Layer 1 and Layer 2 fiber-optic transports. Cisco’s ONS product line, along with the Catalyst 3550 and Catalyst 6500 switches and the Cisco 7600 routers, comprise a collection of network devices that can deliver state-of-the-art TLS. Appendix A, “Check Your Understanding Answer Key”—This appendix lists the solutions to the Check Your Understanding Questions in each chapter. Appendix B, “Gigabit Ethernet and 10 Gigabit Ethernet Standards and Operation”—This appendix introduces the Gigabit and 10 Gigabit Ethernet standards. Appendix C, “Using the Catalyst Operating System”—This appendix introduces the Catalyst operating system. Companies over the years have deployed Catalyst switches, such as the 4000, 5000, and 6000 family switches, using the CatOS. Many of these companies opt not to migrate to the IOS-based alternatives to the CatOS, so Cisco continues to support CatOS options for these switches. This appendix describes how to configure common LAN switching features using the Catalyst OS. Glossary—The glossary lists all the key terms that appear throughout the book.

About the CD-ROM
The CD-ROM included with this book contains eighteen Interactive Media Activities from Cisco Systems, Inc. The Interactive Media Activities are hands-on drag-and-drop, fill-in-theblank, and matching exercises that help you master basic networking concepts. The CD-ROM also contains a test engine by Boson Software, Inc. with a total of 200 multiple choice, drag and drop, and fill in the blank practice exam questions that are exclusive to Cisco Press. The questions cover the full range of exam topics published by Cisco Systems for the CCNP BCMSN # 642-811 exam. Boson Software, Inc. is a software and training company specializing in test preparation and hands-on skills acquisition product development. Boson was among the first software vendors to support Cisco certifications, and is now an authorized Cisco Learning Partner as well as Premier Reseller. Additional Boson practice tests, simulation products, and other study aids are available at www.boson.com.

Objectives
After completing this chapter, you will be able to perform tasks related to the following:
■ ■

Understand the multilayer switching approach to campus networking. Explain the correct placement of Layer 2, Layer 3, and multilayer devices on a campus network. Develop a logical design for the network irrespective of any product that might be implemented to guarantee continued scalability. Perform basic command-line interface (CLI) operations on Cisco Catalyst switches, such as command-line recall, command editing, and uploading and downloading code images and configuration files.

Chapter 1 Campus Networks and Design Models
As corporate intranets continue to evolve, network managers and architects are faced with a multitude of options in building and modifying their networks. Starting from a premise that the existing environment already has a combination of switches and routers within the network, this chapter shows you how to scale the campus intranet to meet the ever-increasing demands of the business. In this chapter, you learn about the approach to campus networking called multilayer switching. This chapter discusses the correct placement of Layer 2, Layer 3, and multilayer devices on a campus network. This chapter also describes a set of building blocks, which presents a logical design for the network irrespective of any product that might be implemented. The success of any campus intranet is based on the placement of network services that, when applied correctly, guarantee continued scalability. Finally, this chapter describes the command-line interface (CLI) on Cisco switches, including aspects such as command-line recall, command editing, uploading and downloading code images, and configuration files.

Overview of a Campus Network
Here, traditional campus networks and their traffic patterns are described, followed by a discussion of the evolving traffic patterns in modern campus networks and their requirements.

4

Chapter 1: Campus Networks and Design Models

Traditional Campus Networks
In the early days of networking, primarily research universities and the military experimented with computer networks. The term campus network derives from networks built on university campuses. Today, the term is used more broadly to include networks that span corporate “campuses,” consisting of buildings, portions of a building, or a collection of colocated buildings. Campus size is an important factor in network design. A large campus has several or many colocated buildings, a medium campus has one or several colocated buildings, and a small campus resides within a single building. Historically, campus networks consisted of a single LAN to which new users were added simply by connecting anywhere on the LAN. Because of the distance limitations of the networking media, campus networks usually were confined to a building or several buildings in close proximity, as shown in Figure 1-1.
Figure 1-1 Traditional Campus Networks Connected Small Groups of Users to Share Local Resources

Broadcast Domain

Collision Domain 1

Collision Domain 2

The LAN was a physical network that connected the devices. In the case of Ethernet, all the devices shared the available half-duplex 10-Mbps network. Because of the carrier sense multiple access collision detect (CSMA/CD) access method used by Ethernet, the whole LAN was a single collision domain (such as Collision Domain 1 in Figure 1-1). Few design considerations were needed to provide user access to the network backbone. Because of Ethernet’s inherent limitations, physically adjacent users were sometimes connected to a single access device to minimize the number of taps into the backbone. Although hubs (see Figure 1-2) met this requirement and became standard devices for multiple network access, increased user demand quickly slowed network performance.

Overview of a Campus Network

5

Figure 1-2 Traditional Campus Networks Typically Used Hubs to Connect Users
Workgroup Server Workgroup Server Workgroup Server

Building A Access Layer
Hubs

Building B

Building C

Hubs

Hubs

Distribution Layer

Core Layer

FDDI Backbone Dual-Homed
Ethernet or Fast Ethernet Port FDDI Port

FDDI Dual Ring Enterprise Servers

WDM LAN PH

Issues with Traditional Campus Network Designs
The two major problems with traditional networks have always been availability and performance. These two problems are both affected by the amount of bandwidth available. In a single collision domain, frames are visible to all devices on the LAN and are free to collide. Multiport Layer 2 devices, such as bridges and switches, are used to segment the LAN into discrete collision domains and forward Layer 2 data frames to only the segment of the network that contains the destination address. For example, a 48-port switch has 48 collision domains. Because the Layer 2 ports separate the LAN into distinct physical segments, they also help resolve issues related to Ethernet’s distance limitations. However, frames containing the broadcast Media Access Control (MAC) address are still flooded throughout the entire broadcast domain. A single network device could malfunction and flood the network with “noise,” and this could bring down the network. This is where routers come in. Because routers operate at Layer 3 of the Open System Interconnection (OSI) model, they can make intelligent decisions about the flow of data to and from a network segment. Routers do not forward broadcasts, so if noise from excessive broadcasts cripples one logical segment, the router does not forward those broadcasts to other logical segments. Traffic that polls the network about component status or availability and that advertises network component status or availability can affect network performance. Two common types of broadcasts that poll the network are IP Address Resolution Protocol (ARP) requests and

6

Chapter 1: Campus Networks and Design Models

NetBIOS name requests. These broadcasts are normally propagated across an entire subnet and expect the target device to respond directly to the broadcast. In addition to broadcasts, multicast traffic can also consume a large amount of bandwidth. Multicast traffic is propagated to a specific group of users, so if deployed correctly, it actually conserves bandwidth relative to broadcast traffic. Depending on the number of users in a multicast group or the type of application data contained in the multicast packet, multicast traffic can consume most, if not all, of the network resources. An example of a multicast implementation is the Cisco IP/TV solution, which uses multicast packets to transport multimedia such as audio and video. As networks grow, so does the amount of broadcast traffic on the network. Excessive broadcasts reduce the bandwidth available to the end users and force end-user nodes to waste CPU cycles on unnecessary processes. In a worst-case scenario, broadcast storms can effectively shut down the network by monopolizing the available bandwidth. Two methods can address the broadcast issue for large switched LAN sites:
■ ■

Using routers to create many subnets and logically segment the traffic Implementing virtual LANs (VLANs) within the switched network

With the option to use routers (see Figure 1-3), broadcasts do not pass through routers. Although this approach contains broadcast traffic, the CPU of a traditional router has to process each packet. This scenario can create a bottleneck in the network. If a router has an interface on a subnet in which a broadcast storm is occurring, the router CPU might be interrupted to the extent that the router is unable to process packets destined for other networks in a timely fashion.
Figure 1-3 Routers Segment Traffic into Independent Broadcast Domains

10.1.1.0

10.1.2.0

10.1.3.0

Overview of a Campus Network

7

Figure 1-4 depicts the option to implement VLANs within the switched network. For the purpose of this curriculum, VLANs are basically defined as broadcast domains. A VLAN includes a group of end devices that populate multiple physical LAN segments and switch ports. They communicate as if they were on a single LAN segment. One of the primary benefits of LAN switches with VLANs is that they can be used to effectively contain broadcast traffic and manage traffic flows. A router is required for traffic to traverse between VLANs. Although routers are almost always part of a network where VLANs exist, a switch also prevents broadcast traffic from one VLAN from affecting another VLAN.
Figure 1-4 VLANs Allow for More Flexible Arrangements of Broadcast Domains

VLAN1

VLAN2

VLAN3

Traditional 80/20 Rule of Network Traffic
Ideally, end users with common interests or work patterns are placed in the same logical network as the servers they access most. Most of the traffic within these logical networks is contained on the local LAN segment. This simple task effectively minimizes the load on the network backbone. As shown in Figure 1-5, the 80/20 rule (pertinent through much of the 1990s) states that in a properly designed network, 80 percent of the traffic on a given network segment is local. No more than 20 percent of the network traffic should move across the network’s backbone. Backbone congestion indicates that traffic patterns are not meeting the 80/20 rule. In this

8

Chapter 1: Campus Networks and Design Models

case, rather than adding switches or replacing hubs with switches, network administrators can improve network performance by doing one of the following:

Moving resources such as applications, software programs, and files from one server to another to contain traffic locally within a workgroup Moving users logically, if not physically, so that the workgroups more closely reflect the actual traffic patterns Adding servers so that users can access them locally without having to cross the backbone

Figure 1-5 The 80/20 Rule of Network Traffic

80+% VLAN1 Local Traffic

VLAN2

80+% Local Traffic

VLAN3 80+% Local Traffic 20% Remote Traffic

The New 20/80 Rule of Network Traffic
In today’s networks, traffic patterns are moving toward what is called the 20/80 model (see Figure 1-6). In the 20/80 model, only 20 percent of traffic remains local to the workgroup LAN, and 80 percent of the traffic leaves the local network. Two factors have contributed to these changing traffic patterns:

The Internet—With web-based computing and Internet applications, a PC can be a tool for both publishing and accessing information. So information can now come from anywhere in the network, potentially creating massive amounts of traffic crossing subnet boundaries. Users hop transparently between servers across the enterprise by using hyperlinks, without having to worry about where the data is located. Server farms—The second factor leading to the decline of local-centric networks is the move toward server consolidation. Enterprises are deploying centralized server farms for security purposes, ease of management, and reduced cost of ownership. All traffic from the client subnets to these servers must travel across the campus backbone.

Overview of a Campus Network

9

Figure 1-6 The 20/80 Rule of Network Traffic

20% VLAN1 Local Traffic

VLAN2

20% Local Traffic

80+% Remote Traffic VLAN3 20% Local Traffic

However, this change in traffic patterns requires the Layer 3 performance to approximate the Layer 2 performance. Because routing is a CPU-intensive process, this Layer 3 processing can create network bottlenecks. This increased reliance on Layer 3 processing is an important factor driving the continued increase in requirements on campus networks.

Key Requirements of the Evolving Campus Structure
The key requirements placing pressure on the emerging campus designs are as follows:

Fast convergence—This requirement stipulates that the network must be able to adapt very quickly to changes in the network topology, such as failed links and insertion of new devices on the network. Fast convergence becomes even more critical as the campus network grows in geographic scope. Deterministic paths—This requirement allows a device or administrator to make a decision based on the desirability of a given path to a destination for certain applications or user groups. Redundancy—This requirement specifies that a mechanism, such as redundant links, devices, or modules, is in place to ensure that the network is operational at all times. Scalable—This requirement states that as the network grows and new applications are added, the infrastructure must be able to handle the increased traffic demands. Centralized applications—This requirement dictates that centralized applications must be available to support most or all users on the network. The server farm is in a centralized location using the same hop count for each area of the network. The new 20/80 rule—This requirement focuses on the shift in traditional traffic patterns.

10

Chapter 1: Campus Networks and Design Models

Multiprotocol support—This requirement specifies that campus networks must be able to support multiprotocol environments, such as mixed Internet Protocol (IP) and Internetwork Packet Exchange (IPX) environments. Multicasting—This requirement demands that campus networks be able to support IP multicast traffic in addition to IP unicast traffic.

Evolving Campus Structure
Increased user demands and complex applications have forced network designers to focus on the network’s actual traffic patterns. Networks can no longer be divided into subnetworks based only on the number of users. The emergence of enterprise servers that run applications serving all users also has a direct effect on the load across the network. A higher traffic load across the entire network results in the need for more efficient routing and switching techniques. In the new campus model, traffic patterns dictate the placement of the services required by the end user. To service the local traffic, Layer 2 switches have moved to the edge of the network and into the wiring closets. These switches connect end-user devices and servers into a common workgroup. Services can be separated into three categories:
■ ■ ■

Local services Remote services Enterprise services

A local service is one in which the entities that provide the service reside on the same subnet and, therefore, the same virtual network as the user. Local services remain in specific areas of the network. Traffic to and from local services is confined to links between the server, the switches, and the end users. Local traffic does not enter the network backbone or pass through a router. A remote service is an entity that might be geographically close to the end user but that is not on the same subnet or VLAN as the user. Traffic to and from remote services might or might not cross the backbone. Requests for the remote services have to cross broadcast domain boundaries because these services are remote to the requesting end user. Therefore, switches must connect to Layer 3 devices to allow for access to remote services. Enterprise services are services common to all users. Examples of enterprise services are e-mail, Internet access, and videoconferencing. Because all users need to access enterprise services, these servers and services exist within a separate subnet placed close to the backbone. Because enterprise services exist outside the end user’s broadcast domain, Layer 3 devices are required to access these services. The enterprise services might or might not be grouped by Layer 2 switches.

Key Characteristics of Various Switching Technologies

11

Assuming a hierarchical design, placing the enterprise servers close to the backbone ensures the same distance from each user. It also means that all traffic going to an enterprise server indeed crosses the network backbone.
Interactive Media Activity Drag and Drop: Evolving Campus Structure

This activity helps you understand local, remote, and enterprise services.

Key Characteristics of Various Switching Technologies
Two primary factors govern a switched network’s success:
■ ■

Availability Performance

Other factors include
■ ■ ■

Reliability Scalability Cost

The range and variety of services now available on modern switches are extensive, can be overwhelming, and will continue to evolve over time because these services are driven by customer needs. Focus on the core concepts of these technologies instead of expecting to master each one. Many of these technologies will be replaced by completely independent solutions in the coming years.

Overview
Modern networks should support data, voice, and video. This means the network devices must support quality of service (QoS) and multicast technologies. QoS is needed to provide acceptable levels of service to the end user. During periods of congestion, a QoS policy ensures that certain types of traffic, defined by the network engineer, receive preferential treatment over other types of traffic. In addition, QoS is not effective when chronic congestion exists. QoS is better suited to handle occasional periods of congestion. The network should also have a high-speed, reliable backbone. This means that one or more switches need to support large capacities on the switch backplane and offer significant Gigabit Ethernet port densities. The network should be scalable. This means having devices that can be upgraded without needing to replace them with completely new equipment. Each switch purchased for the backbone must have a chassis containing sufficient slots to reasonably support module upgrades over

12

Chapter 1: Campus Networks and Design Models

time that are appropriate for the network. Backbone switches should have nonblocking backplanes. A switch that supports high-speed switching at Layer 3 to Layer 7 is needed. This means that the switches should support technologies such as Cisco Express Forwarding (CEF). Finally, the network should have redundancy. This means that the switches need to support such features as Hot Standby Router Protocol (HSRP), Internet Control Message Protocol (ICMP) Router Discovery Protocol (IRDP), VLAN Trunking Protocol (VTP), trunking, channeling, Internet Group Management Protocol (IGMP), Cisco Group Management Protocol (CGMP), and Spanning Tree Protocol (STP). These features are just some of the considerations you need to keep in mind when purchasing a switch. Modern switches support a variety of other features. The OSI model provides a convenient way to describe processes that take place in a networking environment. Each layer in the OSI model relates to a set of specific functions. This book focuses on Layers 2, 3, and 4 of the OSI model. Protocols normally can be categorized into one or more of the OSI layers. Each protocol exchanges information called protocol data units (PDUs) between peer layers of network devices. Table 1-1 shows the specific name for each PDU at each layer and the device type that traditionally processes the PDU.
Table 1-1 Generic Names for PDUs at Each OSI Layer

Layer

PDU Type

Device Type

Data link (Layer 2) Network (Layer 3) Transport (Layer 4)

Frames Packets Segments

Layer 2 switch or bridge Router, Layer 3 switch Router or server (TCP or UDP port), Layer 4 switch

The underlying layer services each protocol peer layer. For example, TCP segments are encapsulated in Layer 3 packets, which are encapsulated in Layer 2 frames. A layer-specific device processes only those PDUs for which it is responsible by inspecting the PDU header. Each device treats the higher-level information as payload. For example, a switch processes Layer 2 information and considers the Layer 3 information payload and merely forwards it without processing it. Switches are available that can make decisions based on PDU header information at Layers 2, 3, and 4. Content service switches, such as the Cisco CSS 11800, make switching decisions based on Layer 2 to Layer 7 header information.

Key Characteristics of Various Switching Technologies

13

Layer 2 Switching
Bridges and switches analyze incoming frames, make forwarding decisions based on information contained in the frames, and forward the frames toward the destination. Upper-layer protocol transparency is a primary advantage of both bridging and switching. Because both bridges and switches operate at the data link layer, they are not required to examine upperlayer information. Bridges also can filter frames based on any Layer 2 fields. Although bridges and switches share most relevant attributes, several distinctions differentiate these technologies. Switches are significantly faster because they switch in hardware. Switches also can support higher port densities than bridges. Some switches support cut-through switching, which reduces latency and delays in the network by processing only the MAC address portion of the frame. Bridges support only store-and-forward traffic switching (where the entire frame is processed before forwarding). The main differences are that bridges perform switching through software, as opposed to hardware, and switches have a higher port density. Layer 2 switching is basically hardware-based bridging, as shown in Figure 1-7. In a switch, frame forwarding is handled by specialized hardware called Application-Specific Integrated Circuits (ASICs). The ASIC technology engineered for switches allows for scalability up to gigabit speeds, with low latency at costs significantly lower than Ethernet bridges.
Figure 1-7 Layer 2 Switching Is Hardware-Based Bridging 7 6 5 4 3 2 1 Data Link
• Hardware-Based Bridging • Wire-Speed Performance • High-Speed Scalability • Low Latency • MAC Address • Low Cost

Layer 2 switches let network managers increase bandwidth without adding complexity to the network. Layer 2 data frames consist of both control information, such as MAC addresses, and end-user content. At Layer 2, no modification of the frame control information is required when moving between similar Layer 1 interfaces, such as Ethernet and Fast

14

Chapter 1: Campus Networks and Design Models

Ethernet. However, changes to control information might occur when bridging between unlike media types, such as Fiber Distributed Data Interface (FDDI), Asynchronous Transfer Mode (ATM), and Ethernet. Workgroup connectivity and network segmentation are the two primary uses for Layer 2 switches. The high performance of a Layer 2 switch allows for network designs that significantly decrease the number of hosts per physical segment, creating a flatter design with more segments in the campus network. Despite the advantages of Layer 2 switching, it still has all the same characteristics and limitations of legacy bridging. Broadcast domains are unaffected by the incorporation of Layer 2 switches. The same scaling and performance issues exist as in the large bridged networks of the past. The broadcast and multicast radius increases with the number of hosts, and broadcasts are still propagated across the network. Also, STP issues are proportional to the size of the Layer 2-only network. It is evident that Layer 3 functionality is still needed within the network. The next section introduces Layer 3 switching.

Layer 3 Switching
Layer 3 switching is hardware-based routing, as illustrated in Figure 1-8.
Figure 1-8 Layer 3 Switching Is Hardware-Based Routing 7 6 5 4 3 2 1 Network
• Hardware-Based Packet Forwarding • High-Performance Packet Switching • High-Speed Scalability • Low Latency • Lower Per-Port Cost • Flow Accounting • Security • QoS

The packet forwarding is handled by specialized hardware ASICs. The goal is to capture the speed of switching and the scalability of routing. A Layer 3 switch acts on a packet in the same way a traditional router does:

Determines the forwarding path based on Layer 3 information

Key Characteristics of Various Switching Technologies

15

■ ■ ■ ■ ■ ■

Validates the integrity of the Layer 3 header via checksum Verifies packet expiration and updates accordingly Processes and responds to any option information Updates forwarding statistics in the Management Information Base (MIB) Applies security controls if required Implements QoS

The primary difference between the packet-switching operation of a router and a Layer 3 switch lies in the physical implementation. In general-purpose routers, microprocessor-based engines typically perform software-based packet switching. A Layer 3 switch performs packet switching with hardware. Because it is designed to handle high-performance LAN traffic, a Layer 3 switch can be placed anywhere within the network, offering a cost-effective alternative to the traditional router.

Layer 4 Switching
Layer 4 switching refers to Layer 3 hardware-based routing that accounts for Layer 4 control information, as shown in Figure 1-9. Information in packet headers typically includes Layer 3 addressing, the Layer 3 protocol type, and more fields relevant to Layer 3 devices, such as Time-To-Live (TTL) and checksum. The packet also contains information relevant to the higher layers within the communicating hosts, such as the protocol type and port number.
Figure 1-9 Layer 4 Switching Is Hardware-Based, or Wire-Speed Routing That Accounts for Layer 4 Control Information
• Based on Layer 3 and Layer 4 • Based on Application-Related Information • TCP Fields • UDP Fields • QoS • Granular Traffic Control

7 6 5 4 3 2 1 Transport

The term Layer 4 switching is sometimes used to describe switching frames based on flows characterized by a combination of source/destination MAC addresses, IP addresses, and port

16

Chapter 1: Campus Networks and Design Models

numbers. One advantage of Layer 4 switching is that it allows QoS to be applied to traffic. QoS is typically applied to classes of traffic defined by port numbers, so it can be said to provide application-based prioritization. Routers can control traffic based on Layer 4 information. One method of controlling Layer 4 traffic is by using extended access lists. Another method of providing Layer 4 accounting of flows, NetFlow switching, is used on the Cisco 7200 and 7500 router platforms and the Catalyst 5000 and 6000 family switches. Finally, when performing Layer 4 functions, a switch reads the TCP and UDP fields in the headers to determine what type of information the packet is carrying. The network manager can program the switch to prioritize traffic by application. This function allows network managers to define a QoS for end users. When used for QoS purposes, Layer 4 switching might mean that a videoconferencing application is granted more bandwidth than an e-mail message or FTP packet. Layer 4 switching is necessary if the organization’s policy dictates granular control of traffic by application or if the organization requires accounting of traffic itemized in terms of applications. However, it should be noted that switches performing Layer 4 switching need the capability to identify and store large numbers of forwarding-table entries, especially if the switch is within the core of an enterprise network. Many Layer 2 and Layer 3 switches have forwarding tables that are sized in proportion to the number of network devices. With Layer 4 switches, the number of network devices must be multiplied by the number of different application protocols and conversations in use in the network. Thus, the size of the forwarding table can grow quickly as the numbers of end devices and types of applications increase. This large table capacity is essential to creating a high-performance switch that supports wire-speed Layer 4 forwarding of traffic.

Multilayer Switching
The term multilayer switching is used for two distinct things. On one hand, multilayer switching is a general network design term used to refer to hardware-based PDU header rewrite of PDUs based on information specific to one or more OSI layers. On the other hand, multilayer switching when referenced by the acronym MLS refers to a specific technology employed by various Cisco devices to perform wire-speed PDU header rewrites. Multilayer switching combines Layer 2 switching, routing, and caching of Layer 4 port information, as shown in Figure 1-10. Multilayer switching provides wire-speed (hardware-based) switching enabled by ASICs within a switch, which share the duties normally assumed by the CPU.

Key Characteristics of Various Switching Technologies

17

Figure 1-10 Multilayer Switching 7 6 5 4 3 2 1 Transport Network Data Link
• Combines Functionality of: • Layer 2 Switching • Layer 3 Routing Functionality • Layer 4 Caching of Port Information • High-Speed Scalability • Low Latency

With MLS, the switch caches information about a given flow of data through the switch, inspecting the PDU header information of the first frame in the flow and switching the remaining data at wire speed based on the information from the first frame (see Figure 1-11). This explains the phrase used with MLS—“route once, switch many.” The figure shows the pertinent Layer 2 and Layer 3 information used as the frame moves from Host A to Host B. MLS stores this information to circumvent the router for subsequent frames in the same flow.
Figure 1-11 “Route Once, Switch Many” Switching Mechanism Provided by MLS

NOTE The term flow loosely describes a stream of data between two endpoints across a network. The flow can be based on Layer 2 and 3 information or a combination of Layer 2, 3, and 4 information.

Fast Ethernet 1/0

int fa 1/0.1 IP Address: 10.1.1.1 MAC Address: 00-00-0C-11-11-11 VLAN: 1 (Black) 1/1

int fa 1/0.2 IP Address: 10.1.2.1 MAC Address: 00-00-0C-22-22-22 VLAN: 2 (Blue)

Host A
2/1

Host B
3/1

Black
VLAN: 1 IP Address: 10.1.1.10 MAC Address: 00-AA-00-11-11-11

Blue
VLAN: 2 IP Address: 10.1.2.20 MAC Address: 00-AA-00-22-22-22

18

Chapter 1: Campus Networks and Design Models

Quality of Service (QoS)
Quality of service (QoS) refers to a network’s capability to provide better service to selected network traffic. QoS maps well to the multilayer campus design. Packet classification is a multilayer service that is applied at the wiring closet switch, the ingress point to the network. Table 1-2 outlines the QoS options available with Cisco IOS software.
Table 1-2 QoS Options Available with Cisco IOS Software

Protocol Group

Protocol

QoS Classification and Marking

Distributed Committed Access Rate (DCAR) Multiprotocol Label Switching (MPLS) EXP bit

QoS Configuration and Monitoring QoS Congestion Avoidance

Network-Based Application Recognition (nBAR) Random Early Detection (RED) Weighted RED (WRED) Distributed WRED (D-WRED) Flow-based WRED

QoS Congestion Avoidance

Low-Latency Queuing (LLQ) Distributed Low Latency Queuing Weighted Fair Queuing (WFQ) Class-Based Weighted Fair Queuing (CBWFQ) First-in, first-out (FIFO) queuing IP RTP priority Priority Queuing (PQ)

QoS Link Efficiency Mechanisms QoS Policing and Shaping

Multilink Point-to-Point Protocol (MLPPP) Committed Access Rate (CAR) CAR rate limiting

QoS Signaling

Resource Reservation Protocol (RSVP)

QoS for voice or video over IP consists of providing minimal packet loss and minimal delay so that voice/video quality is unaffected by conditions in the network. A brute-force solution is to simply provide sufficient bandwidth at all points in the network to minimize packet loss and queuing delay. A better alternative is to apply congestion management and congestion avoidance at oversubscribed points in the network. Most modern Layer 3 and above switches support configuration options for congestion management and congestion avoidance.

Key Characteristics of Various Switching Technologies

19

A reasonable design goal for end-to-end network delay for voice over IP (VoIP) is 150 milliseconds. Providing a separate outbound queue for real-time traffic is sufficient to guarantee low delay for voice at campus speeds. Bursty traffic, such as file transfers, is placed in a different queue from real-time traffic. Low-latency queuing (LLQ) is the preferred method for queuing in this context, giving priority to voice traffic while data traffic is typically governed by weighted fair queuing. Auxiliary VLANs also provide an effective means for optimizing voice traffic in a campus LAN. Another option for achieving low packet loss and high throughput in any queue that experiences bursty data traffic flow is Weighted Random Early Detection (WRED). Note that WRED affects only TCP traffic, so it has no effect on voice traffic, which is UDP-based. QoS plays a significant role in designing a modern switched network. With VoIP and streaming video now commonplace and videoconferencing on the rise, it is important to understand the particular demands of these types of traffic on the network and how to design the switched network to optimally support it.

Multicast
Multicast is becoming an integral part of network design, although it poses one of the greatest challenges to network engineers. Multicast is configured so that one-to-many and many-tomany communication with voice and video take place. Applications such as Cisco IP/TV depend on multicast functionality in the campus network. A good multicast network design is fundamentally important for any enterprise that wants to enjoy the many benefits of multicast technology. If the devices in the network are not specifically configured for multicast, this precludes the possibility of end users receiving multicast streams from multicast servers. In addition, the network might be subject to indiscriminate flooding of multicast traffic in portions of the network, which might result in loss of services. Multicast control is extremely important because of the large amount of traffic involved when several high-bandwidth multicast streams are provided, as illustrated in Figure 1-12. The multilayer campus design is ideal for the control and distribution of IP multicast traffic. Layer 3 multicast control is provided primarily by the Protocol-Independent Multicast (PIM) protocol. Multicast control at the wiring closet is provided by Internet Group Management Protocol (IGMP) and IGMP Snooping or Cisco Group Multicast Protocol (CGMP). At the wiring closet, IGMP Snooping and CGMP (detailed in Chapter 7, “Cisco AVVID”) are multilayer services that prune multicast traffic between switch ports and directly connected routers. Without IGMP Snooping or CGMP, multicast traffic would flood all switch ports. IGMP itself prunes unnecessary multicast traffic on router interfaces connected to client workstations.

20

Chapter 1: Campus Networks and Design Models

Figure 1-12 Multicasting Optimizes Bandwidth Utilization
Example: Audio Streaming All Clients Listening to the Same 8 Kbps Audio

Multicast Unicast

0.8 Traffic Mbps 0.6 0.4 0.2 0 1 20 40 60 Clients
80 100

• Enhanced Efficiency: Controls Network Traffic and Reduced Server and CPU Loads • Optimized Performance: Eliminates Traffic Redundancy • Distributed Applications: Makes Multipoint Applications Possible

In PIM sparse mode (also discussed in Chapter 7), a rendezvous point is used as a broker or proxy for multicast traffic. A design goal of multicast networks is to place the rendezvous point and backup rendezvous point(s) to affect the shortest path. If this is accomplished, there is no potential for suboptimal routing of multicast traffic. Ideally, the rendezvous point and optional backups should be placed on the Layer 3 distribution switch in the server farm close to the multicast sources. If redundant rendezvous points are configured on routers instead of switches, recovery in the case of one rendezvous point going down is more CPU-intensive. In any case, it is critical that network design take into account multicast functionality. The switches should support IGMP Snooping or CGMP, as well as the various PIM modes and Multicast Source Discovery Protocol (MSDP), a relatively new protocol that can, among other things, enhance dynamic rendezvous point selection.

Hierarchical Design Model for Campus Networks
A hierarchical network design includes the following three layers, each of which provides different functionality:
■ ■ ■

The core layer, which provides optimal connectivity between distribution blocks The distribution layer, which provides policy-based connectivity The access layer, which provides access layer aggregation and Layer 3 and Layer 4 services

Figure 1-13 shows a high-level view of the various aspects of a hierarchical network design.

Key Characteristics of Various Switching Technologies

21

Figure 1-13 Hierarchical Design Model: The Core, Distribution, and Access Layers Comprise the Campus Network

Core Layer

Distribution Layer

Access Layer

The Core Layer
The core layer is a high-speed switching backbone and should be designed to switch packets as fast as possible between all distribution layer devices in the campus network. The core layer should not perform any packet manipulation (such as filtering with access lists) that would slow down the switching of packets. It is now common for the core layer to be a pure Layer 3 switched environment, which means that VLANs and VLAN trunks (discussed in Chapter 2, “VLANs and VTP”) are not present in the core. It also means that spanning tree loops (discussed in Chapter 3, “Spanning Tree Protocol (STP)”) are avoided in the core.

The Distribution Layer
The network’s distribution layer divides the access and core layers and helps define and differentiate the core. This layer provides a boundary definition and is where packet manipulation takes place. In the campus environment, the distribution layer can serve several functions:
■ ■ ■

Address or area aggregation Departmental or workgroup access connectivity to the backbone Broadcast/multicast domain definition

22

Chapter 1: Campus Networks and Design Models

■ ■ ■

Inter-VLAN routing Any media transitions that need to occur Security

In the noncampus environment, the distribution layer can be a redistribution point between routing domains or the demarcation between static and dynamic routing protocols. It can also be the point at which remote sites access the corporate network. The distribution layer can be summarized as the layer that provides policy-based connectivity. Packet manipulation, filtering, route summarization, router filtering, route redistribution, inter-VLAN routing, policy routing, and security are some of the primary roles of the distribution layer.

The Access Layer
The access layer is the point at which local end users are allowed into the network. This layer can also use access lists to further optimize the needs of a particular set of users. In the campus environment, access layer functions can include
■ ■ ■ ■

Shared bandwidth Switched bandwidth MAC layer filtering Microsegmentation

In the noncampus environment, the access layer can give remote sites access to the corporate network via wide-area technologies, such as Public Switched Telephone Network (PSTN), Frame Relay, Integrated Services Digital Network (ISDN), digital subscriber line (xDSL), and leased lines. It is often mistakenly thought that the three layers (core, distribution, and access) must exist as clear and distinct physical entities, but this does not have to be the case. The layers are defined to aid successful network design and to represent functionality that must exist in a network. How the layers are implemented depends on the needs of the network being designed. It is important to remember that for a network to function optimally and maintain scalability as growth occurs, hierarchy must be maintained.
Interactive Media Activity Drag and Drop: Hierarchical Design Model for Campus Networks

This activity helps you understand the core, distribution, and access layers.

Building-Block Approach

23

Building-Block Approach
Network building blocks, as shown in Figure 1-14, can be any one of the following fundamental campus elements or contributing variables:

Campus elements: — Switch block — Core block

Contributing variables: — Server block — WAN block — Mainframe block — Internet connectivity

Figure 1-14 Network Building Blocks Enable a Hierarchical Multilayer Campus Network Design Switch Block Building A Building B Building C

Core Block
Token Ring

WAN Block

Mainframe Block

Server Block

24

Chapter 1: Campus Networks and Design Models

The Switch Block
The switch block contains a set of logically grouped switches and associated network devices. This set provides a balance of Layer 2 and Layer 3 services. Although the current generation of LAN switches has replaced bridges and shared-media hubs, LAN switches are not replacements for Layer 3 devices. Therefore, the switch block consists of both switch and router functionality. Layer 2 switches in the wiring closets connect users to the network at the access layer and provide dedicated bandwidth to each port. The access layer devices merge into one or more distribution layer devices. The distribution device provides Layer 2 connectivity between access switches and acts as a central connection point for all the switches in the wiring closets. The distribution layer also provides Layer 3 functionality, which supports routing and networking services. The distribution layer shields the switch block against failures in other parts of the network, as shown in Figure 1-15.
Figure 1-15 The Distribution Layer Switches Prevent Propagation of Network Problems, Such as Broadcast Storms, to Other Switch Blocks Switch Block 1 Access Layer Switch Block 2 Access Layer

Broadcast Storm

Distribution Layer

Distribution Layer

The distribution device can be one of the following:
■ ■

A switch and external router combination A multilayer switch

Building-Block Approach

25

If the switch block experiences a broadcast storm, the router prevents the storm from propagating into the core and across the rest of the network. Of course, this assumes that the Ciscorecommended design using local VLANs is in effect. Each block is protected from the other blocks when failures occur. However, the switch block, in which the broadcast storm occurs, still experiences network problems until the device generating the broadcasts is found and removed from the network. A switch might support one or more subnets. Remember that a subnet must reside within one broadcast domain. This means that all stations residing in or ports configured on the same VLAN are assigned network addresses within the same subnet. The broadcast-isolation feature of VLANs is the characteristic that allows VLANs to be identified with subnets. For example, the IP ARP propagates only within the VLAN of the originating request. All subnets terminate on Layer 3 devices, such as a router or route processor. To connect to devices in other VLANs, the frame must traverse a Layer 3 device. Using this model, VLANs should not extend beyond the distribution switch. Access devices have redundant connections, or uplinks, to the distribution switch to maintain resiliency. STP allows these redundant links to exist while preventing undesirable loops in the switch block. STP terminates at the boundary of the switch block.

Scaling the Switch Block
Although the size of a switch block is flexible, certain factors limit its size. How many switches collapse into the distribution layer depends on several factors:
■ ■ ■ ■ ■

Different types and patterns of traffic Amount of Layer 3 switching capacity at the distribution layer Number of users per access layer switch Extent to which subnets need to traverse geographic locations within the network Size to which the spanning-tree domains should be allowed to grow

Sizing the switch block involves two main factors:
■ ■

Traffic types and behavior Size and number of workgroups

A switch block is too large if

A traffic bottleneck occurs in the routers at the distribution layer because of intensive CPU processing resulting from policy-based filters Broadcast or multicast traffic slows down the switches and routers

26

Chapter 1: Campus Networks and Design Models

Building the Core Block
A core is required when two or more switch blocks exist. The core block is responsible for transferring cross-campus traffic without any processor-intensive operations. All the traffic going to and from the switch blocks, server blocks, the Internet, and the WAN must pass through the core. Traffic going from one switch block to another also must travel through the core. It follows that the core handles much more traffic than any other block. Therefore, the core must be able to pass the traffic to and from the blocks as quickly as possible. Different technologies such as frame, packet, or cell-based technologies can be used in the core, depending on the organization’s specific needs. The examples shown here use an Ethernet core. Because the distribution switch provides Layer 3 functionality, individual subnets connect all distribution and core devices, as shown in Figure 1-16.
Figure 1-16 The Core Layer Switches Prevent Propagation of Network Problems, Such as Broadcast Storms, to Other Switch Blocks

The core can consist of one subnet. However, for resiliency and load balancing, at least two subnets are configured. Because VLANs terminate at the distribution device, core links are not trunk links, and traffic is routed across the core. Therefore, core links do not carry multiple VLANs per link. One or more switches make up a core subnet. It is strongly recommended that a minimum of two devices be present in the core to provide redundancy. The core block can consist of high-speed Layer 2 devices or Layer 3 devices.

Building-Block Approach

27

At a minimum, the media between the distribution switches and the core layer switches should be capable of supporting the amount of load handled by the distribution switch. Also, at a minimum, the links between core switches in the same core subnet should be sufficient to switch the aggregate amount of traffic with respect to the input aggregation switch traffic. The design of the core should consider average link utilization while allowing for future traffic growth. There are two basic core designs:
■ ■

Collapsed core Dual core

Collapsed-Core Design
The collapsed core, shown in Figure 1-17, is characterized by a consolidation of the distribution and core-layer functions into one device. A collapsed-core design is prevalent in small campus networks. Although the functions of each layer are contained in the same device, the functionality remains distinct. In a collapsed-core design, each access layer switch has a redundant link to the distribution layer switch. Each access layer switch might support more than one subnet. However, all subnets terminate at Layer 3 ports on the distribution switch.
Figure 1-17 The Collapsed Core Is Common in Small and Medium Campus Networks Switch Block 1 Access Layer Switch Block 2 Access Layer

Core Connectivity Distribution/Core Layer Distribution/Core Layer

28

Chapter 1: Campus Networks and Design Models

Redundant uplinks provide Layer 2 resiliency between the access and distribution switches. Spanning Tree Protocol blocks the redundant links to prevent loops. Redundancy is provided at Layer 3 by the dual distribution switches with HSRP, providing transparent default gateway operations for IP. If the primary routing process fails, connectivity to the core is maintained.

Dual-Core Design
A dual-core configuration is necessary when two or more switch blocks exist and redundant connections are required. Figure 1-18 shows a dual-core configuration in which the core contains only Layer 2 switches in the backbone.
Figure 1-18 The Dual Core Is Common When the Campus Network Contains Several Switch Blocks Switch Block 1 Access Layer Switch Block 2 Access Layer

Core Connectivity Distribution/Core Layer Distribution/Core Layer

Subnet A

Core Block

Subnet B

A dual-core topology provides two equal-cost paths and twice the bandwidth. Each core switch carries a symmetrical number of subnets to the Layer 3 function of the distribution device. Each switch block is redundantly linked to both core switches, allowing for two distinct, equal path links. If one core device fails, convergence is not an issue, because the routing tables in the distribution devices already have an established route to the remaining core

Building-Block Approach

29

device. The Layer 3 routing protocol provides the link determination across the core, and HSRP provides quick failover determination. Spanning Tree Protocol is not needed in the core because there are no redundant Layer 2 links between the core switches.

Layer 2 and Layer 3 Backbone Scaling
Switched Layer 2 Ethernet cores are very cost-effective, and they provide high-performance connectivity between switch blocks. The classic design model has several switch blocks, each supporting Layer 2 devices in a wiring closet that terminate into a Layer 3 device. A core composed of Layer 2 devices connects the Layer 3 distribution devices. Spanning Tree Protocol represents a practical limit to the scale of a Layer 2 switched backbone. As the number of core devices increases, there is a corresponding increase in the number of links from the distribution switches to maintain redundancy. Because routing protocols dictate the number of equal-cost paths, the number of independent core switches is limited. Interconnecting the core switches creates bridging loops. Introducing Spanning Tree Protocol into the core compromises the high-performance connectivity between switch blocks. Ideally, Layer 2 switched backbones consist of two switches with no spanning-tree loops in the topology. The Layer 2 switched backbone provides redundancy without any spanning-tree loops. Because the two core switches are not linked in Figure 1-19, loops do not occur. Each distribution switch in every switch block has a separate path to each core switch. The dual connection between the core and distribution device provides each Layer 3 device with two equal-cost paths to every other router in the campus.
Figure 1-19 Physical Loops Are Avoided in a Layer 2 Core if the Backbone Switches Are Not Physically Connected

Core Layer

Distribution Layer

VLAN 51 VLAN 52

Access Layer

30

Chapter 1: Campus Networks and Design Models

Note that a Layer 2 switched backbone does not preclude connecting the core switches, as long as Spanning Tree Protocol is carefully configured to logically prevent any loops. The advantage of having the core switches physically connected in a Layer 2 backbone is that failover maintains connectivity between switch blocks when uplinks from distribution switches in independent switch blocks fail. The trade-off is increased complexity in Layer 2 configuration and probably is not worth the trouble. Most of the designs successfully follow the Layer 2/Layer 3/Layer 2 model. However, there are designs where the Layer 2/Layer 3/Layer 3 model is advantageous. Figure 1-20 shows a Layer 3 core.
Figure 1-20 A Layer 3 Core Is Standard in Modern Campus Networks

Implement a Layer 3 core for the following reasons:
■ ■ ■

Fast convergence Automatic load balancing Elimination of peering problems

Fast Convergence
As the number of switch blocks and servers increases, each distribution layer device must be connected to the core. Because there is a limit to the number of switch blocks in a dual Layer 2 core, increasing the number of connections means increasing the number of core devices. To maintain redundancy, the core devices must be connected. Bridging loops appear when you interconnect Layer 2 devices. To eliminate bridging loops in the core, Spanning Tree Protocol must be enabled. Unfortunately, Spanning Tree Protocol has a convergence time of more than 50 seconds. If the network core experiences a fault, Spanning Tree Protocol convergence can disable the core for more than 1 minute.

Building-Block Approach

31

If Layer 3 devices are implemented in the core, Spanning Tree Protocol is unnecessary. In this design, routing protocols are used to maintain the network topology. Convergence for link-state routing protocols takes from 5 to 10 seconds, depending on the routing protocol.

Automatic Load Balancing
Load balancing allows for a traffic-distribution pattern that best uses the multiple links that provide redundancy. With multiple, interconnected Layer 2 devices in the core, the route for using more than one path must be individually selected. The links must then be manually configured to support specific VLAN traffic. With Layer 3 devices in the core, routing protocols can be used to load-balance over multiple equal-cost paths.

Elimination of Peering Problems
Another issue with the Layer 2 core in a very large network is that of router peering. Router peering mandates that the routing protocol running in a router maintain state and reachability information for neighboring routers. In this scenario, each distribution device becomes a peer with every other distribution device in the network. Scalability becomes an issue in the configuration because each distribution device has to maintain state for all other distribution devices. By implementing Layer 3 devices in the core, a hierarchy is created, and the distribution device is not considered a peer with all other distribution devices. This type of core might appear in very large campus networks where the network supports more than 100 switch blocks.

Performance and Cost Issues
Implementing Layer 3 devices in the core can be expensive, although relatively much less so than in the past. As stated earlier, the main purpose of the core is to move packets as quickly and efficiently as possible. Although Layer 3 devices support switching of routed protocols, both performance and equipment costs weigh in heavily as design considerations.

Advantages of the Building-Block Approach
As shown so far, the implementation of a building-block approach and hierarchical model has many advantages, including redundancy, scalability, loop-free topologies, fast convergence, and load balancing. The examples in Figures 1-21, 1-22, and 1-23 illustrate these advantages.

32

Chapter 1: Campus Networks and Design Models

Figure 1-21 A Campus Network Operating Normally North Building M P South Building

M2

M1

P2

P1

A

B

C

D

X

Y

Figure 1-22 Spanning Tree Protocol Provides Redundancy: If One Access Uplink Fails, a Second Uplink Immediately Takes Over North Building M P South Building

M2

M1

P2

P1

A

B

C

D

X

Y

Building-Block Approach

33

Figure 1-23 Failover Takes Place Via Spanning Tree Protocol or Dynamic Routing if an Uplink Between a Distribution Switch and Core Switch Fails, Depending on Whether VLAN Trunks or Routed Links Connect the Distribution and Core Layers North Building M South Building P

M2

M1

P2

P1

A

B

C

D

X

Y

In the sample network, two buildings have an access switch on each floor and redundant connections to a distribution layer switch. Each distribution layer switch has redundant connections into the network core. In Figure 1-21, notice the flow of traffic from host M to host P. Suppose there is a port failure in the access switch. Notice in Figure 1-22 how the switch immediately chooses an alternative path. Assume in Figure 1-23 that the link between the distribution switch and the core switch fails. As shown, the switches choose an alternative path through the core. The following chapters explain how to configure these behaviors on the switch.
Interactive Media Activity Drag and Drop: Advantages of the Building-Block Approach

This activity helps you understand the advantages of the building-block approach.

34

Chapter 1: Campus Networks and Design Models

Small Campus Networks
Small campus networks, as shown in Figure 1-24, are the most common and are typically contained within one building. In this design, it is not unusual to have a single multilayer switch servicing the entire network. In most cases, cost effectiveness is the top priority, not network redundancy. Requirements for this design typically include the following:
■ ■

High performance for applications such as voice, video, and IP multicast Support for applications based on Novell IPX, DECnet, AppleTalk, and Systems Network Architecture (SNA)

Figure 1-24 Small Campus Networks Are the Most Prevalent Type of Network Clients E/FE Attached Access Layer Layer 2 Switching

Server Farm

Backbone and Server Access

Layer 2/3 Switching

Servers FE/GE Attached

A design solution that meets these requirements provides a high-performance, switched infrastructure for a building-sized intranet with hundreds of networked devices. The network backbone consists of a multilayer switch. The access layer switches provide connectivity to clients and servers.

Medium Campus Networks
Medium campus networks, as shown in Figure 1-25, are characterized by a collapsed backbone, where the distribution layer and core layer merge. Medium campus networks are typically contained within one large building or several buildings. In this design, high availability, performance, and manageability are important. Additional requirements for this design typically include the following:

High performance and availability for applications such as voice, video, and IP multicast Support for applications based on Novell IPX, DECnet, AppleTalk, and SNA

Building-Block Approach

35

Figure 1-25 Medium Campus Networks Employ a Collapsed Backbone Clients E/FE Attached

Access Layer

Layer 2 Switching

Backbone and Server Distribution Server Farm

Layer 3 Switching

Layer 2 Switching

Servers FE/GE Attached

The requirements for medium campus networks parallel those of small campus networks. The major differences are the number of users and the importance of building redundancy into medium campus networks. A design solution that meets these requirements provides a high-performance, manageable switched infrastructure for a campus intranet with more than 1000 networked devices. The collapsed backbone uses Layer 3 switching, and network redundancy is provided for clients and servers.

Large Campus Networks
Large campus networks have redundancy, high bandwidth, and well-defined core, distribution, and access layers. As Figure 1-26 illustrates, with typical designs, the buildings or different parts of the campus are connected across a high-performance switched backbone. Network redundancy and high availability are provided at each layer, and a high-capacity centralized server farm provides resources to the campus. Businesses operating large campus networks are increasingly looking for infrastructure upgrades to offer
■ ■ ■

Support for high-bandwidth applications such as voice, video, and IP multicast Support for applications based on Novell IPX, DECnet, AppleTalk, and SNA High availability, performance, and manageability for the company’s intranet

Large campus networks use Layer 2, Layer 3, or ATM backbone solutions to expand the network.

36

Chapter 1: Campus Networks and Design Models

Figure 1-26 Large Campus Networks Can Have Layer 2, Layer 3, or ATM Backbones
Building Access Layer Building Building Catalyst L2 Switch

Distribution Layer

Catalyst L3 Switch

Campus Backbone

Ethernet or ATM Layer 2 or Layer 3

Server Distribution

Catalyst L3 Switch Catalyst L2 Switch Server Farm

Layer 2 Backbone Designs
Layer 2 backbone designs are commonly used when cost-effectiveness and high availability are high priorities. Businesses operating large campus networks are also increasingly looking for infrastructure upgrades to
■ ■ ■

Support high-bandwidth applications based on IP Provide high performance and fast recovery from failures Support applications based on Novell IPX, DECnet, AppleTalk, and SNA

Campus building blocks and server farms connect to the backbone with redundant Gigabit Ethernet, Gigabit EtherChannel, 10 Gigabit Ethernet, or 10 Gigabit EtherChannel trunks. In this design, Catalyst 3550, 4500, and 6500 switches are typically used at the distribution layer and Catalyst 6500 switches at the core layer.

Layer 3 Backbone Designs
Layer 3 backbone designs are commonly used when very high performance is desired for supporting multimedia applications based on IP unicast and multicast. Additional requirements of these designs typically include the following:
■ ■

Nonblocking campus backbone that scales to many Gigabits per second of throughput Broadcast containment

Building-Block Approach

37

■ ■

Very fast deterministic failure recovery campus-wide Support for applications based on Novell IPX, DECnet, AppleTalk, and SNA

This design solution provides a manageable switched infrastructure that scales to a huge campus with many buildings and tens of thousands of networked devices. Buildings connect to a very high-performance, nonblocking Layer 3 switched backbone. Fast failure recovery is achieved campus-wide using a Layer 3 routing protocol such as Enhanced Interior Gateway Routing Protocol (EIGRP), Open Shortest Path First (OSPF), or Intermediate System-to-Intermediate System (IS-IS). One or several high-capacity server farms provide application resources to the campus. The Layer 3 backbone is ideal for multicast traffic because Protocol-Independent Multicast (PIM) runs on the Layer 3 switches in the backbone. PIM routes multicasts efficiently to their destinations along a shortest-path tree, as opposed to the multicast flooding inherent in a Layer 2 switched backbone design. In this design, Catalyst 3550, 4500, and 6500 switches are typically used at the distribution layer; Catalyst 6500 switches are often used at the core layer. Although Catalyst 8500 Campus Switch Routers were often used in the core in the past, they have largely been replaced by Catalyst 6500 switches. All these switches can intelligently distribute a load via routing protocols.

ATM Backbone Designs
ATM backbone designs are typically used for a very large switched campus intranet that demands high performance and availability. Requirements of these designs typically include the following:
■ ■ ■ ■

High performance and very high availability for IP applications Trunking for native real-time voice and video applications Fast deterministic failure recovery for high application availability Support for applications based on Novell IPX, DECnet, AppleTalk, and SNA

The ATM backbone design solution provides a manageable switched infrastructure for a large campus with thousands of networked devices. Buildings are connected across a high-performance ATM switched backbone. IP routing protocols as well as ATM routing with Private Network-to-Network Interface (PNNI) provide network redundancy and high availability. One or more high-capacity server farms provide resources to the campus. In this design, Catalyst 6500 switches and Catalyst 8500 Switch Routers are typically used at the distribution layer; Catalyst 8540 Multiservice Switch Routers are used at the core layer.

38

Chapter 1: Campus Networks and Design Models

Although ATM is still popular in the world of telecommunications, its use as a campus backbone solution is on the decline.

Basic Configuration of the Switch
This section introduces the basic procedures network engineers go through in administering a switched network. These procedures include establishing passwords, password recovery, remote access, and speed and duplex settings.

Cabling the Switch Block
Before switch configuration is begun, physical connectivity between the switch and a workstation must be established. Two types of cable connections are used to manage the switch:

Through the console port—The console port is used to initially configure the switch. The port itself normally does not require configuration. Through the Ethernet port—To access the switch via the Ethernet port, the switch must be assigned an IP address.

As Table 1-3 documents, when connecting the switch’s Ethernet ports to Ethernet-compatible servers, routers, or workstations, use a straight-through unshielded twisted-pair (UTP) cable. When connecting the switch to another switch, you must use a crossover cable.
Table 1-3 Straight-Through and Crossover UTP Connections Used Between Networking Devices, Particularly at the Access Layer

Host Host Switch Router

Switch

Router

Crossover Straight-through Crossover

Straight-through Crossover Straight-through

Crossover Straight-through Crossover

Fiber-optic cable could also be used for these combinations of devices, provided that the devices support fiber-optic connections.

Connecting to the Console Port
Before starting to configure a switch “out of the box,” you need to access the operating system using a console connection from a management terminal. The management terminal is usually a workstation with a terminal emulation program such as HyperTerminal. An RJ-45to-RJ-45 rollover cable is used to connect the workstation from its serial port to the console port of the Cisco switch, as shown in Figure 1-27.

Basic Configuration of the Switch

39

Figure 1-27 Console, or Rollover, Cables Are Used to Configure Catalyst Switches

Console Port (RJ-45)

RJ-45 to RJ-45 Rollover Cable

RJ-45 to DB-9 or RJ-45 to DB-25 Adapter

Laptop Computer

The steps to establish a console connection from a workstation to a switch are as follows: Step 1 Step 2 Connect one end of the supplied rollover cable to the console port. Attach one of the following supplied adapters to a management station or modem:

RJ-45-to-DB-9 female data terminal equipment (DTE) adapter (labeled Terminal) to connect a PC RJ-45-to-DB-25 female DTE adapter (labeled Terminal) to connect a UNIX workstation RJ-45-to-DB-25 male data communications equipment (DCE) adapter (labeled Modem) to connect a modem

Step 3 Step 4

Connect the other end of the supplied rollover cable to the adapter. From the management station, start the terminal emulation program.

40

Chapter 1: Campus Networks and Design Models

Connecting to an Ethernet Port
The Catalyst 2900XL, 2950, 3500XL, 3550, 4000, 4500, 5000, 5500, 6000, and 6500 series switches have ports that can be configured for either 10BASE-T, 100BASE-T, or 1000BASE-T connections. Catalyst 6500 series switches also have module options supporting 10 Gigabit Ethernet. When connecting the switch to servers, workstations, and routers, you must use a straightthrough cable. When connecting to other switches or repeaters, you must use a crossover cable. The port status light emitting diode (LED) illuminates when both the switch and the connected device are powered up. If the LED is not illuminated, it is possible that one of the devices might not be turned on, there might be a problem with the adapter on the attached device or with the cable, or the wrong type of cable might be in use. After setting up the basic IP configuration, you can access the switch through Telnet unless security policy precludes Telnet access. Many applications, such as Tera Term, QVT Term, HyperTerminal, PUTTY (Pretty Useful TTY), SecureCRT, and Secure Shell, include terminal emulation programs that can be used for console access to a Cisco switch. These applications also provide other access options such as Telnet (TCP port 23) and Secure Shell (TCP port 22).

Clearing a Configuration
Cisco routers run Cisco IOS software. The CLI embedded in Cisco IOS software should be familiar to you by now. Some Cisco Catalyst switches such as the 2950 and 3550 series use an IOS-like operating system that is a hybrid OS that evolved from Cisco’s acquisition of Kalpana in 1994. This Catalyst switch OS normally is referred to as command-based or IOS-based. The term command-based comes from the fact that hundreds of commands in various modes are used to configure a variety of technologies. On Cisco Catalyst IOS-based switches, the CLI supports two basic modes of operation that are password-protected and similar to the Cisco routers:
■ ■

User EXEC mode Privileged EXEC mode

No configuration changes are permitted in user EXEC mode. Changes can be entered only in privileged EXEC mode. Privileged EXEC mode functionally equates to router privileged EXEC mode. In privileged mode, configuration files can be viewed, as with a router. Configuration changes can also be made. Also similar to a router, you enter switch privileged mode

Basic Configuration of the Switch

41

using the enable command. Table 1-4 describes the main command modes, how to access each one, the prompt for that mode, and how to exit the mode.
Table 1-4 Catalyst IOS Main Command Modes

Command Mode Access Method Prompt

Exit or Access Next Mode

User EXEC

This is the first level of access. (For the switch) Change terminal settings, perform basic tasks, and list system information.

Switch>

Enter the logout command. To enter privileged EXEC mode, enter the enable command.

Privileged EXEC

From user EXEC mode, enter the enable command.

Switch#

To exit to user EXEC mode, enter the disable command. To enter global configuration mode, enter the configure command.

Global configuration

From privileged EXEC mode, enter the configure command.

Switch(config)#

To exit to privileged EXEC mode, enter the exit or end command, or press Ctrl-Z. To enter interface configuration mode, enter the interface configuration command.

Interface configuration

From global configuration mode, specify an interface by entering the interface command.

Switch(config-if)#

To exit to privileged EXEC mode, enter the end command, or press Ctrl-Z. To exit to global configuration mode, enter the exit command.
continues

42

Chapter 1: Campus Networks and Design Models

Table 1-4 Catalyst IOS Main Command Modes (Continued)

Command Mode Access Method Prompt

Exit or Access Next Mode

Config-vlan

In global configuration mode, enter the vlan vlan-id command.

Switch(config-vlan)#

To exit to global configuration mode, enter the exit command. To return to privileged EXEC mode, enter the end command, or press Ctrl-Z.

VLAN configuration

From privileged EXEC mode, enter the vlan database command. From global configuration mode, specify a line by entering the line command.

Switch(vlan)#

To exit to privileged EXEC mode, enter the exit command. To exit to global configuration mode, enter the exit command. To return to privileged EXEC mode, enter the end command, or press Ctrl-Z.

Line configuration

Switch(config-line)#

Just as with Cisco routers, IOS-based Catalyst switches have a basic and extended configuration dialog that can be used for initial switch setup. A prompt to enter the System Configuration Dialog automatically appears at power-up when no configuration exists in the switch’s nonvolatile RAM (NVRAM). To exit and enter the CLI operating mode, respond “No” to the prompt when you’re asked if you want to continue with the configuration dialog. The switch CLI can be accessed through the console interface or through a Telnet session after an IP address has been assigned. Similar to a router, commands in a switch are additive. This means that adding configuration statements to an existing file doesn’t completely overwrite the existing operating or running configuration. The only way to replace the running configuration with a configuration from NVRAM is to reboot the switch. To clear both the running configuration and startup configuration, enter the erase startupconfig command, and then reboot the switch with the reload command or power-cycle the switch. The configuration can be erased with any of the access methods. If the switch is rebooted during a Telnet session, the connection can be lost because the switch interface is shut down.

Basic Configuration of the Switch

43

On the 2950 and 3550 switches, the erase startup-config command erases the configuration that is stored in NVRAM, but this does not erase the VLAN information. To erase the VLAN information, use the delete flash:vlan.dat command. To ensure absolutely no residual configurations, it is a good idea to erase the startup configuration, VLAN database, and then reboot the switch. See Example 1-1.
Example 1-1 Delete the startup-config File and the vlan.dat File and Reboot to Ensure That There Are No Residual Configurations on a 2950 or 3550 Switch
3550#erase start 3550#erase startup-config Erasing the nvram filesystem will remove all files! Continue? [confirm] [OK] Erase of nvram: complete 3550#dir Directory of flash:/ 2 3 13 5 6 11 12 -rwx drwx -rwx -rwx drwx -rwx -rwx 270 64 856 0 192 264 264 Mar Mar Mar Mar Mar Mar Mar 16 01 01 16 16 16 16 1993 1993 1993 1993 1993 1993 1993 05:58:00 00:00:48 00:01:14 05:58:00 05:55:44 05:55:44 05:55:44 system_env_vars crashinfo vlan.dat env_vars c3550-i5k212q3-mz.121-12c.EA1a info info.ver

16128000 bytes total

(9961984 bytes free)

3550#delete flash:vlan.dat Delete filename [vlan.dat]? Delete flash:vlan.dat? [confirm] 3550#dir Directory of flash:/ 2 3 5 6 11 12 -rwx drwx -rwx drwx -rwx -rwx 270 64 0 192 264 264 Mar Mar Mar Mar Mar Mar 16 01 16 16 16 16 1993 1993 1993 1993 1993 1993 05:58:00 00:00:48 05:58:00 05:55:44 05:55:44 05:55:44 system_env_vars crashinfo env_vars c3550-i5k212q3-mz.121-12c.EA1a info info.ver

continues

44

Chapter 1: Campus Networks and Design Models

Example 1-1 Delete the startup-config File and the vlan.dat File and Reboot to Ensure That There Are No Residual Configurations on a 2950 or 3550 Switch (Continued)
16128000 bytes total 3550#reload (9963520 bytes free)

System configuration has been modified. Save? [yes/no]: no Proceed with reload? [confirm]

As addressed previously, Cisco IOS-based switches use the enable command to access privileged mode, where extensive configuration parameters can be viewed. However, the switch still cannot be configured in this mode. To configure the switch, enter global configuration mode by using the configure command. The configure command puts the switch in global configuration mode, where switch configuration is possible. Configuring the switch through the console port and through Telnet lets you enter commands in real time, but only one at a time. The Cisco IOS-based switch does not immediately store commands in NVRAM. The command copy running-configuration startup-configuration, similar to the Cisco IOS router command, must be used. As with a router, a series of commands can be reversed with a reload command, provided that the running configuration was not saved to NVRAM. Note that VLAN changes made in VLAN database mode (see Chapter 2) cannot be reversed in this way.

Setting a Password
One of the first tasks to perform when configuring a device is to secure it against unauthorized access. The simplest form of security is to limit access to the switches with passwords. Passwords restrict the level of access or completely exclude a user from logging on to a switch. Two types of passwords can be applied to switches:

The login password requires authorization before you access any line, including the console. The enable password requires authentication before you set or change switch parameters.

Cisco also provides levels of authority. A privilege level of 1 gives the user normal EXECmode user privileges. A privilege level of 15 is the level of access permitted by the enable password. To set passwords on a Cisco IOS-based switch, enter either one or both of the following commands in global configuration mode:
Switch(config)#enable password password Switch(config)#enable secret password

Basic Configuration of the Switch

45

The password should at the very least consist of four alphanumeric characters. The difference between the two commands is that the enable secret command encrypts the password, whereas the enable password command displays the password in clear text, as shown in Example 1-2. The service password-encryption global configuration command prevents all configured passwords from being viewed as plain text in the show running-config output.
Example 1-2 The Enable Password and the Enable Secret Password Are Options for Securing Access to Privileged EXEC Mode
3550#show running-config Building configuration...

Current configuration : 1518 bytes

! version 12.1 no service pad service timestamps debut uptime service timestamps log uptime no service password-encryption ! hostname 3550 ! enable secret 5 $1$Eqe9$ThVz.PdVU538SWkvWPVNLO enable password cisco ! ip subnet-zero ! ! spanning-tree extend system-id ! ! ! interface FastEthernet0/1 no ip adress --More--

46

Chapter 1: Campus Networks and Design Models

Naming the Switch
Every switch arrives from the factory with the same default prompt: Switch>. In a large campus network, it is crucial to establish a coherent naming structure for the switches. This is especially true because most network administrators use Telnet to connect to many switches across the campus. To set the host or system name on a Cisco IOS-based switch, enter the following command in global configuration mode:
Switch(config)#hostname name

The name parameter can have from 1 to 255 alphanumeric characters. As soon as the hostname command is entered, the system prompt assumes the host name. To remove the system name (to bring it back to the default configuration), enter the no hostname command in global configuration mode.

Configuring the Switch for Remote Access
For you to perform Layer 3 operations such as Telnet, ping, or remote switch management, the switch must have a valid IP address associated with the management VLAN. Although LAN switches are essentially Layer 2 devices, these switches do maintain an IP stack for administrative purposes. Assigning an IP address to the switch associates that switch with the management VLAN, provided that the subnet portion of the switch IP address matches the subnet number of the management VLAN. To assign an IP address to VLAN 1 on a Cisco IOS-based switch, follow these steps: Step 1 Step 2 Step 3 Enter global configuration mode on the switch. Go to interface VLAN 1 by issuing the following command:
Switch(config)#interface vlan 1

Enter the switch IP address and activate the interface with the following commands:
Switch(config-if)#ip address address mask Switch(config-if)#no shutdown

Step 4

If you’re accessing the switch across a router, you must configure a default gateway on the switch. You can do this in global configuration mode with the following command:
Switch(config)#ip default-gateway address

Layer 3 switches, such as the Catalyst 3550, let you configure IP addresses on any VLAN interface, also known as a switch virtual interface (SVI). So the “management VLAN” on such a device is whichever one the network engineer decides to separate out for that purpose.

Basic Configuration of the Switch

47

Before Cisco IOS Release 12.1, Catalyst 2950 switches had a management command in interface VLAN mode that was used to change the management VLAN to a VLAN other than VLAN 1. VLAN 1 is the default management VLAN. Beginning with Cisco IOS Release 12.1, the management VLAN on a Catalyst 2950 switch is simply determined by configuring an IP address on an alternative VLAN interface, administratively shutting down the VLAN 1 interface, and entering no shutdown on the alternative VLAN interface. A 2950 switch can have only one IP address. Without inter-VLAN routing provided by a router or Layer 3 switch, the IP address of the 2950 switch can be accessed only by nodes connected to ports that belong to the management VLAN. With Step 1 to Step 4 just outlined, a network engineer can Telnet to the switch. Using the additional procedure outlined in the article “Secure Shell Version 1 Support,” at http:// www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t1/ sshv1.htm#1019743, the switch can be configured for Secure Shell (SSH). On the 2950, this requires the strong cryptographic software image (Cisco IOS Release 12.1(12)c or later). On the 3550, the strong cryptographic software image (Cisco IOS Release 12.1(11)EA1 or later) is required. The show interface command displays the device’s IP address and subnet mask. In Example 1-3, the management interface resides in VLAN 1, which is the default management VLAN, and it has a subnet mask of 255.255.255.0.
Example 1-3 Hosts on VLAN 1 Can Telnet to the Switch
2950#configure terminal Enter configuration commands, one per line. 2950(config)#interface vlan 1 2950(config-if)#ip address 10.1.1.1 255.255.255.0 2950(config-if)#no shutdown 2950(config-if)# *Apr *Apr 8 17:31:19: %LINK-3-UPDOWN: Interface VLAN1, changed state to up 8 17:31:20: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, End with CNTL/Z.

changed state to up 2950(config-if)#exit 2950(config)#ip default-gateway 10.1.1.254 2950(config)#show interface fa0/1 Vlan1 is up, line protocol is up Hardware is CPU Interface, address is 0009.430f.a400 (bia 009.430f.a400) Internet address is 10.1.1.1/24 MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

continues

48

Chapter 1: Campus Networks and Design Models

Example 1-3 Hosts on VLAN 1 Can Telnet to the Switch (Continued)
reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set ARP type: ARPA, ARP Timeout 04:00:00 Last input 5w3d, output never, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue :0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 5000 bits/sec, 5 packets/sec 2258699 packets input, 203684534 bytes, 0 no buffer Received 62611 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 16 ignored 11465385 packets output, 2790388760 bytes, 0 underruns 0 output errors, 6 interface requests 0 output buffer failures, 0 output buffers swapped out --More--

To remove the IP address and subnet mask, enter the no ip address command on the VLAN interface. You would do this, for example, if you were changing the management VLAN.
Lab 1.6.1 Catalyst 2950T and 3550 Series Basic Setup

In this lab exercise, you configure a Cisco Catalyst 2950T or 3550 series Ethernet switch for the first time using CLI mode. You complete basic first-time tasks such as configuring a switch name and passwords and assigning an IP address to the Management VLAN for remote management purposes.

Identifying Individual Ports
A description added to an interface or port helps identify specific information about that interface. For example, information could include what access or distribution layer device the interface services. The description command is very useful in an environment where a switch has numerous connections and the administrator needs to check a link to a specific location. This description is meant solely as a comment to help identify how the interface is being used or where it is connected. It could include the floor number or the office number or name. This description appears in the configuration information output.

Basic Configuration of the Switch

49

To add a unique comment to an interface on a Cisco IOS-based switch, enter the following command in interface configuration mode:
Switch(config-if)#description description string

The string might be up to 80 characters, as shown in Example 1-4.
Example 1-4 Standard Operating Procedure Is to Include Descriptions on Switch Ports
3550(config)#interface fa0/1 3550(config-if)#description 3550(config-if)#end 3550# 02:07:26: %SYS-5-CONFIG_I: Configured from console by console 3550#show running-config Building configuration... :Connection to 3rd Floor"

Current configuration : 1584 bytes ! version 12.1 no service pad service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname 3550 ! enable secret 5 $1$Eqe9$ThVz.PdVU538SWkvWPVLNLO enable password cisco ! ip subnet-zero ! ! spanning-tree extend system-id ! ! ! interface FastEthernet0/1 description :Connection to 3rd Floor" --More--

50

Chapter 1: Campus Networks and Design Models

To clear a description, enter the no description command on the interface in interface configuration mode.

Defining Port Speed and Line Mode on a Switch
Setting the port speed and line mode (duplex) are among the most common configuration requirements for a network engineer. It can be frustrating to see messages constantly appear on the console screen, complaining about speed or duplex mismatches. Although autonegotiation is generally supposed to take care of speed configuration, frequently the setting must be hardcoded. You can avoid much frustration by proactively configuring port speed rather than depending on autonegotiation. If the port speed and duplex are hard-coded, connected devices should be configured with the same parameters. The order of configuration for speed and duplex is important:
1. Configure the speed for a port. 2. Follow with the duplex configuration.

Full duplex is the simultaneous action of transmitting and receiving data by two devices. This operation can be achieved only if the devices on each end support full duplex.
NOTE Because the behavior of switch ports on Catalyst switches with respect to speed, duplex, default settings, and autonegotiation is specific to the platform and Cisco IOS release, it is not worth memorizing all the rules governing the behavior. Instead, it is recommended that you consult Cisco.com. For example, see http:// www.cisco.com/ univercd/cc/td/doc/ product/lan/cat2950/ 12114ea1/2950cr/ cli2.htm#1027083 for information on the speed command on 2950 switches running Cisco IOS Release 12.1(14)EA1.

Full-duplex links not only double potential throughput, but also eliminate collisions and the need for each station to wait until the other station finishes transmitting. If reads and writes on a full-duplex link are symmetric, data throughput theoretically can be doubled. However, in reality, bandwidth improvements are more modest. Full-duplex links are particularly useful for server-to-server, server-to-switch, and switch-toswitch connections. The following guidelines can serve as a reference when you configure speed and duplex settings on IOS-based switches:

Gigabit Ethernet ports should always be set to 1000 Mbps, but they can negotiate full duplex with the attached device. To connect to a remote Gigabit Ethernet device that does not autonegotiate, disable autonegotiation on the local device, and set the duplex parameters to be compatible with the other device. Gigabit Ethernet ports that do not match the settings of an attached device lose connectivity and do not generate statistics. To connect to a remote 100BASE-T device that does not autonegotiate, set the duplex setting to full duplex or half duplex, and set the speed setting to autonegotiation. Autonegotiation for the speed setting selects the correct speed even if the attached device does not autonegotiate, but the duplex setting must be explicitly set.

Basic Configuration of the Switch

51

10/100/1000 ports can operate at 10 or 100 Mbps when they are set to half duplex or full duplex, but they operate in full-duplex mode only when set to 1000 Mbps. Gigabit Interface Converter (GBIC) module ports operate at only 1000 Mbps. 100BASE-FX ports operate at only 100 Mbps in full duplex.

■ ■

On a Cisco IOS-based switch, you set the port speed using the speed {10 | 100 | 1000 | auto} command in interface configuration mode. To set an interface’s duplex mode on a Cisco IOS-based switch, enter the duplex {auto | full | half} command in interface configuration mode, as shown in Example 1-5.
Example 1-5 Configure the Speed Setting First, Followed by the Duplex Setting
2950(config)#interface fa0/1 2950(config-if)#speed 100 2950(config-if)# *Apr 8 18:40:08: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down 2950(config-if)# *Apr 8 18:40:09: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up

2950(config-if)# *Apr 8 18:40:013: %LINEPROTO-5-UPDOWN: Line protocol on Interface

FastEthernet0/1, changed state to up 2950(config-if)#duplex full 2950(config-if)# *Apr 8 18:40:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down 2950(config-if)# *Apr 8 18:40:30: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up

2950(config-if)# *Apr 8 18:40:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up 2950(config-if)#end

To view the configuration changes, use the show interface interface-id and show runningconfiguration commands, shown in Examples 1-6 and 1-7.

52

Chapter 1: Campus Networks and Design Models

Example 1-6 The show interface Command Displays the Duplex and Speed Settings
2950(config)#show interface fa0/1 FastEthernet0/1 is up, line protocol is up Hardware is Fast Ethernet, address is 0009.430f.a401 (bia 009.430f.a401) Description: Link to ISP MTU 1500 bytes, BW 100000 Kbit, DLY 1000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s input flow-congrol is off, output flow-control is off ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:19, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue :0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 644584 packets input, 68487493 bytes, 0 no buffer Received 132743 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 122832 multicast, 0 pause input 0 input packets with dribble condition detected 3234255 packets output, 563630304 bytes, 0 underruns --More--

Example 1-7 The show running-config Command with the interface Keyword Provides a Convenient Way to Verify Speed and Duplex Settings
2950#show running-config interface fa0/1 Building configuration...

Current configuration : 124 bytes !

Important IOS Features

53

Example 1-7 The show running-config Command with the interface Keyword Provides a Convenient Way to Verify Speed and Duplex Settings (Continued)
interface FastEthernet0/1 description Link to ISP switchport access vlan 10 no ip address duplex full speed 100 end

Important IOS Features
This section describes further system administration techniques, including command history, password recovery, idle timeouts, verifying connectivity, TFTP transfers, and HTTP access.

Command-Line Recall
When you enter a command on the switch, the command is held in a buffer called the history buffer. On a Cisco IOS-based switch, the history buffer holds the last ten commands by default, like a router does. To access these commands, use the up and down arrows on the keyboard. Use the show history command to see the contents of the history buffer, as shown in Example 1-8.
Example 1-8 The show history Command Displays Previously Entered Commands
Switch#show history enable show running-configuration show interface fastethernet 0/2 show vtp status !! show history Switch#

To change the size of the history buffer, use the terminal history size size command, as shown in Example 1-9.

54

Chapter 1: Campus Networks and Design Models

Example 1-9 The terminal history size Command Conveniently Sets the Number of Commands Stored in the History Buffer
Switch#terminal history size 100 Switch#

Switch#show history enable show running-configuration show interface fastethernet 0/2 show vtp status show history terminal history size 100 show history Switch#

Using the Help Feature
The help command on a Cisco IOS-based switch works the same as that on a router. On a switch, you can access help by entering a question mark (?) on the command line. The switch then prompts you with all the possible choices for the next parameter. If you enter the next parameter followed by ?, the switch displays the next set of command-line choices. In fact, the switch displays help on a parameter-by-parameter basis. Additionally, when the switch displays help options, it ends by displaying the portion of the command entered so far. This lets you append commands to the line without needing to reenter the previous portion of the command. See Example 1-10.
Example 1-10 ? Is Used to View All Subcommands of a Given Command
Switch#? Exec commands: access-enable access-template archive cd clear clock cns configure connect copy Create a temporary Access-List entry Create a temporary Access-List entry manage archive files Change current directory Reset functions Manage the system clock CNS subsystem Enter configuration mode Open a terminal connection Copy from one file to another

Important IOS Features

55

Example 1-10 ? Is Used to View All Subcommands of a Given Command (Continued)
debug delete dir disable disconnect dot1x enable erase exit format fsck help lock login logout mkdir more mrinfo mrm mstat mtrace name-connection no ping pwd rcommand reload rename resume rmdir rsh send setup --More-Debugging functions (see also 'undebug') Delete a file List files on a filesystem Turn off privileged commands Disconnect an existing network connection IEEE 8021.X commands Turn on privileged commands Erase a filesystem Exit from the EXEC Format a filesystem Fsck a filesystem Description of the interactive help system Lock the terminal Log in as a particular user Exit from the EXEC Create a new directory Display the contents of a file Request neighbor and version information from a multicast router IP Multicast Routing Monitor Test Show statistics after multiple multicast traceroutes Trace reverse multicast path from destination to source Name an existing network connection Disable debugging functions Send echo messages Display current working directory Run command on remote switch Halt and perform a cold restart Rename a file Resume and active network connection Remove existing directory Execute a remote command Send a message to other tty lines Run the SETUP command facility

56

Chapter 1: Campus Networks and Design Models

Password Recovery
Each networking device has its own procedure for recovering passwords. For Cisco devices, the procedures are conveniently organized by platform in the document “Password Recovery Procedures” (Document ID: 6130) at http://www.cisco.com/warp/public/474/. As with many security situations, it is extremely important to consider physical security of the equipment. As demonstrated in the password recovery process, an attacker simply needs to be able to reboot the Catalyst switch and access the console to enter privileged mode. When in privileged mode, the attacker can make any changes he or she desires. Keep the wiring closets secured, and minimize access to console ports. The following steps for recovering passwords apply to Catalyst 2950 and 3550 switches. They assume that a console connection is used: Step 1 Step 2 Unplug the power cable. Hold down the MODE button located on the left side of the front panel while reconnecting the power cord to the switch. Release the mode button a second or two after the LED above port 1x is no longer lit. The following instructions appear: The system has been interrupted prior to initializing the Flash file system. The following commands will initiate the Flash file system, and finish loading the operating system software:
flash_init load_helper boot

Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9

Enter flash_init. This initializes the Flash file system. Enter load_helper. This loads and initializes the helper image, which is a minimal IOS image stored in ROM that is typical for disaster recovery. Enter dir flash: (do not forget the colon). This displays a list of files and directories in the Flash file system. Enter rename flash:config.text flash:config.old to rename the configuration file. This is the file that contains the password definition. Enter boot to reboot the system. Enter n (for “no”) at the prompt to bypass the System Configuration dialog. At the normal switch prompt, enter enable to enter privileged mode.

Step 10 Enter rename flash:config.old flash:config.text to rename the configuration file to its original name.

Important IOS Features

57

Step 11 Copy the configuration file, config.text, into the running configuration:
Switch#copy startup-config running-config Destination filename [running-config]? <press ENTER> 1613 bytes copied in 1.316 secs (1613 bytes/sec) Switch#

The configuration is now reloaded. Step 12 Change the password or passwords:
Switch#configure terminal Switch(config)#no enable password Switch(config)#enable secret cisco Switch(config)#^Z

Step 13 Save the running configuration to the configuration file:
Switch#copy running-configuration startup-configuration

This procedure is more complicated than Cisco router password recovery.
Lab 1.6.3 Catalyst 2950T and 3550 Series Password Recovery

In this lab exercise, you recover passwords while retaining configurations for the Catalyst 2950T and 3550 series Ethernet switches.

Setting an Idle Timeout
If a user is logged into a switch and performs no keystrokes or remains idle for 10 minutes, the switch automatically logs the user out. This feature is called idle timeout. If the user doesn’t log out and the terminal is left unattended, this feature prevents someone from gaining unauthorized access to the switch by using the terminal. Although the default setting of this feature is 10 minutes, it can be altered with the exec-timeout line console command:
Switch(config-line)#exec-timeout number of minutes number of seconds

This command works just like the router command. Example 1-11 shows the commands to set the timeout on the console port of a Cisco IOS-based switch to 20 minutes.
Example 1-11 The exec-timeout Command Logs a User Out After the Specified Idle Timeout
Switch(config)#line console 0 Switch(config-line)#exec-timeout 20

Verifying Connectivity
After you assign the switch an IP address and connect at least one switch port to the network and properly configure it, the switch can communicate with other nodes on the network. This communication goes beyond simply switching traffic.

58

Chapter 1: Campus Networks and Design Models

To test connectivity to remote hosts, enter the following command in privileged mode:
Switch#ping destination ip address

The ping command usually returns one of the following responses:

Success rate is 100 percent—This response occurs in 1 to 10 seconds, depending on network traffic and the number of Internet Control Message Protocol (ICMP) packets sent. Destination does not respond—No answer message is returned if the host does not respond. Unknown host—This response occurs if the targeted host does not exist. Destination unreachable—This response occurs if the default gateway cannot reach the specified network. Network or host unreachable—This response occurs if there is no entry in the route table for the host or network.

■ ■

Example 1-12 shows that the destination IP address 172.16.1.1 can be reached by the device generating the ping.
Example 1-12 The ping Command Verifies Layer 3 Connectivity
Switch#ping 172.16.1.1

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms Switch#

Backup and Restoration of a Configuration Using a TFTP Server
Most switches have a Trivial File Transfer Protocol (TFTP) client, allowing configuration files to be sent to and retrieved from a TFTP server. For the switch to obtain the new configuration over the network, after the configuration is cleared, you must configure a valid IP address and default gateway setting. For complete system recovery, make sure that a copy of the configuration file of each switch has been stored somewhere other than on the switch itself. It is a big mistake to have to rebuild the entire configuration file from scratch during a system outage, especially when a backup copy could have easily been created as a backup on a network-accessible machine.

Important IOS Features

59

Through TFTP, a configuration file can be stored on a TFTP server and recovered later when needed. Transferring Cisco IOS-based switch configuration files via TFTP to another device works the same as with a router. The command copy startup-config tftp copies the configuration file to a TFTP server at the location specified by the IP address. The recovery process works in reverse. To recover a configuration file from a TFTP server, issue the command copy tftp running-config. This loads the specified configuration file into the switch’s active memory. When the configuration file is retrieved, it can be written to Macromedia Flash, to the startup configuration (NVRAM), or to the running configuration.
Lab 1.6.2 Catalyst 2950T and 3550 Configuration and IOS Files
CAUTION TFTP servers are inherently weak in security. TFTP uses UDP port 69. It is highly recommended that you not keep your configuration files in a TFTP directory space until you need them. Anyone who compromises the TFTP server can modify the configuration files without approval. A prudent network administrator maintains configuration files in a secure directory space and copies them back to the TFTP directory space only when he or she is ready to use them. Although this adds another step to the recovery process, the security benefits definitely outweigh the procedural disadvantages.

In this lab exercise, you upload and download configuration files and IOS system image files.

HTTP Access to the Switch
The Catalyst Web Interface (CWI), shown in Figure 1-28, is a browser-based tool that can be used to configure Catalyst 4000 family switches running CatOS. Note that each Catalyst platform has its own particular flavor of HTTP access. Communication between the client and server usually occurs on a TCP/IP connection. The TCP/IP port number for HTTP is 80. In this client/server mode, the client (browser) opens a connection to the server (switch) and sends a request. The server receives the request, sends a response to the client, and closes the connection.
Figure 1-28 The Catalyst Web Interface Includes the CiscoView GUI, Which Permits HTTP Configuration of Catalyst 4000 Family Switches Running CatOS

60

Chapter 1: Campus Networks and Design Models

When you log into the switch via HTTP, a dialog box appears and prompts you for the device’s username and password (the default authentication requires a password only). After you provide the correct username and password, the system authenticates the login with the HTTP user authentication method. The system denies access unless the username and password are valid. In the default configuration, verification is enabled for all users of the CWI. The system validates the login password against the enable password. Note that the enable password is sent over the network in clear text. Therefore, the CWI is not a tool that should be used in a nonsecure environment. To access the switch using HTTP, enter the switch IP address in the browser’s Location field (Netscape) or Address field (Microsoft Internet Explorer), and then enter the switch password when prompted. An opening screen with various options appears. Click the Web Console option to enter the mode that lets switch configurations be made. Similar to CWI for 4000 family switches running CatOS, the Cisco Cluster Management Suite (CMS) software is web-based network management software embedded in Cisco Catalyst 2900XL, 2950, 3500XL, and 3550 switches. Also note that many Cisco vulnerabilities have been identified with the HTTP server functionality on Catalyst switches.
Lab 1.6.4 Introduction to Fluke Network Inspector

In this lab exercise, you learn how to use the Network Inspector (NI) from Fluke Networks to discover and analyze network devices in a broadcast domain.

Lab 1.6.5 Introduction to Fluke Protocol Expert

In this lab exercise, you learn how to use the Fluke Networks Optiview Protocol Expert (PE) to analyze network traffic and troubleshoot switched networks.

Summary
After completing this chapter, you should understand the following:

Broadcasts are useful and necessary traffic. However, too much broadcast traffic can cause network performance problems. Managing broadcast traffic is a critical aspect of campus LAN design. The location of common workgroups and servers can have a significant impact on traffic patterns.

Summary

61

Adding bandwidth is not necessarily the long-term solution to meeting the needs of high-priority traffic. Multilayer switching combines Layer 2 switching and Layer 3 routing functionality and caching of Layer 4 port information. The multilayer design model is inherently scalable. Layer 3 switching performance scales because it is distributed. Backbone performance scales as you add more links or switches. A switch block is the unit that contains distributed network services and network intelligence. A switch block consists of Layer 2 switches, Layer 3 switches, and sometimes distributed servers. A core block is the unit that transfers cross-campus traffic. It can consist of Layer 2 or Layer 3 devices. The purpose of network link redundancy is to provide alternative physical pathways through the network in case one pathway fails. How to make initial connections to the switch, connecting to the console port and an Ethernet port. Basic configuration of the switch includes — Clearing a configuration — Setting a password — Naming the switch — Configuring the switch for remote access — Identifying individual ports — Defining link speed and line mode on a switch

Important IOS features include — Command-line recall — Using the help feature — Password recovery — Verifying connectivity — Saving the configuration — Backup and restoration of a configuration using a TFTP server

62

Chapter 1: Campus Networks and Design Models

Key Terms
Application-Specific Integrated Circuit (ASIC) A chip designed for a particular application (as opposed to the integrated circuits that control functions such as RAM). broadcast domain The set of all devices that receive broadcast frames originating from any device in the set. Broadcast domains are typically bounded by routers because routers do not forward broadcast frames. Cisco Group Management Protocol (CGMP) A Cisco-developed protocol that runs between Cisco routers and Catalyst switches to leverage IGMP information on Cisco routers to make Layer 2 forwarding decisions on Catalyst switch ports that are attached to interested receivers. collision domain In Ethernet, the network area within which frames that have collided are propagated. Repeaters and hubs propagate collisions; LAN switches, bridges, and routers do not. flow A unidirectional sequence of packets between a particular source and destination that share the same Layer 3 and Layer 4 information. Hot Standby Router Protocol (HSRP) Provides high network availability and transparent network topology changes. HSRP creates a hot standby router group with a lead router that services all packets sent to the hot standby address. The lead router is monitored by other routers in the group, and if it fails, one of these standby routers inherits the lead position and the hot standby group address. Internet Control Message Protocol (ICMP) A network layer Internet protocol that reports errors and provides other information relevant to IP packet processing. Documented in RFC 792. Internet Group Management Protocol (IGMP) Used by IP hosts to report their multicast group memberships to an adjacent multicast router. nonblocking The ability to switch a packet immediately without encountering a busy condition. Spanning Tree Protocol (STP) A bridge protocol that uses the spanning-tree algorithm, allowing a learning bridge to dynamically work around loops in a network topology by creating a spanning tree. Bridges exchange Bridge Protocol Data Unit (BPDU) messages with other bridges to detect loops and then remove the loops by shutting down selected bridge interfaces. STP refers to both the IEEE 802.1 Spanning Tree Protocol standard and the earlier Digital Equipment Corporation Spanning Tree Protocol on which it is based. The IEEE version supports bridge domains and allows the bridge to construct a loop-free topology across an extended LAN. The IEEE version is generally preferred over the Digital version.

Check Your Understanding

63

VLAN Trunking Protocol (VTP) A Cisco-proprietary protocol that uses Layer 2 trunk frames to communicate VLAN information among a group of switches and to manage the addition, deletion, and renaming of VLANs across the network from a central point of control.

Check Your Understanding
Use the following review questions to test your understanding of the concepts covered in this chapter. Answers are listed in Appendix A, “Check Your Understanding Answer Key.”
1. Which of the following are key requirements in a modern campus network? A. Redundancy B. Scalability C. 80/20 rule D. Multicasting 2. Which of the following is not a category of service in a campus network? A. Local B. Geographic C. Remote D. Enterprise 3. Which of the following layers typically involve Layer 3 switching? A. Access B. Distribution C. Session D. Core 4. What layer is the point at which end users are allowed into the network? A. Access B. Distribution C. Session D. Core

64

Chapter 1: Campus Networks and Design Models

5. Which of the following are backbone campus network solutions? A. Layer 2 switching B. Layer 3 switching C. Layer 4 switching D. ATM 6. What type of cable is used to configure Catalyst 2950 switches through a console

connection?
A. Coaxial B. Straight-through C. Crossover D. Rollover 7. What type of UTP cable can be used to connect FastEthernet ports on two Catalyst

3550 switches?
A. Coaxial B. Straight-through C. Crossover D. Rollover 8. What two commands are used to restore a Catalyst 3550 switch to a default

configuration?
A. delete startup-config B. erase startup-config C. delete vlan.dat D. erase vlan.dat 9. Which of the following commands are used with password recovery on a Catalyst 2950

switch?
A. flash_init B. load_helper C. rename D. boot

Check Your Understanding

65

10. What command is used to set the port speed to 100 on a Catalyst 3550 10/100 interface? A. set speed B. speed C. bandwidth D. set bandwidth

Objectives
After completing this chapter, you will be able to perform tasks related to the following:

Understand and explain the role of virtual LANs (VLANs) and VLAN protocols in modern campus networks. Know the definitions and understand the various ways in which VLANs are categorized. Configure VLANs. Describe situations in which VLANs are appropriate. Explain reasons not to use VLANs. Understand VLAN Membership Policy Server (VMPS). Understand and configure Dynamic Trunking Protocol (DTP). Understand and configure VLAN Trunking Protocol (VTP).

■ ■ ■ ■ ■ ■ ■

Chapter 2 VLANs and VTP
Promotion of virtual LANs (VLANs) in the 1990s by the trade journals and the workforce created confusion. Authors used different and inconsistent interpretations of the new network terminology. Vendors also took varied approaches to creating VLANs, which led to further confusion. VLAN designs have changed over the last decade as a result of advances in technology. In the mid-1990s, deployment of campus-wide VLANs was acknowledged as the best design methodology. Local or geographic VLANs are now considered the better design methodology, because VLANs are separated by geographic location and not by function. The speed of Layer 2 switching influenced campus-wide VLAN design. Multilayer switches can perform Layer 3 switching at rates approximating that of Layer 2 switching. Hardware-based Layer 3 switching provided speeds of hundreds of millions of packets per second (pps). Although campus-wide VLANs play a role in special circumstances, designing a stable, scalable campus network has become more important. The CPU-intensive Spanning Tree Protocol (STP) essential to campus-wide VLANs causes convergence and redundancy problems in some large networks, making them susceptible to network instabilities. With the widespread adoption of high-performance Layer 3 switches, the campuswide model has become obsolete and is no longer recommended in most network designs. With a local VLAN model, Layer 3 switching allows the users’ traffic to be carried based on the network layer address, such as the IP address. VLANs then become a simple mechanism of segmenting an IP subnet at Layer 2. For example, the 172.16.10.0/24 subnet is mapped to VLAN 10, the 172.16.20.0/24 subnet is mapped to VLAN 20, and so forth. A critical tenet of campus design declares that user VLANs terminate at a Layer 3 switch, which is typically located in a data center or basement of a building.

68

Chapter 2: VLANs and VTP

In this chapter, you learn how to do the following:
■ ■ ■ ■ ■ ■

Clarify the role of VLANs and VLAN protocols in modern campus networks. Present definitions and categorizations for VLANs. Explain how to configure VLANs. Describe situations in which VLANs are appropriate. Clarify misinformation about VLANs. Introduce VLAN management tools such as VLAN Trunking Protocol (VTP).

VLAN Basics
VLANs are pervasive in multilayer switched networks. This section introduces VLANs, the motivation for their use, and how they relate to security, broadcast domains, bandwidth utilization, and router latency.

Describe a VLAN
A VLAN is a logical construct that includes a group of hosts with a common set of requirements that communicate as if they were attached to the same wire, regardless of their physical location. A VLAN has the same attributes as a physical LAN, but it allows end stations to be grouped even if they are not located on the same physical LAN segment. Networks that use the campus-wide or end-to-end VLANs logically segment a switched network based on an organization’s functions, project teams, or applications, as shown in Figure 2-1, rather than on a physical or geographic basis. For example, all workstations and servers used by a particular workgroup can be connected to the same VLAN, regardless of their physical network connections or interaction with other workgroups. Network reconfiguration can be done through software instead of physically relocating devices. Cisco recommends the use of local or geographic VLANs that segment the network based on Internet Protocol (IP) subnets. In Figure 2-2, each wiring closet switch is on its own VLAN or subnet, and traffic between each switch is routed by the router (except for the users in VLAN 10 on distinct access layer switches). The examples shown in Figures 2-1 and 2-2 do not show the entire network model. The reasons for the Layer 3 switch and examples of a larger network using both the campus-wide and local VLAN models are discussed in the later section “VLAN Types.” VLAN member hosts are often dedicated to an access layer switch or a cluster of access layer switches.

VLAN Basics

69

Figure 2-1 Campus-Wide or End-to-End VLANs Can Span the Entire Campus Network and Are Not Limited by Geography
Accounting Engineering VLAN 10 VLAN 20 172.16.10.0/24 172.16.20.0/24 Accounting VLAN 10 172.16.10.0/24 Accounting Engineering VLAN 10 VLAN 20 172.16.10.0/24 172.16.20.0/24 Sales VLAN 30 172.16.30.0/24

Gigabit Uplinks VLAN Trunk

Figure 2-2 Local VLANs Based on Physical Location, in One-to-One Correspondence with IP Subnets, Are Now the Norm
Accounting Engineering VLAN 10 VLAN 20 172.16.10.0/24 172.16.20.0/24 Accounting VLAN 10 172.16.10.0/24 Accounting Engineering VLAN 30 VLAN 40 172.16.30.0/24 172.16.40.0/24 Sales VLAN 50 172.16.50.0/24

Gigabit Uplinks
172.16.100.0/24

A VLAN can be thought of as a broadcast domain that exists within a defined set of switches. Ports on a switch can be grouped into VLANs to limit unicast, multicast, and broadcast traffic flooding. Flooded traffic originating from a particular VLAN is flooded only out ports belonging to that VLAN, including trunk ports (assuming that the trunk ports are configured to carry that VLAN traffic). Any switch port can belong to a VLAN. Unicast, broadcast, and multicast packets are forwarded and flooded only to stations in the same VLAN. Each VLAN is a logical network, and packets destined for stations that do not belong to the same VLAN must be forwarded through a router or routing device. Each VLAN can also run a separate instance of STP. The technology that allows Cisco switches to support an independent implementation of STP for each VLAN is called Per-VLAN Spanning Tree (PVST).

70

Chapter 2: VLANs and VTP

VLANs are created to provide flexibility and the segmentation services traditionally provided by routers in LAN configurations. VLANs address scalability, security, and network management issues. Routers in VLAN topologies provide broadcast filtering, security, address summarization, and traffic flow management. By definition, switches cannot bridge IP traffic between VLANs because doing so would violate the integrity of the VLAN broadcast domain (although you can force the issue using Integrated Routing and Bridging). Normally, IP traffic is routed between VLANs. VLANs are essentially Layer 2 constructs, and IP subnets are Layer 3 constructs. In a campus LAN employing VLANs, a one-to-one relationship often exists between VLANs and IP subnets. It is possible to have multiple subnets on one VLAN, and in some cases one subnet might be spread across multiple VLANs. Such cases are the exception, however, not the rule. VLANs and IP subnets provide an example of independent Layer 2 and Layer 3 constructs that normally map to one another. This correspondence is useful during the network design process. Network designers must consider several key issues when designing and building scalable multilayer switched internetworks. These issues are examined in the section “VLAN Types.”

Motivation for VLANs
In a legacy network, administrators assign users to networks based on geography. The administrator attaches the user’s workstation to the nearest network cable. If the user belongs to the engineering department and sits next to someone from the accounting department, they both belong to the same network because they attach to the same segment. Topologies such as this create interesting network issues and highlight some of the reasons for using VLANs. For example, the engineering group might require access to simulation and modeling programs that consume a lot of bandwidth, preventing the accountants from accessing relatively small spreadsheet documents. VLANs help resolve many of the problems associated with legacy network designs. With VLANs, network managers can logically group networks that span all major topologies. This includes high-speed technologies such as
■ ■ ■ ■

ATM Fast Ethernet Gigabit Ethernet 10 Gigabit Ethernet

By creating VLANs, system and network administrators can control traffic patterns, react quickly to relocations, and keep up with constant changes in the network caused by moving requirements and node relocation. VLANs provide the flexibility to carry out these actions. The network administrator simply changes the VLAN member list in the switch configuration.

VLAN Basics

71

The administrator can add, remove, or move devices or make other changes to the network configuration using software. In addition to simplified administration, VLANs are also implemented for their increased security and their capability to contain broadcasts.

VLANs and Network Security
Almost everything in networking has a connection to security. With VLAN technology, security is essentially a side effect. With the exception of the private VLANs that are available on Catalyst 4000 and 6000 family switches, security was not originally a motivating factor for the creation of VLANs. The shared-media nature of legacy networks is a security issue. Whenever a station transmits in a shared network, such as a legacy half-duplex 10BASE-T system, all stations attached to the segment receive a copy of the frame, even if they are not the intended recipients. This does not prevent the network from functioning, but readily available software packages that monitor network traffic make it possible for anyone to capture passwords, sensitive e-mail, and any other unencrypted traffic on the network. If the users on the network belong to the same department, this might not be disastrous, but when users from mixed departments share a segment, sensitive information can be compromised. For example, if someone from human resources or accounting sends sensitive data such as salaries, stock options, or health records on the shared network, anyone with a network-monitoring tool on that LAN can intercept the information. In fact, these problems are not constrained to a single LAN segment. They can occur in multisegment environments interconnected with routers. If the accounting department resides on two isolated segments, packets from one segment must cross the engineering network to reach the other accounting segment, as shown in Figure 2-3. When they cross the engineering segment, it is possible for that information to be intercepted and misused if someone has physical access to the switch on the engineering segment.
Figure 2-3 Traffic Can Be Intercepted When Hosts Reside on Intermediary Segments Accounting Accounting

Engineering

72

Chapter 2: VLANs and VTP

One way to eliminate the problem is to move all accounting users onto the same segment, but that might not be possible. Space limitations might prevent all accountants from sharing a common part of the building. Another reason might be the company’s geographic makeup. Users on one segment might be a considerable distance from users on the other segment. In most cases, assuming physical security of a switch and password-protected remote access, the issue of intercepting data because of shared-media technology should not be a problem. Virtually all hosts in modern networks reside on switched ports, so unicast data normally is not visible to any hosts except the sender and receiver. However, some applications can redirect data in a switched network to a single host. Without physical access to the switches, it should not be possible to intercept data in a switched environment, but a comprehensive security policy should take this possibility into account, especially if the LAN carries sensitive data. Another approach to securing intersubnet traffic (as shown in Figure 2-3) is through the use of VLANs. VLANs add an additional layer of isolation between hosts and, therefore, make it much more difficult for data to be intercepted. All process-related users can be contained in the same broadcast domain and isolated from users in other broadcast domains. All the accounting users can be assigned to the same VLAN, regardless of their physical location in the facility. In fact, all the users can be assigned to VLANs based on their job function. For example, all the accounting users could go on one VLAN, the marketing users on another VLAN, and engineering on a third. When VLANs are implemented with switched network devices, another level of protection is added to the network. Switches bridge traffic within a VLAN. When a station transmits, the frame goes to the intended destination. As long as it is a known unicast frame, the switch does not distribute the frame to all users in the VLAN. Station A transmits a frame to Station B, attached to another switch, as shown in Figure 2-4. Although the frame crosses through a switch, only the destination receives a copy of the frame. The switch does not send the frame to the other stations, whether they belong to a different VLAN or the same VLAN. Assuming that physical access to the switches is not possible, this switch feature limits the opportunity for packets to be captured with a network analyzer. Hosts on different VLANs cannot communicate with each other unless the network is explicitly configured to allow it. If the network has a one-to-one mapping between IP subnets and VLANs, hosts on different VLANs must communicate through IP routing. In this case, access control lists (ACLs) can filter traffic between VLANs. It is possible to configure VLANs without inter-VLAN routing among user VLANs, but this is rarely done.

VLAN Basics

73

Figure 2-4 Normally, Unicast Traffic Cannot Be Intercepted by a Host Connected to the Same Switch as Unicast Traffic Traversing the Same Switch

A

B

Another case where VLANs play a definitive role in network security is the capability to configure ACLs on switches. This is discussed in the section “Understanding Switch ACLs” and in Chapter 9, “Monitoring and Security.” Although these security methods might seem excessive, in the corporate network they are crucial. Consider the data transferred within a company’s accounting department. This department has salary information, stock option information, personal information, and other sensitive and personal material. It is very important to protect the users’ privacy and the data’s integrity. VLANs greatly assist in this endeavor.

VLANs and Broadcast Distribution
Practically every network protocol creates broadcast traffic. AppleTalk hosts, Microsoft hosts, and Novell servers create broadcasts to announce or request services. Furthermore, multimedia applications create broadcast and multicast frames that are distributed across the broadcast domain. Broadcasts are necessary to support protocol operations and, therefore, are acceptable overhead in the network. So why do network administrators dislike broadcast traffic? Broadcasts go to all devices in the broadcast domain and must be processed by the receiving devices. With the exception of multimedia-based traffic, broadcast frames rarely transport user data. Because switches flood broadcasts, they consume bandwidth in the LAN, resulting in a reduction of the bandwidth for productive traffic. Broadcasts also have a profound effect on the performance of workstations. Any broadcast received by a workstation interrupts the CPU and prevents it from working on user applications. As the number of broadcasts per second increases at the interface, effective CPU utilization diminishes. The actual level of degradation depends on the applications running in the workstation, the type of network interface card and drivers, the operating system, and the workstation platform.

74

Chapter 2: VLANs and VTP

VLANs form broadcast domains. Broadcasts and multicasts are not propagated between VLANs unless the intermediary network devices are specifically configured to do so (see Figure 2-5). If broadcasts and multicasts are creating problems in the network, creating smaller broadcast domains can mitigate the negative effects. This means creating additional VLANs and attaching fewer devices to each one. The effectiveness of this action depends on the source of the broadcast. If a local server is sending broadcast traffic, that server should be isolated in another broadcast domain. If the broadcasts and multicasts come from end stations, creating additional VLANs helps reduce the number of broadcasts in each domain.
Figure 2-5 Broadcasts Originating in a VLAN Do Not Propagate Beyond That VLAN’s Boundary

Broadcast Domain 2 VLAN 20 172.16.20.0/24 Broadcast Domain 1 VLAN 10 172.16.10.0/24

VLANs and Bandwidth Utilization
When users attach to the same shared segment, they all share the segment’s bandwidth. With every additional user on the shared medium, less bandwidth is available for each user. User network and application performance begin to diminish if the bandwidth sharing becomes too great. The network administrator needs to take action because the users will be less productive. VLANs can offer more bandwidth to users than is inherent in a shared network; VLANs do this by limiting the size of each broadcast domain. Remember that each interface on a switch behaves like a port on a legacy bridge. Bridges filter traffic for the source segment. If a frame needs to cross the bridge, the bridge forwards the frame to the correct interface. If the bridge or switch does not know the destination port, it floods the frame to all ports in the broadcast domain (VLAN) except the source port. By assigning ports on a switch to different VLANs, you can limit the number of switch ports to which data traffic is flooded.

VLAN Basics

75

In a switched environment, a station usually sees only traffic destined specifically for it. The switch filters most of the other background traffic in the network, which allows the workstation to have full, dedicated bandwidth for sending or receiving traffic. Unlike a shared-hub system, in which only one station can transmit at a time, a switched network allows many concurrent transmissions within a broadcast domain without directly affecting other stations inside or outside the broadcast domain. In Figure 2-6, station pairs A/B, C/D, and E/F can all communicate without affecting the other station pairs.
Figure 2-6 Internal Switched Virtual Circuits Permit Simultaneous Transmissions Between Pairs of Hosts E F

A

C

B

D

VLANs Versus Router Latency
In a traditional routed network, packets going between networks have to be routed by a router. Every router that handles the data increases the end-to-end latency. Latency constitutes the amount of time necessary to transport a frame from the source port to the destination port. The latency could be reduced by replacing the routers with Layer 2 switches, but the network would then become a single broadcast domain and lose other advantages of Layer 3 segmentation such as security management and traffic filtering. VLANs have the advantages of the decreased latency of Layer 2 switching and the segmentation of Layer 3 routing. Campus-wide VLANs were once the answer to Layer 3 latency, but they introduced their own complexities into the network. Campus-wide VLANs are still appropriate in some circumstances; however, Cisco recommends designing networks using the local VLAN model. The local VLAN model has VLANs dedicated to each access layer switch cluster, with Layer 3 switching between wiring closets performed at the distribution layer or Main Distribution Facility (MDF). As illustrated in Figure 2-7, inter-VLAN routing is provided by Layer 3 switches, which are connected by IP subnets instead of the traditional VLAN trunks. With both the local VLAN and campus-wide VLAN model, VLANs have many advantages over traditional switched networks, including segmentation of broadcast domains.

76

Chapter 2: VLANs and VTP

Figure 2-7 VLANs in Modern Campus Networks Are Local to Access Layer Switches
Accounting Engineering 172.16.10.0/24 172.16.20.0/24 Accounting 172.16.30.0/24 Accounting Engineering 172.16.40.0/24 172.16.50.0/24 Sales 172.16.60.0/24

172.16.100.0/24

In modern campus operations, Layer 3 latency issues become rare as a result of multilayer switching (MLS). MLS enables hardware-based routing. In Cisco switches that support MLS, the router routes the first packet in software, and the switch handles subsequent packets in hardware. Newer Cisco switches, such as the Catalyst 3550 and 6500, use Cisco Express Forwarding (CEF). CEF uses a method of communicating information between the routing table and CEF tables that allows packets to be forwarded by the switches without routing table lookups. Chapter 5, “Multilayer Switching,” discusses MLS and CEF in more detail.

Wrong Motives for Implementing VLANs
The advent of VLANs led many to believe that a network administrator’s life would be simplified, which was to be a welcome relief. Many network administrators believed that VLANs would eliminate, to some extent, the need for routers. They also believed that because campuswide VLANs place all users in one large flat network, many long hours of network administration would be eliminated. This turned out to be far from the truth and, unfortunately, enthusiasm quickly met reality. VLANs do not eliminate Layer 3 issues. They might ease some Layer 3 tasks, such as enabling the use of simpler access lists, but routing is still a necessity. Last, contrary to expectations, network monitoring is more challenging with a VLAN-based network than with a traditional routed network, because VLANs permit much more complex logical designs.

VLAN Security
Network security is becoming more pervasive in network design. VLAN implementation must be factored into the network security policy. This section explores the relationship between VLANs and network security.

VLAN Security

77

Overview
Routers allow administrators to introduce policies that control the flow of traffic in the network. ACLs control traffic flow and provide varied degrees of policy granularity. ACLs can prevent a specific user from communicating with another user or network, or they can prevent an entire network from accessing a user or network. ACLs are sometimes implemented for security reasons, and they are also used to prevent traffic from flowing through a segment to protect local bandwidth. In any case, the management of ACLs can be quite cumbersome. ACLs in a production network should be based on the organization’s business and security needs. To safeguard the accounting department’s data, filters in the routers attached to the engineering segment can include ACLs, allowing the accounting traffic to pass through the engineering segment, but never talk to any engineering devices (see Figure 2-8). That does not prevent engineers from monitoring the traffic (using Catalyst Switched Port Analyzer [SPAN] technology, for example), but it does prevent explicit communication between the engineering and accounting devices. Accounting does not see the engineering traffic, but engineering can see all the accounting transit traffic using Catalyst SPAN technology, introduced in Chapter 9.
Figure 2-8 ACLs Can Prevent Accounting Data from Being Transferred to the Engineering Department Accounting Accounting

Engineering

Switches traditionally operate at Layer 2 only, switching traffic within a VLAN, whereas routers route traffic between VLANs. The Catalyst 3550 switch with the Enhanced Multilayer Image (EMI) installed and the Catalyst 6500 switches with the Supervisor Engine 720 can

78

Chapter 2: VLANs and VTP

accelerate packet routing between VLANs by using Layer 3 switching. The process of routing traffic between VLANs is as follows:
1. The switch bridges the packet. 2. The packet is routed internally without going to an external router. 3. The packet is bridged again to send it to its destination.

During this process, the switch can enforce ACLs on all packets it switches, including packets bridged within a VLAN. Layer 3 switching uses the traditional combination of external router and Layer 2 switch, also known as “router-on-a-stick,” into a single device. ACLs can be configured on a Layer 3 switch to provide basic security and traffic management for the network.

Understanding Switch ACLs
Packet filtering can help limit network traffic and restrict network use by certain users or devices. ACLs can filter traffic as it passes through a router and permit or deny packets from crossing specified interfaces. An ACL contains an ordered list of access control entries (ACEs), also called access control entities. Each ACE specifies permit or deny and a set of conditions the packet must satisfy to match the ACE. The meaning of permit or deny depends on the context in which the ACL is used. ACLs on switches function very much like those on a router. When a frame is received on an interface, the switch compares the fields in the frame against any applied ACLs to verify that it should be forwarded, based on the criteria specified in the ACLs. It tests frames against the conditions in an ACL one by one. The first match determines whether the switch accepts or rejects the packets. Because the switch stops testing conditions after the first match, the order of conditions in the list is critical. If no conditions match, the switch rejects the packets. If a switch is not configured with ACLs, all packets passing it are allowed onto all parts of the network. ACLs can be used to control which hosts can access different parts of a network or to decide which types of traffic are forwarded or blocked at router interfaces. For example, a Layer 3 switch can be configured to allow e-mail traffic to be forwarded but not Telnet traffic. ACLs can be configured to block inbound traffic, outbound traffic, or both. The Catalyst 3550 and 6500 switches support two types of ACLs:

IP ACLs filter IP traffic, including Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Internet Group Management Protocol (IGMP), and Internet Control Message Protocol (ICMP). Ethernet ACLs filter non-IP traffic.

VLAN Security

79

Catalyst 6500 switches also support Internetwork Packet Exchange (IPX) ACLs. The 2950 switch with the enhanced image supports only IP ACLs. Catalyst 3550 and 6500 switches support two applications of ACLs to filter traffic:
■ ■

Router ACLs VLAN ACLs

Catalyst 3550 and 6500 switches also support quality of service (QoS) ACLs, which are used to implement QoS features. Router ACLs filter routed traffic between VLANs. For a Catalyst 3550 to filter packets routed between VLANs, it must be running EMI. VLAN ACLs, also called VLAN maps, filter both bridged and routed packets. VLAN maps can be used to filter packets exchanged between devices in the same VLAN. Unlike router ACLs, a switch does not need to run EMI software to use VLAN maps. VLAN maps are configured to provide access control based on Layer 3 IP addresses. Frames for non-IP protocols can be filtered based on their Media Access Control (MAC) addresses, using Ethernet ACEs. An ACE is a single line in an ACL. When a VLAN map is applied to a VLAN, all packets (routed or bridged) entering the VLAN are checked against the VLAN map. Packets can enter the VLAN either through a switch port or through a routed port.

Router ACLs and VLAN Maps
Router ACLs are applied to switch virtual interfaces (SVIs), which are Layer 3 VLAN interfaces. Router ACLs are also applied to physical Layer 3 interfaces and to Layer 3 EtherChannel interfaces. Router ACLs are applied on interfaces as either inbound or outbound. One ACL can be used with multiple features for a given interface, and one feature can use multiple ACLs. When a single router ACL is used by multiple features, such as for QoS and security, it is examined multiple times. Standard IP access lists use source addresses for matching operations. Extended IP access lists use source and destination addresses and optional protocol type information for matching operations. The switch examines ACLs associated with features configured on a given interface with a specific direction. As packets enter the switch on an interface, ACLs associated with all inbound features configured on that interface are examined. After packets are routed and before they are forwarded out to the next hop, all ACLs associated with outbound features configured on the egress interface are examined.

80

Chapter 2: VLANs and VTP

ACLs permit or deny packet forwarding based on how the packet matches the entries in the ACL. For example, ACLs can be used to allow one host to access part of a network but prevent another host from accessing the same part. In Figure 2-9, ACLs applied at the router input allow Host A to access the Human Resources network but prevent Host B from accessing the same network.
Figure 2-9 Router ACLs Are Applied to Switch Virtual Interfaces and Routed Ports

Host A

Catalyst 3550 Switch with Enhanced Multilayer Software Image Human Resources Network = ACL Denying Traffic from Host B and Permitting Traffic from Host A

Host B Research & Development Network = Packet

VLAN maps can filter all traffic received by the switch. VLAN maps are applied to all packets that are routed into or out of a VLAN or are bridged within a VLAN. VLAN maps are used strictly for security packet filtering. Unlike router ACLs, VLAN maps are not defined by direction (inbound or outbound). VLAN maps can be configured to match Layer 3 addresses for IP traffic. All non-IP protocols are filtered through MAC addresses and Ethertype using MAC VLAN maps. IP traffic is not access-controlled by MAC VLAN maps. VLAN maps can be enforced only on packets going through the switch. They cannot be enforced on traffic between hosts on a hub or on another switch connected to the switch on which the VLAN map is applied. With VLAN maps, packets are forwarded or dropped based on the action specified in the map. In Figure 2-10, a VLAN map is applied to deny a specific type of traffic from Host A in VLAN 10 from being forwarded.

VLAN Security

81

Figure 2-10 VLAN Maps or VLAN ACLs (VACLs) Can Perform Intra-VLAN Filtering

Host A (VLAN 10)

Catalyst 3550 Switch Bridging Traffic

Host B (VLAN 10)

= ACL Denying Traffic from Host A in VLAN 10 from Being Forwarded = Packet

Configuring Router ACLs
Router ACLs are configured on Layer 3 SVIs with the same commands used to configure ACLs on Cisco routers. The process is briefly described here. Catalyst 3550 switches do not support all IOS router ACL-related features. They do not support the following:
■ ■ ■ ■ ■ ■ ■

NOTE For more detailed information on configuring router ACLs, refer to the Cisco IOS Security Configuration Guide, Release 12.3 at http// www.cisco.com. For detailed information about the commands, refer to the Cisco IOS Security Command Reference, 12.3.

Non-IP protocol ACLs Bridge-group ACLs IP accounting Rate limiting (except with QoS ACLs) IP packets with a header length of less than 5 Reflexive ACLs Dynamic ACLs (except for certain specialized dynamic ACLs used by the clustering feature on the switch)

Standard and extended IP router ACLs are created on the switch just as they are on a router. In addition to numbered standard and extended ACLs, standard and extended named and time-range ACLs are available. Here are the basic two steps involved in using ACLs: Step 1 Step 2 Create an ACL by specifying an access list number or name and access conditions. Apply the ACL to an interface, terminal line, or VLAN map.

Existing ACLs can be displayed by using show commands. The show access-lists command displays information about all IP and MAC ACLs or about a specific ACL.

82

Chapter 2: VLANs and VTP

The show ip access-lists command displays information about all IP ACLs or about a specific IP ACL. The show ip interface command can be used to view the input and output access groups on the interface, as well as other interface characteristics. If IP is not enabled on the interface, the access groups are not shown. A Catalyst 3550 switch has a routed port, interface GigabitEthernet 0/2, connected to Server A, as shown in Figure 2-11. Server A has benefits information and other documentation on it that all employees can access. The switch also has routed port 0/3 connected to Server B, which contains confidential payroll data. All users can access Server A, but Server B has restricted access.
Figure 2-11 ACLs on Switches Can Restrict Access Between Subnets Just as They Would on a Router Benefits Server A 172.20.128.97/27 Port 0/2 Catalyst 3550 Switch with Enhanced Multilayer Switch Image Payroll Server B 172.20.128.98/27 Port 0/3

Human Resources 172.20.128.0-31/27

Accounting 172.20.128.64-95/27

Use router ACLs to do this in one of two ways:
■ ■

Create a standard ACL and filter traffic coming to the server from port 0/3. Create an extended ACL and filter traffic coming from the server into port 0/3.

Example 2-1 uses a standard ACL to filter traffic coming into Server B from port 0/3, permitting traffic only from hosts in the Accounting department, which have source addresses 172.20.128.64 to 172.20.128.95.

VLAN Security

83

Example 2-1 A Standard ACL Filters Traffic to Server B
Switch(config)#access-list 6 permit 172.20.128.64 0.0.0.31 Switch(config)#end Switch#show access-list Standard IP access list 6 permit 172.20.128.64, wildcard bits 0.0.0.31 Switch#configure terminal Switch(config)#interface gigabitethernet0/3 Switch(config-if)#ip access-group 6 out

The ACL is applied to traffic coming out of routed port 0/3. Only traffic from the specified source address is permitted. Example 2-2 uses an extended ACL to filter traffic coming from Server B into port 0/3, permitting traffic from any source address (in this case, Server B) to only the Accounting destination addresses 172.20.128.64 to 172.20.128.95.
Example 2-2 An Extended ACL Filters Traffic to Server B
Switch(config)#access-list 106 permit ip any 172.20.128.64 0.0.0.31 Switch(config)#end Switch#show access-list Extended IP access list 106 permit ip any 172.20.128.64 0.0.0.31 Switch#configure terminal Switch(config)#interface gigabitethernet0/3 Switch(config-if)#ip access-group 106 in

NOTE Refer to the Catalyst 2950 Desktop Switch Software Configuration Guide, Catalyst 3550 Multilayer Switch Software Configuration Guide, and Catalyst 6500 Series Software Configuration Guide for additional information about configuring ACLs and examples.

The ACL is then applied to traffic going into routed port 0/3, permitting it to go only to the specified destination addresses. Remember that with extended ACLs, a protocol must be entered before the source and destination information.

Configuring VLAN Maps
This section briefly describes how to configure VLAN maps, which is the only way to control filtering within a VLAN. VLAN maps have no direction. To filter traffic in a specific direction using a VLAN map, you must configure an ACL with a specific source or destination address. Unlike router ACLs, the default action for VLAN maps is to forward. This action is taken if the packet does not match any of the entries within the map. Each VLAN map consists of an ordered series of entries. A packet that comes into the switch is tested against the first entry in the VLAN map. If the packet matches the first VLAN map

84

Chapter 2: VLANs and VTP

entry, the action specified for that part of the VLAN map is taken. If no action is specified, the default action is to forward. If no match occurs, the packet is tested against the next entry in the map. If no entries match, the implicit forward default applies. Beginning in privileged EXEC mode, follow the steps listed in Table 2-1 to create, add to, or delete a VLAN map entry. To create a VLAN map and apply it to one or more VLANs, follow these steps: Step 1 Step 2 Step 3 Create the standard or extended IP ACLs or named MAC extended ACLs that will be applied to the VLAN. Enter the vlan access-map global configuration command to create a VLAN ACL map entry. In access map configuration mode, optionally enter an action, either drop or forward, and enter the match command to match the packet against one or more access lists. Use the vlan filter global configuration command to apply a VLAN map to one or more VLANs.

Step 4

Remember that VLAN maps have an implicit forward feature at the end of the list; a packet is forwarded if it does not match any ACL within the VLAN map. Follow these guidelines when configuring VLAN maps:

If no router ACL is configured to deny traffic on a routed VLAN interface, and no VLAN map is configured, all traffic is permitted. As with ACLs, the order of entries in a VLAN map is important. The system might take longer to boot if a large number of ACLs have been configured.

■ ■

Use the no vlan access-map name command to delete a map. Use the no vlan access-map name number command to delete a single sequence entry from within the map. Use the no action command to enforce the default action, which is to forward. VLAN maps do not use the specific permit or deny keywords. To deny a packet by using VLAN maps, create an ACL that would match the packet, and set the action to drop. A permit in the ACL counts as a match. A deny in the ACL means no match. Example 2-3 shows how to create an ACL and a VLAN map to deny a packet. In this example, any packets that match the ip1 ACL (TCP packets) are dropped. First, create the IP ACL to permit any TCP packet and no other packets; then set the action for packets that match the permit list to be dropped.

VLAN Security

85

Table 2-1 The VLAN Map Syntax Involves Configuring a List of Action and Match Entries for Data

Step

Command

Description

1 2

configure terminal vlan access-map name [number]

Enters global configuration mode. Changes to access map configuration mode. It creates a VLAN map and gives it a name and (optionally) a number. The number is the sequence number of the entry within the map. When creating VLAN maps with the same name, numbers are created sequentially in increments of 10. When modifying or deleting maps, enter the number of the map entry to be modified or deleted. (Optional) Sets the action for the map entry. The default is to forward. Matches the packet (using either the IP or MAC address) against one or more standard or extended ACLs. Note that packets are matched only against ACLs of the correct protocol type. IP packets are matched against standard or extended IP ACLs. Non-IP packets are matched only against named MAC extended ACLs. Returns to global configuration mode. Displays the ACL configuration. (Optional) Saves the configuration file.

3 4

action [drop | forward] match {ip address | mac address} {name | number} [name | number]

5 6 7

end show running-config copy running-config startup-config

Example 2-3 Named ACLs Are Convenient for Use in VLAN Maps to Specify Traffic to Drop or Forward. In This Case, All TCP Traffic Is Dropped.
Switch(config)#ip access-list extended ip1 Switch(config-ext-nacl)#permit tcp any any Switch(config-ext-nacl)#exit Switch(config)#vlan access-map map_1 10 Switch(config-access-map)#match ip address ip1 Switch(config-access-map)#action drop

86

Chapter 2: VLANs and VTP

Example 2-4 shows how to create a VLAN map to permit a packet. In this example, ip2 permits UDP packets, and any packets that match the ip2 ACL are forwarded.
Example 2-4 Traffic That Does Not Match an Entry in a VLAN Map Is Forwarded. Continuing from Example 2-3, the Following Results in All Non-TCP Traffic Being Forwarded.
Switch(config)#ip access-list extended ip2 Switch(config-ext-nacl)#permit udp any any Switch(config-ext-nacl)#exit Switch(config)#vlan access-map map_1 20 Switch(config-access-map)#match ip address ip2 Switch(config-access-map)#action forward

In Example 2-5, any packets that do not match any of the previous ACLs (that is, packets that are not TCP packets or UDP packets) are dropped.
Example 2-5 Continuing from Examples 2-3 and 2-4, the Following Results in All Traffic Being Dropped Except UDP Traffic
Switch(config)#vlan access-map map_1 30 Switch(config-access-map)#action drop

Beginning in privileged EXEC mode, follow the steps listed in Table 2-2 to apply a VLAN map to one or more VLANs.
Table 2-2 VLAN Maps Are Applied to VLANs in Global Configuration Mode

Step

Command

Description

1 2

configure terminal vlan filter mapname vlan-list list

Enters global configuration mode. Applies the VLAN map to one or more VLAN IDs. The list can be a single VLAN ID (22), a consecutive list (10-22), or a string of VLAN IDs (12, 22, 30). Spaces around the comma and hyphen are optional. Displays the ACL configuration. (Optional) Saves the configuration file.

3 4

show running-config copy running-config startup-config

VLAN Security

87

Example 2-6 shows how to apply VLAN map 1 to VLANs 20 to 22.
Example 2-6 Applying a VLAN Map Requires Only One Command
Switch(config)#vlan filter map 1 vlan-list 20-22

To display information about VLAN access maps or VLAN filters, use the appropriate show command from privileged EXEC mode. The show vlan access-map [mapname] command displays information about all VLAN access maps or a specified access map. The show vlan filter [access-map name | vlan vlan-id] command displays information about all VLAN filters or about a specified VLAN access map or VLAN. Example 2-7 illustrates some show commands for ACLs and VLAN maps.
Example 2-7 Several show Commands Are Available for Verifying ACLs and VLAN Maps
Switch#show access-list Extended MAC access list mac1 deny any any decnet-iv permit any any Switch#show vlan access-map Vlan access-map "map_1" 10 Match clauses: ip address: ip1 Action: drop Vlan access-map "map_1" 20 Match clauses: mac address: mac1 Action: forward Vlan access-map "map_1" 30 Match clauses: Action: drop Switch#show vlan filter VLAN Map map_1 is filtering VLANs: 20-22

88

Chapter 2: VLANs and VTP

Lab 2.9.4 Catalyst 2950 and 3550 Series Intra-VLAN Security

In this lab exercise, you configure intra-VLAN security with ACLs using commandline interface (CLI) mode.

Using VLAN Maps with Router ACLs
To filter both bridged and routed traffic, VLAN maps can be used by themselves or in conjunction with router ACLs. Router ACLs can be applied on both input and output routed VLAN interfaces, and a VLAN map can be used to filter the bridged traffic. If a packet flow matches a VLAN map deny clause in the ACL, regardless of the router ACL configuration, the packet is dropped. When using router ACLs with VLAN maps, packets that require logging on the router ACLs are not logged if they are denied by a VLAN map. Remember, VLAN maps have a default action of forward, so a packet is forwarded if it does not match any VLAN map entry. These guidelines are for configurations where a router ACL and a VLAN map need to be applied on the same VLAN. These guidelines do not apply to configurations where router ACLs and VLAN maps are used on different VLANs. The switch hardware provides one lookup for security ACLs for each direction, input and output. As a result, a router ACL and a VLAN map must be merged when they are configured on the same VLAN. Merging the router ACL with the VLAN map might significantly increase the number of ACEs. If a router ACL and a VLAN map must be configured on the same VLAN, use the following guidelines for both router ACL and VLAN map configuration:

Whenever possible, try to write the ACL with all entries having a single action except for the final default action of the other type. That is, write the ACL using one of these two forms:
permit... permit... permit... deny ip any any

or
deny... deny... deny... permit ip any any

VLAN Security

89

To define multiple permit and deny actions in an ACL, group each action type to reduce the number of entries. Avoid including Layer 4 information in an ACL. Use wildcard masks in the IP address whenever possible.

■ ■

The best merge results are obtained if the ACLs are filtered based on source or destination IP addresses and not on the full flow (source IP address, destination IP address, protocol, and protocol ports). If the full flow must be specified, and the ACL contains both IP ACEs and TCP/UDP/ICMP ACEs with Layer 4 information, put the Layer 4 ACEs at the end of the list. This gives priority to the filtering of traffic based on IP addresses. ACL processing in the 3550 switch is done mostly in hardware, but if the hardware exceeds its capacity to store ACL configurations, the switch software attempts to fit a simpler configuration into hardware. This simpler configuration does not do all the filtering that has been configured, but instead sends some or all packets to the CPU to be filtered by software. All configured filtering is accomplished, but performance is greatly decreased when the filtering is done in software. Any problem in fitting the configuration into hardware is logged, but it is possible that not everyone who configures the switch can see the log messages as they occur. The show fm command displays feature manager information for the interface or the VLAN. The show fm vlan vlan-id and show fm interface interface-id commands can be executed from privileged mode to determine if any interface or VLAN configuration did not fit into hardware. Example 2-8 shows some sample output.
Example 2-8 An ACL Configuration Conflict Exists
Switch#show fm vlan 1 Conflicts exist with layer 2 access groups. Input VLAN Label:1 Output VLAN Label:0 (default) Priority:normal

The show fm command is also used to determine what label is used in the hardware for the interface or VLAN configuration. VLAN labels are used for features configured on VLANs, such as router ACLs and VLAN maps. The VLAN label ID range is from 0 to 255. The show fm vlan-label label-id command displays what features associated with that label cannot fit in the hardware or if configuration conflicts have occurred, as shown in Example 2-9.

90

Chapter 2: VLANs and VTP

Example 2-9 A Merge Failure on an Input Access Group
Switch#show fm vlan-label 1 Unloaded due to merge failure or lack of space: InputAccessGroup Merge Fail:input Input Features: Interfaces or VLANs: Vl1 Priority:normal Vlan Map:(none) Access Group:131, 6788 VMRs Multicast Boundary:(none), 0 VMRs Output Features: Interfaces or VLANs: Priority:low Bridge Group Member:no Vlan Map:(none) Access Group:(none), 0 VMRs

Applying Router ACLs and VLAN Maps on VLANs
This section contains examples of applying router ACLs and VLAN maps to a VLAN for switched, bridged, routed, and multicast packets. Although the following figures show packets being forwarded to their destination, each time the packet’s path crosses a line indicating a VLAN map or an ACL, it is also possible that the packet might be dropped rather than forwarded. Packets switched within the VLAN without being routed are subject only to the VLAN map of the input VLAN, as shown in Figure 2-12. For routed packets, the ACLs are applied in the following order, as shown in Figure 2-13:
1. VLAN map for input VLAN 2. Input router ACL 3. Output router ACL 4. VLAN map for output VLAN

VLAN Security

91

Figure 2-12 Switched Packets Are Affected Only by VLAN Maps Catalyst 3550 Switch Input Router ACL Output Router ACL

VLAN 10 Map

VLAN 20 Map

Frame

Host A (VLAN 10)

Routing Function or Fall Back Bridge

Host C (VLAN 10) VLAN 10 Packet VLAN 20

Figure 2-13 Routed Packets Can Be Filtered by Multiple VLAN Maps and Incoming and Outgoing ACLs Catalyst 3550 Switch with Enhanced Multilayer Switch Image Input Router ACL Output Router ACL

VLAN 10 Map

VLAN 20 Map

Frame

Host A (VLAN 10)

Routing Function

Host B (VLAN 20)

VLAN 10

Packet

VLAN 20

92

Chapter 2: VLANs and VTP

A multicast packet that is being routed has two different types of filters applied:
■ ■

One for destinations that are other ports in the input VLAN Another for each of the destinations that are in other VLANs to which the packet has been routed

The packet might be routed to more than one output VLAN, in which case a different router output ACL and VLAN map would apply for each destination VLAN, as shown in Figure 2-14.
Figure 2-14 Multicast Packets Are Subject to VLAN Maps and Might Also Be Subject to ACLs, Depending on Their Destination Catalyst 3550 Switch with Enhanced Multilayer Switch Image Input Router ACL Output Router ACL

VLAN 10 Map

VLAN 20 Map

Frame

Host A (VLAN 10)

Routing Function

Host B (VLAN 20)

Host C (VLAN 10) VLAN 10 Packet VLAN 20

The final result is that the packet might be permitted in some of the output VLANs and not in others. A copy of the packet is forwarded to destinations where it is permitted. However, if the input VLAN map drops the packet, no destination receives a copy of the packet.

VLAN Types
VLANs can be implemented in various ways. This section describes different types of VLAN implementations. First, campus-wide VLANs versus local VLANs are explored, followed by static VLANs versus dynamic VLANs.

VLAN Types

93

VLAN Boundaries
Just as routing protocols are classified in various ways, so are VLANs. VLANs are classified as local (geographic) or end-to-end (campus-wide). Alternatively, VLANs are classified as either port-based (static) or dynamic. The number of VLANs in the switch block might vary greatly, depending on several factors:
■ ■ ■ ■

Traffic patterns Types of applications Network management needs Group commonality

In addition, an important consideration in defining the size of the switch block and the number of VLANs is the IP addressing scheme. For example, suppose a network uses a 24-bit mask to define a subnet. Given this criterion, a total of 254 host addresses are allowed in one subnet. Because a one-to-one correspondence between VLANs and IP subnets is strongly recommended, there can be no more than 254 devices in any one VLAN. It is further recommended that VLANs should not extend outside the Layer 2 domain of the distribution switch. With many users spread across three departments in one building, four VLANs would be required under the recommended constraints, as shown in Figure 2-15.
Figure 2-15 Modern Campus Networks Employ a One-to-One Correspondence Between IP Subnets and VLANs

Management VLAN Network Layer
192.26.21.0

Routing Function Interconnects VLANs
192.20.24.0 192.30.20.0

Data-Link Layer Broadcast Domains

Engineering VLAN

Marketing VLAN

Sales VLAN

Physical Layer LAN Switch Human Layer

94

Chapter 2: VLANs and VTP

When scaling VLANs in the switch block, there are two basic methods of defining the VLAN boundaries:
■ ■

End-to-end VLANs Local VLANs

End-to-End VLANs
VLANs can exist either as end-to-end networks (campus-wide) or inside limited geographic (local) boundaries. An end-to-end VLAN network has the following characteristics:

Users are grouped into VLANs independent of physical location and dependent on group or job function. All users in a VLAN should have the same 80/20 traffic flow patterns. As a user moves around the campus, VLAN membership for that user should not change. Each VLAN has a common set of security requirements for all members.

■ ■

Backbone links in a switched LAN should be faster than access level links, as shown in Figure 2-16. Starting in the wiring closet, 100-Mbps dedicated Ethernet ports are provisioned for each user. Each VLAN corresponds to a subnet and, because people have moved around over time, each switch eventually becomes a member of all VLANs. Fast Ethernet Inter-Switch Link (ISL) or IEEE 802.1Q is used to carry multiple VLAN information between the wiring closets and the distribution layer switches.
Figure 2-16 Uplinks Should Provide Greater Bandwidth Than Access Links
Accounting Engineering VLAN 10 VLAN 20 172.16.10.0/24 172.16.20.0/24 Accounting VLAN 10 172.16.10.0/24 Accounting Engineering VLAN 10 VLAN 20 172.16.10.0/24 172.16.20.0/24 Sales VLAN 30 172.16.30.0/24

Gigabit Uplinks VLAN Trunk

ISL is a Cisco-proprietary protocol that maintains VLAN information as traffic flows between switches and routers. IEEE 802.1Q is an open-standard VLAN tagging mechanism that predominates in modern switching installations. VLAN tagging mechanisms are explored later in this chapter in the section “VLAN Identification.”

VLAN Types

95

Workgroup servers operate in a client/server model, and attempts have been made to keep users in the same VLAN as their server to maximize the performance of Layer 2 switching, and keep traffic localized. In the core, a router allows intersubnet communication. The network is engineered in the campus-wide VLAN model, based on traffic flow patterns, to have 80 percent of the traffic within a VLAN and 20 percent crossing the router to the enterprise servers and to the Internet and WAN. End-to-end VLANs allow devices to be grouped based on resource usage. This includes such parameters as server usage, project teams, and departments. The goal of endto-end VLANs is to maintain 80 percent of the traffic on the local VLAN. As corporate networks move to centralize their resources, end-to-end VLANs have become more difficult to maintain. Users are required to use many different resources, many of which are no longer in their VLAN. Because of this shift in placement and usage of resources, VLANs now are frequently created around geographic (local) boundaries rather than commonality boundaries.

Local VLANs
The local VLAN model has VLANs dedicated to each access layer switch cluster, with Layer 3 switching between wiring closets performed at the distribution layer or Main Distribution Facility (MDF), as shown in Figure 2-17. With the campus-wide VLAN model, users who are in the same department would be in the same VLAN regardless of the location of the VLAN in the network. In the local VLAN model, users in the same department are in the same VLAN only if their access layer switches are connected to the same distribution layer switch (see Figure 2-17). If the access layer switch is connected to a different distribution layer switch, the users are assigned a different VLAN ID and subnet address, regardless of the users’ department.
Figure 2-17 Local VLANs Are Based on Physical Location and Are Dedicated to an Access Layer Switch Cluster. Accounting Users on Different Layer 3 Switches Can Be on Different VLANs.
Accounting Engineering VLAN 10 VLAN 20 172.16.10.0/24 172.16.20.0/24 Accounting VLAN 10 172.16.10.0/24 Accounting Engineering VLAN 30 VLAN 40 172.16.30.0/24 172.16.40.0/24 Sales VLAN 50 172.16.50.0/24

NOTE If an access layer switch has only users who belong to a single VLAN, it is not necessary to configure those interfaces for the specific VLAN. However, some network administrators assign these interfaces to their proper VLAN in case the switch has other VLANs configured on it in the future (see Figure 2-18).

Gigabit Uplinks
172.16.100.0/24

96

Chapter 2: VLANs and VTP

Figure 2-18 Access Uplinks Do Not Carry VLAN Tags, So Access Ports Can Be Left with Their Default VLAN Configuration
Accounting Engineering VLAN 10 VLAN 20 172.16.10.0/24 172.16.20.0/24 Accounting VLAN 10 172.16.10.0/24 Accounting Engineering VLAN 30 VLAN 40 172.16.30.0/24 172.16.40.0/24 Sales VLAN 50 172.16.50.0/24

Interfaces on the Switch Must Be Configured for VLANs

VLAN Trunk

NonTrunk

Interfaces on the Switch Do Not Need To Be Configured for VLANs 172.16.100.0/24

Geographic VLANs are also considerably easier to manage and conceptualize than VLANs that span different geographic areas.

Establishing VLAN Memberships
The two common approaches to assigning VLAN membership are as follows:
■ ■

Static VLANs Dynamic VLANs

Static VLANs are also called port-based VLANs. Static VLAN assignments are created by manually assigning ports to a VLAN. As a device enters the network, the device automatically assumes the port’s VLAN. If the user changes ports and needs access to the same VLAN, the network administrator must manually make a port-to-VLAN assignment for the new connection. Dynamic VLANs are created through the use of software packages such as CiscoWorks 2000. With a VLAN Management Policy Server (VMPS), an administrator can assign switch ports to VLANs dynamically based on information such as the source MAC address of the device connected to the port or the username used to log on to that device. As a device enters the network, the device queries a database for VLAN membership. Figure 2-19 illustrates a VMPS setup.

Port-Based VLAN Membership
With port-based VLAN membership, the port is assigned to a specific VLAN independent of the user or system attached to the port. This means that all users attached to the port should be members of the same VLAN, as shown in Figure 2-20. The network administrator typically performs the VLAN assignment. The port configuration is static and cannot be automatically changed to another VLAN without manual reconfiguration.

VLAN Types

97

Figure 2-19 VMPS Lets Ports Be Automatically Assigned VLAN Membership Catalyst 6500 Primary VMPS Server 1
Switch 1
172.20.26.150

TFTP Server

Client
Switch 2
172.20.26.151

172.20.22.7

Secondary VMPS Server 2

Switch 3

172.20.26.152

Ethernet Segment

Switch 4

172.20.26.153

End Station 1

Switch 5

172.20.26.154

Switch 6

172.20.26.155

Switch 7

172.20.26.156

End Station 2

Switch 8

172.20.26.157 Client

Switch 9

172.20.26.158

Secondary VMPS Server 3

Switch 10

172.20.26.159

Figure 2-20 All Users Attached to the Same Switch Port Must Be in the Same VLAN

Management VLAN Network Layer
192.26.21.0

Routing Function Interconnects VLANs
192.20.24.0 192.30.20.0

Data-Link Layer Broadcast Domains

Engineering VLAN

Marketing VLAN

Sales VLAN

Physical Layer LAN Switch Human Layer

98

Chapter 2: VLANs and VTP

As with other VLAN approaches, the packets forwarded using this method do not leak into other VLAN domains on the network. After a port has been assigned to a VLAN, the port cannot send to or receive from devices in another VLAN without the intervention of a Layer 3 device. The device that is attached to the port likely doesn’t understand that a VLAN exists. The device simply knows that it is a member of a subnet and that the device should be able to talk to all other members of the subnet by simply sending information to the cable segment. The switch is responsible for identifying that the information came from a specific VLAN and for ensuring that the information gets to all other members of the VLAN. The switch is further responsible for ensuring that ports in a different VLAN do not receive the information. This approach is quite simple, fast, and easy to manage because no complex lookup tables are required for VLAN segmentation. If port-to-VLAN association is done with an applicationspecific integrated circuit (ASIC), the performance is very good. An ASIC allows the port-toVLAN mapping to be done at the hardware level.

Dynamic VLANs
With a VMPS, ports can be assigned to VLANs dynamically, based on information entered in the VMPS database. When a host moves from a port on one switch in the network to a port on another switch in the network, the switch assigns the new port to the proper VLAN for that host dynamically. When VMPS is enabled, a MAC address-to-VLAN mapping database downloads from a TFTP server, and VMPS begins to accept client requests. If the switch is power-cycled or reset, the VMPS database downloads from the TFTP server automatically, and VMPS is reenabled. VMPS opens a UDP socket to communicate and listen to client requests. When the VMPS server receives a valid request from a client, it searches its database for a MAC address-toVLAN mapping. Figure 2-21 illustrates primary and secondary VMPS servers. If the assigned VLAN is restricted to a group of ports, VMPS verifies the requesting port against this group. If the VLAN is allowed on the port, the VLAN name is returned to the client. If the VLAN is not allowed on the port and VMPS is not in secure mode, the host receives an access-denied response. If VMPS is in secure mode, the port is shut down. If a VLAN in the database does not match the current VLAN on the port and active hosts are on the port, VMPS sends an access-denied or port-shutdown response based on the secure mode of the VMPS.

VLAN Types

99

Figure 2-21 VMPS Servers Process Client Requests for MAC-to-VLAN Maps Catalyst 6500 Primary VMPS Server 1
Switch 1
172.20.26.150

TFTP Server

Client
Switch 2
172.20.26.151

172.20.22.7

Secondary VMPS Server 2

Switch 3

172.20.26.152

Ethernet Segment

Switch 4

172.20.26.153

End Station 1

Switch 5

172.20.26.154

Switch 6

172.20.26.155

Switch 7

172.20.26.156

End Station 2

Switch 8

172.20.26.157 Client

Switch 9

172.20.26.158

Secondary VMPS Server 3

Switch 10

172.20.26.159

Multiple hosts can be active on a dynamic port if they are all in the same VLAN. If the link goes down on a dynamic port, the port returns to an isolated state. Any hosts that come online through the port are checked again with VMPS before the port is assigned to a VLAN. The following guidelines and restrictions apply to dynamic port VLAN membership:
■ ■

VMPS must be configured before the ports can be configured as dynamic. When a port is configured as dynamic, Spanning Tree PortFast is enabled automatically for that port. If a port is converted from static to dynamic on the same VLAN, the port connects immediately to that VLAN, but VMPS eventually checks the host’s legality on the port. Static secure ports cannot become dynamic ports unless security is disabled before the port is made dynamic. Static ports that are trunking cannot become dynamic ports unless trunking is disabled on the port before it is changed from static to dynamic.

It is also important to note that the VLAN Trunking Protocol (VTP) management domain and the management VLAN of VMPS clients and the VMPS server must be the same.

100

Chapter 2: VLANs and VTP

Configuring VLANs and VMPS
A static VLAN is easy to configure and is by far the most common method of configuring VLAN membership. Dynamic VLANs with VMPS is another option, but Cisco is no longer recommending it as a preferred solution. This section describes static and dynamic VLAN configurations.

Configuring Static VLANs
Static VLANs are ports on a switch that are manually assigned to a VLAN by using a VLAN management application or by working directly within the switch. These ports maintain their assigned VLAN configuration until an administrator changes them. Although static VLANs require manual entry changes, they are secure, easy to configure, and straightforward to monitor. This type of VLAN works well in networks where moves are controlled and managed. Static VLANs are also appropriate for networks that employ robust VLAN management software to configure the ports. Static VLANs are also a consideration if it is undesirable to assume the additional overhead required when maintaining end-station MAC addresses and custom filtering tables. The creation of a VLAN on a switch is a very straightforward and simple task. If you’re using a Cisco IOS-based switch, from interface configuration mode, issue the switchport command. The switchport mode [access | dynamic | trunk] command can be used to set the interface to access, dynamic, or trunk. To statically assign an interface to a VLAN, use the switchport mode access command followed by the switchport access vlan number command. To set interface FastEthernet 0/3 on a Catalyst switch to access mode, use the switchport mode IOS command. The port is then assigned to VLAN 2 with the switchport access vlan command, as verified in Example 2-10 using the show running-config command. The switchport mode access command is the default mode for switch interfaces. The mode is not shown in the running configuration.
Example 2-10 The switchport access vlan Command Is Used to Statically Configure a Port for a Particular VLAN
Switch#show running-config hostname switch ! ip subnet-zero !

Configuring VLANs and VMPS

101

Example 2-10 The switchport access vlan Command Is Used to Statically Configure a Port for a Particular VLAN (Continued)
! ! interface FastEthernet0/1 ! interface FastEthernet0/2 ! interface FastEthernet0/3 switchport access vlan 2

Unlike the earlier 2900XL and 3500XL switches, the 2950 switches with Cisco IOS Release 12.1(6)EA2 or later and the 3550 switches with Cisco IOS Release 12.1(4)EA1 or later have an interface range command that lets multiple interfaces be identified for a subsequent operation. For example, several ports can be assigned to a VLAN with one switchport command, as shown in Example 2-11.
Example 2-11 The interface range Command Is Definitely a Time-Saver!
Switch(config)#interface range fa0/1 - 6 Switch(config-if-range)#switchport access vlan 10

These commands assign ports 1 to 6 to VLAN 10 in one command sequence. Ports on Cisco switches usually default to the Dynamic Trunking Protocol (DTP) mode of dynamic desirable. This means that another switch connected to this port can cause trunking to occur on this interface. It is recommended that all nontrunking switch ports be configured as access ports with the command switchport mode access. This helps prevent certain manin-the-middle attacks from occurring within the network. There are also other reasons why it is important not to have rogue switches attaching to the network in regard to STP. Chapter 3, “Spanning Tree Protocol (STP),” discusses these issues in greater detail.
Lab 2.9.1 Catalyst 2950T and 3550 Series Static VLANS

In this lab exercise, you create and maintain VLANs on a Cisco Catalyst 2950T or 3550 series Ethernet switch using CLI mode.

102

Chapter 2: VLANs and VTP

Verifying VLAN Configuration
As soon as a switch has been configured for VLANs, you should verify the configuration with the show vlan or show vlan brief command. The output in Example 2-12 shows that VLAN 2 is configured on interface FastEthernet 0/3.
Example 2-12 The show vlan brief Command Provides a Quick List of VLANs and Associated Ports
Switch#show vlan brief VLAN ---1 Name -----------------default Status -----active Ports -------------------------_ Fa0/1, Fa0/2, Fa0/4, Fa0/5 Fa0/6, Fa0/7, Fa0/8, Fa0/9 Fa0/10, Fa0/11, Fa0/12, Fa0/13 Fa0/14, Fa0/15, Fa0/16, Fa0/17 Fa0/18, Fa0/19, Fa0/20, Fa0/21 Fa0/22, Fa0/23, Fa0/24,

2 1002 1003 1004 1005

VLAN0002 fddi-default token-ring-default fddinet-default trnet-default

active active active active active

Fa0/3

When configuring VLANs, keep the following in mind:
■ ■

A created VLAN remains unused until it is mapped to switch ports. The default configuration has all the switch ports on VLAN 1.

Deleting VLANs
When a VLAN is deleted from a switch that is in VTP server mode, the VLAN is removed from all switches in the VTP domain. When a VLAN is deleted from a switch that is in VTP transparent mode, the VLAN is deleted only on that specific switch. A VLAN cannot be deleted from a switch that is in VTP client mode. The later section “VLAN Trunking Protocol (VTP)” covers the different VTP modes in greater detail. The default VLANs for the different media types cannot be deleted. Ethernet VLAN 1, Fiber Distributed Data Interface (FDDI), and Token Ring VLANs 1002 to 1005 cannot be removed from the switch.

Configuring VLANs and VMPS

103

Beginning in privileged EXEC mode, follow the steps listed in Table 2-3 to delete a VLAN on the switch.
Table 2-3 VLANs Can Be Removed in VLAN Database Configuration Mode

CAUTION When a VLAN is deleted, any ports assigned to that VLAN become inactive. They remain associated with the deleted VLAN until they are assigned to a new VLAN. Use caution when deleting VLANs. It is possible to cause a major loss of connectivity by accidentally eliminating a VLAN that still has active users on it.

Step

Command

Description

1 2 3

vlan database no vlan vlan-id exit

Enters VLAN configuration mode. Removes the VLAN by entering the VLAN ID. Updates the VLAN database, propagates it throughout the administrative domain, and returns to privileged EXEC mode. Verifies the VLAN removal. (Optional) Saves the configuration file.

4 5

show vlan brief copy running-config startup-config

It is important to note that the no vlan command must be issued on a switch in VTP server or VTP transparent mode. VLANs cannot be deleted from a VTP client switch. If the switch is configured in transparent mode, you can delete the VLAN. VLANs deleted from a switch in VTP transparent mode are removed from that one switch only and not throughout the VTP domain. VTP domains are covered in the later section “VLAN Trunking Protocol (VTP).”

VMPS Operation
With VLAN Membership Policy Server (VMPS), switch ports can be assigned to VLANs dynamically, based on the source MAC address or user ID of the device connected to the port. When a host or user moves from a port on one switch in the network to a port on another switch in the network, the switch dynamically assigns the new port to the proper VLAN for that host. When VMPS is enabled, a MAC address-to-VLAN mapping database downloads from a TFTP server to the VMPS server (a Catalyst switch). The VMPS server then begins accepting client requests. The VMPS client communicates with a VMPS server through the VLAN Query Protocol (VQP). When the VMPS receives a VQP request from a client switch, it searches its database for a MAC-address-to-VLAN mapping. The server response is based on this mapping and whether the server is in secure mode. Secure mode determines whether the server shuts down the port when a VLAN is not allowed on it or just denies the port access to the VLAN.

104

Chapter 2: VLANs and VTP

In response to a request, the VMPS takes one of these actions:

If the assigned VLAN is restricted to a group of ports, the VMPS verifies the requesting port against this group and responds as follows: — If the VLAN is allowed on the port, the VMPS sends the VLAN name to the client in response. — If the VLAN is not allowed on the port and the VMPS is not in secure mode, the VMPS sends an access-denied response. — If the VLAN is not allowed on the port and the VMPS is in secure mode, the VMPS sends a port-shutdown response.

If the VLAN in the database does not match the current VLAN on the port and active hosts exist on the port, the VMPS sends an access-denied or port-shutdown response, depending on the secure mode of the VMPS.

If the switch receives an access-denied response from the VMPS, it continues to block traffic from the MAC address to or from the port. The switch continues to monitor the packets directed to the port and sends a query to the VMPS when it identifies a new address. If the switch receives a port-shutdown response from the VMPS, it disables the port. The port must then be enabled manually. It is also possible to configure a fallback VLAN name. If a device is plugged into the network and its MAC address is not in the database, VMPS sends the fallback VLAN name to the client. If no fallback VLAN is configured and the MAC address does not exist in the database, VMPS sends an access-denied response. If VMPS is in secure mode, it sends a port-shutdown response. An administrator can also make an explicit entry in the configuration table to deny access to specific MAC addresses for security reasons by specifying a --NONE-- keyword for the VLAN name. In this case, VMPS sends an access-denied or port-shutdown response.

Dynamic Port VLAN Membership
A dynamic port on the switch can belong to only one VLAN. When the link comes up, the switch does not forward traffic to or from this port until the VMPS server provides the VLAN assignment. The VMPS client receives the source MAC address from the first packet of a new host connected to the dynamic port and attempts to match the MAC address to a VLAN in the VMPS database via a VQP request to the VMPS server.

Configuring VLANs and VMPS

105

If there is a match, the VMPS server sends the VLAN number for that port. If the client switch was not previously configured, it uses the domain name from the first VTP packet it receives on its trunk port from the VMPS. If the client switch was previously configured, it includes its domain name in the query packet to the VMPS to obtain its VLAN number. The VMPS verifies that the domain name in the packet matches its own domain name before accepting the request and responds to the client with the assigned VLAN number for the client. If there is no match, the VMPS either denies the request or shuts down the port, depending on the VMPS secure mode setting. Multiple hosts can be active on a dynamic port if they are all in the same VLAN, but the VMPS shuts down a dynamic port if more than 20 hosts are active on the port for a Catalyst 2950 or 3550 switch. The total number of allowable hosts varies by platform. If the link goes down on a dynamic port, the port returns to an isolated state and does not belong to a VLAN. Any hosts that come online through the port are checked again through VQP request with the VMPS before the port is assigned to a VLAN.

VMPS Configuration Guidelines
There are several restrictions for configuring VMPS client switch ports as dynamic. The following requirements apply to dynamic port VLAN membership:
■ ■

VMPS must be configured before ports can be set as dynamic. The VTP management domain of the VMPS clients and the VMPS server must be the same. The management VLAN of VMPS clients and the VMPS server must be the same. When a port is configured as dynamic, the Spanning Tree Port Fast feature is automatically enabled for that port. After a static port is converted to dynamic on the same VLAN, the port connects immediately to that VLAN until VMPS checks its database for the legality of the specific host on the dynamic port. Static ports cannot become dynamic ports. Static ports that are trunking cannot become dynamic ports. Physical ports in an EtherChannel cannot be configured as dynamic ports. VMPS shuts down a dynamic port when too many active hosts connect to a port.

■ ■

■ ■ ■ ■

To use VMPS, a VMPS database must be created and stored on a TFTP server.

106

Chapter 2: VLANs and VTP

A VMPS database configuration file is an ASCII text file that is stored on a TFTP server accessible to the switch configured as the VMPS server, as shown in Example 2-13.
Example 2-13 A TFTP Server Stores the ASCII VMPS Database File. The VMPS Server Pulls the VLAN-to-MAC Address Mappings from the TFTP Server.
!VMPS FILE FORMAT, version 1.1 !Always begin the configuration file with the word "VMPS" ! !vmps domain <domain-name> !The VMPS domain must be defined. !vmps mode {open | secure} !The default mode is open. !vmps fallback <vlan-name> !vmps no domain-req {allow | deny} ! !The default value is allow. Deny means requests from !clients with no domain name are rejected. vmps domain wBU vmps mode open vmps fallbackback default vmps no-domain-req deny ! ! !MAC Addresses ! vmps-mac-addrs ! !address <addr> vlan-name <vlan_name> ! address 0012.2233.4455 vlan-name hardware address 0000.6509.a080 vlan-name hardware address aabb.ccdd.eeff vlan-name Green address 1223.5678.9abc vlan-name ExecStaff address fedc.ba98.7654 vlan-name -NONEaddress fedc.ba23.1245 vlan-name Purple ! !Port Groups !

Configuring VLANs and VMPS

107

The VMPS parser is line-based. Each entry in the text file starts on a new line. Ranges are not allowed for the switch port numbers. It is probably easiest to take a sample VMPS database file and edit it to meet the network’s needs. Although it is rarely done, a VMPS database file can be created from scratch using these rules:

Begin the configuration file with the word “VMPS” to prevent other types of configuration files from being read incorrectly by the VMPS server. Define the VMPS domain. Define the security mode as either open (the default) or secure mode. Define a fallback VLAN (optional). Define the MAC address-to-VLAN name mappings. Define port groups to which VMPS will be applied, using groups, individual ports, or the all-ports keyword. Define VLAN groups to which VLAN port policies will be applied. Define VLAN port policies to associate ports with a restricted VLAN.

■ ■ ■ ■ ■

■ ■

To review the general mechanism by which VMPS makes policy decisions affecting switch ports and VLAN assignments, review the earlier section “VMPS Operation.” Here’s a summary of the sample VMPS configuration file:
■ ■ ■

The security mode is open. The default is used for the fallback VLAN. MAC address-to-VLAN name mappings provide the MAC address of each host, and the VLAN to which each host belongs is defined. Port groups are defined. VLAN groups are defined. VLAN port policies are defined for the ports associated with restricted VLANs.

■ ■ ■

To create a VMPS database, do the following: Step 1 Step 2 Step 3 Step 4 Determine the MAC addresses of the hosts that will be assigned to VLANs dynamically, and determine the VMPS mode. Map out the port groups, VLAN groups, port policies, and fallback VLAN. Create an ASCII text file that contains the MAC address-to-VLAN mappings and policies. Move the ASCII text file to a TFTP server so that it can be downloaded to the switch that will act as the VMPS server.

108

Chapter 2: VLANs and VTP

As soon as the VMPS database is in place on the TFTP server, the VMPS server and clients can be configured. If a network interface card (NIC) in a PC changes, the VMPS database needs to be updated. Recall that when VMPS is enabled, the switch downloads the VMPS database from the TFTP server and begins accepting VMPS requests from VMPS clients. Configure VMPS clients with the commands shown in Example 2-14, starting in global configuration mode.
Example 2-14 The switchport access vlan dynamic Command Enables Dynamic VLAN Assignment to a Port
Switch#configure terminal Switch(config)#vmps server ipaddress primary Switch(config)#vmps server ipaddress for up to 3 secondary VMPS servers (optional) Switch(config)#interface interface-id Switch(config-if)#switchport mode access Switch(config-if)#switchport access vlan dynamic

Repeat the last three commands for each dynamic switch port. To reenable a shut-down dynamic port, enter the interface configuration command no shutdown. Now that all the VMPS components are configured and in place, verify that everything is working correctly. Use the show vmps command to verify the VMPS server entry. This command did not become available on some IOS-based switch platforms until Cisco IOS Release 12.1(6). The show vmps command displays the VQP version and the VMPS server IP addresses, including which server is the primary. Use the statistics keyword to display client-side statistics. Use the command show interface interface-id switchport to verify dynamic assignment of VLAN membership to a given port. After the database has loaded, a VMPS server switch answers queries from VMPS client switches with dynamic ports. The following assumptions apply to the scenario pictured in Figure 2-22:
■ ■ ■ ■

The VMPS server and the VMPS client are separate switches. Switch 1 is the primary VMPS server. Switch 3 and Switch 10 are secondary VMPS servers. End stations are connected to these clients: — Switch 5 — Switch 8

The database configuration file is called Bldg-G.db and is stored on a TFTP server with IP address 172.20.22.7.

Configuring VLANs and VMPS

109

Figure 2-22 The TFTP Server, the VMPS Server(s), the VMPS Clients, and the VQP Work in Concert to Provide Dynamic VLAN Assignment to Ports Catalyst 6500 Primary VMPS Server 1
Switch 1
172.20.26.150

Router

TFTP Server

Client
Switch 2
172.20.26.151

172.20.22.7

Catalyst 6000

6000

Secondary VMPS Server 2

Switch 3

172.20.26.152

Ethernet Segment

Switch 4

172.20.26.153

End Station 1

Switch 5

172.20.26.154

Switch 6

172.20.26.155

Switch 7

172.20.26.156

End Station 2

Switch 8

172.20.26.157

Client
Switch 9
172.20.26.158

Catalyst 6000

6000

Secondary VMPS Server 3

Switch 10

172.20.26.159

Access Links and Trunk Links
Static switch ports run in either access or trunk mode. Accordingly, the links connected to these switch ports are called access links or trunk links. In access mode, the port belongs to one and only one VLAN. An access port is a switch port that connects to an end-user device or a server; the frames transmitted on an access link look like any other Ethernet frames. A trunk link differs from an access link in that it can support multiple VLANs. The VLANs are multiplexed over the link with a trunking protocol. The trunk link also does not belong to a specific VLAN. Trunk links are typically used to connect switches to other switches, routers, or a server that uses an IEEE 802.1Q-enabled network card to participate in multiple VLANs.

110

Chapter 2: VLANs and VTP

Trunks can extend VLANs across an entire network. A trunk link can be configured to transport all VLANs or a restricted set of VLANs. Trunk links are typically configured on ports that support the greatest bandwidth for a given switch. Catalyst switches support trunk links on Fast Ethernet, Gigabit Ethernet, and 10 Gigabit Ethernet ports. To multiplex VLAN traffic, special protocols exist that encapsulate or tag the frames so that the receiving device can determine the frame’s VLAN membership. The Cisco-proprietary ISL protocol lets Cisco devices multiplex VLANs between Cisco devices. In multivendor environments, switches must use IEEE 802.1Q, an industry-standard protocol that permits multiplexing of VLANs over trunk links. The Catalyst 3550 switches support both ISL and 802.1Q, and the Catalyst 2950 switch supports only 802.1Q. Without trunk links, multiple access links would have to be installed to support multiple VLANs between switches (one link per VLAN). This is clearly neither a cost-effective nor scalable solution. Trunking is absolutely essential for interconnecting switches in a campus network. Figure 2-23 illustrates access and trunk links.
Figure 2-23 Access and Trunk Links Link All the Devices in a Campus Network

Trunk Link

Trunk Link

3 Frame VLAN 200 (Port C)

VLAN 100

W 2 ISL Frame

Z

Trunk Link

1 Frame VLAN 200 (Port A) Y VLAN 200 (Port B)

Legend: Trunk Links VLAN 200 (Access Link)

Port A and Port B on Switch Y have been defined as access links on the same VLAN. By definition, they can belong to only VLAN 200 and cannot receive frames with a VLAN identifier. As Switch Y receives traffic from Port A destined for Port B, Switch Y does not add an ISL header to the frame. Port C is also an access link that has been defined as a member of VLAN 200. If Port A sends a frame destined for Port C, the switch does the following:
1. Switch Y receives the frame and identifies it as traffic destined for VLAN 200 by the

VLAN and port number association.

VLAN Trunking and Dynamic Trunking Protocol

111

2. Switch Y encapsulates the frame with an ISL header identifying VLAN 200 and sends

the frame through the intermediate switch on a trunk link. This process is repeated for every switch that the frame must transit as it moves to its final destination of Port C.
3. Switch Z receives the frame, removes the ISL header, and forwards the frame to Port C.

VLAN Trunking and Dynamic Trunking Protocol
Layer 2 switching relies on trunk links between switches. Trunk ports can be configured to autonegotiate trunk links via DTP, or trunk links can be hard-coded. This section explores Ethernet trunks and DTP.

Trunking Overview
When a port is in trunk mode, the trunk link can be configured to transport all VLANs or a restricted set of VLANs across an entire network. Trunk links are typically used to connect switches to other switches, routers, or VLAN-enabled servers. In basic terminology, a trunk is a point-to-point link that supports several VLANs. The purpose of a trunk is to save ports when creating a link between two devices implementing VLANs, as shown in Figure 2-24.
Figure 2-24 Trunk Links Carry Data Traffic for Multiple VLANs
VLAN 1 VLAN 1 VLAN 1

A
VLAN 2 VLAN 1

Sa

VLAN 2

Sb

VLAN 2 VLAN 1

B
VLAN 2

Trunk

Sa

VLAN 1 and VLAN 2

Sb

VLAN 2

In Portion A of Figure 2-24, two VLANs need to be available on two switches, Sa and Sb. The first easy method of implementation is to create two physical links between the devices, each one carrying the traffic for a separate VLAN. Of course, this first solution does not scale very well. If the network has a third VLAN, you would need to sacrifice two additional ports. This design is also inefficient in terms of load sharing; the traffic on some VLANs might not justify a dedicated link. A trunk bundles virtual links over one physical link. In Portion B of Figure 2-24, one physical link between the two switches can carry traffic for any VLAN. To achieve this, each frame sent on the link is tagged by Sa so that Sb knows

112

Chapter 2: VLANs and VTP

which VLAN it belongs to. Different tagging schemes exist. The most common protocols for Ethernet segments to follow are the IEEE 802.1Q standard and the Cisco-proprietary ISL protocol.

Configuring a VLAN Trunk
To create or configure a VLAN trunk on a Cisco IOS-based switch, you must configure the port as a trunk and specify the trunk encapsulation. To do this, issue the switchport mode trunk and switchport trunk encapsulation [dot1q | isl] commands, as shown in Example 2-15.
Example 2-15 Two Commands Generally Suffice to Configure an Interface for Trunking
Switch(config-if)#switchport mode trunk Switch(config-if)#switchport trunk? allowed Set allowed VLAN characteristics when interface is in trunking mode encapsulation Set trunking encapsulation when interface is in trunking mode native Set trunking native characteristics when interface is in trunking mode pruning Set pruning VLAN characteristics when interface is in trunking mode

Switch(config-if)#switchport trunk encap ? dot1q Interface uses only 801.1q trunking encapsulation when trunking isl Interface uses only ISL trunking encapsulation when trunking

Switch(config-if)#switchport trunk encapsulation isl Switch(config-if)#

dot1q trunk interfaces use only 802.1q trunking encapsulation when trunking. isl trunk interfaces use only ISL trunking encapsulation when trunking.

VLAN Trunking and Dynamic Trunking Protocol

113

When configuring switches that allow multiple trunking encapsulations, dot1q or isl, the switchport trunk encapsulation command must be used before the switchport mode trunk command. By default, the switchport mode trunk command trunks all VLANs. In 802.1Q trunking, all VLAN packets are tagged on the trunk link to indicate the VLAN to which they belong. Frames belonging to the native VLAN are sent untagged on the trunk link. The native VLAN contains ports not assigned to other VLANs that by default belong to VLAN 1. VLAN 1 is the native VLAN by default, but VLANs other than VLAN 1 can be designated as the native VLAN. However, the native VLAN must be the same on trunked switches in 802.1Q trunking. If a VLAN other than VLAN 1 is to be the native VLAN, it needs to be identified on the trunk ports. In the interface configuration mode of the trunk port(s), the IOS-based command to designate the native VLAN is switchport trunk native vlan vlan-id. The switchport trunk native vlan command is necessary only when changing the native VLAN from something other than VLAN 1 or when changing it back to VLAN 1. Remember that the Catalyst 3550 switch supports both 802.1Q and ISL, whereas the Catalyst 2950 supports only 802.1Q.

Removing VLANs from a Trunk
By default, all VLANs are transported across a trunk link when you issue the trunk command. However, in some instances the trunk link should not carry all VLANs. One instance is broadcast suppression. All broadcasts are sent to every port in a VLAN. A trunk link acts as a member port of the VLAN and, therefore, must pass all the broadcasts. Bandwidth and processing time are wasted if no port at the other end of the trunk link is a member of that VLAN. Also, VLANs might also be removed from a trunk as a result of a topology change. Changes that occur in the topology must also be propagated across the trunk link. If the VLAN is not used on the other end of the trunk link, there is no need for the overhead of a topology change. By default, a Cisco IOS-based switch trunk port sends traffic to and receives traffic from all VLANs in the VLAN database. All VLANs, 1 to 1005, are allowed on each trunk, but some of those VLANs can be removed from the list of allowed VLANs, preventing traffic from those VLANs from passing over the trunk. To restrict the traffic a trunk carries, use the remove vlan-list parameter with the switchport trunk allowed vlan command.

114

Chapter 2: VLANs and VTP

In Example 2-16, the switchport trunk allowed command is used to remove VLAN 3 and then remove VLANs 6 to 10 from the trunk. This is verified by using the show runningconfig command.
Example 2-16 Specifying the VLANs Allowed Over the Trunk Link
Switch(config-if)#switchport trunk allowed vlan remove 3 Switch(config-if)#switchport trunk allowed vlan remove 6-10 Switch#show running-config <output omitted> hostname Switch ! ip subnet-zero ! ! ! interface FastEthernet0/1 ! interface FastEthernet0/2 ! interface FastEthernet0/3 switchport trunk allowed vlan 1,2,4,5,11-1005 switchport mode trunk

To remove a large number of VLANs from a trunk link, it is often faster to clear all VLANs from the trunk link before specifying the VLANs that are supposed to be on the link. The command syntax is switchport trunk allowed vlan {add vlan-list | all | except vlan-list | remove vlan-list}.

Basics of Dynamic Trunking Protocol
Ethernet trunk interfaces support several different trunking modes:
■ ■ ■ ■ ■ ■

Access Dynamic desirable (the default mode on Catalyst 2950 and 3550) Dynamic auto Trunk Nonnegotiate Dot1q-tunnel (not an option on the Catalyst 2950)

VLAN Trunking and Dynamic Trunking Protocol

115

Using these different trunking modes, an interface can be set to trunking or nontrunking or can be set to negotiate trunking with the neighboring interface. To automatically negotiate trunking, the interfaces must be in the same VTP domain. Trunk negotiation is managed by DTP, which is a Cisco-proprietary point-to-point protocol. These various modes are configured using the switchport mode interface command, as shown in Example 2-17. Table 2-4 shows the various DTP modes.
Example 2-17 Configuring Trunking Modes
3550-Switch(config-if)#switchport mode ? access dot1q-tunnel dynamic trunk Set trunking mode to ACCESS unconditionally Set trunking mode to DOT1Q TUNNEL unconditionally Set trunking mode to dynamically negotiate access or trunk mode Set trunking mode to TRUNK unconditionally

2950-Switch(config-if)#switchport mode ? access dynamic trunk Set trunking mode to ACCESS unconditionally Set trunking mode to dynamically negotiate access or trunk mode Set trunking mode to TRUNK unconditionally

Table 2-4 DTP Modes

Command

Description

switchport mode access

Puts the interface (access port) into permanent nontrunking mode. The interface generates DTP frames, negotiating with the neighboring interface to convert the link into a nontrunk link. The interface becomes a nontrunk interface even if the neighboring interface does not agree to the change. Makes the interface actively attempt to convert the link into a trunk link. The interface becomes a trunk interface if the neighboring interface is set to trunk, desirable, or auto mode. This is the default mode for all Ethernet interfaces. If the neighboring interface is set to access or non-negotiate mode, the link becomes nontrunking. Makes the interface willing to convert the link to a trunk link if the neighboring interface is set to trunk or desirable mode. Otherwise, the link becomes nontrunking.
continues

switchport mode dynamic desirable

switchport mode dynamic auto

116

Chapter 2: VLANs and VTP

Table 2-4 DTP Modes (Continued)

Command

Description

switchport mode trunk

Puts the interface into permanent trunking mode and negotiates to convert the link into a trunk link. The interface becomes a trunk interface even if the neighboring interface does not agree to the change. Prevents the interface from generating DTP frames. You can use this command only when the interface switchport mode is access or trunk. You must manually configure the neighboring interface as a trunk interface to establish a trunk link; otherwise, the link is nontrunking.

switchport nonegotiate

DTP Trunk and Access Modes
Using the switchport mode interface command, two of the DTP modes set trunking to off or on, as demonstrated in Example 2-18.
Example 2-18 Trunking Is Turned Off or On Based on the Switchport Mode
Switch(config-if)#switchport mode access ! Sets trunking OFF Switch(config-if)#switchport mode trunk ! Sets trunking ON

Access Mode
In Example 2-19, Switch A and Switch B are connected on their FastEthernet 0/1 interfaces. If both switches are set to access mode, the link is a nontrunking link. Both interfaces must be on the same VLAN, and only that single VLAN is transmitted across the link.
Example 2-19 The switchport mode access Command Is Used for Access Links
SwitchA(config)#inter fa 0/1 SwitchA(config-if)#switchport mode access SwitchB(config)#inter fa 0/1 SwitchB(config-if)#switchport mode access

VLAN Trunking and Dynamic Trunking Protocol

117

Trunk Mode
If both switches are set to trunk mode, as shown in Example 2-20, the link is a trunking link. By default, all VLANs are transmitted across this trunk.
Example 2-20 The switchport mode trunk Command Is Used for Trunk Links
SwitchA(config)#inter fa 0/1 SwitchA(config-if)#switchport mode trunk SwitchB(config)#inter fa 0/1 SwitchB(config-if)#switchport mode trunk

NOTE For switches such as the Catalyst 3550 that are capable of either 802.1Q or ISL trunking encapsulation, the switchport trunk encapsulation [dot1q | isl | negotiate] interface command must be used before the switchport mode trunk command.

DTP Combinations
All the DTP modes and their various combinations can be somewhat confusing. Looking at some of the basic combinations can help clarify this.

The Default: Desirable Mode
By default, Ethernet interfaces on most Cisco switches are set to desirable mode. This is true for both the Catalyst 2950 and 3550 switches. Desirable mode creates a trunk link if the neighboring interface is set to desirable, trunk, or auto mode. Because both interfaces by default are in desirable mode, this means a link between two Cisco switches automatically becomes a trunk link unless configured otherwise.

Combinations
Table 2-5 shows the various DTP trunking modes and the results of the different combinations. One combination that could result in traffic being blocked from transmitting the link is if one interface is in access mode and the neighboring interface is in trunk mode. In this case, the access mode interface only wants to do nontrunking, whereas the trunk mode interface only wants to do trunking. This is not a recommended combination and might create unexpected results. Traffic might or might not be able to transit the link depending on several factors, such as the spanning-tree root bridge location. In some situations, the link works as a nontrunking link even though one interface is in access mode and the other interface is in trunk mode. In other situations, spanning tree puts the access mode port into blocking mode and traffic does not transit the link to the neighboring trunk mode interface. To get consistent results, regardless of the topology, it is recommended that you never have a combination of access mode and trunk mode on the interfaces of two neighboring switches.

118

Table 2-5 The DTP Trunking Modes Configured on Either End of a Link Determine the Link’s Operational Mode

Administrative Auto Desirable Trunk (On) Access (Off) (Access)

Nonnegotiate

Nonnegotiate (Trunk)

Chapter 2: VLANs and VTP

Mode

Auto

Static access (NT) Trunk Trunk Static access Static access Unexpected results Unexpected results Trunk Static access Unexpected results Static access Unexpected results Trunk Trunk Unexpected results Static access Static access Unexpected results Trunk Trunk Static access

Trunk

Trunk

Static access

Static access Static access Unexpected results Static access Static access Unexpected results

Unexpected results Unexpected results Trunk Unexpected results Unexpected results Trunk

Desirable

Trunk (On)

Access (Off)

Nonnegotiate

(Access)

Nonnegotiate

(Trunk)

VLAN Trunking and Dynamic Trunking Protocol

119

The only modes that actually negotiate trunking between adjacent switches are trunk, dynamic desirable, and dynamic auto. Even though the switchport mode trunk command does not modify its own interface to be anything other than trunking, it sends out DTP frames to attempt to negotiate the other end of the link to be a trunking interface. In Example 2-21, the show interface switchport command shows the negotiation of trunking set to on. The interface always attempts to negotiate trunking on the link unless the switchport nonegotiate command is configured on the interface.
Example 2-21 Without the switchport nonegotiate Command, Trunking Negotiation Is Turned On
2950-1(config-if)#switchport mode dynamic auto 2950-1(config-if)#end 2950-1#show interface switchport Name: Fa0/1 Switchport: Enabled Administrative Mode: dynamic auto Operational Mode: static access Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: native Negotiation of Trunking: on Access mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Administrative private-vlan host-assocation: none Administrative private-vlan mapping: none Operational private-vlan: none Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001

Nonegotiate
The switchport nonegotiate command prevents the interface from generating DTP frames, turning off the negotiation of trunking. This can be viewed with the show interface switchport command. Example 2-22 shows the switchport nonegotiate interface command, which can be used only on an interface that is in access or trunk mode, previously configured with either the switchport mode access command or the switchport mode trunk command.

120

Chapter 2: VLANs and VTP

Example 2-22 The switchport nonegotiate Command Prevents the Interface from Generating DTP Frames
2950-1(config-if)#switchport mode access 2950-1(config-if)#switchport mode nonegotiate 2950-1(config-if)#end

2950-1#show interface switchport Name: Fa0/1 Switchport: Enabled Administrative Mode: static access Operational Mode: static access Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: native Negotiation of Trunking: Off Access mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Administrative private-vlan host-assocation: none Administrative private-vlan mapping: none Operational private-vlan: none Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001

If an interface is configured with both the switchport mode trunk command and the switchport nonegotiate command, the interface on the neighboring switch must be configured as with the switchport mode trunk command to establish a trunk link. Otherwise, the link is a nontrunking link. To enable trunking to a device that does not support DTP, the switchport mode trunk and switchport nonegotiate interface configuration commands should be used to cause the interface to become a trunk but not to generate DTP frames. The switchport mode access and switchport nonegotiate interface configuration commands should be used when configuring a nontrunking interface to another switch that does not support DTP.

Verifying DTP
The show interface switchport command, shown in Example 2-23, can be used to verify the following DTP information and status:
■ ■ ■ ■

Administrative mode Operational mode Administrative trunking encapsulation Negotiation of trunking

VLAN Trunking and Dynamic Trunking Protocol

121

Example 2-23 The show interface switchport Command Is Extremely Useful for Verifying LAN Configuration
2950-1(config-if)#switchport mode dynamic auto 2950-1(config-if)#end 2950-1#show interface switchport Name: Fa0/1 Switchport: Enabled Administrative Mode: dynamic auto Operational Mode: static access Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: native Negotiation of Trunking: on Access mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Administrative private-vlan host-assocation: none Administrative private-vlan mapping: none Operational private-vlan: none Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001

The Administrative Mode displays the interface’s DTP state. The default on most Cisco switches is dynamic desirable. The DTP mode can be set using the switchport mode interface command. The Operational Mode shows whether the interface is in a trunking or nontrunking state. If the Operational Mode is static access, this interface considers the link nontrunking. If the operational mode is trunk, as shown in the output of the show interface switchport command in Example 2-24, this interface is considered a trunking link. The show interface trunk command can be used to display all the interfaces on the switch that have the Operational Mode set to trunk, as shown in Example 2-24. The Administrative Trunking Encapsulation displays the trunking protocol, 802.1Q or ISL, that is used on this interface if the operational mode is trunk. If the switch’s Operational Mode is static access, nontrunking, the trunking protocol that Administrative Trunking Encapsulation displays is not currently being used on the link. The Negotiation of Trunking shows whether the interface is willing to negotiate trunking by sending DTP frames. By default, the interface negotiates trunking and the Negotiation of Trunking shows as on. Use the switchport nonegotiate interface command to turn off this negotiation.

122

Chapter 2: VLANs and VTP

Example 2-24 The show interface trunk Command Displays Useful Details About a Trunking Interface
2950-1#show interface switchport Name: Fa0/1 Switchport: Enabled Administrative Mode: dynamic desirable Operational Mode: trunk Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: dot1q Negotiation of Trunking: on Access mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Administrative private-vlan host-assocation: none Administrative private-vlan mapping: none Operational private-vlan: none Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001

2950-1#show interface trunk

Port Fa0/1

Mode desirable

Encapsulation 802.1q

Status trunking

Native vlan 1

Port Fa0/1

Vlans allowed on trunk 1-4094

Port Fa0/1

Vlans allowed and active in management domain 1

Port

Vlans in spanning tree forwarding state and not pruned

Fa0/1

1

VLAN Identification
Although Ethernet VLAN frames are by far the most common type of tagged Layer 2 LAN traffic, FDDI and Asynchronous Transfer Mode (ATM) also have their own tagging mechanism for transporting traffic for multiple subnets over a single link. This section describes the various tagging mechanisms used in LAN networks.

VLAN Identification

123

VLAN Frame Identification
VLAN identification logically identifies which packets belong to which VLAN group. Multiple trunking methods exist (as shown in Table 2-6):
■ ■ ■ ■

ISL IEEE 802.1Q IEEE 802.10 ATM LAN Emulation (LANE)

Table 2-6 Different LAN Media Use Different VLAN Encapsulation Methods

Identification Method Encapsulation

Tagging (Insertion into Frame) Media

802.1Q ISL 802.10 LANE

No Yes No No

Yes No No No

Ethernet Ethernet FDDI ATM

ISL is a Cisco-proprietary encapsulation protocol for trunking between switches. ISL prepends a 26-byte header and appends a 4-byte cyclic redundancy check (CRC) to each frame. ISL is supported in Cisco switches and routers. The IEEE 802.1Q protocol is an IEEE standard method for identifying VLANs by inserting a VLAN identifier into the frame header. This process is called frame tagging or internal tagging. The IEEE 802.10 standard is a method of transporting VLAN information inside the standard 802.10 frame (FDDI). The VLAN information is written to the Security Association Identifier (SAID) portion of the 802.10 frame. This method is typically used to transport VLANs across FDDI backbones. LAN Emulation (LANE) is an ATM Forum standard that can be used to transport VLANs over ATM networks, in which case they are called Emulated LANs (ELANs).

Inter-Switch Link (ISL)
ISL is a Cisco-proprietary protocol used to interconnect multiple switches and maintain VLAN information as traffic travels between switches on trunk links. This technology provides one method for multiplexing bridge groups (VLANs) over a high-speed backbone. It is

124

Chapter 2: VLANs and VTP

defined for Fast Ethernet and Gigabit Ethernet, as is IEEE 802.1Q. ISL has been available on Cisco routers since Cisco IOS Release 11.1. With ISL, an Ethernet frame is encapsulated with a header that transports VLAN IDs between switches and routers, as shown in Figure 2-25.
Figure 2-25 The Cisco-Proprietary ISL Frame Format Has a 26-Byte Header 26-Byte ISL Header 4-Byte CRC

DA

SA

Ethernet/Length

Data

FCS

DA = Destination Address SA = Source Address FCS = Frame Check Sequence

ISL does add overhead to the packet as a 26-byte header containing a 10-bit VLAN ID. In addition, a 4-byte CRC is appended to the end of each frame, as shown in Figure 2-26. This CRC is in addition to any frame checking that the Ethernet frame requires.
Figure 2-26 The ISL Frame Format Includes a Field for the VLAN ID
40 Bits 4 Bits 4 48 16 Bits Bits Bits 24 Bits 24 Bits 15 Bits 1 Bit 16 Bits 16 Bits Variable Length 32 Bits

DA TYPE USER SA LEN SNAP/ HSA VLAN BPDU/ INDX Reserved Encapsulated FCS LLC ID CDP Frame (CRC)

The fields in an ISL header identify the frame as belonging to a particular VLAN:

DA—A 40-bit multicast address with a value of 0x01-00-0C-00-00 that indicates to the receiving Catalyst switch that the frame is an ISL encapsulated frame. Type—A 4-bit value indicating the source frame type. Values include 0 0 0 0 (Ethernet), 0 0 0 1 (Token Ring), 0 0 1 0 (FDDI), and 0 0 1 1 (ATM). User—A 4-bit value usually set to 0. It can be used for special situations when transporting Token Ring. SA—The 802.3 MAC address of the transmitting Catalyst switch. This is a 48-bit value. Length—The LEN field is a 16-bit value indicating the length of the user data and ISL header, excluding the DA, Type, User, SA, Length, and ISL CRC bytes. SNAP—A 3-byte field with a fixed value of 0xAA-AA-03. HSA—This 3-byte value duplicates the high-order bytes of the ISL SA field.

■ ■

VLAN Identification

125

VLAN—A 15-bit value to reflect the numerical value of the source VLAN that the user frame belongs to. Note that only 10 bits are used. BPDU—A single-bit value that, when set to 1, indicates that the receiving Catalyst switch should immediately examine the frame at an end station because the data contains either a spanning tree, ISL, VTP, or CDP message. Index—Indicates what port the frame exited from the source Catalyst switch. Reserved—Token Ring and FDDI frames have special values that need to be transported over the ISL link. These values, such as AC and FC, are carried in this field. The value of this field is 0 for Ethernet frames. User Frame—The original user data frame is inserted here, including the frame’s frame check sequence (FCS). CRC—ISL calculates a 32-bit CRC for the header and user frame. This double-checks the message’s integrity as it crosses an ISL trunk. It does not replace the User Frame CRC.

■ ■

A VLAN ID is added only if the frame is forwarded out a port configured as a trunk link. If the frame is to be forwarded out a port configured as an access link, the ISL encapsulation is removed.

The IEEE 802.1Q Protocol
The official name of the IEEE 802.1Q protocol is the Standard for Virtual Bridged LocalArea Networks. It relates to the capability to carry the traffic of more than one subnet down a single cable. The IEEE 802.1Q committee defined this method of multiplexing VLANs in an effort to provide multivendor VLAN support. Both ISL and IEEE 802.1Q tagging perform explicit tagging, meaning that the frame is tagged with VLAN information explicitly. However, whereas ISL uses an external tagging process that does not modify the existing Ethernet frame, IEEE 802.1Q uses an internal tagging process that does modify the Ethernet frame. This internal tagging process is what allows IEEE 802.1Q tagging to work on both access and trunk links, because the frame appears to be a standard Ethernet frame. The IEEE 802.1Q frame-tagging scheme also has significantly less overhead than the ISL tagging method. As opposed to the 30 bytes added by ISL, 802.1Q inserts only an additional 4 bytes into the Ethernet frame, as shown in Figure 2-27.
Figure 2-27 IEEE 802.1Q VLAN Encapsulation Is the Most Common Format Currently Used
Initial MAC Address 2-Byte TPID 2-Type TCI Initial Type/Data New CRC

126

Chapter 2: VLANs and VTP

The IEEE 802.1Q header contains a 4-byte tag header that contains the following:

A 2-byte tag protocol identifier (TPID) with a fixed value of 0x8100 that indicates that the frame carries the 802.1Q/802.1p tag information. A 2-byte tag control information (TCI) that contains the following: — 3-bit user priority — 1-bit canonical format indicator (CFI) — 12-bit VLAN identifier (VID) that uniquely identifies the VLAN to which the frame belongs

The 802.1Q standard can create an interesting scenario on the network. Recalling that the maximum size for an Ethernet frame as specified by IEEE 802.3 is 1518 bytes, this means that if a maximum-sized Ethernet frame gets tagged, the frame size is 1522 bytes, a number that violates the IEEE 802.3 standard. To resolve this issue, the 802.3 committee created a subgroup called 802.3ac to extend the maximum Ethernet size to 1522 bytes. Network devices that do not support a larger frame size process the frame successfully but might report these anomalies as a “baby giant.”

The IEEE 802.10 Protocol
VLANs can be multiplexed across an FDDI backbone supporting the IEEE 802.10 protocol. Catalyst 5000 and 6000 family switches support 802.10 trunking. FDDI interfaces that support 802.10 make selective forwarding decisions within a network domain based on a VLAN identifier. This VLAN identifier is the user-configurable 4-byte IEEE 802.10 SAID. The SAID identifies traffic as belonging to a particular VLAN. On a Catalyst 5000 or 6000, if an FDDI module receives a packet containing a VLAN SAID that maps to a locally supported Ethernet VLAN on the switch, the FDDI module translates the packet into Ethernet format and forwards it across the switch backplane to the Ethernet module. FDDI modules filter the packets they receive from reaching the backplane if the VLAN SAIDs in the packets do not map to a locally supported VLAN. A SAID is applied when a frame from an Ethernet VLAN needs to cross an FDDI backbone, as shown in Figure 2-28. Switch 1 must forward a packet from the Ethernet Module, Port 1, Slot 2, to the FDDI Module, Port 1, Slot 5. In this example, the translation of Ethernet VLAN 2 to FDDI VLAN 22 must be specified. The VLAN SAID must be identical on both FDDI modules. Because 802.10 FDDI interface links can also operate as ISL trunks, multiple VLAN translations can take place over a single link.

VLAN Identification

127

Figure 2-28 IEEE 802.10 Is the VLAN Encapsulation Method Used with FDDI
Ethernet Module Slot 2 Port 1 VLAN 2 SAID 100002 FDDI Module Slot 5 Port 1 VLAN 22 SAID 2 FDDI Module Slot 3 Port 1 VLAN 22 SAID 2 FDDI Module Slot 4 Port 11 VLAN 2 SAID 100002

FDDI Catalyst Switch 1 Catalyst Switch 2

FDDI modules also support one native (nontrunk) VLAN, which handles all non-802.10 encapsulated FDDI traffic.

LAN Emulation (LANE)
ATM LANE is a standard defined by the ATM Forum that gives two stations attached via ATM the same capabilities they normally would have with legacy LANs, such as Ethernet and Token Ring. As the name suggests, the function of the LANE protocol is to emulate a LAN on top of an ATM network. Specifically, the LANE protocol defines mechanisms for emulating either an IEEE 802.3 Ethernet or 802.5 Token Ring LAN. The LANE protocol defines a service interface for network layer protocols that is identical to that of existing LANs. Data sent across the ATM network is encapsulated in the appropriate LAN MAC format. In other words, the LANE protocols make an ATM network look and behave like an Ethernet or Token Ring LAN, albeit one operating much faster than standard Ethernet or Token Ring LAN networks (see Figure 2-29). An emulated LAN (ELAN) provides Layer 2 communication between all users on an ELAN. One or more ELANs can run on the same ATM network. However, each ELAN is independent of the others, and users on separate ELANs cannot communicate directly. As with a VLAN, communication between ELANs is possible only through routers or bridges. Because an ELAN provides Layer 2 communication, it can be equated to a broadcast domain. VLANs can also be thought of as broadcast domains. This makes it possible to map an ELAN to a VLAN on Layer 2 switches with different VLAN multiplexing technologies such as ISL or 802.10. In addition, IP subnets and Internetwork Packet Exchange (IPX) networks that are defined on Layer 3-capable devices such as routers frequently map into broadcast domains. This makes it possible to assign an IP subnetwork or IP network to an ELAN.

128

Chapter 2: VLANs and VTP

Figure 2-29 LANE Is the Mechanism Used by ATM for VLAN Encapsulation LAN Emulation Client Catalyst 6500 LAN Emulation Services LECS, LES, BUS ATM-Attached Desktop

Layer 3 Services

Enterprise and Department Servers

ATM Core LAN Emulation Clients Catalyst 6500 Catalyst 6500 Catalyst 6500

LAN Switches with ATM Uplinks

It is important to note that LANE does not attempt to emulate the access method of the specific LAN concerned (that is, carrier sense multiple access collision detect [CSMA/CD] for Ethernet or token passing for IEEE 802.5). LANE requires no modifications to higher-layer protocols to enable their operation over an ATM network. Because the LANE service presents the same service interface of existing MAC protocols to network layer drivers, such as a network driver interface specification (NDIS) or Open Data-Link Interface (ODI) driver interface, no changes are required for these drivers.

VLAN Trunking Protocol (VTP)
The role of VTP is to maintain VLAN configuration consistency across the entire network. VTP is a messaging protocol that uses Layer 2 trunk frames to manage the addition, deletion, and renaming of VLANs on a network-wide basis from a centralized switch that is in VTP server mode. VTP is responsible for synchronizing VLAN information within a VTP domain. This reduces the need to configure the same VLAN information on each switch.

VTP Benefits
VTP minimizes the possible configuration inconsistencies that arise when changes are made. These inconsistencies can result in security violations, because VLANs can crossconnect

VLAN Trunking Protocol (VTP)

129

when duplicate names are used. VLANs also could become internally disconnected when they are mapped from one LAN type to another, such as Ethernet to ATM LANE ELANs or FDDI 802.10 VLANs. VTP provides a mapping scheme that enables seamless trunking within a network employing mixed-media technologies. VTP provides the following benefits:
■ ■ ■ ■ ■

VLAN configuration consistency across the network Mapping scheme that allows a VLAN to be trunked over mixed media Accurate tracking and monitoring of VLANs Dynamic reporting of added VLANs across the network Plug-and-play configuration when adding new VLANs

As beneficial as VTP can be, it does have disadvantages that are normally related to STP. The greatest risk is a bridging loop propagating throughout the entire campus network. Because Cisco switches run an instance of STP for each VLAN, and because VTP propagates VLANs across the campus LAN, VTP effectively creates more opportunities for a bridging loop to occur. Network designers and administrators must balance the ease of administration made possible by VTP with the risk of a large, potentially unstable STP domain. Before you create VLANs on the switch that will be propagated via VTP, you must set up a VTP domain. A VTP domain for a network is a set of all contiguously trunked switches with the same VTP domain name. All switches in the same management domain share their VLAN information with each other, and a switch can participate in only one VTP management domain. Switches in different domains do not share VTP information. Using VTP, each Catalyst family switch advertises the following on its trunk ports:
■ ■ ■

Management domain Configuration revision number Known VLANs and their specific parameters

VTP Operation
A VTP domain is made up of one or more interconnected devices that share the same VTP domain name. A switch can be configured to be in one VTP domain only. Global VLAN information is propagated across the network by way of connected switch trunk ports. When VTP messages are transmitted to other switches in the network, the VTP message is encapsulated in a trunking protocol frame such as ISL or IEEE 802.1Q, as shown in Figure 2-30.

130

Chapter 2: VLANs and VTP

Figure 2-30 VTP Messages Are Encapsulated in ISL or IEEE 802.1Q Frames ISL Header 26 Bytes Ethernet Header 14 Bytes LLC Header 3 Bytes SNAP Header 3 Bytes Varied Length VTP Header VTP Message CRC

The VTP header varies, depending on the type of VTP message, but generally, four items are found in all VTP messages:
■ ■

VTP protocol version—Either version 1 or 2. VTP message type—Indicates one of four types (summary advertisement, subset advertisement, advertisement request, and/or join message). Management domain name length—Indicates the size of the name that follows. Management domain name—The name configured for the management domain.

■ ■

It is important to note that switches can be configured not to accept VTP information. These switches forward VTP information on trunk ports to ensure that other switches receive the update, but the switches do not modify their database, nor do they send an update indicating a change in VLAN status. This is called transparent mode. By default, management domains are set to a nonsecure mode, meaning that the switches interact without using a password. Adding a password automatically sets the management domain to secure mode. A password must be configured on every switch in the management domain to use secure mode. Detecting the addition of VLANs within the advertisements notifies the switches that they should be prepared to receive traffic on their trunk ports with the newly defined VLAN IDs, emulated LAN names, or 802.10 SAIDs. For example, in Figure 2-31, C6500-3 transmits a VTP database entry with additions or deletions to C6500-1 and C6500-2. The configuration database has a revision number that is notification +1. A higher configuration revision number indicates that the VLAN information that is being sent is more current than the stored copy. Any time a switch receives an update that has a higher configuration revision number, the switch overwrites the stored information with the new information being sent in the VTP update.

VLAN Trunking Protocol (VTP)

131

Figure 2-31 The VTP Configuration Revision Number Iterates When VLAN Information Is Changed on a VTP Server

N+1

C6500-3 BCMSN Domain
N+1 1/1 3/1 3/2 2/2 N+1 5/1

C6500-6 CE_ Domain
4/1 4/2 1/1

1/2

2/1

C6500-1

C6500-2

C6500-4

C6500-5

To use VTP, a VTP domain name must be assigned to each switch. VTP domain names are case-sensitive. VTP information remains in the VLAN management domain. The following are conditions for a VTP domain:

Each Catalyst switch in a domain must have the same VTP domain name, whether learned or configured. The Catalyst switches must be adjacent, meaning that all switches in the VTP domain form a contiguous tree in which every switch is connected to every other switch in the domain via the tree. Trunking must be enabled between all Catalyst switches.

If any one of these conditions is not met, the VTP domain becomes disconnected, and information does not travel between the separate parts of the network.

VTP Modes
Switches can operate in any one of the following three VTP modes, as described in Table 2-7 and the following sections:
■ ■ ■

Server Client Transparent

132

Chapter 2: VLANs and VTP

Table 2-7 VTP Mode Characteristics

Feature

Server

Client

Transparent

Source VTP messages Listen to VTP messages Create VLANs Remember VLANs
*

Yes Yes Yes Yes

Yes Yes No No

No No Yes* Yes*

Locally significant only

VTP Server Mode
By default, a Catalyst switch is in VTP server mode and in the “no management domain” state until the switch receives an advertisement for a domain over a trunk link or a VLAN management domain is configured. A switch that has been put in VTP server mode and that has a domain name specified can create, modify, and delete VLANs. VTP servers can also specify other configuration parameters, such as VTP version and VTP pruning for the entire VTP domain. VTP information is stored in nonvolatile RAM (NVRAM). VTP servers advertise their VLAN configuration to other switches in the same VTP domain and synchronize the VLAN configuration with other switches based on advertisements received over trunk links. When a change is made to the VLAN configuration on a VTP server, it is propagated to all switches in the VTP domain. VTP advertisements are transmitted out all trunk connections, including ISL, IEEE 802.1Q, IEEE 802.10, and ATM LANE trunks. A critical parameter governing VTP function is the VTP configuration revision number. This 32-bit number indicates the particular revision of a VTP configuration. A configuration revision number starts at 0 and increments by 1 with each modification until it reaches 4294927295, at which point it cycles back to 0 and starts incrementing again. Each VTP device tracks its own VTP configuration revision number; VTP packets contain the sender’s VTP configuration number. This information determines whether the received information is more recent than the current version. To reset a configuration revision number to 0, simply disable trunking, change the VTP domain name, change it back to the original name, and reenable trunking. If the switch receives a VTP advertisement over a trunk link, it inherits the VTP domain name and configuration revision number. The switch ignores advertisements that have a different VTP domain name or an earlier configuration revision number.

VLAN Trunking Protocol (VTP)

133

VTP Client Mode
The VTP client maintains a full list of all VLANs within the VTP domain, but it does not store the information in NVRAM. VTP clients behave the same way as VTP servers, but it is not possible to create, change, or delete VLANs on a VTP client. Any changes made must be received from a VTP server advertisement.

VTP Transparent Mode
VTP transparent switches do not participate in VTP. A VTP transparent switch does not advertise its VLAN configuration and does not synchronize its VLAN configuration based on received advertisements. However, in VTP version 2, transparent switches do forward VTP advertisements that the switches receive out their trunk ports. VLANs can be configured on a switch in VTP transparent mode, but the information is local to the switch (VLAN information is not propagated to other switches) and is stored in NVRAM. There is also an “off” VTP mode in which switches behave the same as in VTP transparent mode, except that VTP advertisements are not forwarded.

Adding a Switch to a VTP Domain
Use caution when inserting a new switch into an existing domain. To prepare a switch to enter an existing VTP domain, follow these steps: Step 1 Delete the VLAN database, erase the startup configuration, and power-cycle the switch. This avoids potential problems resulting from residual VLAN configurations or from adding a switch with a higher VTP configuration revision number that could result in the propagation of incorrect VLAN information. From privileged mode, issue the delete vlan.dat and erase startup-config commands, and then power-cycle the switch. Determine the switch’s VTP mode of operation and include it when setting the VTP domain name information on the switch. If you leave the switch in server mode, be sure to verify that the configuration revision number is set to 0 before adding the switch to the VTP domain. It is generally recommended that you have several servers in the domain, with all other switches set to client mode for the purposes of controlling VTP information. It is also highly recommended that you use secure mode in your VTP domain. Assigning a password to the domain accomplishes this. It prevents unauthorized switches from participating in the VTP domain. From privileged mode or VLAN configuration mode, use the vtp password password command.

Step 2

Step 3

134

Chapter 2: VLANs and VTP

VTP Advertisements
Periodic VTP advertisements are sent out each trunk port with the multicast destination MAC address 01-00-0C-CC-CC-CC. VTP advertisements contain the following configuration information:
■ ■ ■ ■ ■ ■

VLAN IDs (ISL and 802.1Q) Emulated LAN names (ATM LANE) 802.10 SAID values (FDDI) VTP domain name VTP configuration revision number VLAN configuration, including the maximum transmission unit (MTU) size for each VLAN Frame format

VTP messages are encapsulated in either ISL frames or IEEE 802.1Q frames. VTP messages are sent with the following Ethernet frame field values:
■ ■

Multicast destination MAC address 01-00-0C-CC-CC-CC Destination Service Access Point (DSAP) 0xAA in the Logical Link Control (LLC) header Source Service Access Point (SSAP) 0xAA in the LLC header Organizational Unique Identifier (OUI) of 00-00-0C (for Cisco) in the Subnetwork Access Protocol (SNAP) header Ethertype of 2003 in the SNAP header

■ ■

VTP packets can be encapsulated into an ISL frame. The VTP header’s format varies, depending on the type of VTP message. However, all packets contain the following fields in the header:
■ ■ ■ ■

VTP protocol version—1 or 2 VTP message type Management domain length Management domain name

VTP uses the following message types:
■ ■ ■ ■

Summary advertisements Subset advertisements Advertisement requests VTP join messages

VLAN Trunking Protocol (VTP)

135

VTP join messages, which rely on the VTP pruning protocol, are examined in the “VTP Configuration and VTP Pruning” section. Advertisements on factory-default VLANs are based on media types. User ports should not be configured as VTP trunks. There are two types of advertisements:
■ ■

Requests from clients that want information at bootup Response from servers

Figure 2-32 illustrates advertisement requests, summary advertisements, and subset advertisements.
Figure 2-32 Advertisement Requests, Summary Advertisements, and Subset Advertisements Are Used with VTP Operation Advertisement Request
1 Version 2 Code 3 Rsvd 4 MgmtD Len

Management Domain Name (Zero-Padded to 32 Bytes) Start Value

Summary Advertisement
1 Version 2 Code 3 Followers 4 MgmtD Len

Management Domain Name (Zero-Padded to 32 Bytes) Configuration Revision Number Updater Identity Update Timestamp (12 Bytes) MD5 Digest (16 Bytes)

Subset Advertisement
1 Version 2 Code 3 Seq-Num 4 MgmtD Len

Management Domain Name (Zero-Padded to 32 Bytes) Configuration Revision Number VLAN-Info Field 1 Updater Identity Update Timestamp (12 Bytes) VLAN-Info Field N

Advertisement Requests
A switch issues a VTP advertisement request in the following situations:
■ ■ ■

The switch has been reset. The VTP domain name has been changed. The switch has received a VTP summary advertisement with a higher configuration revision number than its own.

136

Chapter 2: VLANs and VTP

The server responds with summary and subset advertisements (refer to Figure 2-32):
■ ■ ■

Code is 0x03 for advertisement request (type 3). Rsvd is reserved and always set to 0. Start-Value is used in cases in which there are several subset advertisements. If subset advertisements n is the first advertisement that has not been received in a sequence of advertisements, an advertisement request is sent for advertisements starting with n. If the start value is 0, all subset advertisements are sent for the particular management domain.

Summary Advertisements
By default, Catalyst switches issue summary advertisements every 5 minutes. They inform neighbor switches of the current domain name and the configuration revision number. When the switch receives a summary advertisement packet, as shown in Figure 2-33, it compares the VTP domain name. If the name is different, the switch simply ignores the packet. If the name is the same, the switch then compares the configuration revision. If its own configuration revision is higher or equal, the packet is ignored. If it is lower, an advertisement request is sent.
Figure 2-33 Summary Advertisements Include the VTP Domain Name and the Configuration Revision Number Number of Subset Advertisement Messages Domain Name Length

Version

Code

Management Domain Name (Zero-Padded to 32 Bytes) Configuration Revision Number Updater Identity Update Timestamp (12 Bytes) MD5 Digest (16 Bytes)

The fields illustrated in Figure 2-33 are defined as follows:
■ ■

Version indicates the VTP version, which is either 1 or 2. Code indicates which of the four VTP message types is included. Here, 0x01 or type 1 indicates summary advertisements. Number of Subset Advertisement Messages (type 2) follows the Code field. The value can range from 0 to 255; 0 indicates that no subset advertisements follow. A Catalyst transmits the subset advertisement only if there is a change in the system or as a response to an advertisement request.

VLAN Trunking Protocol (VTP)

137

■ ■ ■ ■

Domain Name Length specifies the length of the VTP domain name. Management Domain Name specifies the VTP domain name. The Configuration Revision Number field is 32 bytes. The Updater Identity is the IP address of the last switch that incremented the configuration revision. Update Timestamp is the date and time of the last increment of the configuration revision. MD5 Digest consists of a message-digest hash—a function of the VTP password and the VTP header contents (excluding the MD5 Digest field). If the receiving Catalyst hash computation does not match, the packet is discarded.

Subset Advertisements
When a VLAN is added, changed, or deleted on a VTP server, the configuration revision number is incremented, and a summary advertisement is issued, followed by one or several subset advertisements. Subset advertisements are also triggered by suspending or activating a VLAN, changing its name, or changing the MTU. A subset advertisement contains a list of VLANs and corresponding VLAN information. If there are several VLANs, as shown in Figure 2-34, more than one subset advertisement might be required to advertise all the information.
Figure 2-34 Multiple VLANs Might Require Several VTP Subset Advertisements
Version Code Seq-Number Domain Name Length

Management Domain Name (Zero-Padded to 32 Bytes) Configuration Revision Number VLAN-info Field 1 VLAN-info Field N

. .

The VLAN-info Field Contains Information for Each VLAN and Is Formatted as Follows:
Info Length ISL VLAN-ID 802.10 Index VLAN-Name (Padded with Zeros to Multiple of 4 Bytes) Status VLAN-Type MTU Size VLAN-Name Len

The fields in a VTP subset advertisement are as follows:
■ ■

Code is 0x02 for subset advertisement (type 2). Seq-Number represents the packet’s sequence number in the stream of subset advertisements following a summary advertisement. The sequence starts with 1. The receiving Catalyst uses this value to ensure that it receives all subset advertisements. If it does not receive all the subsets, it requests a resend, starting with a specific subset advertisement.

138

Chapter 2: VLANs and VTP

VLAN-info fields each contain the following information:
■ ■ ■ ■ ■ ■ ■

The VLAN’s status (active or suspended) VLAN-Type (Ethernet, Token Ring, FDDI, or otherwise) VLAN-Name Len—Length of the VLAN name ISL VLAN-ID—VLAN number of this named VLAN MTU size—Maximum frame size supported for this VLAN 802.10 Index—SAID value used if the frame passed over an FDDI trunk VLAN-name

The VTP subset advertisement lists this information for each individual VLAN, including default VLANs.

VTP Configuration and VTP Pruning
Basic Configuration Steps
The following basic tasks should be carried out before implementing VTP on a network: Step 1 Step 2 Determine the version number of VTP that will be running. Decide if this switch is to be a member of an existing management domain or if a new domain should be created. If a management domain does exist, determine the domain’s name and password. Choose a VTP mode for the switch.

Step 3

Remember too that for VTP to function, ports designated as trunk links also need to be configured.

VTP Configuration Options
VTP can be configured using the following configuration modes:
■ ■

Global configuration mode. VLAN configuration mode. VLAN configuration mode is accessed by entering the vlan database privileged EXEC command.

Example 2-25 demonstrates VTP configuration in global configuration mode.

VTP Configuration and VTP Pruning

139

Example 2-25 VTP Configuration in Global Configuration Mode
Switch#config terminal Switch(config)#vtp version 2 Switch(config)#vtp mode server Switch(config)#vtp domain cisco Switch(config)#vtp password mypassword Switch(config)#end

NOTE The exit or end command can be used to leave VLAN global configuration mode. The exit command must be used to leave VLAN database configuration mode.

Example 2-26 illustrates VTP configuration in VLAN database configuration mode.
Example 2-26 VTP Configuration in VLAN Database Configuration Mode
Switch#vlan database Switch(vlan)#vtp v2-mode Switch(vlan)#vtp server Switch(vlan)#vtp domain cisco Switch(vlan)#vtp password mypassword Switch(vlan)#exit

Lab 2.9.2 Catalyst 2950T and 3550 Series VTP Domain and VLAN Trunking

In this lab exercise, you configure a VLAN trunk between two Cisco Catalyst WS-C2950T-24-EI switches and a Cisco Catalyst WS-C3550-24-EMI switch in CLI mode.

Configuring the VTP Version
Two different versions of VTP can run in the management domain: VTP version 1 and VTP version 2. The two versions are not interoperable in the same VTP domain. The major difference between the two versions is that version 2 introduces support for Token Ring VLANs. If all switches in a VTP domain can run VTP version 2, version 2 needs to be enabled on only one VTP server switch. The version number is propagated to the other VTP version 2-capable switches in the VTP domain. Version 2 should not be enabled unless every switch in the VTP domain supports version 2. The VTP version can be configured from global configuration mode or VLAN database mode on a Cisco IOS-based switch. From there, the VTP version can be changed with the vtp command.

140

Chapter 2: VLANs and VTP

Example 2-27 specifies the VTP version in global configuration mode.
Example 2-27 Specifying the VTP Version in Global Configuration Mode
Switch#config terminal Switch(config)#vtp version 2

Example 2-28 specifies the VTP version in VLAN database configuration mode.
Example 2-28 Specifying the VTP Version in VLAN Database Configuration Mode
Switch#vlan database Switch(vlan)#vtp v2-mode

Configuring the VTP Domain
If the switch being installed is the first switch in the network, the management domain needs to be created. However, if the network has other switches running VTP, the new switch joins an existing management domain. Verify the name of the management domain. If the management domain has been secured, verify and configure its password. To create a management domain or to add a switch to a management domain, use the vtp domain command in global configuration mode or VLAN configuration mode. If a VTP password is in use, it needs to be configured on all switches in the domain. The VTP password is translated using an algorithm resulting in a 16-byte MD5 value carried in all summary advertisements. From privileged mode or VLAN configuration mode, use the vtp password command. To remove the password, use the no vtp password command. The domain name can be up to 32 characters, and the password must be between 8 and 64 characters. Example 2-29 configures the VTP domain and password in global configuration mode.
Example 2-29 Specifying the VTP Domain and Password in Global Configuration Mode
Switch#config terminal Switch(config)#vtp domain cisco Switch(config)#vtp password mypassword

VTP Configuration and VTP Pruning

141

Example 2-30 demonstrates that the VTP domain and password can also be configured in VLAN database configuration mode.
Example 2-30 Specifying the VTP Domain and Password in VLAN Database Configuration Mode
Switch#vlan database Switch(vlan)#vtp domain cisco Switch(vlan)#vtp password mypassword

Configuring the VTP Mode
Here are some general guidelines for choosing a switch’s VTP mode:

If this is the first switch in the management domain and additional switches will be added, set the mode to server. If there are any other switches in the management domain, set the switch mode to client to prevent the new switch from accidentally propagating the incorrect information to your existing network. If a new switch needs to be set up as a VTP server, change the switch’s mode to server after it has learned the correct VLAN information from the network while in client mode. If the switch won’t share VLAN information with any other switch on the network, set it to transparent mode.

To set the correct mode of a Cisco IOS-based switch in global configuration mode, use the vtp mode command, as demonstrated in Example 2-31.
Example 2-31 Specifying the VTP Mode in Global Configuration Mode
Switch#config terminal Switch(config)#vtp mode [client | server | transparent]

To set the correct mode of a Cisco IOS-based switch in VLAN database configuration mode, use the vtp command, as demonstrated in Example 2-32.
Example 2-32 Specifying the VTP Mode in VLAN Database Configuration Mode
Switch#vlan database Switch(vlan)#vtp [client | server | transparent]

142

Chapter 2: VLANs and VTP

Verifying VTP Configuration
The show vtp status command, shown in Example 2-33, is used to verify VTP configuration settings on a Cisco IOS-based switch.
Example 2-33 The show vtp status Command Displays Important VTP Information
Elmhurst#show vtp status VTP Version Configuration Revision : 2 : 0

Maximum VLANs supported locally : 250 Number of existing VLANs VTP Operating Mode VTP Domain Name VTP Pruning Mode VTP V2 Mode VTP Traps Generation MD5 digest : 9 : Transparent : CIT : Enabled : Disabled : Disabled : 0x61 0xEB 0x7B 0x1E 0xX4 0x2D 0x24 0x58

Configuration last modified by 0.0.0.0 at 3-1-93 00:02:53

The show vtp counters command, shown in Example 2-34, can also be used to verify VTP advertisement messages sent and received, as well as configuration errors detected. This command is useful when troubleshooting VTP.
Example 2-34 The show vtp counters Command Displays the Number of VTP Advertisement Requests, Summary Advertisements, Subset Advertisements, and Join Messages Sent and Received
Elmhurst#show vtp counters VTP statistics: Summary advertisements received Subset advertisements received Request advertiements received : 0 : 0 : 0

Summary advertisements transmitted : 0 Subset advertisements transmitted Request advertiements transmitted Number of config revision errors Number of config digest errors Number of V1 summary errors : 0 : 0 : 0 : 0 : 0

VTP Configuration and VTP Pruning

143

Example 2-34 The show vtp counters Command Displays the Number of VTP Advertisement Requests, Summary Advertisements, Subset Advertisements, and Join Messages Sent and Received (Continued)
VTP pruning statisitcs:

Trunk

Join Transmitted Join Received

Summary advts received from non-pruning-capable device

---------------- ---------------- --------------Fa0/2 Po6 0 0 0 0

-------------------------0 0

Default Behavior of a Switch
A switch’s default behavior is to propagate broadcast and unknown packets across the network. This behavior results in a large amount of unnecessary traffic crossing the network. VTP pruning increases bandwidth efficiency by reducing unnecessary flooding of traffic, such as broadcast, multicast, unknown, and flooded unicast packets. VTP pruning increases available bandwidth by restricting flooded traffic to those trunk links that the traffic must use to access the appropriate network devices. By default, VTP pruning is disabled. In a switched network that does not have VTP pruning enabled, broadcasts are sent to switches that do not need to receive them. In Figure 2-35, Port 1 on Switch 1 and Port 2 on Switch 4 are assigned to VLAN 10. A broadcast is sent from the host connected to Switch 1.
Figure 2-35 Ethernet Frames Are Propagated According to How VTP Pruning Is Configured C6500-4 Port 2 VLAN 10

Port 4

C6500-5 Port 5

C6500-2

Port 1 C6500-6 C6500-3 C6500-1 VLAN 10

Switch C6500-1 floods the broadcast. Every switch in the network receives this broadcast, even though Switches C6500-3, C6500-5, and C6500-6 have no ports in VLAN 10.

144

Chapter 2: VLANs and VTP

With VTP pruning enabled, the broadcast traffic from Switch C6500-1 is not forwarded to Switches C6500-3, C6500-5, and C6500-6 because traffic for VLAN 10 has been pruned on Port 5 on Switch C6500-2 and Port 4 on Switch C6500-4.

Configuring VTP Pruning
Enabling VTP pruning on a VTP server enables pruning for the entire management domain. VTP pruning takes effect several seconds after it is enabled. By default, VLANs 2 to 1000 or 2 to 1001 are pruning-eligible, depending on the platform. VTP pruning does not prune traffic from VLANs that are pruning-ineligible. VLAN 1 is always pruning-ineligible, and it cannot be removed from a trunk. However, the “VLAN 1 disable on trunk” feature available on Catalyst 4000, 5000, and 6000 family switches enables the pruning of user traffic, but not protocol traffic, such as CDP and VTP, for VLAN 1 from a trunk. Use the vtp pruning VLAN database configuration command to make VLANs pruning-eligible on a Cisco IOS-based switch. As soon as pruning is enabled, use the switchport trunk pruning interface configuration command to make a specific VLAN pruning-ineligible. Example 2-35 shows how to enable pruning for all VLANs except VLANs 5 to 10 (VLANs 5 to 10 are pruning-ineligible).
Example 2-35 VTP Pruning Is Enabled on a VTP Server. The Specific VLANs That Are Pruned Can Be Configured on an Interface
Switch(vlan)#vtp pruning Pruning switched ON Switch#configure terminal Enter configuration commands, one per line. End with CNTL/Z Switch(config)#interface fastethernet 0/3 Switch(config-if)#switchport trunk pruning vlan remove 5-10 Switch(config-if)#

Lab 2.9.3 Catalyst 2950T and 3550 Series VTP Pruning

In this lab exercise, you configure VTP pruning between two Cisco Catalyst WS-C2950T-24-EI switches and a Cisco Catalyst WS-C3550-24-EMI switch using CLI mode.

VTP Configuration and VTP Pruning

145

Verifying VTP Pruning
To verify the VLANs that are either pruned or not pruned on a Cisco IOS-based switch, use either the show running-config or show interface interface-id switchport command, as shown in Example 2-36.
Example 2-36 Verifying VTP Pruning
Switch#show running-config

<output omitted>

hostname Switch ! ip subnet-zero ! ! ! interface FastEthernet0/1 ! interface FastEthernet0/2 ! interface FastEthernet0/3 switchport trunk allowed vlan 1,2,4,5,11-1005 switchport trunk pruning vlan 2-4, 11-1001 switchport mode trunk ! interface FastEthernet0/4 Switch#show interface fastethernet 0/3 switchport Name: Fa0/2 Switchport: Enabled Administrative mode: trunk Operational Mode: trunk Administrative Trunking Encapsulation: isl Operational Trunking Encapsulation: isl Negotiation of Trunking: Disabled

continues

146

Chapter 2: VLANs and VTP

Example 2-36 Verifying VTP Pruning (Continued)
Access Mode VLAN: 0 ((Inactive)) Trunking Native Mode VLAN: 1 (default) Trunking VLANs Enabled: 1,2,4,5,11-1005 Trunking VLANs Active: 1,2 Pruning VLANs Enabled: 2-4,11-1001

Priority for untagged frames: 0 Override vlan tag priority: FALSE Voice VLAN: none Appliance trust: none Switch#

The show vtp counters and debug sw-vlan vtp pruning commands can also be useful for verifying VTP pruning.

Summary
The following concepts were covered in this chapter:

VLANs solve many of the issues found in Layer 2 environments, including broadcast control, isolation of problem components in the network, security, and load balancing through the use of a Layer 3 protocol between VLANs. VLAN identification allows different VLANs to be carried on the same physical link, called a trunk link. Four major trunking technologies exist: ISL, IEEE 802.1Q, IEEE 802.10, and ATM LANE. ISL encapsulates Ethernet frames, and IEEE 802.1Q embeds a tag in the Ethernet header. The VLAN Trunking Protocol (VTP) provides support for dynamic reporting of the addition, deletion, and renaming of VLANs across the switch fabric. VTP pruning permits the dynamic pruning of unnecessary VLAN traffic within the management domain.

Key Terms

147

Key Terms
access port A switch port that connects to an end-user device or a server. ATM LAN Emulation (ATM LANE) A standard defined by the ATM Forum that gives two stations attached via ATM the same capabilities they normally have with Ethernet and Token Ring. clustering A method of managing a group of switches without having to assign an IP address to every switch. Dynamic Trunking Protocol (DTP) A Cisco-proprietary protocol that autonegotiates trunk formation for either ISL or 802.1Q trunks. Dynamic VLAN A VLAN in which end stations are automatically assigned to the appropriate VLAN based on their MAC address. This is made possible via a MAC address-to-VLAN mapping table contained in a VLAN Management Policy Server (VMPS) database. Emulated LAN (ELAN) A logical construct, implemented with switches, that provides Layer 2 communication between a set of hosts in a LANE network. See ATM LAN Emulation (ATM LANE). end-to-end VLAN Also known as a campus-wide VLAN. An end-to-end VLAN spans a campus network. It is characterized by the mapping to a group of users carrying out a similar job function (independent of physical location). IEEE 802.10 The IEEE standard that provides a method for transporting VLAN information inside the IEEE 802.10 frame (FDDI). The VLAN information is written to the security association identifier (SAID) portion of the 802.10 frame. This allows for transporting VLANs across FDDI backbones. IEEE 802.1Q The IEEE standard for identifying VLANs associated with Ethernet frames. IEEE 802.1Q trunking works by inserting a VLAN identifier into the Ethernet frame header. Inter-Switch Link (ISL) A Cisco-proprietary encapsulation protocol for creating trunks. ISL prepends a 26-byte header and appends a 4-byte CRC to each data frame. LAN Emulation (LANE) An ATM Forum standard used to transport VLANs over ATM networks. local VLAN Also known as a geographic VLAN. A local VLAN is defined by a restricted geographic location, such as a wiring closet. native VLAN The VLAN that a trunk port reverts to if trunking is disabled on the port. port-based VLAN Also known as a static VLAN. A port-based VLAN is configured manually on a switch, where ports are mapped, one by one, to the configured VLAN. This hardcodes the mapping between ports and VLANs directly on each switch.

148

Chapter 2: VLANs and VTP

private VLAN A VLAN you configure to have some Layer 2 isolation from other ports within the same private VLAN. Ports belonging to a private VLAN are associated with a common set of supporting VLANs that create the private VLAN structure. trunk A point-to-point link connecting a switch to another switch, router, or server. A trunk carries traffic for multiple VLANs over the same link. The VLANs are multiplexed over the link with a trunking protocol. virtual LAN (VLAN) A group of end stations with a common set of requirements, independent of their physical location, that communicate as if they were attached to the same wire. A VLAN has the same attributes as a physical LAN but allows you to group end stations even if they are not located physically on the same LAN segment. VLAN Management Policy Server (VMPS) A Cisco-proprietary solution for enabling dynamic VLAN assignments to switch ports within a VTP domain. VLAN map Referred to as a VLAN access control list (VACL) in the context of Catalyst 6500 switches. A generalized access control list applied on a Catalyst switch that permits filtering of both intra-VLAN and inter-VLAN packets. VLAN Trunking Protocol (VTP) A Cisco-proprietary protocol used to communicate information about VLANs between Catalyst switches. VTP domain Also called a VLAN management domain. A network’s VTP domain is the set of all contiguously trunked switches with the same VTP domain name. VTP pruning A switch feature used to dynamically eliminate, or prune, unnecessary VLAN traffic.

Check Your Understanding
Use the following review questions to test your understanding of the concepts covered in this chapter. Answers are listed in Appendix A, “Check Your Understanding Answer Key.”
1. For which of the following VTP modes does a Catalyst switch listen to VTP

advertisements?
A. Client B. Server C. Transparent D. Peer

Check Your Understanding

149

2. Which of the following are Cisco-proprietary protocols? A. CDP B. VQP C. VTP D. ISL 3. Which of the following are VLAN trunking methods? A. ATM LANE B. IEEE 802.10 C. IEEE 802.1Q D. ISL 4. Two devices in the same VLAN require a Layer 3 switch to communicate. What

campus design model is used?
A. Remote VLANs B. Campus VLANs C. Local VLANs D. End-to-end VLANs 5. Which of the following are required for dynamic VLAN assignment to ports with

VMPS?
A. VQP B. VMPS server C. VMPS client D. TFTP server 6. Which VLAN database configuration mode command is used to remove VLAN 20? A. erase vlan 20 B. clear vlan 20 C. delete vlan 20 D. no vlan 20

150

Chapter 2: VLANs and VTP

7. What is the operational mode of a link when both ends are configured as dynamic

desirable?
A. Trunk B. Static access 8. What three commands are used to restore a Catalyst 3550 switch to a default

configuration?
A. copy running-config startup-config B. erase startup-config C. delete vlan.dat D. reload 9. Which construct can be used to filter both intra-VLAN and inter-VLAN traffic? A. Router ACL B. VLAN map C. IOS ACL D. Port ACL 10. Which of the following messages are used with VTP? A. Join messages B. Advertisement requests C. Subset advertisements D. Summary advertisements

Objectives
After completing this chapter, you will be able to perform tasks related to the following:
■ ■

Explain the evolution of Spanning Tree Protocol (STP). Understand and have the knowledge and skills to configure basic STP operations, processes, and enhancements. Have a basic understanding of Rapid Spanning Tree Protocol (RSTP). Configure basic STP functions, operations, and tuning. Verify and troubleshoot STP configuration. Differentiate between Mono Spanning Tree and Multiple Spanning Tree, both of which are abbreviated MST. Configure EtherChannel.

■ ■ ■ ■

Chapter 3 Spanning Tree Protocol (STP)
Of all the protocols that network engineers spend time learning about and planning for, the one that is probably overlooked the most is Spanning Tree Protocol (STP). As routers became popular in the early 1990s, STP faded into the background as a “less-important protocol that just worked.” However, with switching technology now in the forefront, STP has once again earned its place as an important consideration in network design. A poorly planned initial implementation of STP can mean that an inordinate proportion of the configuration, troubleshooting, and maintenance effort on a campus network becomes devoted to STP. This chapter explains the mechanics of STP, detailing its loop-prevention function in switched networks. Understanding these mechanics enables a proactive rather than reactive approach to configuring STP on the target switched network. STP is one of the most technical subjects in LAN switching. The challenge of understanding STP is similar to that of understanding the underlying operation of Open Shortest Path First (OSPF) or Enhanced Interior Gateway Routing Protocol (EIGRP) in a campus network (timers, packet types, algorithms, and so on). It is essential to gain this understanding. STP serves as a fundamental logical building block in every campus network, and it plays a key role in network design and implementation. This chapter discusses Layer 2 techniques and technologies designed to optimize network reliability, resiliency, and redundancy within a campus network. In particular, this chapter explores scaling issues with STP as they pertain to virtual LANs (VLANs).

154

Chapter 3: Spanning Tree Protocol (STP)

STP Operation
Broadcast storms and bridge table corruption are primary motivators for the use of STP in a switched network. STP parameters such as Bridge Priority, Path Cost, and Port ID govern STP’s behavior. This section discusses the motivators for STP and the parameters affecting its behavior.

STP Concepts
STP is a Layer 2 protocol that uses a special-purpose algorithm to discover physical loops in a network and effect a logical loop-free topology. STP creates a loop-free tree structure consisting of leaves and branches that span the entire Layer 2 network. The actual mechanics of how bridges communicate and how the STP algorithm works are discussed at length in this chapter. Note that the terms bridge and switch are used interchangeably when discussing STP, because with respect to the IEEE 802.1D STP specifications, there is no distinction between bridges and switches. In addition, unless otherwise indicated, connections between switches are assumed to be trunks. The greater discussion of STP concerns its behavior on trunk connections, which form the spanning tree. Loops can occur in a network for a variety of reasons. Usually, loops in a network are the result of a deliberate attempt to provide redundancy. However, loops can also result from configuration errors. Figure 3-1 shows a typical switched network and how physical loops can be intentionally used to provide redundancy. Without STP, looping network traffic would degrade performance to the extent that the network would be effectively unusable. Physical loops without proper STP design can be disastrous. Two problems that can result are broadcast storms and bridge table corruption. These phenomena are discussed in the next two sections.

Broadcast Loops
Broadcasts and physical loops are a dangerous combination. Figure 3-2 shows how broadcast loops are generated. Two switches, Cat-1 and Cat-2, have STP disabled. Host A and Host B are connected to Cat-1 and Cat-2 by hubs.

STP Operation

155

Figure 3-1 Physical Loops Provide Redundancy in Switched Networks Server Farm

Wiring Closet

Backbone

Cat-6

Cat-1

Cat-2 Cat-5

Cat-7

Cat-3

Cat-4

Hub

Figure 3-2 Broadcast Loops Would Occur in This Scenario Because STP Is Disabled Host A

1/1

1/1

Cat-1
1/2

Cat-2
1/2

Host B

156

Chapter 3: Spanning Tree Protocol (STP)

Host A sends a frame to the broadcast Media Access Control (MAC) address FF-FF-FF-FF-FF-FF, which travels to both Cat-1 and Cat-2. When the frame arrives at Port 1/1 on Cat-1, Cat-1 follows the standard transparent bridging algorithm and floods the frame out all the other ports, including Port 1/2. The frame exiting Port 1/2 travels to all nodes on the lower Ethernet segment, including Port 1/2 on Cat-2. Cat-2 floods the broadcast frame out all the other ports, including Port 1/1, and, once again, the frame shows up at Port 1/1 on Cat-1. Oblivious to the loop, Cat-1 sends the frame out Port 1/2 for the second time, and a broadcast loop is now in effect. Recall that a switch does not forward a frame out the same port through which it entered the switch. The discussion so far has not mentioned that not only would Cat-1 have received the initial broadcast from Host A, but Cat-2 would receive it as well. The same problem would propagate in the reverse direction as a result. The “feedback” loop would occur in both directions. An important conclusion to be drawn is that bridging loops are much more dangerous than routing loops. Why is this? Suppose the initial broadcast frame were an Ethernet version II frame, as shown in Figure 3-3.
Figure 3-3 The Format for the Ethernet Version II Frame Was Developed by Digital, Intel, and Xerox

Dest MAC

Source MAC

Type

Data

CRC

6

6

2

46-1500

4

The Ethernet version II frame contains only two MAC addresses, a Type field, the networklayer packet as data, and a cyclic redundancy check (CRC). In contrast, an IP header contains a Time-To-Live (TTL) field that is set by the source and is decremented at each router. By discarding packets that reach TTL = 0, routers prevent “runaway” datagrams. Unlike IP, Ethernet does not have a TTL field. Therefore, after a frame starts to loop in the network, as just described, it continues until a switch is turned off or a link is broken. The network shown in Figure 3-2 is extremely simple. Feedback loops of this type grow exponentially as additional switches and links are incorporated into the network. A single broadcast can render a network unusable, all because STP is disabled or configured incorrectly.

Bridge Table Corruption
A less-understood problem than broadcast storms is unicast frames causing network bottlenecks. Figure 3-4 illustrates how a unicast packet can cause such a problem.

STP Operation

157

Figure 3-4 The MAC Address-to-Port Associations for Host A Flip-Flop on Cat-1 and Cat-2 Host A

1/1

1/1

Cat-1
1/2

Cat-2
1/2

Host B

Host A possesses a prior Address Resolution Protocol (ARP) entry for Host B and wants to ping Host B. However, Host B has been temporarily removed from the network, and the corresponding bridge-table entries in the switches have been flushed for Host B. Assume that neither switch is running STP. As with the previous example, the frame travels to Port 1/1 on both switches. Consider the scenario relative to Cat-1 alone. Cat-1 does not have an entry for the MAC address of Host B, BB-BB-BB-BB-BB-BB, in its bridging table; as a result, it floods the frame to all other ports. Cat-2 then receives the frame on Port 1/2. Two things happen at this point:
1. Cat-2 floods the frame because MAC address BB-BB-BB-BB-BB-BB is not in its

bridging table.
2. Cat-2 notices that it received a frame on Port 1/2 with a source MAC address of

AA-AA-AA-AA-AA-AA (from Host A). As a result, Cat-2 changes its bridging table entry for the MAC address of Host A to the wrong port. As frames loop in the reverse direction (the feedback loop goes both ways), the MAC address of Host A flip-flops between Port 1/1 and Port 1/2 on the switches. In short, not only does this permanently saturate the network with the unicast ping packet, but it also corrupts the bridging tables and drives the switch CPU utilization to 100 percent (which prevents the switch from forwarding traffic). This example demonstrates that broadcasts are not the only types of frames that can bring down a network.

158

Chapter 3: Spanning Tree Protocol (STP)

Bridge Priority
An algorithm is a formula or set of steps for solving a particular problem. Algorithms rely on a set of rules. They have a clear beginning and end. The Spanning Tree Algorithm is no exception. The IEEE 802.1D standard defines the Spanning Tree Algorithm that characterizes STP. This algorithm relies on the BID, Path Cost, and Port ID parameters to make decisions (the following sections cover Path Cost and Port ID in greater detail). The Bridge ID (BID) is the first parameter used by the Spanning Tree Algorithm. STP uses the BID to determine the center of the bridged network, known as the Root Bridge or Root Switch. The BID parameter is an 8-byte field consisting of an ordered pair of numbers, as shown in Figure 3-5. The first is a 2-byte decimal number called the Bridge Priority, and the second is a 6-byte (hexadecimal) MAC address. The Bridge Priority is a decimal number used to measure the preference of a bridge in the Spanning Tree Algorithm. The possible values range between 0 and 65,535. The default setting is 32,768.
Figure 3-5 The BID Consists of an Ordered Pair of Numbers, the Bridge Priority, and the MAC Address BID - 8 Bytes

Bridge Priority 2 Bytes Range: 0-65,535 Default: 32,768

MAC 6 Bytes From Backplane/Supervisor

The MAC address in the BID is one of the switch’s MAC addresses. Each switch has a pool of MAC addresses, one for each instance of STP, used as BIDs for the VLAN spanning-tree instances (one per VLAN). For example, Catalyst 6000 switches each have a pool of 1024 MAC addresses assigned to the Supervisor module or backplane for this purpose. The way to compare BIDs is as follows: Let (s,t) and (u,v) represent two BIDs, where the first coordinate is the Bridge Priority and the second coordinate is the MAC address (Priority, MAC address). Then (s,t) < (u,v) if and only if

s<u

or

s = u and t < v

STP Operation

159

Two BIDs cannot be equal, because Catalyst switches are assigned unique MAC addresses. In terms of the Spanning Tree Algorithm, when a comparison is made between two values of a given STP parameter, the lower value is always preferred.

Path Cost
The Path Cost is the second parameter used by the Spanning Tree Algorithm to determine the path to the Root Switch. Path Cost is a measure of how close bridges are to each other. Path Cost is the sum of the costs of the links in a path between two bridges. It is not a measure of hop count. The hop count for Path A might be greater than the hop count for Path B, while the cost of Path A is less than the cost of Path B. Closeness is not necessarily reflected by hop count. Switches use the Path Cost to determine the best path to the Root Switch. The lowest combination of links has the lowest cumulative Path Cost and is the best path to the Root Switch. The IEEE 802.1D standard originally defined the cost of a link as 1000 Mbps divided by the link’s bandwidth in Mbps. For example, a 10BASE-T link has a cost of 100 (1000/10), and Fast Ethernet and Fiber Distributed Data Interface (FDDI) each have a cost of 10 (1000/100). With the advent of Gigabit Ethernet and other high-speed technologies, a problem with this definition evolved. The cost is stored as an integer value, not as a floating-point value. For example, 10 Gbps results in 1000 Mbps/10000 Mbps = .1, an invalid cost value. To solve this problem, the IEEE changed the “inverse proportion” definition. Table 3-1 shows the definition of the STP cost for a link exceeding 1 Gbps on a CatOS switch (short mode). Table 3-2 shows the definition of the STP cost for a link of 10 Gbps or higher on a CatOS switch (long mode). The default cost mode for a CatOS switch can be manually configured; all switches in a network must use the same default. On newer IOS-based switches such as the Catalyst 2950 and Catalyst 3550, the valid range from which the STP cost can be assigned is 1 to 200,000,000.
Table 3-1 The CatOS STP Cost Definition Was Updated to Account for Links with Speeds Up to 10 Gbps (Short Mode)

Bandwidth

STP Cost

4 Mbps 10 Mbps 16 Mbps 45 Mbps

250 100 62 39
continues

160

Chapter 3: Spanning Tree Protocol (STP)

Table 3-1 The CatOS STP Cost Definition Was Updated to Account for Links with Speeds Up to 10 Gbps (Short Mode) (Continued)

Bandwidth

STP Cost

100 Mbps 155 Mbps 622 Mbps 1 Gbps 10 Gbps

19 14 6 4 2

Table 3-2 The CatOS STP Cost Definition Was Again Updated to Account for Links with Speeds Up to 10 Tbps (Long Mode)

Bandwidth

STP Cost

4 kbps 1 Mbps 10 Mbps 100 Mbps 1 Gbps 10 Gbps 100 Gbps 1 Tbps (terabits per second) 10 Tbps

200,000,000 20,000,000 2,000,000 200,000 20,000 2000 200 20 2

Port ID
The Port ID is the third parameter used by the Spanning Tree Algorithm to determine the path to the Root Switch. Figure 3-6 illustrates the Port ID, which is a 2-byte STP parameter consisting of an ordered pair of numbers, the Port Priority and the Port Number.

STP Processes

161

Figure 3-6 The Port ID 16 Bits

Port Priority 6 Bits

Port Number 10 Bits

On a CatOS switch, the Port Priority is 6 bits and the Port Number is 10 bits. On an IOS-based switch, both numbers are 8 bits. Port ID should not be confused with the Port Number. The Port Number is just part of the Port ID. Lower Port IDs are preferred over higher Port IDs in the STP decision process. The order relation for Port IDs is explained in the following example. If (s,t) and (u,v) represent two Port IDs (the first coordinate being the Port Priority and the second coordinate being the Port Number), (s,t) < (u,v) if and only if
■ ■

s<u s = u and t < v

Two Port IDs cannot be equal, because Port Numbers uniquely identify the switch ports on a Catalyst switch. The Port Priority is a configurable STP parameter (unlike the Port Number), with values ranging from 0 to 255 on an IOS-based switch (the default value is 128). Port Numbers are numerical identifiers used by Catalyst switches to enumerate the ports. The Port Number leaves room for 28 (256) ports on an IOS-based switch (Cisco routers also use the 8-bit/8-bit Port ID definition).

STP Processes
This section provides details of exactly how IEEE 802.1D STP works by describing the three steps of STP convergence, as well as the election of the Root Switch, Root Port, and Designated Port. Furthermore, this section explores STP timers and the process of topology change.

162

Chapter 3: Spanning Tree Protocol (STP)

STP Decisions and BPDU Exchanges
The Spanning Tree Algorithm operates as a function of the BID, Path Cost, and Port ID. When creating a loop-free logical topology, STP always uses the same four-step decision sequence: Step 1 Step 2 Step 3 Step 4 Determine the Root Switch. Calculate the lowest Path Cost to the Root Switch. Determine the lowest sender BID. Determine the lowest Port ID.

Figure 3-7 illustrates this sequence.
Figure 3-7 The Four-Step Decision Process of STP

Root BID Root Path Cost Sender BID Port ID

Who is the root bridge? How far away is the root bridge? What is the BID of the bridge that sent this BPDU? What port on the sending bridge did this BPDU come from?

As a clarification, Step 1 is essentially the election of the switch that has the lowest BID when compared with other switches in the topology. This is fully discussed in the following sections. To make good decisions, STP needs to ensure that the participating bridges have the correct information. The bridges need to communicate the STP information between them. Bridges pass spanning-tree information between them using Layer 2 frames called bridge protocol data units (BPDUs). A bridge uses the four-step decision sequence to determine the “best” BPDU seen on each port. The bridge determines the best BPDU based on the four-step STP process. The bridge stores the best BPDU it receives for each port. When making this evaluation, it considers all the BPDUs received on the port, as well as the BPDU it would send on that same port.

STP Processes

163

As each BPDU arrives at the switch port, it is checked against this four-step sequence to see if it is more attractive than the existing BPDU saved for that port. If the new BPDU (or the locally generated BPDU) is more attractive, the old value is replaced. Additionally, this “saving-the-best-BPDU” process also controls the sending of BPDUs. When a bridge first becomes active, all its ports send BPDUs every 2 seconds (the default Hello Time). However, if a port hears about a BPDU from another bridge that is more attractive than the BPDU it has been sending, the local port eventually stops sending BPDUs. If the moreattractive BPDU stops arriving from a neighbor for 20 seconds (the default Max Age), the local port resumes sending BPDUs. Max Age is the time it takes for the best BPDU to time out.

Three Steps of STP Convergence
The Spanning Tree Algorithm is somewhat complex, but the initial process used to converge on a loop-free topology consists of three election steps: Step 1 Step 2 Step 3 Elect a Root Switch. Elect Root Ports. Elect Designated Ports.
NOTE The default configuration for Catalyst switches is to run one instance of the Spanning Tree Algorithm per VLAN.

Figure 3-8 illustrates Root Port election.
Figure 3-8 Root Port Election is the Second Step
BID = 32,768.AA-AA-AA-AA-AA-AA Cat-A
1/1 1/2

1/1

1/1

Cat-B
1/2

Cat-C
1/2

BID = 32,768.BB-BB-BB-BB-BB-BB

BID = 32,768.CC-CC-CC-CC-CC-CC

When the network first “starts,” all the bridges flood it with a mixture of BPDU information. The bridges begin applying the STP four-step decision sequence discussed in the preceding section. This allows the bridges to hone in on a set of BPDUs that enable the formation of a single spanning tree for the entire network or VLAN.

164

Chapter 3: Spanning Tree Protocol (STP)

A single Root Switch is elected to act as the central point of this network (Step 1). All the remaining bridges calculate a set of Root Ports (Step 2) and Designated Ports (Step 3) to build a loop-free topology. The resulting topology is a tree, with the Root Switch as the trunk and loop-free active paths radiating outward as tree branches. In a steady-state network, BPDUs flow from the Root Switch outward along these loop-free branches to every segment in the network. After the network has converged on a loop-free active topology using this three-step process, changes are handled using the spanning-tree topology change process. The following sections consider the three steps of STP convergence in detail.

Electing the Root Switch
As a first step in the STP process, the switches need to elect a single Root Switch by looking for the bridge with the lowest BID. This process of selecting the bridge with the lowest BID is sometimes called the “root war.” As discussed in the earlier “Bridge Priority” section, a BID is an 8-byte identifier that is composed of two subfields, the Bridge Priority and a MAC address. As Figure 3-8 illustrates, Cat-A has a default BID of 32,768.AA-AA-AA-AA-AA-AA, Cat-B assumes a default BID of 32,768.BB-BB-BB-BB-BB-BB, and Cat-C uses 32,768.CC-CC-CC-CC-CC-CC. Because all three bridges use the default Bridge Priority of 32,768, the lowest MAC address, AA-AA-AA-AA-AA-AA, serves as the tiebreaker, and Cat-A becomes the Root Switch. The process of how to configure a switch to become the Root Switch is examined in the following sections. Normally, the default settings should not be allowed to determine the location of the Root Switch. How did the bridges learn that Cat-A has the lowest BID? This is accomplished through the exchange of BPDUs. As discussed earlier, BPDUs are special frames that bridges use to exchange spanning-tree information with each other. By default, BPDUs are sent every 2 seconds. BPDUs propagate between bridges, which includes switches and all routers configured for bridging. BPDUs do not carry end-user traffic. Figure 3-9 illustrates the layout of a BPDU.
Figure 3-9 A BPDU Includes Root BID, Root Path Cost, Sender BID, and Port ID Information

Root BID Root Path Cost Sender BID Port ID

Who is the root bridge? How far away is the root bridge? What is the BID of the bridge that sent this BPDU? What port on the sending bridge did this BPDU come from?

STP Processes

165

For the purposes of the root war, this discussion involves only the Root BID and Sender BID fields. When a bridge generates a BPDU every 2 seconds, the bridge places what it thinks is the Root Switch at that instant in the Root BID field. The bridge always places its own BID in the Sender BID field. Initially, before the switch knows any better, it populates the Root BID field with its own BID. Suppose that Cat-B boots first and starts sending out BPDUs announcing itself as the Root Switch every 2 seconds. A few minutes later, Cat-C boots and announces itself as the Root Switch. When the Cat-C BPDU arrives at Cat-B, Cat-B discards the BPDU because it has a lower BID saved on its ports (its own BID). As soon as Cat-B transmits a BPDU, Cat-C learns that it is not as important as it initially thought. At this point, Cat-C starts sending BPDUs that list Cat-B as the Root BID and Cat-C as the sender BID. The network now agrees that Cat-B is the Root Switch. Five minutes later, Cat-A boots. Cat-A initially thinks it is the Root Switch and starts advertising this fact via BPDUs. As soon as these BPDUs arrive at Cat-B and Cat-C, the switches hand over the Root Switch position to Cat-A. All three switches now send BPDUs that announce Cat-A as the Root Switch and themselves as the sender BID.

Electing Root Ports
At the conclusion of the root war, the switches move on to selecting Root Ports. A bridge’s Root Port is the port that is closest to the Root Switch in terms of Path Cost. Every non-Root Switch must select one Root Port. Again, bridges use the concept of cost to measure closeness. As with some routing metrics, the measure of closeness using STP is not necessarily reflected by hop count. Specifically, bridges track the Root Path Cost, the cumulative cost of all links to the Root Switch. Figure 3-10 illustrates how this value is calculated across multiple bridges and the resulting Root Port election process.
Figure 3-10 Root Ports Are Elected After the Root Switch Is Elected Root Bridge Cost = 19 1/1 BPDU Cost = 0
Cat-A

1/2

Cost = 19

BPDU Cost = 0

1/1 Root Port
Cat-B

BPDU Cost = X 19 0

BPDU Cost = X 19 0

1/1 Root Port
Cat-C

1/2

BPDU Cost = 19 Cost = 19

1/2

BPDU Cost = 19 38 X

BPDU Cost = 19

166

Chapter 3: Spanning Tree Protocol (STP)

When Cat-A (the Root Switch) sends out BPDUs, they contain a Root Path Cost of 0. When Cat-B receives these BPDUs, it adds the Path Cost of Port 1/1 to the Root Path Cost contained in the received BPDU. Assume that the network is running Fast Ethernet:
1. Cat-B receives a Root Path Cost of 0 and adds in the Port 1/1 cost of 19. 2. Cat-B uses the value of 19 internally and sends BPDUs with a Root Path Cost of

19 out Port 1/2.
3. When Cat-C receives these BPDUs from Cat-B, it increases the Root Path Cost to

38 (19 + 19).
4. However, Cat-C is also receiving BPDUs from the Root Switch on Port 1/1. 5. These BPDUs enter Port 1/1 on Cat-C with a cost of 0, and Cat-C increases the cost

to 19 internally. Cat-C has a decision to make.
6. Cat-C must select a single Root Port—the port that is closest to the Root Switch. 7. Cat-C sees a Root Path Cost of 19 on Port 1/1 and 38 on Port 1/2. Port 1/1 on Cat-C

becomes the Root Port.
8. Cat-C begins advertising this Root Path Cost of 19 to downstream switches.

Cat-B goes through a similar set of calculations. Port 1/1 on Cat-B can reach the Root Switch at a cost of 19, whereas Port 1/2 on Cat-B calculates a cost of 38. Port 1/1 becomes the Root Port for Cat-B. The costs increment as BPDUs are received on a port, not as they are sent out the port. For example, BPDUs arrive on Port 1/1 on Cat-B with a cost of 0 and get increased to 19 “inside” Cat-B.

Electing Designated Ports
At this point, the Spanning Tree Algorithm still has not eliminated any loops. This is taken care of after the Designated Ports and non-Designated Ports are determined. Each segment in a bridged network has one Designated Port. A Designated Port for a segment is the bridge port connected to that segment that both sends traffic toward the Root Switch and receives traffic from the Root Switch over that segment. The idea behind this is that if only one port handles traffic for each link, all the loops have been broken. The Designated Bridge for a segment is the bridge containing the Designated Port for that segment. With the Root Port selection, the Designated Ports are chosen based on the Root Path Cost to the Root Switch, as shown in Figure 3-11.

STP Processes

167

Figure 3-11 Designated Ports Are Elected After the Root Switch and Root Ports Are Elected Root Bridge Segment 1 1/1 Designated Port BID = 32,768.BB-BB BB-BB-BB-BB BID = 32,768.CC-CCCC-CC-CC-CC
Cat-A

Segment 2 1/2 Designated Port

1/1
Cat-B

1/1
Cat-C

1/2

Designated Port

1/2

Segment 3

The Root Path Cost is the cumulative cost of all links leading to the Root Switch. Segment 1 forms a link between Cat-A and Cat-B. This segment has two bridge ports, Port 1/1 on Cat-A and Port 1/1 on Cat-B. Port 1/1 on Cat-A has a Root Path Cost of 0 because Cat-A is the Root Switch. Port 1/2 on Cat-A has a Root Path Cost of 0 because Cat-A is the Root Switch. Port 1/1 on Cat-B has a Root Path Cost of 19—the value 0 received in BPDUs from Cat-A plus the Path Cost of 19 assigned to Port 1/1 on Cat-B. Because Port 1/1 Cat-A has the lower Root Path Cost, it becomes the Designated Port for this link. For Segment 2, the Cat-A-to-Cat-C link, a similar election takes place. Port 1/2 on Cat-A has a Root Path Cost of 0, whereas Port 1/1 on Cat-C has a Root Path Cost of 19. Port 1/2 on Cat-A has the lower cost and becomes the Designated Port. Notice that every active port on the Root Switch becomes a Designated Port. Examining Segment 3, the link from Cat-B to Cat-C, both Port 1/2 on Cat-B and Port 1/2 on Cat-C have a Root Path Cost of 19, resulting in a tie. When faced with a tie, STP always uses the STP four-step decision sequence discussed earlier. Recall that the four steps are as follows: Step 1 Step 2 Step 3 Step 4 Determine the Root Switch. Calculate the lowest Root Path Cost. Determine the lowest sender BID. Determine the lowest Port ID.

168

Chapter 3: Spanning Tree Protocol (STP)

All three bridges shown in Figure 3-11 agree that Cat-A is the Root Switch, so the algorithm checks Root Path Cost next. However, both Cat-B and Cat-C have a cost of 19, so the algorithm resorts to the lowest sender BID. Because the Cat-B BID (32,768.BB-BB-BB-BB-BB-BB) is lower than the Cat-C BID (32,768.CC-CC-CC-CC-CC-CC), Cat-B:Port 1/2 becomes the Designated Port for Segment 3. Cat-C:Port 1/2 becomes a non-Designated Port. Note that access ports do not play a role in the election of Designated Ports. Trunk ports are used to connect to other switches. Access ports are used to connect to hosts or routers. The process described here involves communication of STP parameters over trunk links.

STP States
After the bridges have determined which ports are Root Ports, Designated Ports, and nonDesignated Ports, STP is ready to create a loop-free topology. To do this, STP configures Root Ports and Designated Ports to forward traffic. STP sets non-Designated Ports to block traffic. Although Forwarding and Blocking are the only two states commonly seen in a stable network, there are actually five STP states, as described in Table 3-3.
Table 3-3 STP States

State

Description

Forwarding Learning Listening Blocking Disabled

Sends and receives user data Builds the bridging table Builds the “active” topology Receives BPDUs only Administratively down

The STP states can be viewed hierarchically in that bridge ports start at the Blocking state and work their way up to the Forwarding state. The Disabled state is the administratively shut down STP state. It is not part of the normal STP port processing. After the switch is initialized, ports start in the Blocking state. The Blocking state is the STP state in which a bridge listens for BPDUs.

Blocking State
A port in the Blocking state has the following characteristics and functions:

It discards frames received from the attached segment or internally forwarded through switching.

STP Processes

169

■ ■ ■ ■

It receives BPDUs and directs them to the system module. It has no address database. It does not transmit BPDUs received from the system module. It receives and responds to network management messages but does not transmit them.

Listening State
If a bridge thinks it is the Root Switch immediately after booting or in the absence of BPDUs for a certain period of time, the port transitions into the Listening state. The Listening state is the STP state in which no user data is being passed, but the port is sending and receiving BPDUs in an effort to determine the active topology. A port in the Listening state has the following characteristics and functions:

It discards frames received from the attached segment or frames switched from another port. It has no address database. It receives BPDUs and directs them to the system module. It processes BPDUs received from the system module. (Processing BPDUs is a separate action from receiving or transmitting BPDUs.) It receives and responds to network management messages.

■ ■ ■

The three initial convergence steps—electing a Root Switch, Root Ports, and Designated Ports—take place during the Listening state. Ports that lose the Designated Port election become non-Designated Ports and drop back to the Blocking state. Ports that remain Designated Ports or Root Ports after 15 seconds—the default Forward Delay STP timer value—progress into the Learning state.

Learning State
The Learning state is the STP state in which the bridge is doesn’t pass user data frames but builds the bridging table and gathers information, such as the source VLANs of data frames. As the bridge receives a frame, it places the source MAC address and port into the bridging table. The Learning state reduces the amount of flooding required when data forwarding begins. The lifetime of the Learning state is also governed by the Forward Delay timer of 15 seconds, the default setting. A port in the Learning state has the following characteristics and functions:
■ ■ ■

It discards frames received from the attached segment. It discards frames switched from another port for forwarding. It incorporates station location into its address database.

170

Chapter 3: Spanning Tree Protocol (STP)

■ ■ ■

It receives BPDUs and directs them to the system module. It receives, processes, and transmits BPDUs received from the system module. It receives and responds to network management messages.

Forwarding State
If a port is still a Designated Port or Root Port after the Forward Delay timer expires for the Learning state, the port transitions into the Forwarding state. The Forwarding state is the STP state in which data traffic is both sent and received on a port. It is the “last” STP state. At this stage, it finally starts forwarding user data frames. A port in the Forwarding state has the following characteristics and functions:
■ ■ ■ ■ ■ ■

It forwards frames received from the attached segment. It forwards frames switched from another port for forwarding. It incorporates station location information into its address database. It receives BPDUs and directs them to the system module. It processes BPDUs received from the system module. It receives and responds to network management messages.

Transitions Between STP States
Figure 3-12 illustrates the transitions between STP states. The scenario in Figure 3-13 shows Root Ports, Designated Ports, and non-Designated Ports and the associated STP states.
Figure 3-12 Various Events Trigger Transitions Between STP States 2 2 3 1
Disabled or Down Blocking Listening

5 4 4
Learning

2 2 6 4

7 5
Forwarding

Legend of Events: 1. Port Enabled or Initialized 2. Port Disabled or Fails 3. Port Selected as Root or Designated Port 4. Port Ceases to be a Root or Designated Port 5. Forwarding Timer Expires 6. PortFast 7. UplinkFast

STP Processes

171

Figure 3-13 Root Ports, Designated Ports, and Non-Designated Ports and the Associated STP States in a Stable STP Topology Root Bridge Segment 1 Forwarding Designated Port Root Port 1/1
Cat-A

1/2

Forwarding Segment 2 Designated Port Root Port

Forwarding 1/1
Cat-B

Forwarding 1/1
Cat-C

1/2 Forwarding Designated Port Segment 3 Non-Designated Port

1/2 Blocking

STP Timers
STP operation is controlled by three timers, as described in Table 3-4.
Table 3-4 Three Timers Used with STP

Timer

Primary Purpose

Default

Hello Time Forward Delay Max Age

The amount of time between the sending of Configuration BPDUs by the Root Switch The duration of the Listening and Learning states How long a BPDU is stored

2 seconds 15 seconds 20 seconds

The Hello Time is the amount of time between the sending of Configuration BPDUs. The 802.1D standard specifies a default value of 2 seconds. This value controls Configuration BPDUs as the Root Switch generates them. Other bridges propagate BPDUs from the Root Switch as they are received. If BPDUs stop arriving for the time interval ranging from 2 to 20 seconds because of a network disturbance, or if the Root Switches stop sending periodic BPDUs during this time, the timer expires. The range between the expected receipt of a BPDU and the expiration of

172

Chapter 3: Spanning Tree Protocol (STP)

the Max Age time is 2 to 20 seconds. If the outage lasts for more than 20 seconds (the default Max Age time), the bridge invalidates the saved BPDUs and begins looking for a new Root Port. Forward Delay is the amount of time the bridge spends in the Listening and Learning states. This is a single value that controls both states. The default value of 15 seconds was originally derived assuming a maximum network size of seven bridge hops, a maximum of three lost BPDUs, and a Hello Time of 2 seconds. The Forward Delay timer also controls the bridge table age-out period after a change in the active topology. Max Age is the STP timer that controls how long a bridge stores a BPDU before discarding it. Max Age is an issue only when the link failure is not on a directly connected link. When a failure occurs on a directly connected link, the switch knows that no BPDUs will be coming in on that link, so Max Age is not considered in transitioning the port to Forwarding state. Recall that each port saves a copy of the best BPDU it has seen. As long as the bridge receives a continuous stream of BPDUs every 2 seconds, Max Age does not come into play. However, if the device sending this best BPDU fails, a mechanism must exist to allow other bridges to take over. For example, assume that the Segment 3 link shown in Figure 3-14 uses a hub and that Port 1/2 on the Cat-B transceiver fails. Cat-C receives no immediate notification of the failure, because it still has an active Ethernet link to the hub. The only thing Cat-C knows is that BPDUs stop arriving. Twenty seconds (Max Age) after the failure, Port 1/2 on Cat-C ages out the BPDU information that lists Cat-B as having the best Designated Port for Segment 3. This forces Port 1/2 on Cat-C to transition to the Listening state in an effort to become the Designated Port. Because Port 1/2 on Cat-C now offers the most attractive access from the Root Switch to this link, it eventually transitions all the way into Forwarding state. In this example, with a hub between Cat-B and Cat-C, it takes approximately 50 seconds (20 Max Age + 15 Listening + 15 Learning) for Cat-C to take over after the failure of Port 1/2 on Cat-B. In some situations, switches can detect topology changes on directly connected links and immediately transition into the Listening state without waiting Max Age seconds. For example, in Figure 3-15, Port 1/1 on Cat-C fails. Because the failure results in a loss of link on the Root Port, there is no need to wait 20 seconds for the old information to age out. Note the difference between this scenario and the one in Figure 3-14, where link integrity was maintained because of the presence of a hub. When Port 1/1 on Cat-C fails, Port 1/2 on Cat-C immediately goes into Listening state in an attempt to become the new Root Port. The STP convergence time decreases from 50 seconds to 30 seconds (15 Listening + 15 Learning). So the port moves into Forwarding state within 30 seconds.

STP Processes

173

Figure 3-14 A Hub Connects Cat-B and Cat-C in a Converged STP Topology Root Bridge Segment 1 Forwarding Designated Port Root Port 1/1
Cat-A

1/2

Forwarding Segment 2 Designated Port Root Port

Forwarding 1/1
Cat-B

Forwarding 1/1
Cat-C

1/2 Forwarding Designated Port Non-Designated Port

1/2 Blocking

X

Figure 3-15 Port 1/1 on Cat-C Fails Root Bridge Segment 1 Forwarding Designated Port Root Port 1/1
Cat-C

1/1
Cat-A

1/2

Forwarding Segment 2 Designated Port

X

Forwarding 1/1
Cat-B

1/2 Forwarding Designated Port Segment 3 Root Port

1/2 Forwarding

174

Chapter 3: Spanning Tree Protocol (STP)

There are two key points to remember about using the STP timers:
■ ■

Default timer values should not be changed without careful consideration. If timer tuning is attempted, modify the STP timers only from the Root Switch, because the BPDUs contain three fields with timer values that can be passed from the Root Switch to all other bridges in the network. If every bridge were locally configured, some bridges could work their way up to the Forwarding state before other bridges ever left the Listening state. This chaotic approach could quickly lead to an unstable network. By providing timer fields in the BPDUs, the single bridge acting as the Root Switch can dictate the timing parameters for the entire bridged network.

BPDU Format
The format of a STP BPDU frame varies depending on the type of protocol used. Figure 3-16 shows the format of an IEEE 802.1D Spanning Tree Protocol BPDU frame. Figure 3-17 shows the format of a Cisco STP BPDU frame.
Figure 3-16 IEEE 802.1D Is the Original Specification for STP

Frame Control (1 Byte)

Destination Address (6 Bytes)

Source Address (6 Bytes)

Logical Link Control (3 Bytes)

IEEE BPDU

Figure 3-17 Cisco Catalyst Switches Use a Proprietary BPDU Frame Format

Frame Control (1 Byte)

Destination Address (6 Bytes)

Source Address (6 Bytes)

Routing Information Field (Variable)

Logical Link Control (3 Bytes)

IEEE BPDU

The fields shown in both Figures 3-16 and 3-17 are as follows:
■ ■

The Frame Control field is always 01. The Destination Address field indicates the destination address as specified in the Bridge Group Address table. For IEEE STP BPDU frames, the address is 0x800143000000. The Source Address field indicates the base MAC address used by the switch. For Cisco STP BPDU frames, the multicast bit is set to indicate the presence of a Routing Information Field (RIF) in the header.

STP Processes

175

The Routing Information field is applicable only to Cisco STP BPDU frames. The RIF must be set to 0x0200. The Logical Link Control field controls all types of STP BPDU frames. This field is set to 0x424203.

Figure 3-18 shows the format of the fields inside a BPDU. All fields in the BPDU are common to all STPs except for the Port ID field. For IEEE and Cisco STP BPDU frames, the Port ID field specifies the transmitting Port Number of the originating bridge.
Figure 3-18 Fields in the BPDU

Protocol Identifier (2 Bytes)

Version (1 Byte)

Message Type (1 Byte)

Flags (1 Byte)

Root ID (8 Bytes)

Root Path Cost (4 Bytes)

Bridge ID (8 Bytes)

Port ID (2 Bytes)

Message Age (2 Bytes)

Maximum Age (2 Bytes)

Hello Time (2 Bytes)

Forward Delay (2 Bytes)

The Protocol Identifier, Version, and Message Type fields are all set to 0. The Flags field includes one of the following:

A Topology Change (TC) bit, which signals a topology change and designates this BPDU as a Topology Change Notification (TCN) BPDU. Without this bit set, the BPDUs are Configuration BPDUs. A Topology Change Acknowledgment (TCA) bit, which is set to acknowledge receipt of a configuration message with the TC bit set.

The remaining fields contained in a BPDU frame are as follows:

The Root ID field indicates the Root Switch by listing its 2-byte priority followed by its 6-byte ID. The Root Path Cost field indicates the path’s cost from the bridge sending the configuration message to the Root Bridge. The BID field indicates the priority and ID of the bridge sending the message. The Port ID field indicates the Port Number (IEEE or Cisco STP BPDU) from which the configuration message was sent. This field allows loops created by multiple attached bridges to be detected and corrected. The Message Age field indicates how much time has elapsed since the root sent the configuration message on which the current configuration message is based. The Maximum Age field indicates when the current configuration message should be deleted. The Hello Time field indicates the time between Root Bridge configuration messages.

■ ■

176

Chapter 3: Spanning Tree Protocol (STP)

The Forward Delay field indicates how long bridges should wait before transitioning to a new state after a topology change. If a bridge transitions too soon, it is possible that not all network links will be ready to change their state, and loops can result.

Topology Changes and STP
STP implements a series of timers to prevent bridging loops from occurring within the network. It can take from 30 to 50 seconds for a network to converge to a new topology when a change occurs in an otherwise stable STP process. While the network is converging, physical addresses that can no longer be reached are still listed in the switch table. Because these addresses are in the table, the switch attempts to forward frames to devices it cannot reach. Fortunately, the STP change process requires the switch to clear the table faster to get rid of unreachable physical addresses. Figure 3-19 illustrates a link failure between Switch D and Switch E, which in turn triggers a topology change condition. This topology change condition triggers a Topology Change Notification BPDU to be generated and sent toward the Root Switch. For this BPDU to reach the Root Switch, each switch forwards the update out the Root Port (RP in the figure) and toward the Designated Port (DP in the figure) of each Designated Bridge along the path to the Root Switch.
Figure 3-19 A Link Failure Triggers a Topology Change, Which STP Handles Via Built-in Mechanisms Switch B Regenerates Topology Change BPDU
RP

500:000000000001
DP

Root A
1 2

DP

32768:000000000002

RP 1 2

1 2

32768:000000000004

B
DP

C
DP

NDP

Switch D Generates Topology Change BPDU

RP

1

2 3

D

E

32768:000000000003

The topology change in this spanning-tree network triggers the following steps: Step 1 Switch D notices that a change to a link has occurred.

STP Enhancements

177

Step 2

Switch D sends a Topology Change Notification (TCN) BPDU out the Root Port destined ultimately for the Root Switch. The TCN BPDU is indicated by the value 0x80 in the BPDU’s 1-byte Type field. The bridge sends out the TCN BPDU until the Designated Bridge for that segment responds with a TCA Configuration BPDU, indicated by the high-order bit in the 1-byte Flag field. The Designated Bridge (Switch B) for that segment sends out a TCA Configuration BPDU to the originating bridge (Switch D). Switch B also sends a TCN BPDU out the Root Port destined for the Root Switch. When the Root Switch receives the (upstream) TCN BPDU, it sends Configuration BPDUs to indicate that a topology change is occurring (using the loworder bit in the Flag field). The Root Switch sets the topology change in the configuration for a period of time equal to the sum of the Forward Delay and Max Age parameters. A bridge receiving a (downstream) topology change configuration message from the Root Switch uses the Forward Delay timer (15 seconds) to age out entries in the address table. This allows the device to age out entries faster than the normal 5-minute default so that stations that are no longer available are aged out faster. The bridge continues this process until it no longer receives topology change configuration messages from the Root Switch.

Step 3

Step 4

Step 5

STP Enhancements
Cisco implemented several proprietary improvements to IEEE 802.1D STP to speed convergence in certain situations. PortFast allows immediate conversion to the Forwarding state on ports connected to workstations, servers, or routers (access ports). UplinkFast speeds up STP convergence on uplink trunk ports when redundant uplinks are available and one of them fails. BackboneFast speeds up STP convergence when an indirect trunk link goes down.

Delay in STP Updates
The current IEEE 802.1D STP standard was designed at a time when recovering connectivity after an outage within a minute or so was considered adequate performance. With the advent of Layer 3 switching in LAN environments, Layer 2 switching (as illustrated in Figure 3-20) competes with routed solutions where protocols, such as OSPF and EIGRP, can provide an alternate path in less time.

178

Chapter 3: Spanning Tree Protocol (STP)

Figure 3-20 A Traditional Switched Campus Network Was Layer 2 Switched Throughout

IDF

IDF Access

IDF

IDF

MDF Layer 2

MDF

MDF

MDF

Distribution

Core

Core

Core

Server Farm

Enhancements to the IEEE 802.1D specification have been developed in an attempt to speed up STP alternate path selection. These areas are discussed in the following sections.

PortFast
STP PortFast is a Catalyst feature that causes a switch or trunk port to enter the STP Forwarding state immediately, bypassing the Listening and Learning states. IOS-based switches use PortFast only on access ports connected to end stations, as shown in Figure 3-21. When a device is connected to a port, the port normally enters the Listening state. When the Forward Delay timer expires, the port enters the Learning state. When the Forward Delay timer expires a second time, the port is transitioned to the Forwarding or Blocking state. When PortFast is enabled on a switch or trunk port, the port is immediately transitioned to the Forwarding state. As soon as the switch detects the link, the port is transitioned to the Forwarding state (less than 2 seconds after the cable is plugged in).

STP Enhancements

179

Figure 3-21 PortFast Is an Extremely Useful Option for Access Switch Ports Connected to Hosts Catalyst 3550 Series Switch

Catalyst 2950 Switch PortFastEnabled Ports

Catalyst 2950-T Switch

Server

Workstations

Workstations

If a loop is detected and PortFast is enabled, the port is transitioned to the Blocking state. It is important to note that PortFast begins only when the port first initializes. If the port is forced into the Blocking state for some reason and later needs to return to the Forwarding state, the usual Listening and Learning processes are performed. (Note the difference here from the usual PortFast operation when a link first initializes.) A primary reason for enabling PortFast is in cases where a PC boots in a period less than the 30 seconds it takes for a switch to put a port into Forwarding state from Disconnected state. Some network interface card (NICs) do not enable a link until the MAC layer software driver is actually loaded. Most operating systems try to use the network almost immediately after the driver is loaded, as in the case of Dynamic Host Configuration Protocol (DHCP). This can create a problem, because the 30 seconds of STP delay from listening to Forwarding states begins right when the IOS begins trying to access the network. In the case of DHCP, the PC does not obtain a valid IP address from the DHCP server. This problem is common with PC Card (PCMCIA) NICs used in laptop computers. Additionally, there is a race between operating systems and CPU manufacturers. CPU manufacturers keep making the chips faster while operating systems keep slowing down, but the chips are speeding up at a greater rate than the operating systems are slowing down. As a result, PCs are booting faster than ever. In fact, modern machines are often finished booting and need to use the network before the STP 30-second delay is over.

180

Chapter 3: Spanning Tree Protocol (STP)

This problem motivates some network administrators to disable STP altogether. This certainly fixes any STP booting problems, but it can easily create other problems. If this strategy is employed, all physical loops must be eliminated, meaning no redundancy. STP cannot be disabled for a single port, so the PortFast feature should be considered. The PortFast feature gives the best of both worlds—immediate end-station access and the safety net of STP. The later section “Configuring PortFast” details the procedures for configuring this feature on a Catalyst switch.

UplinkFast
During the time it takes for STP to converge, some end stations might become inaccessible, depending on the STP state of the switch port to which the station is attached. This disrupts network connectivity, so it would be advantageous to decrease STP convergence time and reduce the length of the disruption. UplinkFast was developed to facilitate fast STP convergence. UplinkFast is a Catalyst feature that accelerates the choice of a new Root Port when a link or switch fails. Switches in hierarchical networks can be grouped into core layer switches, distribution layer switches, and access layer switches. Figure 3-22 shows a portion of a campus network in which distribution switches and access switches each have at least one redundant link that STP blocks to prevent loops. If a switch loses connectivity on a link, it begins using the alternative paths as soon as STP selects a new Root Port. When STP reconfigures the new Root Port, other interfaces flood the network with multicast packets, at least one for each address that was learned on the interface.
Figure 3-22 Redundancy Is Critical for a Robust Network Design Root Switch Core Switches 3550 3550

Distribution Switches

2900

2950T

3500 XL

2950 Access Switches
Active Link Blocked Link

2950

2950

2950

STP Enhancements

181

UplinkFast accelerates the choice of a new Root Port when a link or switch fails or when STP reconfigures itself. The Root Port transitions to the Forwarding state immediately without going through the Listening and Learning states, as it would with the usual STP process. UplinkFast also limits the burst of multicast traffic by reducing the max-update-rate, which specifies the maximum rate (in packets per second) at which update packets are sent. For IOS the default for this parameter is 150 packets per second. UplinkFast is most useful in wiring closet switches at the edge of the network. It is inappropriate for backbone (core) devices. UplinkFast provides fast convergence after a direct link failure and achieves load sharing between redundant links using uplink groups. An uplink group is a set of interfaces (per VLAN), only one of which is forwarding at any given time. Specifically, an uplink group consists of the Root Port (which is forwarding) and a set of Blocked Ports. The uplink group provides an alternative path in case the currently forwarding link fails. Figure 3-23 shows a sample topology with no link failures and a Blocked Port on Switch C.
Figure 3-23 A Blocked Port Is in Effect When Physical Loops Are Present in a Network Running STP Switch A (Root)
L1

Switch B

L2

L3 Blocked Port

Switch C

Switch A, the Root Switch, is connected directly to Switch B over link L1 and to Switch C over link L2. The interface on Switch C that is connected directly to Switch B is in a Blocking state. Switch C is configured with UplinkFast. If Switch C detects a link failure on the currently active link L2 on the Root Port (a direct link failure), UplinkFast unblocks the Blocked Port on Switch C and transitions it to the Forwarding state without going through the Listening and Learning states, as illustrated in Figure 3-24.

182

Chapter 3: Spanning Tree Protocol (STP)

Figure 3-24 UplinkFast Enables a Quick Transition to Forwarding State for an Alternate Uplink Upon Primary Link Failure Switch A (Root)
L1

Switch B

L2 Link Failure

L3

UplinkFast Transition Port Directly to Forwarding State

Switch C

The change affected by UplinkFast takes approximately 1 to 5 seconds. As soon as a switch transitions an alternative port to the Forwarding state, the switch begins transmitting dummy multicast frames on that port, one for each entry in the local bridge table (except entries that are associated with the failed Root Port). By default, approximately 15 dummy multicast frames are transmitted per 100 milliseconds. Each dummy multicast frame uses the station address in the bridge table entry as its source MAC address and a dummy multicast address (01-00-0C-CD-CD-CD) as the destination MAC address. Switches receiving these dummy multicast frames immediately update their bridge table entries for each source MAC address to use the new port, allowing the switches to begin using the new path almost immediately. In the event that connectivity on the original Root Port is restored, the switch waits for a period equal to twice the Forward Delay time plus 5 seconds before transitioning the port to the Forwarding state to give the neighbor port time to transition through the Listening and Learning states to the Forwarding state. Configuring UplinkFast on Catalyst switches is straightforward, as you will see in the section “Configuring UplinkFast.”

BackboneFast
BackboneFast is a Catalyst feature that is initiated when a Root Port or Blocked Port on a switch receives inferior BPDUs from its Designated Bridge. An inferior BPDU identifies one switch as both the Root Switch and the Designated Bridge. When a switch receives an

STP Enhancements

183

inferior BPDU, it means that a link to which the switch is not directly connected (an indirect link) has failed. That is, the Designated Bridge has lost its connection to the Root Switch. Under STP rules, the switch ignores inferior BPDUs for the configured Max Age (the default is 20 seconds). The role of BackboneFast is essentially to cheat this 20-second delay. When the switch receives the inferior BPDU, the switch tries to determine if it has an alternative path to the Root Switch. There are two cases to consider:

If the inferior BPDU arrives on a Blocked Port, the Root Port and other Blocked Ports on the switch become alternative paths to the Root Switch. If the inferior BPDU arrives on the Root Port, all Blocked Ports become potential alternative paths to the Root Switch.

If the inferior BPDU arrives on the Root Port and there are no Blocked Ports, the switch assumes that it has lost connectivity to the Root Switch, causing the Max Age on the root to expire, and it becomes the Root Switch according to normal STP rules. If the switch has alternative paths to the Root Switch, it uses these alternative paths to transmit a new kind of protocol data unit (PDU) called the Root Link Query PDU. The switch sends the Root Link Query PDU on all potential alternative paths to the Root Switch. If the switch determines that it still has an alternative path to the root, it causes the Max Age on the ports on which it received the inferior BPDU to expire. The switch then makes all ports on which it received an inferior BPDU its Designated Ports and moves them out of the Blocking state (if they were in the Blocking state), through the Listening and Learning states, and into the Forwarding state. On the other hand, if the switch learns via the Root Link Query process that all the alternative paths to the Root Switch have lost connectivity to the root, the switch causes the Max Age on the ports on which it received inferior BPDUs to expire, and a new STP topology is calculated. To illustrate this process, Figure 3-25 shows a sample topology with no link failures. Switch A, the Root Switch, connects directly to Switch B over link L1 and to Switch C over link L2. The interface on Switch C that connects directly to Switch B is in the Blocking state.

184

Chapter 3: Spanning Tree Protocol (STP)

Figure 3-25 A Converged Spanning-Tree Topology Is in Place Switch A (Root)
L1

Switch B

L2

L3 Blocked Port

Switch C

If link L1 fails, Switch C cannot directly detect this failure, because it is not directly connected to link L1. Switch B is directly connected to the Root Switch over L1, detects the failure, elects itself as the root, and begins sending BPDUs to Switch C. When Switch C receives the inferior BPDUs from Switch B, Switch C assumes that an indirect failure has occurred. At that point, BackboneFast allows the Blocked Port on Switch C to move immediately to the Listening state without waiting for Max Age on the port to expire. BackboneFast then transitions the interface on Switch C to the Forwarding state, providing a path from Switch B to Switch A. This switchover takes approximately 30 seconds, twice the Forward Delay time if the default Forward Delay time of 15 seconds is set. This saves up to 20 seconds. Figure 3-26 shows how BackboneFast reconfigures the topology to account for the failure of link L1.
Figure 3-26 BackboneFast Permits Rapid STP Reconvergence When a Remote Link Fails Switch A (Root)
L1 Link Failure

Switch B

L2

L3

BackboneFast Transition Port Through Listening and Learning State to Forwarding State.

Switch C

802.1w Rapid STP

185

The later section “Configuring BackboneFast” details the procedures for configuring this feature on a Catalyst switch.

802.1w Rapid STP
Rapid Spanning Tree Protocol (RSTP) IEEE 802.1w can be seen as more of an evolution of the 802.1D standard than a revolution (see Figure 3-27). The 802.1D terminology remains primarily the same, and most parameters have been left unchanged so that users familiar with 802.1D can rapidly configure the new protocol comfortably. In most cases, RSTP performs better than Cisco’s proprietary extensions without any additional configuration. 802.1w also can revert to 802.1D to interoperate with legacy bridges (thus, dropping the benefits it introduces) on a per-port basis. This section briefly explains the enhancements RSTP adds to the previous 802.1D standard.
Figure 3-27 Trying to Keep All the STPs and Their Features in Perspective Is Challenging
Cisco’s Implementation
Spanning Tree Protocol (STP): • 802.1D • Common Spanning Tree (CST) • Mono Spanning Tree (MST) Cisco Enhancements (First Evolution): • PortFast • UplinkFast • BackboneFast

Spanning Tree Protocol Process
ST = Spanning Tree

IEEE Standard
RSTP: • 802.1W • Edge Port (Cisco PortFast) • UplinkFast RSTP (Cisco UplinkFast) • BackboneFast Engine (Cisco BackboneFast)

ST

VLAN 1

VLAN 2

VLAN 3

Cisco Enhancements (Second Evolution): • PVST: ISL • PVST+: ISL & 802.1Q • Includes previous Enhancements • Additional Enhancements: • BPDU Guard • Root Guard Cisco MISTP: • Uses PVST+ • Includes previous Enhancements • Catalyst 4000/6000

ST

ST

ST

VLAN 1

VLAN 2

VLAN 3

ST

ST

Multiple Spanning Tree (MSTP): • 802.1s • Uses RSTP

VLAN 1

VLAN 2

VLAN 3

186

Chapter 3: Spanning Tree Protocol (STP)

RSTP States
802.1D defined five different port states:
■ ■ ■ ■ ■

Disabled Listening Learning Blocking Forwarding

Table 3-5 compares the 802.1D STP states with the 802.12 RSTP states.
Table 3-5 IEEE 802.1w Has Three Port States Versus the Five Port States Used in IEEE 802.1D

Is the Port Included RSTP (802.1w) STP (802.1D) Port State Port State in the Active Topology?

Is the Port Learning MAC Addresses?

Disabled Blocking Listening Learning Forwarding

Discarding Discarding Discarding Learning Forwarding

No No No No Yes

No No No Yes Yes

IEEE 802.1D STP was a bit confusing in that it mixed a port’s state (whether it blocks or forwards traffic) and the role it plays in the active topology (Root Port, Designated Port, and so on). For example, from an operational point of view, there is no difference between a port in Blocking state and a port in Listening state. They both discard frames and do not learn MAC addresses. The real difference lies in the role the spanning tree assigns to the port. It can be safely assumed that a port in Listening state is either Designated or Root and is on its way to the Forwarding state. Unfortunately, once in Forwarding state, there is no way to infer from the port state whether the port is Root or Designated, which demonstrates the weakness of this state-based terminology. RSTP addresses this by decoupling a port’s role and state. Only three port states in RSTP correspond to the three possible operational states. The 802.1D states Disabled, Blocking, and Listening have been merged into a unique 802.1w Discarding state, as shown in Table 3-5. Rapid transition to Forwarding state is the most important feature introduced by 802.1w. The legacy Spanning Tree Algorithm passively waited for the network to converge before turning

802.1w Rapid STP

187

a port into the Forwarding state. Achieving faster convergence was a matter of tuning the conservative default parameters (Forward Delay and Max Age timers), often putting the network’s stability at stake. RSTP can actively confirm that a port can safely transition to the Forwarding state without relying on any timer configuration. RSTP provides a real feedback mechanism that takes place between RSTP-compliant bridges. To achieve fast convergence on a port, the protocol relies on two new variables—edge ports and link type. The edge port concept is already well known to the Cisco implementation of STP, because it basically corresponds to the PortFast feature. All ports directly connected to end stations cannot create bridging loops in the network and, thus, can directly transition to the Forwarding state, skipping the Listening and Learning states. Neither edge ports nor PortFast-enabled ports generate topology changes when the link toggles. Unlike PortFast, an edge port that receives a BPDU immediately loses its edge port status and becomes a normal spanning-tree port. At this point, the edge port state has a user-configured value and an operational value. Cisco implementation maintains the portfast keyword to be used for edge port configuration, thus making the transition to RSTP simpler. RSTP link type, point-to-point or shared, can achieve rapid transition to the Forwarding state only on edge ports and on point-to-point links. The link type is automatically derived from a port’s duplex mode. A port operating in full duplex is assumed to be point-to-point, whereas a half-duplex port is considered a shared port by default. This automatic link type setting can be overridden by explicit configuration. In today’s switched networks, most links operate in full-duplex mode and, therefore, are treated as point-to-point links by RSTP. This makes them candidates for rapid transition to the Forwarding state.

RSTP Port Roles
The RSTP role is now a variable assigned to a given port. The Root Port and Designated Port roles remain, but the Blocking Port role is now split into backup and Alternate Port roles. The Spanning Tree Algorithm determines a port’s role based on BPDUs. To keep things simple, the thing to remember about a BPDU is that there is always a way to compare any two of them and to decide whether one is more useful than the other. This is based on the values stored in the BPDU and occasionally on the port on which they are received. This considered, the following paragraphs explain practical approaches to port roles. As in standard STP, the port receiving the best BPDU on a bridge is the Root Port. This is the port that is the closest to the Root Bridge in terms of Path Cost, as shown in Figure 3-28.

188

Chapter 3: Spanning Tree Protocol (STP)

Figure 3-28 RSTP Also Uses Root Ports

R Root Port

Root

R
A

R
B

If a port can send the best BPDU on the segment to which it is connected, the port is considered a Designated Port (see Figure 3-29). As with 802.1D, bridges create a bridged domain by linking different segments. A given segment can have only one path to the Root Switch. Multiple paths would create a bridging loop in the network.
Figure 3-29 RSTP Uses Designated Ports as Well

D Designated Port

Root

D

D

R
A

R
B

D

Alternate Port and Backup Port roles correspond to the Blocking state of 802.1D. A Blocked Port is defined as not being the Designated or Root Port. A Blocked Port receives a more useful BPDU than the one it would send out on its segment. Remember that a port absolutely needs to receive BPDUs to stay blocked. RSTP introduces these two roles for this purpose. An Alternate Port is a port blocked by receiving more useful BPDUs from another bridge, as shown in Figure 3-30.

802.1w Rapid STP

189

Figure 3-30 An Alternate Port Is a Port Blocked by Receiving More Useful BPDUs from Another Bridge

Root

Alternate Port

D

D

R
A

R
B

D

A Backup Port is a port blocked by receiving more useful BPDUs from the same bridge it is on, as shown in Figure 3-31.
Figure 3-31 A Backup Port Is a Port Blocked by Receiving More Useful BPDUs from the Same Bridge

Root

Backup Port

D

D

R
A

R
B

D

This Backup Port distinction was already made internally within 802.1D and is essentially how Cisco UplinkFast functions. The rationale behind 802.1w is that an Alternate Port provides an alternate path to the Root Bridge and, therefore, could replace the Root Port should it fail. A Backup Port provides redundant connectivity to the same segment and cannot guarantee alternate connectivity to the Root Switch. Therefore it was excluded from the uplink group.

190

Chapter 3: Spanning Tree Protocol (STP)

RSTP calculates the final topology for the spanning tree using exactly the same criteria as 802.1D. There is absolutely no change in how the different bridge and port priorities are used. The term Blocking is used for the Discarding state in Cisco implementation. With RSTP, there is a difference between the role the protocol has determined for a port and its current state. For example, with RSTP it is perfectly valid for a port to be both a Designated Port and a Blocking Port at the same time. Although this typically happens for very short periods of time, it simply means that this port is in a transitory state toward designated forwarding.

RSTP Timers
When the Spanning Tree Algorithm selects a port to become a Designated Port, 802.1D still waits twice the Forward Delay number of seconds (2 * 15 seconds by default) before transitioning it to the Forwarding state. In RSTP, this condition corresponds to a port with a designated role but a Blocking state. Figures 3-32 to 3-36 illustrate how fast transition is achieved step by step. If a new link is created between the root and Switch A, both ports on the link are put in a Discarding state until they receive a BPDU from their counterpart. When a Designated Port is in Discarding or Learning state, and only in this case, it sets the proposal bit on the BPDUs it sends out. This is what happens for port p0 of the Root Switch, as shown in Step 1 of Figure 3-32. Because Switch A receives superior information, it immediately knows that p1 will be its new Root Port. Switch A then starts a sync to ensure that all its ports are in sync with this new information.
Figure 3-32 RSTP Uses a Sync Mechanism That Does Not Depend on Timers

Root
p0 3. Agreement, p1 Forwarding p1 1. Proposal p0: Designated Port p1: New Root Port p2: Alternate Port p3: Designated Port p4: Edge Port

A
p2 p3 p4

2. Sync (Unchanged)

2. Sync (Block)

2. Sync (Unchanged)

A port is in sync if it meets either of the following criteria:
■ ■

It is in a Blocking state (which means Discarding in a stable topology) It is an edge port

802.1w Rapid STP

191

To illustrate the effect of the sync mechanism on different kinds of ports, suppose there exists an Alternate Port p2, a designated forwarding port p3, and an edge port p4 on Switch A, as illustrated in Figure 3-32. Notice that p2 and p4 already meet one of the criteria just listed. To be in sync, Switch A needs to block port p3, assigning it the Discarding state. Now that all of its ports are in sync, Switch A can unblock its newly selected Root Port p1, and reply to the root by sending an agreement message. This message is a copy of the proposal BPDU, with the agreement bit set instead of the proposal bit. This ensures that port p0 knows exactly to which proposal the agreement it receives corresponds. After p0 receives that agreement, it can immediately transition to the Forwarding state, as shown in Figure 3-33. Notice that port p3 was left in a designated Discarding state after the sync. In Step 4, that port is in the same situation as was port p0 during Step 1 (in Figure 3-32). It then starts proposing to its neighbor, attempting to quickly transition to forwarding.
Figure 3-33 p0 Immediately Transitions to Forwarding

Root
p0 4. go forwarding p1

A
p2 p3 p4

4. proposal

The proposal agreement mechanism is very fast, because it does not rely on any timers. This wave of handshakes propagates quickly toward the edge of the network and quickly restores connectivity after a change in the topology. If a designated discarding port does not receive an agreement after having sent a proposal, it falls back to the traditional 802.1D Listening-Learning sequence. This could happen if the remote bridge does not understand RSTP BPDUs or if the remote bridge port is blocking, as with Switch C in Figure 3-34. UplinkFast RSTP incorporates an automatically enabled feature similar to the Cisco UplinkFast proprietary STP extension. The 802.1w topology change mechanism clears the appropriate entries in the Content Addressable Memory (CAM) tables of the upstream bridges, removing the need for UplinkFast’s dummy multicast generation process.

192

Chapter 3: Spanning Tree Protocol (STP)

Figure 3-34 If a Remote Bridge Does Not Support RSTP, the Sync Mechanism Will Not Work, and the Switches Resort to Traditional 802.1D STP

Root 1

A 2 3 B C D

When an 802.1D bridge detects a topology change, it first notifies the Root Bridge using a reliable mechanism, as shown in Figure 3-35. As soon as the Root Bridge is aware of a change in the network topology, it sets the TC flag on the BPDUs it sends out, which are then relayed to all the bridges in the network. When a bridge receives a BPDU with the TC flag bit set, it reduces its bridging table aging time to forward delay seconds, ensuring a relatively quick flushing of stale information.
Figure 3-35 An 802.1D Bridge Reacts to a Topology Change by Notifying the Root Switch with a Reliable Mechanism

Root

Root

T

This topology change mechanism has been deeply remodeled in RSTP. Both the detection of a topology change and propagation through the network have evolved.

802.1w Rapid STP

193

In RSTP, only non-edge ports moving to the Forwarding state cause a topology change. This means that a loss of connectivity is not considered a topology change, contrary to 802.1D (that is, a port moving to blocking no longer generates a TC). When a RSTP bridge detects a topology change, the following happens:

The RSTP bridge starts the TC While timer with a value equal to twice the Hello Time for all its non-edge Designated Ports and its Root Port if necessary. The RSTP bridge flushes the MAC addresses associated with all of these ports. As long as the TC While timer is running on a port, the BPDUs sent out that port have the TC bit set. BPDUs are also sent on the Root Port while the timer is active.

■ ■

Topology change propagation with RSTP is handled differently with RSTP. When a bridge receives a BPDU from a neighbor with the TC bit set, the following happens:

The bridge clears the MAC addresses learned on all of its ports except the one that received the topology change. The bridge starts the TC While timer and sends BPDUs with the TC set on all of its Designated Ports and Root Port. (RSTP no longer uses the specific TCN BPDU unless a legacy bridge needs to be notified.)

This way, the TCN is flooded very quickly across the whole network, as shown in Figure 3-36.
Figure 3-36 The Initiator of the Topology Change Floods the Information Throughout the Network

Root

TC

With RSTP, the TC propagation is a one-step process. In fact, the initiator of the topology change floods this information throughout the network (as opposed to 802.1D, where only the root could do so). This mechanism is much faster than the 802.1D equivalent. There is no need to wait for the Root Bridge to be notified and then maintain the topology change state for the whole network for Max Age plus Forward Delay seconds. In just a few seconds (a

194

Chapter 3: Spanning Tree Protocol (STP)

small multiple of Hello Time), most of the entries in the CAM tables of the entire network (VLAN) are flushed. This approach results in potentially more temporary flooding, but on the other hand, it clears potential stale information that prevents rapid connectivity restitution. RSTP is fully compatible with and capable of interoperating with legacy (802.1D) STP protocols. However, it is important to note that 802.1w inherent fast convergence benefits are lost when interacting with legacy bridges.

RSTP BPDU Format
RSTP has introduced a few changes to the BPDU format. Only two flags, Topology Change (TC) and TC Acknowledgment (TCA), were defined in 802.1D. As shown in Figure 3-37, RSTP uses all 6 remaining bits of the flag byte to do the following:
■ ■

Encode the role and state of the port originating the BPDU Handle the proposal/agreement mechanism

Figure 3-37 The RSTP BPDU Uses All the Bits in the Flag Byte

0

1

2

3 Portrole

4 Learning

5 Forwarding

6

7

Topology Proposal Change

Agreement Topology Change ACK

00 Unknown 01 Alternate/Backup 10 Root 11 Designated

Another important change is that the RSTP BPDU is of type 2, version 2. The implication is that legacy bridges must drop this new BPDU. This property makes it easy for an 802.1w bridge to detect legacy bridges connected to it. BPDUs are sent every Hello Time (not simply relayed, as with 802.1D). With 802.1D, a non-Root Switch generated BPDUs only when it received one on its Root Port. In fact, with 802.1D, a bridge relays BPDUs more than actually generating them. This is not the case with 802.1w, where a bridge sends a BPDU with its current information every Hello Time seconds (2 by default), even if it does not receive any BPDUs from the Root Bridge. On a given port, if hellos are not received for three consecutive times (or if Max Age expires), protocol information can be immediately aged out. Because of the previously mentioned protocol modification, BPDUs are now used as a keepalive mechanism between bridges. A bridge decides it has lost connectivity to its direct neighboring root or designated bridge if it

Evolution of Spanning Tree

195

misses three BPDUs in a row. This fast aging of the information allows quick failure detection. If a bridge fails to receive BPDUs from a neighbor, it is certain that the connection to that neighbor has been lost, as opposed to 802.1D, where the problem could be anywhere on the path to the root. Note that with RSTP, failures are detected much faster in case of physical link failures than with 802.1D. The concept of accepting inferior BPDUs is what makes up the core of the BackboneFast engine. The IEEE 802.1w committee decided to incorporate a similar mechanism into RSTP. When a bridge receives inferior information from its Designated or Root Switch, it immediately accepts it and replaces the one previously stored. In Figure 3-38, Bridge C still knows the root is alive and well and immediately sends a BPDU to Bridge B containing information about the Root Switch. As a result, Bridge B stops sending its own BPDUs and accepts the port leading to Bridge C as its new Root Port.
Figure 3-38 Bridge B Stops Sending Its Own BPDUs and Accepts the Port Leading to Bridge C as Its New Root Port

B Root Inferior BPDU “I Am the Root”

C

Evolution of Spanning Tree
Several options are now available with STP on Catalyst switches, as described in this section. PVST+ is still the default setting on Catalyst switches, but RSTP and MST are now viable alternatives. The legacy 802.1D implementations of spanning tree are also described here.

PVST (Per-VLAN Spanning Tree), PVST+, and Mono Spanning Tree Modes
Common Spanning Tree (CST) is specified in the IEEE 802.1Q standard. CST defines a single instance of spanning tree for all VLANs. BPDUs are transmitted over VLAN 1. Per-VLAN Spanning Tree (PVST) is a Cisco-proprietary implementation requiring Interlink

196

Chapter 3: Spanning Tree Protocol (STP)

Switch (ISL) trunk encapsulation. PVST runs a separate instance of STP for each VLAN. Among other things, this lets you configure distinct Root Switches for each VLAN and configure Layer 2 load sharing, as shown in Figure 3-39.
Figure 3-39 PVST Enables Layer 2 Load Sharing by Running a Separate Instance of Spanning Tree for Each VLAN

VLAN 1 Root Switch

VLAN 2 Root Switch

VLAN 1 Spanning Tree VLAN 2 Spanning Tree

Having a separate spanning tree instance for each VLAN reduces the recovery time for STP recalculation and, hence, increases network reliability in the following ways:
■ ■ ■

It reduces the overall size of the spanning-tree topology. It improves scalability and decreases convergence time. It provides faster recovery and better reliability.

Disadvantages of a spanning tree for each VLAN include the following:

Use of switches (such as CPU load) to support spanning tree maintenance for multiple VLANs Use of bandwidth on trunk links to support BPDUs for each VLAN

PVST+ is a Cisco-proprietary STP mode that allows CST and PVST to exist on the same network.

Evolution of Spanning Tree

197

PVST+ supports 802.1Q trunks and the mapping of multiple spanning trees to the single spanning tree of non-Cisco 802.1Q switches. PVST+ is automatically enabled on Catalyst 802.1Q trunks. It runs one instance of STP per VLAN when Catalyst switches are connected by 802.1Q trunks. PVST+ is the default STP used on all Ethernet, Fast Ethernet, and Gigabit Ethernet port-based VLANs on the Catalyst 4000 and 6000 family of switches. PVST+ runs on each VLAN on the switch, ensuring that each has a loop-free path through the network. PVST+ provides Layer 2 load sharing for the VLAN on which it runs. Different logical topologies can be created using the VLANs on a network to ensure that all links are used, but no single link is oversubscribed. Each instance of spanning tree has a single Root Switch. This Root Switch propagates the spanning tree information associated with that VLAN to all other switches in the network. Because each switch has the same knowledge about the network, this process ensures that the network topology is maintained. The PVST+ architecture distinguishes three types of zones or regions:
■ ■ ■

A PVST zone or region A PVST+ zone or region A mono spanning tree zone or region

Mono Spanning Tree (MST) is the spanning tree implementation used by non-Cisco 802.1Q switches. One instance of STP is responsible for all VLAN traffic. Each zone or region consists of a homogenous type of switch. Connecting two ISL ports can connect a PVST region to a PVST+ region. Similarly, connecting two 802.1Q ports can connect a PVST+ region to an MST region. Note that an MST and PVST region cannot be connected via a trunk link. Although it is possible to provide a nontrunk connection between the two regions by using an access link, this is of limited use in real-world networks. Figure 3-40 illustrates the three types of STP regions and how they are linked. At the boundary between a PVST region and a PVST+ region, the mapping of spanning trees is one-to-one. At the boundary between an MST region and a PVST+ region, the spanning tree in the MST region maps to one PVST in the PVST+ region. The one it maps to is the CST. The default CST is VLAN 1. All PVSTs, except the CST, are tunneled through the MST region. Tunneling means that BPDUs are flooded through the MST region along the single spanning tree that is present in the MST region. Do not confuse this use of the term tunnel with the point-to-point tunnels configured on Cisco routers and PIX firewalls. In general, a tunnel refers to a mechanism that enables the propagation of packets or frames through a series of devices in such a way that the contents of the packets or frames are not changed in transit.

198

Chapter 3: Spanning Tree Protocol (STP)

Figure 3-40 PVST+ Allows for Interoperation Between PVST Switches and Non-Cisco 802.1Q Mono Spanning Tree Switches

PVST+ Backbone Cisco Devices ISL Trunk 802.1Q Trunk

PVST Zone Cisco Devices

MST Zone Non-Cisco Devices

Enhanced PVST+
Enhanced PVST+ permits interoperability between PVST+ and MST. MISTP mode is a Cisco-proprietary implementation of MST on some Catalyst switches. MISTP-PVST+ allows the use of MISTP functionality of the Catalyst 4000 and 6000 series switches while continuing to communicate with the older Catalyst switches in the network that use PVST+. The MISTP options are implemented under Catalyst OS (CatOS).

MISTP Mode
After the development of PVST+, someone got the idea that it would be useful to have an STP mode that allows for a compromise between PVST+ and MST. Multiple Instances of Spanning Tree Protocol (MISTP) lets you group multiple VLANs under a single instance of spanning tree. MISTP combines the Layer 2 load-balancing benefits of PVST+ with the lower CPU load of IEEE 802.1Q. MISTP is an optional STP mode that runs on the Catalyst 4000 and 6000 switch families. A MISTP instance is a virtual logical topology defined by a set of bridge and port parameters. An MISTP instance becomes a real topology when VLANs are mapped to it. Each MISTP instance has its own Root Switch and a different set of forwarding links (that is, different bridge and port parameters). This Root Switch propagates the information associated with that instance of MISTP to all other switches in the network. This process ensures that the network topology is maintained, because each switch has the same knowledge about the network.

Evolution of Spanning Tree

199

MISTP builds MISTP instances by exchanging MISTP BPDUs with peer entities in the network. There is only one BPDU for each MISTP instance, rather than for each VLAN as in PVST+. There are fewer BPDUs in a MISTP network, so there is less overhead in the network. MISTP discards any PVST+ BPDUs it sees. A MISTP instance can have any number of VLANs mapped to it, but a VLAN can be mapped to only a single MISTP instance. VLANs can be easily moved in a MISTP topology to another MISTP instance if they have converged. However, if ports are added at the same time the VLAN is moved, additional convergence time is required.

MISTP-PVST+ Mode
MISTP-PVST+ is a transition STP mode that allows the use of MISTP functionality of the Catalyst 4000 and 6000 series switches while continuing to communicate with the older Catalyst switches in the network that use PVST+. A switch using PVST+ mode and a switch using MISTP mode that are connected cannot see the BPDUs of the other switch, a condition that can cause loops in the network. MISTP-PVST+ allows interoperability between PVST+ and MISTP, because it detects the BPDUs of both modes. To convert a network to MISTP, MISTP-PVST+ can be used to transition the network from PVST+ to MISTP to avoid problems. MISTP-PVST+ conforms to the limits of PVST+.

MST (802.1s)
The acronym MST stands for two things:
■ ■

Mono Spanning Tree Multiple Spanning Tree

Be careful to differentiate between the two in context. The Multiple Spanning Tree feature was originally released for Catalyst 4000 and 6000 series switches. MST is specified in IEEE 802.1s, an amendment to IEEE 802.1Q. MST extends the IEEE 802.1w Rapid Spanning Tree (RST) Algorithm to multiple spanning trees, as opposed to the single CST of the original IEEE 802.1Q specification. This extension provides for both rapid convergence and load sharing in a VLAN environment. Cisco implementation of MST is backward-compatible with 802.1D STP, the 802.1w RSTP, and the Cisco PVST+ architecture. MST can be thought of as a standards-based MISTP. The IEEE 802.1w specification, RSTP, provides for subsecond reconvergence of STP after failure of one of the uplinks in a bridged environment. 802.1w provides the structure on which the 802.1s feature operates.

200

Chapter 3: Spanning Tree Protocol (STP)

Table 3-6 describes support for MST on Cisco switches.
Table 3-6 MST Is Supported on All New Catalyst Switches

Catalyst Platform

MST with RSTP Support

Catalyst 2900 XL and 3500 XL Catalyst 2950 and Catalyst 3550 Catalyst 2955 Catalyst 2948G-L3 and Catalyst 4908G-L3 Catalyst 4000, Catalyst 2948G, and Catalyst 2980G (Catalyst OS) Catalyst 4000 and Catalyst 4500 (Cisco IOS) Catalyst 5000 and Catalyst 5500 Catalyst 6000 and Catalyst 6500 (Catalyst OS) Catalyst 6000 and Catalyst 6500 (Cisco IOS) Catalyst 8500

Unavailable Cisco IOS Release 12.1(9)EA1 All Cisco IOS software releases Unavailable Catalyst OS version 7.1 Cisco IOS Release 12.1(12c)EW Unavailable Catalyst OS version 7.1 Cisco IOS Releases 12.1(11b)EX, 12.1(13)E, and 12.2(14)SX Unavailable

The IEEE 802.1s Multiple Spanning Tree specification allows a user to build multiple spanning trees over VLAN trunks. Fast convergence of the MST topology is achieved using a modified version of the RSTP protocol. VLANs can be grouped and associated to spanning-tree instances. Each instance can have a topology independent of other spanning-tree instances. This new architecture provides multiple forwarding paths for data traffic and enables load sharing. Network fault tolerance is improved, because a failure in one instance does not affect other instances. In large networks, having different VLAN spanning-tree instance assignments located in different parts of the network makes it easier to administer and use redundant paths. However, a spanning-tree instance can exist only on bridges that have compatible VLAN instance assignments. Therefore, MST requires the configuration of a set of bridges with the same MST configuration information, allowing them to participate in a given set of spanning-tree instances. Interconnected bridges that have the same MST configuration are called MST regions. MST, like MISTP (see Figure 3-41), provides interoperability with PVST+ regions.

Evolution of Spanning Tree

201

Figure 3-41 MISTP Is a Cisco-Proprietary Implementation of MST PVST + Layer 2 Load Balancing

+
MST (802.1Q) Group Multiple VLANs in One Instance of Spanning Tree

=
MISTP Load Balancing + Lower CPU Utilization

Load Sharing
Load sharing can be accomplished using a couple of different methods. The most common method of load sharing is through Root Bridge placement on a per-VLAN basis. This distributes traffic for separate VLANs across separate paths to different Root Switches. A separate method divides the bandwidth supplied by parallel trunks connecting switches. To avoid loops, STP normally blocks all but one parallel link between switches. Using load sharing, traffic can be divided between the links according to which VLAN the traffic belongs to. Load sharing can be configured on trunk ports using one of the following methods:
■ ■

STP port priorities—Both load-sharing links must be connected to the same switch. STP path costs—Each load-sharing link can be connected to the same switch or to two different switches.

The following sections examine each of these methods in greater detail. For detailed configuration information, consult the “Configuring Load Sharing” section later in this chapter.

Load Sharing Using STP Port Priorities
When two ports on the same switch form a loop, the STP Port Priority setting determines which port is enabled and which port is in a blocking state. The priorities on a parallel trunk port can be set so that the port carries all the traffic for a given VLAN. The trunk port with the

202

Chapter 3: Spanning Tree Protocol (STP)

higher priority (lower values) for a VLAN forwards traffic for that VLAN. The trunk port with the lower priority (higher values) for the same VLAN remains in a Blocking state for that VLAN. One trunk port sends or receives all traffic for the VLAN. Figure 3-42 shows two trunks connecting supported switches configured as follows:
■ ■ ■ ■

VLANs 8 to 10 are assigned a Port Priority of 10 on Trunk 1. VLANs 3 to 6 retain the default Port Priority of 128 on Trunk 1. VLANs 3 to 6 are assigned a Port Priority of 10 on Trunk 2. VLANs 8 to 10 retain the default Port Priority of 128 on Trunk 2.

Figure 3-42 Port Priorities Can Be Used to Affect STP Load Sharing
Switch 1

Trunk 1 VLANs 8 to 10 (Priority 10) VLANs 3 to 6 (Priority 128) Switch 2

Trunk 2 VLANs 3 to 6 (Priority 10) VLANs 8 to 10 (Priority 128)

In the configuration shown in Figure 3-42, Trunk 1 carries traffic for VLANs 8 to 10, and Trunk 2 carries traffic for VLANs 3 to 6. If the active trunk fails, the trunk with the lower priority takes over and carries the traffic for all the VLANs. No duplication of traffic occurs over any trunk port.

Load Sharing Using STP Path Cost
Parallel trunks can be configured to share VLAN traffic by setting different Path Costs on a trunk and associating them with different sets of VLANs. The VLANs keep the traffic separate. Because no loops exist, STP does not disable the ports, and redundancy is maintained in the event of a lost link. Figure 3-43 shows that trunk ports 1 and 2 are 100BASE-T ports. The Path Costs for the VLANs are assigned as follows:
■ ■ ■ ■

VLANs 2 to 4 are assigned a Path Cost of 30 on Trunk Port 1. VLANs 8 to 10 retain the default 100BASE-T Path Cost of 19 on Trunk Port 1. VLANs 8 to 10 are assigned a Path Cost of 30 on Trunk Port 2. VLANs 2 to 4 retain the default 100BASE-T Path Cost of 19 on Trunk Port 2.

Evolution of Spanning Tree

203

Figure 3-43 Path Costs Can Be Used to Affect STP Load Sharing
Switch 1

Trunk Port 1 VLANs 2 to 4 (Path Cost 30) VLANs 8 to 10 (Path Cost 19) Switch 2

Trunk Port 2 VLANs 8 to 10 (Path Cost 30) VLANs 2 to 4 (Path Cost 19)

In the configuration shown in Figure 3-43, Trunk 1 carries traffic for VLANs 8 to 10, and Trunk 2 carries traffic for VLANs 2 to 4. If the active trunk fails, the trunk with the higher Path Cost takes over and carries the traffic for all the VLANs. No duplication of traffic occurs over any trunk port.

Switchport Tuning Using BPDU Guard
STP configures a meshed topology into a loop-free, tree-like topology. When the link on a bridge port goes up, STP calculation is done on that port. The result of the calculation is the transition of the port into the Forwarding or Blocking state, depending on the port’s position in the network and the STP parameters. This calculation and transition period usually takes about 30 to 50 seconds. At this time, no user data passes via the port. Some user applications might time out during this period. To allow immediate transition of the port into the Forwarding state, the STP PortFast feature is enabled. PortFast transitions the port into the STP Forwarding state immediately upon linkup. The port still participates in STP in the event that the port is to be a part of a loop; if so, the port eventually transitions into STP blocking mode. As long as the port is participating in STP, there is a possibility that some device attached to that port and also running STP with a lower Bridge Priority than that of the current Root Switch will assume the Root Bridge function and affect active STP topology, thus rendering the network suboptimal. Permanent STP recalculation caused by the temporary introduction and subsequent removal of STP devices with low (0) Bridge Priority represents a simple form of Denial of Service (DoS) attack on the network. The STP PortFast BPDU guard enhancement is designed to allow network designers to enforce the STP domain borders and keep the active topology predictable. The devices behind the ports with STP PortFast enabled are not allowed to influence the STP topology. This is achieved by disabling the port with PortFast configured upon receipt of BPDU. The

204

Chapter 3: Spanning Tree Protocol (STP)

port is transitioned into Errdisable state, and a message appears on the console. The following is an example of the message that appears as a result of BPDU guard operation:
2000 May 12 15:13:32 %SPANTREE-2-RX_PORTFAST:Received BPDU on PortFast enable port. Disabling 2/1 2000 May 12 15:13:32 %PAGP-5-PORTFROMSTP:Port 2/1 left bridge port 2/1

On the left side of Figure 3-44, Bridge A has priority 8192 and is the root for the VLAN. Bridge B has priority 16384 and is the backup Root Switch for the same VLAN. Bridges A and B, connected by a Gigabit Ethernet link, make up the network core. Bridge C is an access switch and has PortFast configured on the port connected to Device D. Given that the other STP parameters are the default, the Bridge C port that connects to Bridge B is in STP Blocking state. Device D (a PC) is not participating in STP. The red arrows indicate the flow of STP BPDUs.
Figure 3-44 BPDU Guard Prevents Rogue Devices from Affecting the STP Topology 1) A B A 2) B

C

C

D

D

Now, suppose that Device D starts participating in STP (for example, if a Linux-based bridge application were launched on a PC), as shown on the right side of Figure 3-44. If the software bridge’s priority is 0 or any value below that of the Root Switch, the software bridge takes over the Root Bridge function (as the bridge with the lowest priority). The Gigabit link connecting the two core switches transitions into blocking mode, causing all the data in that particular VLAN to flow via the 100-Mbps link. If more data is flowing via the core in the VLAN than the link can accommodate, dropping of frames occurs, leading to a connectivity outage. The STP PortFast BPDU guard feature would prevent such a situation by disabling the port as soon as an STP BPDU is received from Device D.

Evolution of Spanning Tree

205

Switchport Tuning Using Root Guard
Traditional 802.1D STP does not provide any means for the network administrator to securely enforce the switched Layer 2 network topology. This might become especially important in networks with shared administrative control (for example, one switched network controlled by different administrative entities or companies). The switched network’s forwarding topology is calculated based on, among other parameters, the Root Switch position. Although any switch can be the Root Switch in the network, it is better to place the Root Bridge manually (somewhere in the core layer) so that the forwarding topology is optimal. The standard 802.1D STP does not allow the administrator to enforce the Root Switch’s position. If a bridge is introduced into the network with a lower Bridge Priority, it takes the role of the Root Bridge. The root guard ensures that the port on which root guard is enabled is the Designated Port. (Normally, Root Bridge ports are all designated unless two or more ports of the Root Bridge are connected.) If the bridge receives superior STP BPDUs on a root guard-enabled port, this port is moved to a root-inconsistent STP state (effectively equal to the Listening state), and no traffic is forwarded across this port. The position of the Root Switch is enforced, as shown in Figure 3-45.
Figure 3-45 The Root Guard Feature Enforces the Placement of the Root Switch in a Network Root Bridge A B NOTE Even if the administrator sets the Root Bridge Priority to 0 in an effort to secure the Root Bridge position, there is still no guarantee, because there might be a bridge with priority 0 and a lower BID. The Root Guard feature is designed to provide a way to enforce the Root Switch placement in the network.

C

D

Consider an example of why a rogue Root Bridge can cause problems on the network and how root guard can help:

Switches A and B comprise the core of the network, and Switch A is the Root Switch for a VLAN. Switch C is an access layer switch. The link between Switches B and C is blocking on the C side. The flow of STP BPDUs is shown with arrows.

■ ■

206

Chapter 3: Spanning Tree Protocol (STP)

In Figure 3-46, Device D begins to participate in STP. If the priority of Bridge D is 0 or any value lower than that of the Root Switch, the software bridge is elected as a Root Switch for this VLAN. In turn, the Gigabit link connecting the two core switches blocks, causing all the data in that particular VLAN to flow via a 100-Mbps link across the access layer. If more data is flowing via the core in that VLAN than this link can accommodate, some frames are dropped, causing performance loss or a connectivity outage.
Figure 3-46 Root Guard Prevents Device D from Becoming the Root Switch A B

C

D New Root

The root guard feature is designed to protect the network from such issues. Root guard is configured on a per-port basis and does not allow the port to become an STP Root Port. This means that the port is always STP-designated. If a better BPDU is received on this port, BPDU guard disables the port rather than taking the BPDU into account and electing a new STP root. Root guard needs to be enabled on all ports where the Root Switch should not appear. In Figure 3-46, root guard should be enabled as follows:
■ ■ ■

Switch A: the port connecting to Switch C Switch B: the port connecting to Switch C Switch C: the port connecting to Switch D

In this configuration, Switch C blocks the port connecting to Switch D as soon as it receives a better (superior) BPDU. The port is put in a special STP state (root-inconsistent) that is effectively the same as the Listening state. No traffic passes through the port in this state. As soon as Device D stops sending superior BPDUs, the port is unblocked again and goes, via STP, into the Listening and Learning states, and eventually transitions to the Forwarding state. Recovery is automatic—no human intervention is required.

STP Configuration

207

The following message appears when root guard blocks a port:
%SPANTREE-2-ROOTGUARDBLOCK: Port 1/1 tried to become non-designated in VLAN 77. Moved to root-inconsistent state

STP Configuration
Configuring PVST+ on Catalyst switches involves configuring the Root Switches for each VLAN and optionally configuring load sharing via Port Cost and Port Priority. The default STP timers can be tuned in specialized situations.

Default STP Configuration
Table 3-7 shows the default STP (PVST/PVST+) configuration settings.
Table 3-7 The Default PVST+ Settings Include the Bridge Priority, Port Priority, and Port Cost

Feature

Default Setting

enable state switch priority spanning-tree port priority (Can be configured on a per-interface basis and used on interfaces configured as Layer 2 access ports) spanning-tree port cost (Can be configured on a per-interface basis and used on interfaces configured as Layer 2 access ports) spanning-tree vlan port priority (Can be configured on a per-VLAN basis and used on interfaces configured as Layer 2 trunk ports) spanning-tree vlan port cost (Can be configured on a per-VLAN basis and used on interfaces configured as Layer 2 trunk ports)

Enabled on VLAN 1. Up to 64 spanning-tree instances can be enabled. 32768 128

1000 Mbps: 4 100 Mbps: 19 10 Mbps: 100 128

1000 Mbps: 4 100 Mbps: 19 10 Mbps: 100
continues

208

Chapter 3: Spanning Tree Protocol (STP)

Table 3-7 The Default PVST+ Settings Include the Bridge Priority, Port Priority, and Port Cost (Continued)

Feature

Default Setting

Hello Time Forward Delay Time Max Age Time

2 seconds 15 seconds 20 seconds

Lab 3.10.1 STP Default Behavior

In this lab exercise, you observe STP’s default behavior.

Lab 3.10.2 Use Network Inspector to Observe STP Behavior

In this lab exercise, you observe STP behavior with the Network Inspector switch trace feature.

NOTE In Cisco IOS Release 12.1(9)EA1 and later, Catalyst 2950 switches support the IEEE 802.1t STP extensions. Some of the bits previously used for the switch priority are now used as the VLAN identifier. The result is that fewer MAC addresses are reserved for the switch, and a larger range of VLAN IDs can be supported, all while maintaining the uniqueness of the BID. The 2 bytes previously used for the switch priority are reallocated into a 4-bit priority value and a 12-bit extended system ID value equal to the VLAN ID.

Enabling and Disabling STP
STP is enabled by default on VLAN 1 and on all newly created VLANs up to the spanningtree limit as specified. Disable STP only if the network topology has no loops. When STP is disabled and loops are present in the topology, excessive traffic and indefinite packet duplication can drastically reduce network performance. To re-enable STP, use the spanning-tree vlan vlan-id global configuration command.

Modifying the Root Switch
By default, switches with Cisco PVST and PVST+ maintain a separate spanning-tree instance for each active VLAN configured on them. A BID consisting of the switch priority and the switch MAC address is associated with each instance. For each VLAN, the switch with the lowest BID becomes the Root Bridge for that VLAN. To configure a switch to become the root for the specified VLAN, use the spanning-tree vlan vlan-id root primary global configuration command to change the switch priority from the default value (32768) to a significantly lower value. When this command is entered, the switch checks the switch priority of the Root Switches for each VLAN. Because of the extended system ID support, the switch sets its own priority for the specified VLAN to 24576 if this value will cause this switch to become the root for the specified VLAN.

STP Configuration

209

If any Root Bridge for the specified VLAN has a switch priority lower than 24576, the switch sets its own priority for the specified VLAN to 4096 less than the lowest switch priority. 4096 is the value of the least-significant bit of a 4-bit switch priority value. Beginning in privileged EXEC mode, follow the steps listed in Table 3-8 to configure a switch to become the root for the specified VLAN.
Table 3-8 A Single Command Is Used to Configure a Switch to Be the Root of the Spanning Tree for a Particular VLAN NOTE The spanning-tree vlan vlan-id root primary global configuration command fails if the value necessary to be the Root Switch is less than 1.

Step

Command

Description

1 2

configure terminal spanning-tree vlan vlan-id root primary [diameter net-diameter [hello-time seconds]]

Enters global configuration mode. Configures a switch to become the root of the specified VLAN. For vlan-id, the range is 1 to 4094 when the Enhanced Image is installed and 1 to 1005 when the Standard Image is installed. Do not enter leading 0s. (Optional) For diameter net-diameter, specify the maximum number of switches between any two end stations. The range is 2 to 7. (Optional) For hello-time seconds, specify the interval in seconds between the generation of configuration messages by the Root Bridge. The range is 1 to 10 seconds; the default is 2 seconds.

3 4

end show spanning-tree detail

Returns to privileged EXEC mode. Verifies the entries.

Before Cisco IOS Release 12.1(9)EA1, entering the spanning-tree vlan vlan-id root primary global configuration command on a Catalyst 2950 switch (no extended system ID) caused it to set its own switch priority for the specified VLAN to 8192 if this value caused this switch to become the root for the specified VLAN. If any Root Switch for the specified VLAN has a switch priority lower than 8192, the switch sets its own priority for the specified VLAN to 1 less than the lowest switch priority.

210

Chapter 3: Spanning Tree Protocol (STP)

The following examples show the effect of the spanning-tree vlan vlan-id root primary command with and without the extended system ID support:

For Catalyst 2950 switches with the extended system ID (Release 12.1(9)EA1 and later), if all network devices in VLAN 20 have the default priority of 32768, entering the spanning-tree vlan 20 root primary command on the switch sets the switch priority to 24576, which causes this switch to become the Root Switch for VLAN 20. For Catalyst 2950 switches without the extended system ID (software earlier than Release 12.1(9)EA1), if all network devices in VLAN 100 have the default priority of 32768, entering the spanning-tree vlan 100 root primary command on the switch sets the switch priority for VLAN 100 to 8192, which causes this switch to become the Root Switch for VLAN 100.

If the network consists of switches that both do and do not support the extended system ID, it is unlikely that the switch with the extended system ID support will become the Root Switch. The extended system ID increases the switch priority value every time the VLAN number is greater than the priority of the connected switches running older software. The Root Switch for each spanning-tree instance should be a backbone or distribution switch. Do not configure an access switch as the spanning-tree primary root. Use the diameter keyword to specify the Layer 2 network diameter (that is, the maximum number of switch hops between any two end stations in the Layer 2 network). When the network diameter is specified, the switch automatically sets an optimal hello time, forward-delay time, and maximum-age time for a network of that diameter, which can significantly reduce the convergence time. The hello-time keyword can be used to override the automatically calculated hello time. After configuring the switch as the Root Switch, the recommended practice is to avoid manual configuration of the hello time, forward-delay time, and maximum-age time using the spanning-tree vlan vlan-id hello-time, spanning-tree vlan vlan-id forward-time, and spanning-tree vlan vlan-id max-age global configuration commands. To return the switch to its default setting, use the no spanning-tree vlan vlan-id root global configuration command.

Setting the Priority for Ports and VLANs
If a loop occurs, STP uses the Port Priority when selecting an interface to put into the Forwarding state. Assign higher-priority values (lower numerical values) to interfaces that the network administrator prefers to have selected first and lower-priority values (higher numerical values) to interfaces that the network administrator wants selected last. If all interfaces have the same priority value, STP puts the interface with the lowest interface number in the Forwarding state and blocks the other interfaces.

STP Configuration

211

Cisco IOS uses the Port Priority value when the interface is configured as an access port and uses VLAN Port Priority values when the interface is configured as a trunk port. Beginning in privileged EXEC mode, follow the steps listed in Table 3-9 to configure an interface’s Port Priority.
Table 3-9 Port Priority Can Be Configured on Interfaces to Influence the Spanning-Tree Topology

Step

Command

Description

1 2

configure terminal interface interface-id

Enters global configuration mode. Enters interface configuration mode and specifies an interface to configure. Valid interfaces include physical interfaces and port-channel logical interfaces (portchannel port-channel-number).

3

spanning-tree vlan port-priority priority

Configures the Port Priority for an interface that is an access port. For priority, the range is 0 to 255; the default is 128. The lower the number, the higher the priority.

4

spanning-tree vlan vlan-id portpriority priority

Configures the VLAN Port Priority for an interface that is a trunk port. For vlan-id, the range is 1 to 4094 when the Enhanced Image is installed and 1 to 1005 when the Standard Image is installed. Do not enter leading 0s. For priority, the range is 0 to 255; the default is 128. The lower the number, the higher the priority.

5 6

end show spanning-tree interface interface-id or show spanning-tree vlan vlan-id

Returns to privileged EXEC mode. Verifies the entries.

The show spanning-tree interface interface-id privileged EXEC command displays information only if the port is in a link-up operative state. Otherwise, use the show runningconfig interface privileged EXEC command to confirm the configuration.

212

Chapter 3: Spanning Tree Protocol (STP)

To return the interface to its default setting, use the no spanning-tree [vlan vlan-id] portpriority interface configuration command.
Lab 3.10.3 Advanced PVST+ Configuration

In this lab exercise, you modify the default PVST+ configuration to control the spanning-tree behavior.

Setting the Port Cost
The spanning-tree Path Cost default value is derived from an interface’s media speed. If a loop occurs, STP uses cost when selecting an interface to put in the Forwarding state. Assign lower-cost values to interfaces that the network administrator prefers to have selected first and higher-cost values to interfaces that the network administrator wants selected last. If all interfaces have the same cost value, STP puts the interface with the lowest interface number in the Forwarding state and blocks the other interfaces. STP uses the cost value when the interface is configured as an access port and uses VLAN port cost values when the interface is configured as a trunk port. Beginning in privileged EXEC mode, follow the steps listed in Table 3-10 to configure an interface’s cost.
Table 3-10 Port Cost Can Be Configured on Interfaces to Influence the Spanning-Tree Topology

Step

Command

Description

1 2

configure terminal interface interface-id

Enters global configuration mode. Enters interface configuration mode and specifies an interface to configure. Valid interfaces include physical interfaces and port-channel logical interfaces (portchannel port-channel-number).

3

spanning-tree cost cost

Configures the cost of an interface that is an access port. If a loop occurs, STP uses the Path Cost when selecting an interface to place in the Forwarding state. A lower Path Cost represents higher-speed transmission. For cost, the range is 1 to 200000000; the default value is derived from the interface’s media speed.

STP Configuration

213

Table 3-10 Port Cost Can Be Configured on Interfaces to Influence the Spanning-Tree Topology (Continued)

Step

Command

Description

4

spanning-tree vlan vlan-id cost cost

Configures the VLAN cost for an interface that is a trunk port. If a loop occurs, STP uses the Path Cost when selecting an interface to place in the Forwarding state. A lower Path Cost represents higher-speed transmission. For vlan-id, the range is 1 to 4094 when the Enhanced Image is installed and 1 to 1005 when the Standard Image is installed. Do not enter leading 0s. For cost, the range is 1 to 200000000; the default value is derived from the interface’s media speed.

5 6

end show spanning-tree interface interface-id or show spanning-tree vlan vlan-id

Returns to privileged EXEC mode. Verifies the entries.

The show spanning-tree interface interface-id privileged EXEC command displays information only for ports that are in a link-up operative state. Otherwise, use the show runningconfig privileged EXEC command to confirm the configuration. To return the interface to its default setting, use the no spanning-tree [vlan vlan-id] cost interface configuration command.

Configuring Switch Priority of a VLAN
You can configure the switch priority to make it more likely that the switch will be chosen as the Root Switch. For most situations, the recommended practice is to use the spanning-tree vlan vlan-id root primary and spanning-tree vlan vlan-id root secondary global configuration commands to modify the switch priority.

214

Chapter 3: Spanning Tree Protocol (STP)

However, beginning in privileged EXEC mode, you can follow the steps outlined in Table 3-11 to configure a VLAN’s switch priority.
Table 3-11 Bridge Priority Can Be Configured to Influence the Spanning-Tree Topology

Step

Command

Description

1 2

configure terminal spanning-tree vlan vlan-id port-priority priority

Enters global configuration mode. Configures a VLAN’s switch priority. For vlan-id, the range is 1 to 4094 when the Enhanced Image is installed and 1 to 1005 when the Standard Image is installed. Do not enter leading 0s. For priority, the range is 0 to 61440 in increments of 4096; the default is 32768. The lower the number, the more likely the switch will be chosen as the Root Switch. Valid priority values are 4096, 8192, 12288, 16384, 20480, 24576, 28672, 32768, 36864, 40960, 45056, 49152, 53248, 57344, and 61440. All other values are rejected.

3 4

end show spanning-tree vlan vlan-id

Returns to privileged EXEC mode. Verifies the entries.

To return the switch to its default setting, use the no spanning-tree vlan vlan-id priority global configuration command.

Modifying Default Timers
IEEE 802.1D STP parameters can be individually configured in specialized situations. These parameters include hello time, forward delay, and VLAN maximum aging time.

Hello Time
Changing the hello time configures the interval period of configuration messages generated by the Root Switch. For most situations, it is recommended that you use the spanning-tree vlan vlan-id root primary and spanning-tree vlan vlan-id root secondary global configuration commands to modify the hello time.

STP Configuration

215

However, beginning in privileged EXEC mode, you can follow the steps outlined in Table 3-12 to configure the hello time for a VLAN.
Table 3-12 The Default STP Hello Time Is 2 Seconds

Step

Command

Description

1 2

configure terminal spanning-tree vlan vlan-id hello-time seconds

Enters global configuration mode. Configures a VLAN’s hello time. The hello time is the interval between the generation of configuration messages by the Root Switch. These messages mean that the switch is alive. For vlan-id, the range is 1 to 4094 when the Enhanced Image is installed and 1 to 1005 when the Standard Image is installed. Do not enter leading 0s. For seconds, the range is 1 to 10; the default is 2.

3 4

end show spanning-tree vlan vlan-id

Returns to privileged EXEC mode. Verifies the entries.

To return the switch to its default setting, use the no spanning-tree vlan vlan-id hello-time global configuration command.

Forward Delay
Use the global configuration command spanning-tree vlan vlan-id forward-time seconds command to configure the Forward Delay for a VLAN. The forwarding time determines how long each of the Listening and Learning states last before the interface begins forwarding. The range is 4 to 30 seconds. To return the switch to its default setting, use the no spanning-tree vlan vlan-id forward-time global configuration command.

VLAN Maximum Aging Time
Use the global configuration command spanning-tree vlan vlan-id max-age seconds command to configure the Max Age for a VLAN.

216

Chapter 3: Spanning Tree Protocol (STP)

This command sets the interval between messages the spanning tree receives from the Root Switch. If a switch does not receive a BPDU message from the Root Switch within this interval, it recomputes the spanning-tree topology. The range is 6 to 40 seconds. To return the switch to its default setting, use the no spanning-tree vlan vlan-id max-age global configuration command.

Tuning, Verifying, and Troubleshooting STP
Cisco added several features to its PVST+ STP implementation. Configuring these options can significantly enhance convergence time in switched networks. PortFast speeds up the amount of time it takes an access port to transition to Forwarding state when a workstation or router is attached. UplinkFast and BackboneFast speed up STP convergence when an uplink trunk link or indirect trunk link fails, respectively. BPDU guard and root guard prevent rogue devices or unintended devices from influencing spanning-tree behavior. This section also explores spanning-tree load sharing.

Configuring PortFast
A port with the PortFast feature enabled is moved directly to the STP Forwarding state without waiting for the standard forward-time delay. Use PortFast only when connecting a single end station to an access or trunk port. Enabling this feature on a port connected to a switch or hub could prevent STP from detecting and disabling loops in the network, which could cause broadcast storms and address-learning problems. When the voice VLAN feature is enabled, the PortFast feature is automatically enabled. When voice VLAN is disabled, the PortFast feature is not automatically disabled. Enable PortFast if the switch is running PVST or Multiple Spanning Tree Protocol (MSTP). Note that MSTP is available only if the EI is installed on the switch. Beginning in privileged EXEC mode, follow the steps outlined in Table 3-13 to enable PortFast. Use the spanning-tree portfast global configuration command to globally enable the PortFast feature on all nontrunking ports.

Tuning, Verifying, and Troubleshooting STP

217

To disable the PortFast feature, use the no spanning-tree portfast interface configuration command.
Table 3-13 PortFast Is Disabled by Default and Can Be Configured Per Interface

Step

Command

Description

1 2

configure terminal spanning-tree portfast [trunk]

Enters global configuration mode. Enables PortFast on an access port connected to a single workstation or server. By specifying the trunk keyword, you can enable PortFast on a trunk port. Returns to privileged EXEC mode. Verifies the entries.

3 4

end show spanning-tree interface interface-id portfast

Configuring UplinkFast
UplinkFast RSTP incorporates an automatically enabled feature similar to the Cisco UplinkFast proprietary STP extension. The 802.1w topology change mechanism clears the appropriate entries in the CAM tables of the upstream bridges, removing the need for UplinkFast’s dummy multicast generation process. UplinkFast cannot be enabled on VLANs that have been configured for switch priority. To enable UplinkFast on a VLAN with switch priority configured, first restore the switch priority on the VLAN to the default value by using the no spanning-tree vlan vlan-id priority global configuration command. When UplinkFast is enabled, it affects all VLANs on the switch. UplinkFast cannot be configured on an individual VLAN. The UplinkFast feature is supported only when the switch is running PVST. Beginning in privileged EXEC mode, follow the steps outlined in Table 3-14 to enable UplinkFast.

218

Chapter 3: Spanning Tree Protocol (STP)

Table 3-14 UplinkFast Can Be Configured Only for All VLANs on a Switch; It Cannot Be Configured on a Per-VLAN Basis

Step

Command

Description

1 2

configure terminal spanning-tree uplinkfast [max-update-rate pkts-per-second]

Enters global configuration mode. Enables UplinkFast. (Optional) For pkts-per-second, the range is 0 to 65535 packets per second; the default is 150. If you set the rate to 0, station-learning frames are not generated, and the spanningtree topology converges more slowly after a loss of connectivity.

3 4

end show spanning-tree summary

Returns to privileged EXEC mode. Verifies the entries.

When UplinkFast is enabled, the switch priority of all VLANs is set to 49152. If the Path Cost is changed to a value less than 3000 and then UplinkFast is enabled, or if UplinkFast is already enabled, the Path Cost of all interfaces and VLAN trunks is increased by 3000. (If the Path Cost is changed to 3000 or greater, the Path Cost is not altered.) The changes to the switch priority and the Path Cost reduce the chance that the switch will become the Root Switch. When UplinkFast is disabled, the switch priorities of all VLANs and Path Costs of all interfaces are set to default values unless the defaults have been modified. To return the update packet rate to the default setting, use the no spanning-tree uplinkfast max-update-rate global configuration command. To disable UplinkFast, use the no spanning-tree uplinkfast command.

Configuring BackboneFast
Accepting inferior BPDUs is what makes up the core of the BackboneFast engine. The IEEE 802.1w committee decided to incorporate a similar mechanism into RSTP. When a bridge receives an inferior BPDU from its Designated or Root Switch, the bridge immediately accepts this BPDU and replaces the one previously stored. BackboneFast can be enabled to detect indirect link failures and to start the spanning-tree reconfiguration sooner. You must enable BackboneFast on all switches in the network for it to

Tuning, Verifying, and Troubleshooting STP

219

work properly. BackboneFast is not supported on Token Ring VLANs; however, BackboneFast is supported for use with third-party switches. The BackboneFast feature is supported only when the switch is running PVST. Beginning in privileged EXEC mode, follow the steps outlined in Table 3-15 to enable BackboneFast.
Table 3-15 BackboneFast Must Be Configured on All Switches in the Network

Step

Command

Description

1 2 3 4

configure terminal spanning-tree backbonefast end show spanning-tree summary

Enters global configuration mode. Enables BackboneFast. Returns to privileged EXEC mode. Verifies the entries.

To disable the BackboneFast feature, use the no spanning-tree backbonefast global configuration command.

Configuring BPDU Guard
When BPDU guard is enabled globally on ports that are PortFast-enabled (the ports are in a PortFast-operational state), STP shuts down PortFast-enabled ports that receive BPDUs. In a valid configuration, PortFast-enabled ports do not receive BPDUs. Receiving a BPDU on a PortFast-enabled port signals an invalid configuration, such as the connection of an unauthorized device, and the BPDU guard feature puts the port in the error-disabled state. The BPDU guard feature provides a secure response to invalid configurations because the port must be manually put back into service. Use the BPDU guard feature in a service provider network to prevent an access port from participating in the spanning tree. Configure PortFast only on ports that connect to end stations; otherwise, an accidental topology loop could cause a data packet loop and disrupt switch and network operation. Use the spanning-tree bpduguard enable interface configuration command to enable BPDU guard on any port without also enabling the PortFast feature. When the port receives a BPDU, it is put in the error-disabled state. The BPDU guard feature can be enabled if the switch is running PVST or MSTP. MSTP is available only if the Enhanced Image is installed on the switch.

220

Chapter 3: Spanning Tree Protocol (STP)

Beginning in privileged EXEC mode, follow the steps outlined in Table 3-16 to globally enable the BPDU guard feature on all access ports and to enable PortFast on all access ports.
Table 3-16 BPDU Guard Can Be Globally Configured, But PortFast Must Also Be Configured on the Interfaces Connected to End Stations

Step

Command

Description

1 2 3

configure terminal spanning-tree portfast bpduguard default interface interface-id

Enters global configuration mode. Globally enables BPDU guard. By default, BPDU guard is disabled. Enters interface configuration mode and specifies the interface connected to an end station. Enables the PortFast feature. Returns to privileged EXEC mode. Verifies the entries.

4 5 6

spanning-tree portfast end show running-config

To disable BPDU guard on all access ports, use the no spanning-tree portfast bpduguard default global configuration command. You can override this command on a particular interface by using the spanning-tree bpduguard enable interface configuration command.
Lab 3.10.7 Port-Level Tuning to Control STP Behavior

In this lab exercise, you use PortFast, UplinkFast, BPDU guard, root guard, and UDLD to control STP behavior on a port.

Configuring Root Guard
Root guard enabled on an interface applies to all the VLANs to which the interface belongs. Do not enable the root guard on interfaces to be used by the UplinkFast feature. With UplinkFast, the backup interfaces (in the blocked state) replace the Root Port in case of a failure. However, if root guard is also enabled, all the backup interfaces used by the UplinkFast feature are placed in the root-inconsistent state (blocked) and are prevented from reaching the Forwarding state. Root guard and loop guard cannot both be enabled at the same time. Loop guard can be used to prevent alternate or Root Ports from becoming Designated Ports because of a failure that leads to a unidirectional link. This feature is most effective when it is

Tuning, Verifying, and Troubleshooting STP

221

configured on the entire switched network. Loop guard operates only on ports that the spanning tree considers point-to-point. Root guard can be enabled if the switch is running PVST or MSTP. Recall that the MSTP feature is available only if the Enhanced Image is installed on the switch. Beginning in privileged EXEC mode, follow the steps listed in Table 3-17 to enable root guard on an interface.
Table 3-17 Root Guard Is Configured on Interfaces to Prevent Inadvertent Root Switch Election

Step

Command

Description

1 2 3

configure terminal interface interface-id spanning-tree guard root

Enters global configuration mode. Enters interface configuration mode and specifies the interface to configure. Enables root guard on the interface. By default, root guard is disabled on all interfaces. Returns to privileged EXEC mode. Verifies the entries.

4 5

end show running-config

To disable root guard, use the no spanning-tree guard interface configuration command.

Configuring Load Sharing
Load sharing divides the bandwidth supplied by parallel trunks connecting switches. To avoid loops, STP normally blocks all but one parallel link between switches. Using load sharing, divide the traffic between the links according to which VLAN the traffic belongs to. Configure load sharing on trunk ports by using STP port priorities or STP Path Costs. For load sharing using STP port priorities, both load-sharing links must be connected to the same switch. For load sharing using STP Path Costs, each load-sharing link can be connected to the same switch or to two different switches.

Load Sharing Using STP Port Priorities
When two ports on the same switch form a loop, the STP Port Priority setting determines which port is enabled and which port is in a Blocking state. The priorities on a parallel trunk port can be set so that the port carries all the traffic for a given VLAN. The trunk port with the higher priority (lower Port Priority values) for a VLAN forwards traffic for that VLAN.

222

Chapter 3: Spanning Tree Protocol (STP)

The trunk port with the lower priority (higher Port Priority values) for the same VLAN remains in a Blocking state for that VLAN. One trunk port sends or receives all traffic for the VLAN. Figure 3-47 shows two Gigabit Ethernet trunks connecting supported switches. In this example, the switches are configured as follows:
■ ■ ■ ■

VLANs 8 to 10 are assigned a Port Priority of 10 on Trunk 1. VLANs 3 to 6 retain the default Port Priority of 128 on Trunk 1. VLANs 3 to 6 are assigned a Port Priority of 10 on Trunk 2. VLANs 8 to 10 retain the default Port Priority of 128 on Trunk 2.

Figure 3-47 Port Priority Can Be Configured to Enable STP Load Sharing
Switch 1

Trunk 1 VLANs 8 to 10 (Priority 10) VLANs 3 to 6 (Priority 128)

Trunk 2 VLANs 3 to 6 (Priority 10) VLANs 8 to 10 (Priority 128)

Switch 2

In this way, Trunk 1 carries traffic for VLANs 8 to 10, and Trunk 2 carries traffic for VLANs 3 to 6. If the active trunk fails, the trunk with the lower priority takes over and carries the traffic for all the VLANs. No duplication of traffic occurs over any trunk port. Beginning in privileged EXEC mode, follow the steps shown in Table 3-18 to configure the network shown in Figure 3-47.
Table 3-18 Port Priority Can Be Configured on Interfaces to Affect STP Load Sharing

Step

Command

Description

1

interface gigabitethernet0/1

Enters interface configuration mode and defines the interface to set the STP Port Priority. Assigns a Port Priority of 10 for VLAN 8. Assigns a Port Priority of 10 for VLAN 9.

2 3

spanning-tree vlan 8 port-priority 10 spanning-tree vlan 9 port-priority 10

Tuning, Verifying, and Troubleshooting STP

223

Table 3-18 Port Priority Can Be Configured on Interfaces to Affect STP Load Sharing (Continued)

Step

Command

Description

4 5 6

spanning-tree vlan 10 port-priority 10 exit interface gigabitethernet0/2

Assigns a Port Priority of 10 for VLAN 10. Returns to global configuration mode. Enters interface configuration mode and defines the interface to set the STP Port Priority. Assigns a Port Priority of 10 for VLAN 3. Assigns a Port Priority of 10 for VLAN 4. Assigns a Port Priority of 10 for VLAN 5. Assigns a Port Priority of 10 for VLAN 6. Returns to privileged EXEC mode.

7 8 9 10 11

spanning-tree vlan 3 port-priority 10 spanning-tree vlan 4 port-priority 10 spanning-tree vlan 5 port-priority 10 spanning-tree vlan 6 port-priority 10 end

Load Sharing Using STP Path Cost
Parallel trunks can be configured to share VLAN traffic by setting different Path Costs on a trunk and associating the Path Costs with different sets of VLANs. The VLANs keep the traffic separate. Because no loops exist, STP does not disable the ports, and redundancy is maintained in the event of a lost link. In Figure 3-48, trunk ports 1 and 2 are 100BASE-T ports. The Path Costs for the VLANs are assigned as follows:
■ ■ ■ ■

VLANs 2 to 4 are assigned a Path Cost of 30 on Trunk Port 1. VLANs 8 to 10 retain the default 100BASE-T Path Cost of 19 on Trunk Port 1. VLANs 8 to 10 are assigned a Path Cost of 30 on Trunk Port 2. VLANs 2 to 4 retain the default 100BASE-T Path Cost of 19 on Trunk Port 2.

224

Chapter 3: Spanning Tree Protocol (STP)

Figure 3-48 Port Cost Can Be Configured to Enable STP Load Sharing
Switch 1

Trunk Port 1 VLANs 2 to 4 (Path Cost 30) VLANs 8 to 10 (Path Cost 19)

Trunk Port 2 VLANs 8 to 10 (Path Cost 30) VLANs 2 to 4 (Path Cost 19)

Switch 2

Beginning in privileged EXEC mode, follow the steps outlined in Table 3-19 to configure the network shown in Figure 3-48.
Table 3-19 Port Cost Can Be Configured on Interfaces to Affect STP Load Sharing

Step

Command

Description

1 2

configure terminal interface fastethernet 0/1

Enters global configuration mode on Switch 1. Enters interface configuration mode and defines Fast Ethernet port 0/1 as the interface to be configured as a trunk. Configures the trunk encapsulation. Configures the port as a trunk port. Returns to global configuration mode. Repeat Steps 2 to 4 on Switch 1 interface Fast Ethernet 0/2.

3 4 5 6 7 8

switchport trunk encapsulation dot1q switchport mode trunk exit

end show running-config

Returns to privileged EXEC mode. Verifies your entries. In the display, make sure that interfaces Fast Ethernet 0/1 and Fast Ethernet 0/2 are configured as trunk ports. When the trunk links come up, Switch 1 receives the VLAN Trunking Protocol (VTP) information from the other switches. Verify that Switch 1 has learned the VLAN configuration.

9

show vlan

Tuning, Verifying, and Troubleshooting STP

225

Table 3-19 Port Cost Can Be Configured on Interfaces to Affect STP Load Sharing (Continued)

Step

Command

Description

10 11

configure terminal interface fastethernet 0/1

Enters global configuration mode. Enters interface configuration mode and defines Fast Ethernet port 0/1 as the interface to set the STP cost. Sets the spanning-tree Path Cost to 30 for VLAN 2. Sets the spanning-tree Path Cost to 30 for VLAN 3. Sets the spanning-tree Path Cost to 30 for VLAN 4. Returns to global configuration mode. Repeat Steps 9 to 11 on the Switch 1 interface Fast Ethernet 0/2 and set the spanningtree Path Cost to 30 for VLANs 8, 9, and 10.

12 13 14 15 16

spanning-tree vlan 2 cost 30 spanning-tree vlan 3 cost 30 spanning-tree vlan 4 cost 30 end

Lab 3.10.6 Per-VLAN Spanning-Tree Load Sharing

In this lab exercise, you modify spanning tree’s default behavior for VLAN load sharing using Cisco IOS commands.

Verifying STP, RSTP, and MSTP Configuration
Table 3-20 lists and describes the privileged EXEC commands for displaying spanning-tree status.
Table 3-20 show Commands for Verifying Spanning-Tree Configuration

Command

Description

show spanning-tree active show spanning-tree detail

Displays spanning-tree information on active interfaces only. Displays a detailed summary of interface information.
continues

226

Chapter 3: Spanning Tree Protocol (STP)

Table 3-20 show Commands for Verifying Spanning-Tree Configuration (Continued)

Command

Description

show spanning-tree interface interface-id show spanning-tree mst interface interface-id
NOTE Within each MST region, the MSTP maintains multiple spanning-tree instances. Instance 0 is a special instance for a region, known as the internal spanning tree (IST). All other MST instances are numbered from 1 to 15. The IST is the only spanning-tree instance that sends and receives BPDUs. A common and internal spanning tree (CIST) is a collection of the internal spanning trees in each MST region and the common spanning tree (CST) that interconnects the MST regions and single spanning trees. The spanning tree computed in a region appears as a subtree in the CST that encompasses the entire switched domain. The CIST is formed as a result of the Spanning Tree Algorithm running between switches that support the 802.1w, 802.1s, and 802.1D protocols. The CIST inside an MST region is the same as the CST outside a region.

Displays spanning-tree information for the specified interface. Displays MST information for the specified interface. Displays a summary of port states or displays the total lines of the STP state section.

show spanning-tree summary [totals]

For information about other keywords for the show spanning-tree privileged EXEC command, refer to the command reference for the particular Cisco IOS release.

RSTP and MSTP Configuration
RSTP and MSTP can be used in place of the default PVST+ to improve Layer 2 convergence in the network and to improve Catalyst switch CPU and memory utilization. Configuring MST involves defining instances and assigning Layer 2 properties to each instance. Here you learn how to enable RSTP, how to enable MST, and how to configure the MST Root Switch, MST Bridge Priority, MST Path Cost, MST Port Priority, MSTP timers, and maximum hop count.

Default RSTP and MSTP Configuration
The switch uses the default settings of PVST/PVST+, as shown in Table 3-21. By default, RSTP/MST are not enabled.
Table 3-21 The Default Settings for RSTP/MST Are Exactly the Same as Those for PVST+ Because RSTP/MST Is Disabled by Default

Feature

Default Setting

Spanning-tree mode switch priority (Can be configured on a per-CIST interface basis) spanning-tree port priority (Can be configured on a per-CIST interface basis)

PVST (MSTP and RSTP are disabled) 32768

128

RSTP and MSTP Configuration

227

Table 3-21 The Default Settings for RSTP/MST Are Exactly the Same as Those for PVST+ Because RSTP/MST Is Disabled by Default (Continued)

Feature

Default Setting

spanning-tree port cost (Can be configured on a per-CIST interface basis)

1000 Mbps: 4 100 Mbps: 19 10 Mbps: 100

Hello Time Forward Delay Time Max Age Time Maximum hop count

2 seconds 15 seconds 20 seconds 20 hops

RSTP and MSTP Configuration Guidelines
The configuration guidelines for RSTP and MSTP are as follows:

TIP Cisco.com includes an extensive set of technical information describing RSTP and MSTP operation and configuration, which you can find at http:// www.cisco.com/ univercd/cc/td/doc/ product/lan/c3550/ 12120ea2/3550scg/ swmstp.htm.

Per-VLAN RSTP (PVRST) is not supported. When MST is enabled using the spanning-tree mode mst global configuration command, RSTP is enabled. PVST, PVST+, and MSTP are supported, but only one version can be active at any time: all VLANs run PVST, or all VLANs run MSTP. VTP propagation of the MST configuration is not supported. Manually configure the MST configuration (region name, revision number, and VLAN-to-instance mapping) on each switch within the MST region by using the command-line interface (CLI) or through the SNMP support. For load sharing across redundant paths in the network to work, all VLAN-to-instance mapping assignments must match. Otherwise, all traffic flows on a single link. All MST boundary ports must be forwarding for load sharing between a PVST+ and an MST cloud. For this to happen, the IST master of the MST cloud should also be the root of the CST. If the MST cloud consists of multiple MST regions, one of the MST regions must contain the CST root, and all the other MST regions must have a better path to the root contained with the MST cloud than a path through the PVST+ cloud. It might be necessary to manually configure the switches in the clouds. Partitioning the network into a large number of regions is not recommended. However, if this situation is unavoidable, it is recommended that the switched LAN be partitioned into smaller LANs interconnected by routers or non-Layer 2 devices.

228

Chapter 3: Spanning Tree Protocol (STP)

Enabling RSTP and MSTP
For two or more switches to be in the same MST region, they must have the same VLANto-instance mapping, the same configuration revision number, and the same name. A region can have one member or multiple members with the same MST configuration. Each member must be capable of processing RSTP BPDUs. There is no limit to the number of MST regions in a network, and each region can support up to 16 spanning-tree instances. A VLAN can be assigned to only one spanning-tree instance at a time. Beginning in privileged EXEC mode, follow the steps outlined in Table 3-22 to specify the MST region configuration and enable MSTP.
Table 3-22 Up to 16 Spanning-Tree Instances Can Be Configured with MST

Step

Command

Description

1 2 3

configure terminal spanning-tree mst configuration instance instance-id vlan vlan-range

Enters global configuration mode. Enters MST configuration mode. Maps VLANs to an MST instance. For instance-id, the range is 1 to 15. For vlan vlan-range, the range is 1 to 4094. When you map VLANs to an MST instance, the mapping is incremental, and the range of VLANs specified is added to or removed from the existing ones. To specify a range, use a hyphen. For example, instance 1 vlan 1-63 maps VLANs 1 through 63 to MST instance 1. To specify a series, use a comma. For example, instance 1 vlan 10, 20, 30 maps VLANs 10, 20, and 30 to MST instance 1.

4

name name

Specifies the configuration name. The name string has a maximum length of 32 characters and is case-sensitive. Specifies the configuration revision number. The range is 0 to 65535. Verifies your configuration by displaying the pending configuration.

5 6

revision version show pending

RSTP and MSTP Configuration

229

Table 3-22 Up to 16 Spanning-Tree Instances Can Be Configured with MST (Continued)

Step

Command

Description

7 8

exit spanning-tree mode mst

Applies all changes and returns to global configuration mode. Enables MSTP. RSTP is also enabled. Caution: Changing spanning-tree modes can disrupt traffic because all spanningtree instances are stopped for the previous mode and restarted in the new mode.

9 10

end show running-config

Returns to privileged EXEC mode. Verifies your entries.

To return to the default MST region configuration, use the no spanning-tree mst configuration global configuration command. To return to the default VLAN-to-instance map, use the no instance instance-id [vlan vlan-range] MST configuration command. To return to the default name, use the no name MST configuration command. To return to the default revision number, use the no revision MST configuration command. To re-enable PVST, use the no spanning-tree mode or the spanning-tree mode pvst global configuration command. Example 3-1 demonstrates how to enter MST configuration mode, map VLANs 10 to 20 to MST instance 1, name the region region1, set the configuration revision to 1, display the pending configuration, apply the changes, and return to global configuration mode. MST information is not propagated in VTP updates, so this configuration must be done on all the appropriate switches.
Example 3-1 Mapping VLANs 10 to 20 to MST Instance 1
Switch(config)#spanning-tree mst configuration Switch(config-mst)#instance 1 vlan 10-20 Switch(config-mst)#name region1 Switch(config-mst)#revision 1 Switch(config-mst)#show pending Pending MST configuration Name [region1] Revision 1

continues

230

Chapter 3: Spanning Tree Protocol (STP)

Example 3-1 Mapping VLANs 10 to 20 to MST Instance 1 (Continued)
Instance Vlans Mapped -------- -----------------------0 1 1-9, 21-4094 10-20

--------------------------------Switch(config-mst)#exit Switch(config)#

Configuring the MST Root Switch
The switch maintains a spanning-tree instance for the group of VLANs mapped to it. A BID, consisting of the switch priority and the switch MAC address, is associated with each instance. The switch with the lowest BID becomes the Root Switch for the group of VLANs. To configure a switch to become the root, use the spanning-tree mst instance-id root global configuration command to modify the switch priority from the default value (32768) to a significantly lower value so that the switch becomes the Root Switch for the specified spanning-tree instance. When this command is issued, the switch checks the switch priorities of the Root Switches. Because of the extended system ID support, the switch sets its own priority for the specified instance to 24576 if this value will cause this switch to become the root for the specified spanning-tree instance. If any Root Switch for the specified instance has a switch priority lower than 24576, the switch sets its own priority to 4096 less than the lowest switch priority. 4096 is the value of the least-significant bit of a 4-bit switch priority value. Catalyst 2950 switches running Cisco IOS software earlier than Release 12.1(9)EA1 do not support the extended system ID. Catalyst 2950 switches running Cisco IOS software earlier than Release 12.1(9)EA1 do not support the MSTP. If the network consists of switches that both do and do not support the extended system ID, it is unlikely that the switch with the extended system ID support will become the Root Switch. The extended system ID increases the switch priority value every time the VLAN number is greater than the priority of the connected switches running older software. The Root Switch for each spanning-tree instance should be a backbone or distribution switch. Do not configure an access switch as the spanning-tree primary root. Use the diameter keyword, which is available only for MST instance 0, to specify the Layer 2 network diameter (that is, the maximum number of switch hops between any two end stations in the Layer 2 network). When specifying the network diameter, the switch automatically sets an optimal hello time, forward-delay time, and maximum-age time for a network of that

RSTP and MSTP Configuration

231

diameter, which can significantly reduce the convergence time. Use the hello keyword to override the automatically calculated hello time. The recommended practice is that you avoid manually configuring the hello time, forwarddelay time, and maximum-age time. In other words, the recommended practice is to avoid using the spanning-tree mst hello-time, spanning-tree mst forward-time, and spanning-tree mst max-age global configuration commands after configuring the switch as the Root Switch. Beginning in privileged EXEC mode, follow the steps outlined in Table 3-23 to configure a switch as the Root Switch.
Table 3-23 Configuring the Root Switch with MST Is Done Per Instance Instead of Per VLAN

Step

Command

Description

1 2

configure terminal spanning-tree mst instance-id root primary [diameter net-diameter [hello-time seconds]]

Enters global configuration mode. Configures a switch as the Root Switch. For instance-id, the range is 0 to 15. (Optional) For diameter net-diameter, specify the maximum number of switches between any two end stations. The range is 2 to 7. This keyword is available only for MST instance 0. (Optional) For hello-time seconds, specify the interval in seconds between the generation of configuration messages by the Root Switch. The range is 1 to 10 seconds; the default is 2 seconds.

3 4

end show spanning-tree mst instance-id

Returns to privileged EXEC mode. Verifies your entries.

To return the switch to its default setting, use the no spanning-tree mst instance-id root global configuration command.
Lab 3.10.4 Implementing MST

In this lab exercise, you implement MST in a switched network.

232

Chapter 3: Spanning Tree Protocol (STP)

Configuring MST Switch Priority
The switch priority can be configured to make it more likely that the switch will be chosen as the Root Switch. Exercise care when using the spanning-tree mst instance-id priority global configuration command. For most situations, it is recommended that you use the spanningtree mst instance-id root primary and spanning-tree mst instance-id root secondary global configuration commands to modify the switch priority. Beginning in privileged EXEC mode, follow the steps outlined in Table 3-24 to configure the switch priority.
Table 3-24 MST Bridge Priority Can Also Be Used to Influence Root Bridge Election

Step

Command

Description

1 2

configure terminal spanning-tree mst instance-id priority priority

Enters global configuration mode. Configures the switch priority for an MST instance. For instance-id, the range is 0 to 15. For priority, the range is 0 to 61440 in increments of 4096; the default is 32768. The lower the number, the more likely the switch will be chosen as the Root Switch. Valid priority values are 0, 4096, 8192, 12288, 16384, 20480, 24576, 28672, 32768, 36864, 40960, 45056, 49152, 53248, 57344, and 61440. All other values are rejected.

3 4

end show spanning-tree mst instance-id

Returns to privileged EXEC mode. Verifies your entries.

To return the switch to its default setting, use the no spanning-tree mst instance-id priority global configuration command.

Configuring MST Path Cost
The MST Path Cost default value is derived from an interface’s media speed. If a loop occurs, the MSTP uses cost when selecting an interface to put in the Forwarding state. Assign lowercost values to interfaces that the network administrator wants selected first and higher-cost values to interfaces that the administrator wants selected last. If all interfaces have the same

RSTP and MSTP Configuration

233

cost value, the MSTP puts the interface with the lowest interface number in the Forwarding state and blocks the other interfaces. Beginning in privileged EXEC mode, follow the steps outlined in Table 3-25 to configure an interface’s MSTP cost.
Table 3-25 MST Port Cost Can Be Configured to Alter the Default MST Topology

Step

Command

Description

1 2

configure terminal interface interface-id

Enters global configuration mode. Enters interface configuration mode and specifies an interface to configure. Valid interfaces include physical ports and port channels. Valid port-channel numbers are 1 to 6. Configures the cost of an MST instance. If a loop occurs, MSTP uses the Path Cost when selecting an interface to place in the Forwarding state. A lower Path Cost represents higher-speed transmission. For instance-id, the range is 0 to 15. For cost, the range is 1 to 200000000; the default is derived from the interface’s media speed.

3

spanning-tree mst instance-id cost cost

4 5

end show spanning-tree mst interface instance-id or show spanning-tree mst instance-id

Returns to privileged EXEC mode. Verifies your entries.

The show spanning-tree mst interface interface-id privileged EXEC command displays information only for ports that are in a link-up operative state. Otherwise, use the show running-config privileged EXEC command to confirm the configuration. To return the interface to its default setting, use the no spanning-tree mst instance-id cost interface configuration command.

234

Chapter 3: Spanning Tree Protocol (STP)

Configuring MST Port Priority
If a loop occurs, MSTP uses the Port Priority when selecting an interface to put in the Forwarding state. Assign higher-priority values (lower numerical values) to interfaces that the network administrator wants selected first and lower-priority values (higher numerical values) to interfaces that the administrator wants selected last. If all interfaces have the same priority value, the MSTP puts the interface with the lowest interface number in the Forwarding state and blocks the other interfaces. Beginning in privileged EXEC mode, follow the steps outlined in Table 3-26 to configure an interface’s MSTP Port Priority.
Table 3-26 MST Port Priority Can Be Configured to Alter the Default MST Topology

Step

Command

Description

1 2

configure terminal interface interface-id

Enters global configuration mode. Enters interface configuration mode and specifies an interface to configure. Valid interfaces include physical ports and port channels. Valid port-channel numbers are 1 to 6. Configures the Port Priority for an MST instance. For instance-id, the range is 0 to 15. For priority, the range is 0 to 255; the default is 128. The lower the number, the higher the priority.

3

spanning-tree mst instance-id port-priority priority

4 5

end show spanning-tree mst interface instance-id or show spanning-tree mst instance-id

Returns to privileged EXEC mode. Verifies your entries.

The show spanning-tree mst interface interface-id privileged EXEC command displays information only if the port is in a link-up operative state. Use the show running-config interface privileged EXEC command to confirm the configuration.

RSTP and MSTP Configuration

235

To return the interface to its default setting, use the no spanning-tree mst instance-id portpriority interface configuration command.

Configuring MSTP Timers
The MSTP Hello time, MSTP Forward Delay time, and MSTP Maximum Aging time can be configured. This section explores the steps to configuring these timers.

MSTP Hello Time
You can change how often the Root Switch generates configuration messages by adjusting the hello time. Exercise care when using this command. For most situations, the recommended practice is to use the spanning-tree mst instance-id root primary and spanning-tree mst instance-id root secondary global configuration commands to modify the hello time. Beginning in privileged EXEC mode, follow the steps outlined in Table 3-27 to configure the hello time for all MST instances.
Table 3-27 The MST Hello Time Can Be Configured to Alter the Default Value of 2 Seconds

Step

Command

Description

1 2

configure terminal spanning-tree mst hello-time seconds

Enters global configuration mode. Configures the hello time for all MST instances. The hello time is the interval between the generation of configuration messages by the Root Switch. These messages mean that the switch is alive. For seconds, the range is 1 to 10; the default is 2.

3 4

end show spanning-tree mst

Returns to privileged EXEC mode. Verifies your entries.

To return the switch to its default setting, use the no spanning-tree mst hello-time global configuration command.

MSTP Forward Delay Time
Beginning in privileged EXEC mode, follow the steps shown in Table 3-28 to configure the forward delay time for all MST instances.

236

Chapter 3: Spanning Tree Protocol (STP)

Table 3-28 The MST Forward Delay Can Be Configured to Alter the Default Value of 15 Seconds

Step

Command

Description

1 2

configure terminal spanning-tree mst forward-time seconds

Enters global configuration mode. Configures the forward time for all MST instances. The forward time is the number of seconds a port waits before changing from its STP Learning and Listening states to the Forwarding state. For seconds, the range is 4 to 30; the default is 15.

3 4

end show spanning-tree mst

Returns to privileged EXEC mode. Verifies your entries.

To return the switch to its default setting, use the no spanning-tree mst forward-time global configuration command.

MSTP Maximum Aging Time
Beginning in privileged EXEC mode, follow the steps outlined in Table 3-29 to configure the maximum aging time for all MST instances.
Table 3-29 The MST Max Age Can Be Configured to Alter the Default Value of 20 Seconds

Step

Command

Description

1 2

configure terminal spanning-tree mst max-age seconds

Enters global configuration mode. Configures the maximum aging time for all MST instances. The maximum aging time is the number of seconds a switch waits without receiving spanning-tree configuration messages before attempting a reconfiguration. For seconds, the range is 6 to 40; the default is 20.

3 4

end show spanning-tree mst

Returns to privileged EXEC mode. Verifies your entries.

EtherChannel

237

To return the switch to its default setting, use the no spanning-tree mst max-age global configuration command.

Configuring Maximum Hop Count
Beginning in privileged EXEC mode, follow the steps outlined in Table 3-30 to configure the maximum hop count for all MST instances.
Table 3-30 The MST Maximum Hop Count Can Be Configured to Alter the Default Value of 20 Hops

Step

Command

Description

1 2

configure terminal spanning-tree mst max-hops hop-count

Enters global configuration mode. Specifies the number of hops in a region before the BPDU is discarded and the information held for port is aged. For hop-count, the range is 1 to 40; the default is 20.

3 4

end show spanning-tree mst

Returns to privileged EXEC mode. Verifies your entries.

To return the switch to its default setting, use the no spanning-tree mst max-hops global configuration command.

EtherChannel
EtherChannel is a Cisco-proprietary technology that, by aggregating links into a single logical link, provides incremental trunk speeds ranging from 10 Mbps to 160 Gbps (full duplex). EtherChannel comes in four flavors:
■ ■ ■ ■

Standard EtherChannel Fast EtherChannel (FEC) Gigabit EtherChannel (GEC) 10-Gigabit EtherChannel

The term EtherChannel encompasses all these technologies. EtherChannel combines up to eight standard Ethernet links (160 Mbps on a Catalyst 3000), up to eight Fast Ethernet links (1.6 Gbps), up to eight Gigabit Ethernet links (16 Gbps), and up to eight 10 Gigabit Ethernet links (160 Gbps).

238

Chapter 3: Spanning Tree Protocol (STP)

EtherChannel Explained
EtherChannel provides fault-tolerant, high-speed links between switches, routers, and servers, as shown in Figure 3-49. The term heard most often in the context of EtherChannel is “resiliency.” Cisco defines resiliency as “the ability to recover from any network failure or issue, whether it is related to a disaster, link, hardware, design, or network service.” Recall STP and how it handles link failures within a Layer 2 topology. With EtherChannel, resiliency refers to EtherChannel’s ability to continue to operate when one of the links in a “bundle” goes down as well as its ability to restore the full bundle should the downed link come back into service. Chapter 2, “VLANs and VTP,” discussed trunking technologies. In particular, it looked at the IEEE 802.1Q and ISL Ethernet trunking technologies. What might not have been made clear at that time is that Ethernet trunks frequently go hand in hand with EtherChannel links. The reason for this should be clear. Trunk links carry more traffic and require more bandwidth than access links.
Figure 3-49 EtherChannel Enables Logical Links with Aggregate Bandwidth of Up to 160 Gbps

A

100/1000 Ethernet 1 100/1000 Ethernet 2 100/1000 Ethernet 3 100/1000 Ethernet 4

B

EtherChannel

EtherChannel

100/1000 Ethernet 5 100/1000 Ethernet 6 100/1000 Ethernet 7 100/1000 Ethernet 8

EtherChannel bundles segments into groups of two to eight links. This lets links scale at rates between 100 Mbps and a healthy fraction of 1 Tbps. T1 or 1.544 Mbps used to be the fastest WAN link available. Now it is at least 16 Tbps for up to a 50-kilometer stretch with singlemode fiber, using the Catalyst 6500 10GBASE-EX4 Metro 10 Gigabit Ethernet module. EtherChannel operates as either an access link or trunk link. For example, EtherChannel can

EtherChannel

239

be deployed between the wiring closet and the data center, as illustrated in Figure 3-50. In the data center, EtherChannel links can be deployed between servers and the network backbone to provide scalable incremental bandwidth.
Figure 3-50 EtherChannel Can Be Deployed Between the Wiring Closet and the Data Center Data Center

400 Mbps

400 Mbps

400 Mbps

Wiring Closets

Some of the benefits of EtherChannel are as follows:

EtherChannel does not require any changes because it is transparent to networked applications. For support of EtherChannel on enterprise-class servers and NICs, smart software drivers can coordinate distribution of loads across multiple network interfaces. When EtherChannel is used within the campus, switches and routers provide load distribution transparently across multiple links to network users. Unicast, multicast, and broadcast traffic is distributed across the links in the channel. EtherChannel provides automatic recovery for loss of a link by redistributing loads across remaining links. If a link does fail, EtherChannel redirects traffic from the failed link to the remaining links in less than a second. This convergence is transparent to the end user. No host protocol timers expire, so no sessions are dropped.

Figure 3-51 shows a typical EtherChannel network configuration. Now that you have a fair understanding of EtherChannel technology, you can investigate how it works and how to configure it in a network. The following section explains how EtherChannel uses frame distribution.

240

Chapter 3: Spanning Tree Protocol (STP)

Figure 3-51 All Catalyst Switches Support EtherChannel. Catalyst 6500 Switches Support 10 Gigabit EtherChannel (10 GEC). Catalyst 2950-T, Catalyst 3550, and Catalyst 4500 Switches Support Gigabit EtherChannel (GEC). Other Catalyst Switches Support Only Fast EtherChannel (FEC) or EtherChannel. Catalyst 8500, 6000, 5500, or 4000 Series Switch Gigabit EtherChannel Catalyst 3550-12T Switch 1000BASE-X Catalyst 2950-T Switch 10/100 Switched Links Workstations 10/100 Switched Links Workstations 1000BASE-X Catalyst 2950-T Switch

Frame Distribution
EtherChannel balances the traffic load across the links in a channel by applying an algorithm to a portion of the binary pattern extracted from addresses in the Ethernet frame or encapsulated data packets. The algorithm output is a numeric value that is then associated with one of the links in the channel. On IOS-based switches, Catalyst 4000 series switches, and Catalyst 5000/5500 family switches, EtherChannel load distribution can be based on either source MAC or destination MAC addresses. On the Catalyst 6000 family of switches, the loadbalancing policy (frame distribution) can be based on a MAC address, IP address, or Port Number. With source MAC address forwarding, when packets are forwarded to an EtherChannel, they are distributed across the ports in the channel based on the incoming packet’s source MAC address. Therefore, to provide load distribution, frames from different hosts use different ports in the channel, but frames from the same host use the same port in the channel. With destination MAC address forwarding, when frames are forwarded to an EtherChannel, they are distributed across the ports in the channel based on the MAC address of the destination host in the incoming frame. Therefore, frames to the same destination are forwarded over

EtherChannel

241

the same port, and frames to a different destination might be sent on a different port in the channel. The most recent EtherChannel frame distribution process is based on a Cisco-proprietary hashing algorithm. Hash algorithms, such as Message Digest 5 (MD5), are normally used to ensure that traffic arriving at the destination is identical to that generated at the source; however, the hash algorithm used with EtherChannel is designed to consistently and somewhat randomly distribute Ethernet frames across member links in an EtherChannel. The algorithm is deterministic, meaning that given the same addresses and session information, it always hashes to the same port in the channel, preventing out-of-order frame delivery. Although EtherChannel frame distribution based on a MAC address, IP address, or Layer 4 Port Number is possible, the configurable options allow for distribution based on source only (MAC, IP, or port), destination only (MAC, IP, or port), or both source and destination (MAC, IP, or port). The mode selected applies to all EtherChannels configured on the switch. Use the option that provides the greatest variety in the configuration. For example, if the traffic on a channel is going to a single MAC address only, using source addresses, IP addresses, or Layer 4 Port Numbers as the basis for frame distribution might provide better frame distribution than selecting MAC addresses as the basis. In Figure 3-52, an EtherChannel connects a Catalyst 2950 to a router. The switch is also connected to four workstations. Because the router is referenced by the switch with a single MAC address, source-based forwarding on the switch EtherChannel ensures that the switch uses all available bandwidth to the router. The router is configured for destination-based forwarding because the large number of workstations ensures that the traffic is evenly distributed from the router EtherChannel. Cisco 7000, 7200, 7500, 7600, and 8500 routers support Fast EtherChannels via logical port channel interfaces binding Fast Ethernet interfaces. Cisco 7600 and 8500 routers also support Gigabit EtherChannel.

EtherChannel Methods
EtherChannel uses two methods to negotiate bundles:
■ ■

Port Aggregation Protocol (PAgP): Cisco-proprietary Link Aggregation Control Protocol (LACP): IEEE 802.3ad

242

Chapter 3: Spanning Tree Protocol (STP)

Figure 3-52 Source-Based Frame Distribution Is Used on the Switch, and Destination-Based Frame Distribution Is Used on the Router

Catalyst 2950 switch with source-based forwarding enabled. EtherChannel Cisco router with destination-based forwarding enabled.

Port Aggregation Protocol (PAgP)
Port Aggregation Protocol (PAgP) is a Cisco-proprietary technology that facilitates the automatic creation of EtherChannels by exchanging packets between Ethernet interfaces. By using PAgP, the switch learns the identity of partners that can support PAgP and learns the capabilities of each interface. It then dynamically groups similarly configured interfaces into a single logical link (channel or aggregate port). These interfaces are grouped based on hardware, administrative, and port parameter constraints. For example, PAgP groups the interfaces with the same speed, duplex mode, native VLAN, VLAN range, and trunking status and type. After grouping the links into an EtherChannel, PAgP adds the group to the spanning tree as a single switch port. Table 3-31 lists and defines the various PAgP modes.
Table 3-31 PAgP Modes

Mode or Keyword

Description

on

The mode that forces the port to channel without PAgP. With the on mode, a usable EtherChannel exists only when a port group in on mode is connected to another port group in on mode. The mode that prevents the port from channeling.

off

EtherChannel

243

Table 3-31 PAgP Modes (Continued)

Mode or Keyword

Description

auto

The mode that places a port in a passive negotiating state, in which the port responds to PAgP packets it receives but does not initiate PAgP packet negotiation. This is the default setting. The mode that places a port in an active negotiating state, in which the port initiates negotiations with other ports by sending PAgP packets. The keyword that is used with auto or desirable mode when no traffic is expected from the other device. This option prevents the link from being reported to STP as down. This is the default, secondary PAgP setting. The keyword that is used with auto or desirable mode when traffic is expected from the other device.

desirable

silent

non-silent

As described in Table 3-31, EtherChannel includes the four user-configurable modes of on, off, auto, and desirable. Only auto and desirable are PAgP modes. The auto and desirable modes can be modified with the silent and non-silent keywords. By default, ports are in autosilent mode. Both the auto and desirable modes allow ports to negotiate with connected ports to determine if they can form an EtherChannel, based on criteria such as port speed, trunking state, and VLAN numbers. The on mode forces the port to channel without PAgP. With the on mode, a usable EtherChannel exists only when a port group in on mode is connected to another port group in on mode. The off mode prevents the port from channeling. The auto mode places a port in a passive negotiating state, in which the port responds to PAgP packets it receives but does not initiate PAgP packet negotiation. This is the default setting. The desirable mode places a port in an active negotiating state, in which the port initiates negotiations with other ports by sending PAgP packets. Ports can form an EtherChannel when they are in different PAgP modes as long as the modes are compatible. For example, a port in desirable mode can form an EtherChannel successfully with another port that is in desirable or auto mode. A port in auto mode can form an EtherChannel with another port in desirable mode. A port in auto mode cannot form an EtherChannel with another port that is also in auto mode, because neither port initiates negotiation, as shown in Table 3-32.

244

Chapter 3: Spanning Tree Protocol (STP)

Table 3-32 Different Combinations of PAgP Modes on Either End of a Potential EtherChannel Might or Might Not Result in a Valid EtherChannel Bundle

Valid EtherChannel Modes

Invalid EtherChannel Modes

on-on auto-desirable desirable-desirable

off-any auto-auto on-desirable on-auto

On CatOS switches, configuring an EtherChannel automatically creates an administrative group, designated by an integer between 1 and 1024, to which the EtherChannel belongs. If preferred, specify the administrative group number. Forming a channel without specifying an administrative group number creates a new automatically numbered administrative group. An administrative group can contain a maximum of eight ports. In addition, on CatOS switches, each EtherChannel is automatically assigned a unique EtherChannel ID.

Link Aggregation Control Protocol (LACP)
The open-standard equivalent to PAgP is Link Aggregation Control Protocol (LACP). Defined in IEEE 802.3ad, LACP allows Cisco switches to manage Ethernet channels with non-Cisco devices conforming to the 802.3ad specification. It is likely that LACP will become the norm for Catalyst switches, just as Cisco migrated from ISL to IEEE 802.1Q. (Cisco cannot always wait for the IEEE to complete its standards process before incorporating new features on its devices.) To have LACP handle channeling, use the active and passive channel modes. To start automatic Ethernet channel configuration with LACP, configure at least one end of the link to active mode to initiate channeling, because ports in passive mode passively respond to initiation and never initiate the sending of LACP packets. Table 3-33 lists and defines the various LACP modes.
Table 3-33 LACP Modes

Mode

Description

on

Forces the port to channel without LACP. With the on mode, a usable EtherChannel exists only when a port group in on mode is connected to another port group in on mode. Prevents the port from channeling.

off

EtherChannel

245

Table 3-33 LACP Modes (Continued)

Mode

Description

passive

Similar to the auto mode for PAgP, passive mode places a port in a passive negotiating state, in which the port responds to LACP packets it receives but does not initiate LACP packet negotiation. Passive is the default mode. Similar to the desirable mode for PAgP, active mode places a port in an active negotiating state, in which the port initiates negotiation with other ports by sending LACP packets.

active

The on mode forces the port to channel without LACP. With the on mode, a usable EtherChannel exists only when a port group in on mode is connected to another port group in on mode. The off mode prevents the port from channeling. The passive mode is similar to the PAgP auto mode, because it places the port in a passive negotiating state, in which the port responds to LACP packets it receives but does not initiate LACP packet negotiation. Passive mode is the default LACP mode. When enabled, LACP always tries to configure the maximum number of compatible ports in a channel, up to the maximum allowed by the hardware (eight ports for Catalyst switches). If LACP cannot aggregate all the ports that are compatible (for example, if the remote system has more restrictive hardware limitations), all the ports that cannot be actively included in the channel are put in hot-standby state and are used only if one of the channeled ports fails.

Modifying Port Cost for EtherChannel Groups
If Port Cost is not specified, the STP Port Cost is updated based on the current Port Costs of the channeling ports. However, if channel Port Cost is specified, the Port Costs of member ports in the channel are modified to reflect the new cost. This enables load sharing of VLAN traffic across multiple channels configured with trunking, because some VLANs in the channel have Port VLAN Cost values and the others have Port Cost values. This might not sound useful (or meaningful), but it allows, for example, the configuration of VLAN traffic to loadshare between one EtherChannel connected to one core switch and another EtherChannel connected to another core switch.

EtherChannel Configuration Guidelines
There are a host of guidelines for configuring EtherChannels. Figure 3-53 shows a Fast EtherChannel. The EtherChannel configuration guidelines relate to trunks, dynamic VLANs, STP, and otherwise. If improperly configured, some EtherChannel interfaces are automatically disabled to avoid network loops and other problems.

246

Chapter 3: Spanning Tree Protocol (STP)

Figure 3-53 Fast EtherChannel Topology

A

Fast EtherChannel Fast Ethernet 1 Fast Ethernet 2

Fast EtherChannel

D

B Fast Ethernet 3 Fast Ethernet 4 C

E

F

To minimize time spent troubleshooting EtherChannel, adhere to the following recommendations:

Assign all ports in an EtherChannel to the same VLAN, or configure them as trunk ports. If the EtherChannel is configured as a trunk, configure the same trunk mode on all the ports in the EtherChannel. Configuring ports in an EtherChannel in different trunk modes can have unexpected results. An EtherChannel supports the same allowed range of VLANs on all the ports in a trunking EtherChannel. If the allowed range of VLANs is not the same for a port list, the ports do not form an EtherChannel even when set to auto or desirable mode. Do not configure the ports in an EtherChannel as dynamic VLAN ports. Doing so can adversely affect switch performance. An EtherChannel does not form with ports that have different GARP, GVRP, or QoS configurations. GARP and GVRP are industrystandard protocols described in IEEE 802.1p. If a broadcast limit is configured on the ports, configure it as a percentage limit for the channeled ports. With a packets-per-second broadcast limit, unicast packets might get dropped for 1 second when the broadcast limit is exceeded. An EtherChannel does not form with ports that have the port security feature enabled. The port security feature cannot be enabled for ports in an EtherChannel. If Internet Group Management Protocol (IGMP) multicast filtering is using one port in an EtherChannel, set the EtherChannel mode for both PAgP and LACP to off. No other mode can be used. An EtherChannel does not form if one of the ports is a Switched Port Analyzer (SPAN) destination port. An EtherChannel does not form if protocol filtering is set differently on any of the ports. Each EtherChannel can have up to eight compatibly configured

EtherChannel

247

Ethernet interfaces. Configure all interfaces in an EtherChannel to operate at the same speed and duplex modes.

Enable all interfaces in an EtherChannel. If an interface in an EtherChannel is shut down, it is treated as a link failure, and its traffic is transferred to one of the remaining interfaces in the EtherChannel. Interfaces with different STP Port Costs can form an EtherChannel as long they are otherwise compatibly configured. Setting different STP Port Costs does not, by itself, make interfaces incompatible for the formation of an EtherChannel. However, it is preferable to set STP Port Costs to be equal for all ports in an EtherChannel.

Beyond the restrictions listed here, the only remaining concern is what ports can be used when configuring an EtherChannel. Catalyst 4000 and 6000 line cards have newer chipsets that allow the use of an even or odd number of links in the EtherChannel. The ports do not have to be contiguous or even on the same line card, as is true with some Catalyst devices and line modules. The newer chips on the Catalyst 4000s and 6000s are not available on all Catalyst hardware. Older Catalyst switches use an Ethernet Bundle Controller (EBC) to manage aggregated EtherChannel ports (for example, performing frame distribution). The EBC communicates with the Enhanced Address Recognition Logic (EARL) application-specific integrated circuit (ASIC). The EARL is responsible for, among other things, learning MAC addresses. For example, the EARL ages out all addresses learned on a link in an EtherChannel bundle when it fails. After a link failure, the EBC and the EARL work together to recalculate in hardware the “lost” source-destination address pairs on a different link. On the older switches, when selecting ports to group for an EtherChannel process, ports that belong to the same EBC must be selected. A 24-port module has three groups of eight ports, and a 12-port module has three groups of four ports, as shown in Figure 3-54.
Figure 3-54 Groups of Four or Eight Ports Are Managed by Ethernet Bundle Controllers on Older Catalyst Switches

1 1 1

2 1 1

3 1 1

4 5 1 1 1 2

6 1 2

7 8 1 2 1 2

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 2 3 2 3 2 3 2 3 2 2 2 2 3 3 3 3 3 3 3 3

Be sure to check the hardware documentation before attempting to create EtherChannel bundles. Older Catalyst switches restrict which ports are used in a given bundle. The remainder of the material in this section pertains primarily to Catalyst 5000 line modules.

248

Chapter 3: Spanning Tree Protocol (STP)

In a 12-port module, up to two dual-segment EtherChannel configurations can be created within each group of four ports, as illustrated in Example A in Table 3-34. One dual-segment EtherChannel configuration can be created within each group, as shown in Example B. Example C illustrates a four-segment and two-segment EtherChannel configuration.
Table 3-34 Some Combinations of Ports Are Invalid for EtherChannel Formation on Older Catalyst Switches

Port

1

2

3

4

5

6

7

8

9

10

11

12

Example A Example B Example C Example D Example E Example F Example G

OK OK OK Not OK Not OK Not OK Not OK

1 1 1

1 1 1

2

2

3 2

3 2 2

4

4

5 3

5 3

6

6

1 1

1 1 2

2

1 1

1

2 1

2

2

1

1

Some EtherChannel configurations must be avoided on older Catalyst devices, including most Catalyst 5000 line cards. Example D illustrates an invalid two-segment EtherChannel configuration using Ports 3 and 4 of a group. The EBC must start its bundling with the first ports of a group. This does not mean that the first group has to be used. In contrast, a valid dual-segment EtherChannel configuration can use Ports 5 and 6 with no EtherChannel segment on the first group. Example E illustrates another invalid configuration. In this example, two EtherChannel segments are formed. One is a dual-segment EtherChannel configuration, and the other is a four-segment EtherChannel configuration. The dual-segment EtherChannel configuration is valid. The four-segment EtherChannel configuration, however, violates the rule that all ports must belong to the same group (EBC). This EtherChannel configuration uses two ports from the first group and two ports from the second group. Finally, Example G is an invalid EtherChannel configuration because it does not use the first ports on the module to start the EtherChannel process (like Example D). The EtherChannel process cannot be started with middle ports on the line module. All the examples in Table 3-34 apply to 24-port modules as well. The only difference between 12- and 24-port modules is the number of EtherChannel segments that can be formed within a group. The 12-port module allows only two (two-port) EtherChannel segments in a group, whereas the 24-port module supports up to four (two-port) EtherChannel segments per group.

EtherChannel

249

Configuring Fast EtherChannel
To configure EtherChannel on an IOS-based switch, on each of the participating interfaces (up to eight), enter the following command:
channel-group channel-group-number mode {auto [non-silent] | desirable [non-silent] | on}

The channel-group command replaces the port group command, which was used before Cisco IOS Release 12.1. To remove an interface from the EtherChannel group, use the no channel-group interface configuration command. Example 3-2 demonstrates the configuration of EtherChannel on an IOS-based switch. A shortcut is available, beginning with Cisco IOS Release 12.1(5)T. Identical commands can be entered once for a range of interfaces, rather than being entered separately for each interface, using the interface range command.
Example 3-2 A Gigabit EtherChannel Is Configured Just as a Fast EtherChannel Is Configured
Switch(config)#interface range gigabitethernet0/1 - 2 Switch(config-if)#channel-group 1 mode desirable

To verify the EtherChannel configuration and view EtherChannel information, use the following command:
show etherchannel [channel-group-number] {brief | detail | load-balance | port | port-channel | summary}

Example 3-3 demonstrates some sample output from this command.
Example 3-3 The show etherchannel Command Replaces the Previous show port group Command
Switch#show etherchannel 1 summary

Flags:

D - down I - stand-alone R - Layer3

P - in port-channel s - suspended S - Layer2

U - port-channel in use

Group

Port-channel

Ports

................................................................... 1 Po1(SU) Ci0/1(P) Gi0/2(P)

250

Chapter 3: Spanning Tree Protocol (STP)

The show etherchannel command replaces the show port group command, which was used before Cisco IOS Release 12.1. To specify the technique for load distribution (frame distribution) among links comprising an EtherChannel, use the following command:
port-channel load-balance {dst-mac | src-mac}

A sample configuration using this command would be as follows:
Switch(config)#port-channel load-balance dst-mac

Verify the configuration with the command show etherchannel load-balance. Finally, to view PAgP status information, use the following command:
show pagp [channel-group-number] {counters | internal | neighbor}

Example 3-4 demonstrates some sample output from this command.
Example 3-4 Use the show pagp counters Command to View PAgP Status Information
Switch#show pagp counters

Information Port Sent Recv Sent

Flush Recv

..................................................... Channel group: 1 Gi0/1 Gi0/2 45 45 42 41 0 0 0 0

Lab 3.10.5 Configuring Fast EtherChannel

In this lab exercise, you provide more bandwidth between Ethernet switches. You combine two 100-Mbps links to form a full-duplex 200-Mbps link.

Summary
This chapter discussed Layer 2 techniques and technologies designed to optimize network reliability, resiliency, and redundancy within a campus network. In particular, this chapter explored
■ ■

The importance of STP as a key Layer 2 network protocol Scaling issues with STP as they pertain to VLANs

Summary

251

STP enables Layer 2 reliability, resiliency, and redundancy in a campus network. STP dynamically configures a Layer 2 topology that blocks physical loops in a switched network while at the same time providing a number of configuration options for tailoring the flow of traffic in a network. A Root Switch serves as the focal point of the topology for each VLAN configured in PVST+ STP mode. With Path Cost, Port Priority, Bridge Priority, STP timers, PortFast, UplinkFast, and BackboneFast, the tools are available to design a robust Layer 2 topology. EtherChannel provides the finishing touch to the Layer 2 switched infrastructure. EtherChannel provides for incremental bandwidth Ethernet link options, ranging from 10 Mbps (half-duplex) 100-m links to 160 Gbps (full-duplex) 70-km links. EtherChannel relies on PAgP to dynamically manage bundles of Ethernet links. Several protocols are important for Layer 2 switched design and deployment. This chapter focused on STP and PAgP.

252

Chapter 3: Spanning Tree Protocol (STP)

Key Terms
BackboneFast A Catalyst feature that is initiated when a Root Port or Blocked Port on a switch receives inferior BPDUs from its Designated Bridge. Max Age is skipped to allow appropriate Blocked Ports to transition quickly to Forwarding state in the case of an indirect link failure. Blocking state The STP state in which a bridge listens for BPDUs. This state follows the Disabled state. Bridge ID (BID) An 8-byte field consisting of an ordered pair of numbers—a 2-byte decimal number called the Bridge Priority and a 6-byte (hexadecimal) MAC address. Bridge Priority A decimal number used to measure the preference of a bridge in the Spanning Tree Algorithm. The possible values range between 0 and 65,535. Bridge Protocol Data Unit (BPDU) A frame used by switches and bridges to communicate spanning-tree information. Common Spanning Tree (CST) A spanning-tree implementation specified in the IEEE 802.1Q standard. CST defines a single instance of spanning tree for all VLANs with BPDUs transmitted over VLAN 1. Designated Bridge The Designated Bridge for a segment is the bridge containing the Designated Port for that segment. Designated Port The Designated Port for a segment is the bridge port connected to the segment that both sends traffic toward the Root Switch and receives traffic from the Root Switch over that segment. Disabled state The administratively shut-down STP state. edge port With RSTP, an edge port is functionally equivalent to a port configured with PortFast under PVST+. An edge port immediately transitions to the Forwarding state. An edge port should be configured only on ports that connect to a single end station. EtherChannel A Cisco-proprietary technology that, by aggregating links into a single logical link, provides incremental trunk speeds ranging from 100 Mbps to 160 Gbps. forward delay How much time the bridge spends in the Listening and Learning states. Forwarding state The STP state in which data traffic is both sent and received on a port. It is the last STP state, following the Learning state. hello time The time interval between the sending of Configuration BPDUs.

Key Terms

253

Learning state The STP state in which the bridge does not pass user data frames but builds the bridging table and gathers information, such as the source VLANs of data frames. This state follows the Listening state. Link Aggregation Control Protocol (LACP) Allows Cisco switches to manage Ethernet channels with non-Cisco devices conforming to the 802.3ad specification. Defined in IEEE 802.3ad. Listening state The STP state in which no user data is passed, but the port sends and receives BPDUs in an effort to determine the active topology. It is during the Listening state that the three initial convergence steps take place—elect a Root Switch, elect Root Ports, and elect Designated Ports. This state follows the Blocking state. Max Age An STP timer that controls how long a bridge stores a BPDU before discarding it. The default is 20 seconds. Mono Spanning Tree (MST) The spanning-tree implementation used by non-Cisco 802.1Q switches. One instance of STP is responsible for all VLAN traffic. Multiple Instances of Spanning Tree Protocol (MISTP) Lets you group multiple VLANs under a single instance of spanning tree. MISTP combines the Layer 2 load-balancing benefits of PVST+ with the lower CPU load of IEEE 802.1Q. Multiple Spanning Tree (MST) Extends the IEEE 802.1w Rapid Spanning Tree (RST) algorithm to multiple spanning trees, as opposed to the single CST of the original IEEE 802.1Q specification. This extension provides for both rapid convergence and load sharing in a VLAN environment. Path Cost An STP measure of how close bridges are to each other. Path Cost is the sum of the costs of the links in a path between two bridges. Per-VLAN Spanning Tree (PVST) A Cisco-proprietary spanning-tree implementation requiring ISL trunk encapsulation. PVST runs a separate instance of STP for each VLAN. PortFast A Catalyst feature that, when enabled, causes an access or trunk port to enter the spanning-tree Forwarding state immediately, bypassing the Listening and Learning states. Port Aggregation Protocol (PAgP) A Cisco-proprietary technology that facilitates the automatic creation of EtherChannels by exchanging packets between Ethernet interfaces. Port ID A 2-byte STP parameter consisting of an ordered pair of numbers—the Port Priority and the Port Number. Port Number A numerical identifier used by Catalyst switches to enumerate the ports.

254

Chapter 3: Spanning Tree Protocol (STP)

Port Priority A configurable STP parameter with values ranging from 0 to 63 on a CatOS switch (the default is 32) and from 0 to 255 on an IOS-based switch (the default is 128). Port Priority is used to influence Root Switch selection when all other STP parameters are equal. PVST+ A Cisco-proprietary implementation that allows CST and PVST to exist on the same network. Rapid Spanning Tree Protocol (RSTP) An evolution of STP (802.1D standard) that provides for faster spanning-tree convergence after a topology change. The standard also includes features equivalent to Cisco PortFast, UplinkFast, and BackboneFast for faster network reconvergence. Root Bridge The bridge/switch with the lowest Bridge ID for that VLAN. Each VLAN has a Root Bridge. Also called the Root Switch. Root Path Cost The cumulative cost of all links to the Root Switch. Root Port A port on a bridge closest to the Root Switch in terms of Path Cost. Root Switch See Root Bridge. Spanning Tree Protocol (STP) A Layer 2 protocol that uses a special-purpose algorithm to discover physical loops in a network and effect a logical loop-free topology. UplinkFast A Catalyst feature that accelerates the choice of a new Root Port when a link or switch fails.

Check Your Understanding
Use the following review questions to test your understanding of the concepts covered in this chapter. Answers are listed in Appendix A, “Check Your Understanding Answer Key.”
1. Which of the following is used in Root Switch election? A. Port ID B. Path Cost C. BID D. Port Priority 2. What are the three steps of STP convergence? A. Elect a Root Switch B. Elect Designated Ports C. Elect Blocking Ports D. Elect Root Ports

Check Your Understanding

255

3. On an IOS-based switch, the Port ID is a 16-bit ordered pair composed of what two val-

ues?
A. Port Preference B. Port Priority C. Port Number D. Port Cost 4. The BID is an 8-byte ordered pair composed of what two values? A. Bridge Priority B. Bridge Preference C. Bridge Number D. MAC Address 5. Every active trunk port on the Root Switch is which of the following? A. Root Port B. Non-Designated Port C. Designated Port D. Blocking Port 6. Which of the following are IEEE 802.1D spanning-tree states? A. Blocking B. Discarding C. Learning D. Forwarding E. Listening 7. Which of the following are IEEE 802.1w spanning-tree states? A. Blocking B. Listening C. Learning D. Forwarding E. Discarding

256

Chapter 3: Spanning Tree Protocol (STP)

8. Multiple Spanning Tree is specified by which IEEE standard? A. 802.1D B. 802.1w C. 802.1Q D. 802.1s 9. Which of the following spanning-tree parameters can be used to enable load sharing? A. Port Priority B. Bridge Priority C. EtherChannel D. Path Cost 10. Which of the following are the two protocols used to create Ethernet channels or

bundles?
A. LACP B. VQP C. DTP D. PAgP

Objectives
After completing this chapter, you will be able to perform tasks related to the following:
■ ■

Explain the role of each type of VLAN. Understand the methods of routing between VLANs: adding a route processor to a switch by way of a daughter card or module, using router-on-a-stick, using one routerto-switch link per VLAN, and using fixed-chassis (nonmodular) multilayer switches. Understand the advantages and disadvantages of each inter-VLAN routing method. Configure inter-VLAN routing using each inter-VLAN routing method, with emphasis on switch virtual interfaces and routed ports. Troubleshoot inter-VLAN routing.

■ ■

Chapter 4 Inter-VLAN Routing
Configuring virtual LANs (VLANs) helps you control the size of broadcast domains and keeps local traffic local. The downside of this benefit is that devices in different VLANs are unable to communicate without the presence of some form of Layer 3 routing. This chapter focuses on the alternative inter-VLAN routing solutions that may be used within Layer 2 switched environments.

Methods of Inter-VLAN Routing
Over the years, the methods of routing traffic between VLANs have changed. The method is dependent on the particular Catalyst switch platforms and the version of the operating system. Basically, the evolution has gone from requiring a one-to-one mapping of switch ports to router ports (one per VLAN), to router-on-a-stick (one switch port trunked to one router port populated with subinterfaces—one per VLAN), and finally to routing via switch virtual interfaces on the Catalyst switch. Also, not too long ago, the ability to configure switch ports as Layer 3 interfaces, totally independent of any VLAN association, became available on switches such as the Catalyst 3550 and 6500.

Key Components of Inter-VLAN Routing
To provide routing between VLANs, three key components must be present:
■ ■ ■

A VLAN-capable switch A router Some form of connectivity between the switch and the router

Figure 4-1 illustrates a legacy method of inter-VLAN routing.

260

Chapter 4: Inter-VLAN Routing

Figure 4-1 The First Form of Inter-VLAN Routing Required a Separate Physical Connection Between the Layer 2 Switch and the Router for Each VLAN

VLAN 10

VLAN 20

VLAN 30

The router can be an external standalone unit, or it can be integrated within the switch hardware. Common names used to describe routers that are integrated within the switch itself include
■ ■ ■ ■ ■ ■ ■

Route Switch Module Route Processor Route Switch Processor Route Switch Feature Card (RSFC) Multilayer Switch Module (MSM) Multilayer Switch Feature Card Layer 3 Services Module

Or, the switch is simply called a Layer 3 switch. If an external router is employed to perform inter-VLAN routing, connection to the switch can be via a separate Ethernet/Fast Ethernet/Gigabit Ethernet link for each VLAN, or a single trunking link can be used. Figure 4-2 illustrates the single-trunk option. Layer 3 switches integrate the route processor within the switch itself, either in the form of a daughter card or module added to a chassis-based (modular) switch or in the form of an embedded processor in a nonmodular switch, as shown in Figure 4-3. The Catalyst 6509 switch with an MSFC2 daughter card is an example of a chassis-based switch with a route processor added by way of a daughter card. The Catalyst 3550-24 switch is an example of a nonmodular switch with an embedded route processor.

Methods of Inter-VLAN Routing

261

Figure 4-2 The Second Generation of Inter-VLAN Routing Was Implemented by Connecting a Layer 2 Switch to a Router with a Trunk Link

VLAN 10

VLAN 20 VLAN 20

Figure 4-3 The Third Generation of Inter-VLAN Routing Came in the Form of Route Processors Integrated Within the Switches Layer 3 Switch Internal Route Processor

VLAN 10

The brains of a newly purchased chassis-based Catalyst switch, called the Supervisor Engine, now come with embedded route processors, so it is no longer necessary to purchase separate daughter cards or modules to add Layer 3 switching functionality. Examples of these are the Supervisor Engine III and IV used with the Catalyst 4500 series switches and the Supervisor Engine 720 used with the Catalyst 6500 switches.

VLAN 30

VLAN 30

Tru n

k

262

Chapter 4: Inter-VLAN Routing

Comparison of Layer 2 and Layer 3 Operations in the Core
The core is a crucial component of every network. Failure of a core device or link can isolate large sections of a network from one another. For this reason, both core links and devices should be designed with adequate redundancy. In a LAN environment, it is possible to implement the core as a switched or routed layer. Although both methods provide redundancy, they differ significantly in operation. The Layer 2 or switched core manages its redundant links using Spanning Tree Protocol (STP), as shown in Figure 4-4. This means that some links are not used because one or more ports are in a blocking state. Not only does this underutilize the available bandwidth, but it also often results in inefficient traffic paths.
Figure 4-4 Spanning Tree Protocol Handles Redundant Connections in a Switched Core

STP Blocked

A routing protocol is used to manage redundant links in a routed core, as shown in Figure 4-5. The routing protocol can select the optimal path for traffic and can make use of redundant links through load balancing. Furthermore, implementing the core using Layer 3 allows more flexibility and control over packet flows, permitting additional benefits, such as quality of service (QoS), to be implemented.

Methods of Inter-VLAN Routing

263

Figure 4-5 A Routing Protocol Is Used in a Routed Core to Handle Redundant Connections

Optimal Path Selected by Routing Protocol

Inter-VLAN Routing Performance and Scalability Issues
For networks with just a couple of VLANs, using a physical interface for each VLAN can be a viable inter-VLAN routing strategy, as shown in Figure 4-6.
Figure 4-6 The One-Link-Per-VLAN Inter-VLAN Routing Method Theoretically Could Still Be Used in a Network with Only a Few Data VLANs

VLAN 10

VLAN 20

VLAN 30

264

Chapter 4: Inter-VLAN Routing

For networks with more than a few VLANs, however, a routing strategy that uses virtual interfaces becomes a must. Both an external and internal router can be used with subinterfaces. The difference between the two solutions involves a trade-off between cost and performance. An entry-level external router is generally cheaper than a switch with Layer 3 functionality, but the lack of integration between the Layer 2 and Layer 3 elements of the network and the “up and back” nature of external routers limit performance, as shown in Figure 4-7. As soon as the 100-Mbps capacity of the external router’s link is exceeded, the use of an integrated route processor becomes the only realistic option for providing inter-VLAN routing, as shown in Figure 4-8.
Figure 4-7 The Bandwidth of the Trunk Link Between a Router and a Layer 2 Switch Is One Limitation of the Second-Generation Inter-VLAN Routing Method

Tru n

k

Sending Traffic

Receiving Traffic

Figure 4-8 An Integrated Route Processor Is the Ideal Solution for Inter-VLAN Routing Layer 3 Switch Internal Route Processor

VLAN 10

VLAN 20

VLAN 30

Internal Links

Methods of Inter-VLAN Routing

265

Regardless of the routing technique chosen, it is essential that the switched elements of the access and distribution layer be aligned with the routing functionality at the distribution layer. In particular, you should ensure that the distribution switch is the root of the spanning tree for each VLAN that is routed by the distribution router. This step is easily overlooked. Although a network will provide connectivity with an access layer switch acting as the STP root, the inefficient traffic flow will seriously limit the throughput of the distribution layer links.

Roles of the Different Types of VLANs
Various types of VLANS exist:
■ ■ ■ ■ ■

VLAN 1 The default VLAN The user VLANs The native VLAN The management VLAN

By default, all Ethernet interfaces on Cisco switches are on VLAN 1. On Catalyst switches, all the VLAN types in the preceding list default to VLAN 1, which can add to the difficulty of understanding their differences. This section explains the various types of VLANS to clear up some of the confusion.

VLAN 1
The reason VLAN 1 became a special VLAN is that Layer 2 devices needed to have a default VLAN to assign to their ports, including their management port(s). In addition, many Layer 2 protocols, such as Bridge Protocol Data Unit (BPDU), Cisco Discovery Protocol (CDP), VLAN Trunking Protocol (VTP), Port Aggregation Protocol (PAgP), and Dynamic Trunking Protocol (DTP), needed to be sent on a specific VLAN on trunk links. For all these reasons, VLAN 1 was chosen. Figure 4-9 illustrates that the control traffic is associated with VLAN 1. BPDU, CDP, VTP, PAgP, and DTP are always transmitted over VLAN 1. This is always the case and cannot be changed. Cisco recommends that VLAN 1 be used only for these protocols. The management VLAN and user VLANs should all be configured to use VLANs other than VLAN 1.

266

Chapter 4: Inter-VLAN Routing

Figure 4-9 The Default VLAN (VLAN 1), the User VLANs, the Native VLAN, and the Management VLAN Are All Important Considerations in Network Design

VLAN Trunk
VLAN 1 - Native VLAN, Untagged CDP, VTP, PAgP, DTP User VLAN 10 - Tagged 172.16.10.0/24 User VLAN 20 - Tagged 172.16.20.0/24 Management VLAN 99 - Tagged 172.16.99.0/24

Default VLAN
By default, VLAN 1 is also the VLAN assigned to all switch ports (unless configured otherwise). VLAN 1 is also known as the default VLAN because all switch ports are in VLAN 1 when the switch boots with a clean configuration and vlan.dat file. It is possible to artificially change the default VLAN upon initial switch configuration by configuring all ports on the switch to be members of a particular VLAN other than VLAN 1. However, the Catalyst switch show vlan output will still display VLAN 1 as the default VLAN. The other types of VLANs—the native VLAN, the management VLAN, and the user VLANs—are all automatically members of the default VLAN unless specifically configured otherwise (see Figure 4-9). All Ethernet interfaces on Catalyst switches default to VLAN 1. Any device connected to an interface on a switch is a member of VLAN 1 unless that interface is configured to use a different VLAN with the switchport access vlan interface command.

User VLANs
User VLANs are typically what people think of when referring to VLANs. A user VLAN is created to segment a group of users, either geographically or logically, from the rest of the network (see Figure 4-9). The switchport access vlan interface command is used to assign interfaces to these various user VLANs.

Methods of Inter-VLAN Routing

267

Native VLAN
A topic that causes considerable confusion is the native VLAN. Native VLAN is a term used with interfaces that are configured as VLAN trunks. When a switch port is configured as a trunk, it tags frames with the appropriate VLAN number. Frames from all VLANs are carried across the trunk link containing the 802.1Q tag, except for frames belonging to the native VLAN. With factory defaults on a Catalyst switch, frames from VLAN 1 belong to the native VLAN and are carried across the trunk untagged. Figure 4-9 illustrates this default association between the native VLAN and VLAN 1. The IEEE committee that defined 802.1Q decided that, for backward compatibility, it was desirable to associate all untagged traffic on an 802.1Q link with a specific VLAN. This VLAN is the native VLAN and is implicitly used for all the untagged traffic received on an 802.1Q-capable port. This capability is desirable because it allows 802.1Q-capable ports to talk to old 802.3 ports directly by sending and receiving untagged traffic. However, in all other cases, leaving traffic untagged might be very detrimental. For example, identity enforcement and class of service (802.1p) bits are lost when untagged frames are transmitted over an 802.1Q link. For these reasons—loss of means of identification and loss of classification—you should avoid the use of the native VLAN for data traffic. There are very few reasons why the native VLAN would ever need to be used explicitly for traffic. The native VLAN can be modified to be a VLAN other than VLAN 1 with the switchport trunk native vlan vlan-id interface command. The recommended practice is that the native VLAN should never be used as a user VLAN or the management VLAN. As stated in the section “VLAN 1,” control traffic—CDP, VTP, PAgP, and DTP—is transmitted over VLAN 1, which is the default native VLAN. If the native VLAN is changed to something other than VLAN 1, the control traffic is transmitted on VLAN 1 as tagged traffic. This has no ill effects on the control traffic. It is fine to leave VLAN 1 as the default native VLAN, as long as it is not used as a user VLAN or as the management VLAN. Control traffic should be the only information carried across VLAN 1. However, common practice is to change the native VLAN to a dummy VLAN (other than VLAN 1) that is not used for any data or management traffic. Figure 4-10 illustrates this, with VLAN 2 configured as the native VLAN.

268

Chapter 4: Inter-VLAN Routing

Figure 4-10 Common Practice Is to Create a Dummy VLAN to Be Used As the Native VLAN for IEEE 802.1Q Trunks

VLAN Trunk
VLAN 1 - Tagged CDP, VTP, PAgP, DTP VLAN 2 - Untagged Native VLAN User VLAN 10 - Tagged 172.16.10.0/24 User VLAN 20 - Tagged 172.16.20.0/24 Management VLAN 99 - Tagged 172.16.99.0/24

It’s important to ensure that both ends of a switch-to-switch link have consistent native VLANs configured. If the native VLANs on both ends of a link are not the same, there will effectively be a bridge between them, and they will no longer be independent broadcast domains. Fortunately, recent versions of Cisco IOS software alert the user when mismatches in the native VLAN occur.

Management VLAN
Most of today’s switches and routers can be accessed remotely via Telnet or SSH to the device’s management Internet Protocol (IP) address. The recommended practice is to put these and other networking devices in their own VLAN, known as the management VLAN. The management VLAN should be a separate VLAN, independent of any user VLANs, independent of the native VLAN, and independent of VLAN 1. In case network problems occur, such as broadcast storms or spanning-tree convergence issues, an independent management VLAN still allows the network administrator to access these devices and troubleshoot the problem. In Figure 4-9, the management VLAN is configured as VLAN 99. Another reason to keep the management VLAN independent of user VLANs is that it keeps “trusted devices” separate from “untrusted devices.” This lessens the possibility, either by misconfiguration, accident, or intent, that users gain access to the routers or switches.

Methods of Inter-VLAN Routing

269

Configuring the Router with a Native VLAN
When a router’s interface is configured as a trunk link, frames received on that interface from the native VLAN on the switch enter the interface untagged. Frames from the other nonnative VLANs enter the interface tagged as Inter-Switch Link (ISL) or 802.1Q. Configuring the router’s interface as a trunk link requires the use of subinterfaces. Each VLAN is configured on a separate subinterface. Each subinterface is configured to match the proper trunking protocol on the switch, 802.1Q or ISL using the encapsulation [dot1q | isl] vlan-id router interface command. However, the router’s subinterface that receives the native VLAN traffic must be configured to expect those frames to be untagged. This is done using the native option of the encapsulation dot1q vlan-id [native] subinterface command. Note that the native option is unavailable when you perform ISL trunking—it is unique to IEEE 802.1Q trunking. Before Cisco IOS software Release 12.1(3)T, the router had to be configured with the native VLAN on the physical interface, and nonnative VLANs were configured on the subinterface with the ISL or 802.1Q tag.

Summary of VLAN Types
The following list summarizes the different VLANs and how they should be used:

By default, VLAN 1 is the native VLAN and should only be used to carry control traffic, such as CDP, VTP, PAgP, and DTP. This information is transmitted across trunk links untagged. User VLANs should not include the native VLAN. VLAN 1 is the native VLAN unless this is changed. User VLAN traffic is sent as tagged frames across VLAN trunks. The management VLAN should be separate from the user VLANs. It should not be the native VLAN, and it should not be VLAN 1. This ensures access to networking devices in case of problems with the network. The subinterface on the router that is used to send and receive native VLAN traffic must be configured with the native option of the encapsulation interface command. Doing so lets the router know that any frames coming in untagged belong to that subinterface and are members of the native VLAN.

Route Switch Processors
The highest-performing inter-VLAN routing option uses an internal route switch processor. Figure 4-11 shows one type of route switch processor. In the case of a modular switch, the route switch processor resides on a router card that is plugged into the switch. On some switch platforms, the route switch processor is not modular but is an integral part of the switch hardware architecture.

270

Chapter 4: Inter-VLAN Routing

Figure 4-11 Catalyst 4500 and 6500 Switches Provide Layer 3 Switching if the Appropriate Module Is Inserted in the Chassis

Integrated route switch processors perform better than external routers for the following reasons:
■ ■

The router’s CPU power is well matched to the switch’s capacity. The router has direct access to the switch’s backplane. This offers more bandwidth than a physical interface. The router is highly integrated within the switch. This allows high-speed routing features such as Cisco Express Forwarding (CEF) to be implemented easily.

In addition to the route switch processor’s high-speed routing performance, there can also be significant benefits in terms of ease of configuration and management. For most Catalyst switches, the route switch processor’s interfaces are actually specified as VLAN interfaces. For example, Example 4-1 shows the commands needed to configure an IP address for the router’s interface in VLAN 55.
Example 4-1 Integrated Route Processors Make It Easy to Configure Inter-VLAN Routing
Switch(config)#interface vlan 55 Switch(config-if)#ip address 10.0.1.1 255.255.255.0

This ease of configuration and management makes it difficult to mismatch router interfaces and VLAN IDs and produces Layer 2 and Layer 3 configuration files that are easier to interpret than when an external router is used.

Methods of Inter-VLAN Routing

271

Router-on-a-Stick
The technique of implementing inter-VLAN routing using a single trunk-connected Fast Ethernet link to a router is called router-on-a-stick (see Figure 4-12).
Figure 4-12 Router-on-a-Stick Uses a Layer 2 Switch and an External Router Connected with an ISL or IEEE 802.1Q Trunk
VLAN 10 192.168.1.0 VLAN 20 192.168.2.0

Trunk

VLAN 30 192.168.3.0

Physical Interface FastEthernet 0/0
Logical Interface FastEthernet 0/0.10 IP Address 192.168.1.1 Logical Interface FastEthernet 0/0.20 IP Address 192.168.2.1 Logical Interface FastEthernet 0/0.30 IP Address 192.168.3.1

The primary advantage of using a trunk link is a reduction in router and switch ports. Doing so not only saves money but also can reduce configuration complexity. Consequently, the trunk-connected router approach can scale to a much larger number of VLANs than a onelink-per-VLAN design. The number of subinterfaces on a router interface can easily accommodate the maximum number of VLANs on the connected Layer 2 switch. The Catalyst 2950T switch with the enhanced image, for example, supports up to 4094 VLANs. However, the trunk-connected router configuration has disadvantages, including the following:
■ ■ ■

There is a possibility of inadequate bandwidth for each VLAN. Additional overhead on the router can occur. Older versions of Cisco IOS software support only a limited set of features on trunked interfaces and might support only Cisco’s proprietary ISL trunking encapsulation. Trunking is not supported on most Cisco routers with standard Ethernet interfaces and some lower-end routers with Fast Ethernet interfaces.

272

Chapter 4: Inter-VLAN Routing

With regard to inadequate bandwidth for each VLAN, consider the situation in which all VLANs must share the Fast Ethernet 100 Mbps of bandwidth. A single VLAN could easily consume the entire capacity of the router or link, especially in the event of a broadcast storm or spanning-tree problem. Furthermore, the up-and-back nature of router-on-a-stick designs effectively doubles the link’s bandwidth consumption (see Figure 4-12). With regard to the additional overhead on the router caused by using a trunk-connected router, not only must the router perform normal routing and data-forwarding duties, it also must handle the additional encapsulation used by the trunking protocol.

When to Use the Router-on-a-Stick Design
In general, the router-on-a-stick approach to inter-VLAN routing is most appropriate when other options using internal route processors are unavailable. Internal route processors include Route Switch Modules (RSMs) and Multilayer Switch Feature Cards (MSFCs). The routeron-a-stick design is not necessarily a poor choice; however, other options tend to provide higher throughput and functionality. Also, because the router-on-a-stick technique functions as if the router were sitting on the edge of the network (at least as far as the Layer 2 network is concerned), it tends to be less tightly integrated with the rest of the campus network, as illustrated in Figure 4-13. Newer approaches, employing embedded route processors, seek to place routing in the middle of the network, where it can have a greater influence on the network’s overall scalability and stability.
Figure 4-13 The Router-on-a-Stick Technique Functions As If the Router Were Sitting on the Edge of the Network

802.1Q Trunk

802.1Q Trunk

802.1Q Trunk

802.1Q Trunk

Methods of Inter-VLAN Routing

273

Cisco Layer 3 Feature Cards
Although the performance of route switch processors generally is adequate for typical applications, circumstances exist in which additional performance is required. Here are some situations that might require additional routing performance:

A high proportion of traffic needs to cross VLAN boundaries. 80 percent is a figure that approximates this type of traffic in modern switched networks. A large number of interfaces are present, say 100 or more, and many are 1 Gbps or greater in speed. Additional switching capacity has been provided through the addition of a Switch Fabric Module on a Catalyst 6500.

Two Layer 3 feature cards available for the Catalyst 6500 Series switches are the MSFC, shown in Figure 4-14, and the Policy Feature Card (PFC), shown in Figure 4-15.
Figure 4-14 The MSFC Is the Daughter Card on the Left Side of the Supervisor Engine

MSFC

The MSFC provides Layer 3 functionality and enables the use of CEF for increased routing performance. The PFC contains the application-specific integrated circuits (ASICs) for Layer 2 and Layer 3 lookups and performs many Cisco IOS features in hardware. The PFC performs IP Unicast and Multicast forwarding, QoS, and access control list (ACL) lookups in hardware. The PFC scales central forwarding to 30 Mbps.

274

Chapter 4: Inter-VLAN Routing

Figure 4-15 The PFC Is the Daughter Card on the Right Side of the Supervisor Engine PFC

Configuring Inter-VLAN Routing
The following four sections examine the configuration required to implement inter-VLAN routing on a Catalyst 3550 or 3750 switch. In all the examples, the first task should always be to turn on IP routing functionality with the ip routing global configuration command. The next sections detail inter-VLAN routing involving the following:
■ ■ ■ ■

Switch virtual interfaces Routed ports External router and internal route processor Routing between an external router and an internal route processor

Configuring Inter-VLAN Routing in a Switched Network
Catalyst 3550, 3750, 4000, 4500, 5000, 5500, 6000, and 6500 series switches all can perform inter-VLAN routing. The Catalyst 3550 and 3750 series switches provide fixed-chassis solutions for inter-VLAN routing, without the capability to add line cards for increasing port density. All Cisco routers with Fast Ethernet interfaces, except the 1720 router, can support routeron-a-stick functionality. The router-on-a-stick solution is used if the distribution switches do not include an internal route processor. Cisco 2900XL, 2950, and 3500XL switches are examples of Layer 2 switches, which do not include route processors.

Configuring Inter-VLAN Routing Via the Switch Virtual Interface
By far the most common method of achieving inter-VLAN routing is to configure the switch virtual interface. Using this technique, the router has a virtual interface in every VLAN

Configuring Inter-VLAN Routing

275

created on the switch. Rather than configuring a physical interface for each VLAN, the router uses a virtual or VLAN interface. For example, the commands shown in Example 4-2 allow the router to route traffic to and from VLAN 55.
Example 4-2 Switch Virtual Interfaces Are Used to Configure Inter-VLAN Routing on IOS-Based Layer 3 Catalyst Switches
Switch(config)#interface vlan 55 Switch(config-if)#ip address 10.0.1.1 255.255.255.0

These commands have the same effect as if a physical router interface were connected to a switch port in the appropriate VLAN. Following the configuration of the IP address, the no shutdown interface command is required when configuring interface VLAN 1. The interface is shut down by default.
Lab 4.3.2 Inter-VLAN Routing with the Internal Route Processor

In this lab exercise, you configure inter-VLAN routing using a switch with an internal route processor.

Configuring Inter-VLAN Routing Via the Routed Port
Although it is more common to configure inter-VLAN routing using the virtual (VLAN) interface, it is also possible to configure a physical switch port/interface as a router interface. Through this process, it is possible to turn a 12- or 24-port multilayer Ethernet switch into a 12- or 24-interface Ethernet router. Turning a switch port into a router interface is simply a matter of turning off the switch port functionality, as shown in Example 4-3.
Example 4-3 Routed Ports Are Used to Configure Layer 3 Catalyst Switch Ports as Router Interfaces
Switch(config)#interface fa0/1 Switch(config-if)#no switchport Switch(config-if)#ip address 10.0.1.1 255.255.255.0

As soon as the Layer 2 functionality is turned off, the interface can be treated as though it is a regular Fast Ethernet router interface. For example, an IP address can be configured. The switch port can now be used as a physical router port for connection to external devices.

276

Chapter 4: Inter-VLAN Routing

Configuring Routing Between an External Router and an Internal Route Processor
Connecting an external router to an internal route switch processor is often necessary (see Figure 4-16). A common reason for this is to provide access to a WAN interface, because these often are not provided on a switch.
Figure 4-16 A Multilayer Switch Can Obtain WAN Connectivity Through a Routed Link Connection to an External Router

WAN

s 0/0 Routed Port fa 0/1 fa 0/0

External Router

The easiest method of implementing this is to create a routed port, as shown in Example 4-4.
Example 4-4 A Routed Link Can Be Configured Between a Multilayer Switch Port, Configured as a Routed Port, and an External Router
RouteSwitch(config)#interface fa 0/1 RouteSwitch(config-if)#no switchport RouteSwitch(config-if)#ip address 10.0.1.1 255.255.255.0

ExtRouter(config)#interface fa 0/0 ExtRouter(config-if)#ip address 10.0.1.2 255.255.255.0

Although a routed port is configured for connectivity with an external router, inter-VLAN routing would most likely be achieved through the use of switch virtual interfaces. To route between VLANs 10 and 20, which have been configured on the multilayer switch, use the configuration shown in Example 4-5.

Configuring Inter-VLAN Routing

277

Example 4-5 Inter-VLAN Routing with Switch Virtual Interfaces Can Be Coupled with Routing Over a Routed Link Between a Switch Port on a Multilayer Switch Configured as a Routed Port and a Router Interface on an External Router
RouteSwitch(config)#interface vlan 10 RouteSwitch(config-if)#ip address 10.0.10.1 255.255.255.0 RouteSwitch(config)#interface vlan 20 RouteSwitch(config-if)#ip address 10.0.20.1 255.255.255.0

The internal route processor on the switch most likely will need to run a dynamic routing protocol and perhaps include some static routes. If there are network segments that are not directly connected to the switch, a dynamic routing protocol or static routes are required.
Lab 4.3.3 Routing Between an External Router and an Internal Route Processor

In this lab exercise, you configure routing between an internal route processor and an external router.

Configuring the Router for the Native VLAN
A native VLAN is configured on the trunk link, as shown in Figure 4-17. An 802.1Q trunk requires the native VLAN for each opposing trunk port on a trunk link to match. Both the router and the switch require the native VLAN to be configured unless the default of VLAN 1 is desired (but this is not recommended).
Figure 4-17 The Native VLAN Must Be Configured on a Trunk Link Between a Router and a Catalyst Switch

WAN

s 0/0 802.1Q Trunk fa 0/1 fa 0/0

Layer 2 Switch

External Router

278

Chapter 4: Inter-VLAN Routing

With Cisco IOS software Release 12.1(3)T and later, the router’s subinterface can be configured as the native VLAN, as shown in Example 4-6.
Example 4-6 The Native VLAN Is Configured on a Trunk Link Between a Layer 2 Switch and an External Router Using a Subinterface on the Router for the Native VLAN
! Layer 2 Switch Commands: Switch(config)#interface vlan 10 Switch(config-if)#description Management VLAN 10 Switch(config-if)#ip address 192.168.10.2 255.255.255.0 Switch(config-if)#no shutdown Switch(config)#interface fa 0/1 Switch(config-if)#switchport mode trunk Switch(config-if)#switchport trunk native vlan 1

! Router Commands: Router(config)#interface fa 0/0.1 Router(config-subif)#description Control Traffic VLAN 1 Router(config-subif)#encapsulation dot1q 1 native Router(config-subif)#ip address 192.168.1.1 255.255.255.0 Router(config)#interface fa 0/0.10 Router(config-subif)#description Management VLAN 10 Router(config-subif)#encapsulation dot1q 10 Router(config-subif)#ip address 192.168.10.1 255.255.255.0 Router(config)#interface fa 0/0.20 Router(config-subif)#description Engineering VLAN 20 Router(config-subif)#encapsulation dot1q 20 Router(config-subif)#ip address 192.168.20.1 255.255.255.0 Router(config)#interface fa 0/0.30 Router(config-subif)#description Marketing VLAN 30 Router(config-subif)#encapsulation dot1q 30 Router(config-subif)#ip address 192.168.30.1 255.255.255.0

The native option tells the router to accept any frames coming in untagged on FastEthernet0/0 as belonging to VLAN 1. Before Cisco IOS software Release 12.1(3)T, the native VLAN had to be configured on the router’s physical interface, as shown in Example 4-7.

Configuring Inter-VLAN Routing

279

Example 4-7 The Native VLAN Is Configured on a Trunk Link Between a Layer 2 Switch and an External Router Using the Physical Interface on the Router for the Native VLAN
Router(config)#interface fa 0/0 Router(config-if)#description VLAN 1 Router(config-if)#ip address 192.168.1.1 255.255.255.0 Router(config)#interface fa 0/0.10 Router(config-subif)#description Management VLAN 10 Router(config-subif)#encapsulation dot1q 10 Router(config-subif)#ip address 192.168.10.1 255.255.255.0 Router(config)#interface fa 0/0.20 Router(config-subif)#description Engineering VLAN 20 Router(config-subif)#encapsulation dot1q 20 Router(config-subif)#ip address 192.168.20.1 255.255.255.0 Router(config)#interface fa 0/0.30 Router(config-subif)#description Marketing VLAN 30 Router(config-subif)#encapsulation dot1q 30 Router(config-subif)#ip address 192.168.30.1 255.255.255.0

Configuring Router-on-a-Stick
When using an external router, you can logically divide an interface into multiple virtual subinterfaces. Subinterfaces provide a flexible solution for routing multiple VLANs through a single physical interface, as illustrated in Figure 4-18.
Figure 4-18 Router-on-a-Stick Is Configured on a Trunk Link Between a Router and a Layer 2 Switch
VLAN 10 192.168.1.0 VLAN 20 192.168.2.0

Trunk

VLAN 30 192.168.3.0

Physical Interface FastEthernet 0/0
Logical Interface FastEthernet 0/0.10 IP Address 192.168.1.1 Logical Interface FastEthernet 0/0.20 IP Address 192.168.2.1 Logical Interface FastEthernet 0/0.30 IP Address 192.168.3.1

280

Chapter 4: Inter-VLAN Routing

To configure subinterfaces on a physical interface, follow these steps: Step 1 Step 2 Step 3 Identify the interface. Define the VLAN encapsulation. Assign an IP address to the interface.

To identify the interface, enter the global configuration command interface FastEthernet slot-number/port-number.subinterface-number, where slot-number/port-number.subinterfacenumber is the physical and logical interface. To define the VLAN encapsulation, enter the subinterface configuration command encapsulation dot1Q vlan-number, where vlan-number is the VLAN for which the subinterface carries traffic. To assign the IP address to the subinterface, enter the interface configuration command ip address ip-address subnet-mask, where ip-address and subnet-mask are the 32-bit network address and mask of the specific interface. In Figure 4-18, the router has three subinterfaces configured on FastEthernet interface 0/0. These three interfaces are identified as FastEthernet0/0.10, FastEthernet0/0.20, and FastEthernet0/0.30. All interfaces are encapsulated for 802.1Q. Interface FastEthernet0/0.10 is routing packets for VLAN 10, whereas interface FastEthernet0/0.20 is routing packets for VLAN 20 and FastEthernet0/0.30 is routing packets for VLAN 30. Note that the subinterface number does not have to match the VLAN number, but that is common practice. With Cisco IOS software Release 12.1(3)T and later, the router subinterface can be configured as the native VLAN. The native option tells the router to accept any frames coming in untagged on FastEthernet0/0 as belonging to VLAN 1. Example 4-8 shows the configuration with Cisco IOS software Release 12.1(3)T and later.
Example 4-8 With IOS 12.1(3)T and Later, One of the Router Subinterfaces Is Configured as the Native VLAN
! Layer 2 Switch Commands: Switch(config)#interface vlan 10 Switch(config-if)#description Management VLAN 10 Switch(config-if)#ip address 192.168.10.2 255.255.255.0 Switch(config-if)#no shutdown

Switch(config)#interface fa0/0.1 Switch(config-if)#switchport mode trunk Switch(config-if)#switchport trunk native vlan 1

Configuring Inter-VLAN Routing

281

Example 4-8 With IOS 12.1(3)T and Later, One of the Router Subinterfaces Is Configured as the Native VLAN (Continued)

! Router Commands: Router(config)#interface fa0/1.1 Router(config-subif)#description Control Traffic VLAN 1 Router(config-subif)#encapsulation dot1q 1 native Router(config-subif)#ip address 192.168.1.1 255.255.255.0

Router(config)#interface fa0/0.10 Router(config-subif)#description Management VLAN 10 Router(config-subif)#encapsulation dot1q 10 Router(config-subif)#ip address 192.168.10.1 255.255.255.0

Router(config)#interface fa0/0.20 Router(config-subif)#description Engineering VLAN 20 Router(config-subif)#encapsulation dot1q 20 Router(config-subif)#ip address 192.168.20.1 255.255.255.0

Router(config)#interface fa0/0.30 Router(config-subif)#description Marketing VLAN 30 Router(config-subif)#encapsulation do1q 30 Router(config-subif)#ip address 192.168.30.1 255.255.255.0

Before Cisco IOS software Release 12.1(3)T, the native VLAN had to be configured on the router’s physical interface, as shown in Example 4-9.
Example 4-9 Before IOS 12.1(3)T, the Physical Interface Was Configured with the Native VLAN
! Layer 2 Switch Commands: Switch(config)#interface vlan 10 Switch(config-if)#description Management VLAN 10 Switch(config-if)#ip address 192.168.10.2 255.255.255.0 Switch(config-if)#no shutdown

Switch(config)#interface fa0/0.1 Switch(config-if)#switchport mode trunk Switch(config-if)#switchport trunk native vlan 1

continues

282

Chapter 4: Inter-VLAN Routing

Example 4-9 Before IOS 12.1(3)T, the Physical Interface Was Configured with the Native VLAN (Continued)

! Router Commands: Router(config)#interface fa0/0 Router(config-if)#description VLAN 1 Router(config-if)#ip address 192.168.1.1 255.255.255.0

Router(config)#interface fa0/0.10 Router(config-subif)#description Management VLAN 10 Router(config-subif)#encapsulation dot1q 10 Router(config-subif)#ip address 192.168.10.1 255.255.255.0

Router(config)#interface fa0/0.20 Router(config-subif)#description Engineering VLAN 20 Router(config-subif)#encapsulation dot1q 20 Router(config-subif)#ip address 192.168.20.1 255.255.255.0

Router(config)#interface fa0/0.30 Router(config-subif)#description Marketing VLAN 30 Router(config-subif)#encapsulation do1q 30 Router(config-subif)#ip address 192.168.30.1

Lab 4.3.1 Inter-VLAN Routing with an External Router

In this lab exercise, you configure an external router (router-on-a-stick) to route interVLAN traffic.

Verifying the Inter-VLAN Routing Configuration
To verify that inter-VLAN routing functionality is available, use the show ip route command. A useful summary of interfaces, both virtual and routed, can be obtained through the use of the command show ip interface brief, as shown in Example 4-10 for the topology shown in Figure 4-19.
Example 4-10 The show ip interface brief Command Is Useful for Verifying a Router-on-a-Stick/Inter-VLAN Routing Configuration
Interface Vlan1 Vlan10 IP-Address unassigned 10.0.10.1 OK? YES YES Method unset manual Status Protocol down up

administratively down up

Configuring Inter-VLAN Routing

283

Example 4-10 The show ip interface brief Command Is Useful for Verifying a Router-on-a-Stick/Inter-VLAN Routing Configuration (Continued)
Vlan20 FastEthernet0/1 FastEthernet0/2 FastEthernet0/3 FastEthernet0/4 FastEthernet0/5 FastEthernet0/6 FastEthernet0/7 FastEthernet0/8 FastEthernet0/9 FastEthernet0/10 FastEthernet0/11 FastEthernet0/12 10.0.20.1 10.0.1.1 unassigned unassigned unassigned unassigned unassigned unassigned unassigned unassigned unassigned unassigned unassigned YES YES YES YES YES YES YES YES YES YES YES YES YES manual manual unset unset unset unset unset unset unset unset unset unset unset up up down up up up up up up up down down down up up down up up up up up up up down down down

Figure 4-19 The Layer 3 Switch Is Set Up with Two User VLANs

WAN

s 0/0 Routed Port fa 0/1 10.0.20.0/24 VLAN 20 fa 0/0

10.0.10.0/24 VLAN 10

External Router

The command show ip route confirms that IP routing is enabled on a Layer 3-capable switch, as shown in Example 4-11.

284

Chapter 4: Inter-VLAN Routing

Example 4-11 The show ip route Command Is Used on a Layer 3 Switch Just as It Is on a Router
Switch#show ip route Codes:C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, IA - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type1, N - OSPF NSSA external type 2 E1 - OSPF external type1, E2 - OSPF external type2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * -candidate default, U - per-user static route, o - ODR P - periodic downloaded static route

Gateway of last resort is not set

10.0.0.0/24 is subnetted, 3 subnets

C C C

10.0.10.0 is directly connected, Vlan10 10.0.1.0 is directly connected, FastEthernet0/1 10.0.20.0 is directly connected, Vlan20

The presence of the directly connected networks in the routing table indicates that IP routing is enabled. Without IP routing enabled, the command show ip route produces an empty output, as shown in Example 4-12.
Example 4-12 The show ip route Command Yields Empty Output When IP Routing Is Disabled
Switch#show ip route Default gateway is not set Host Gateway Last Use Total Uses Interface

ICMP redirect cache is empty Switch#

To determine whether a switch port is acting as a Layer 2 member of a VLAN or is configured as a routed port, use either the show ip interface fastethernet module/port command or the show interface fastethernet module/port switchport command. In Example 4-13, these two commands have been applied to interface FastEthernet0/1. This interface has been configured as a routed port through the use of the interface command no switchport. The output illustrates that the interface has an IP status but no switchport status. This indicates that it is configured for routing.

Configuring Inter-VLAN Routing

285

Example 4-13 Two Useful Commands for Verifying Whether a Switch Port Is Configured as a Routed Port
Switch#show ip interface fastethernet 0/1

FastEthernet0/1 is up, line protocol is up Internet address is 10.0.1.1/24 Broadcast address is 255.255.255.255 Address determined by setup command MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is not set Proxy ARP is enabled Local Proxy ARP is disabled Security level is default Split horizon is enabled ICMP redirects are always sent IP CEF Fast switching turbo vector IP multicast fast switching is enabled IP multicast distributed fast switching is disabled IP route-casch flags are Fast, CDF Router Discovery is disabled IP output packet accounting is disabled IP access violation accounting is disabled TCP/IP header compression is disabled RTP/IP header compression is disabled Probe proxy name replies are disabled Policy routing is disabled Network address translation is enabled, interface in domain outside WCCP Redirect outbound is disabled WCCP Redirect inboud is disabled WCCP Redirect exclude is disabled BGP Policy Mapping is disabled Switch# Switch#show interface fastethernet 0/1 switchport Name: Fa0/1 Switchport: Disabled

286

Chapter 4: Inter-VLAN Routing

When the same commands are applied to interface FastEthernet0/2, which is configured as a regular switchport and VLAN member, the output, shown in Example 4-14, clearly shows that the interface has no Layer 3 functionality but is acting as a Layer 2 interface.
Example 4-14 The show ip interface fastethernet and show interface fastethernet switchport Commands Clarify Whether a Port Is Configured as a Layer 2 Switch Port
Switch#show ip interface fastethernet

FastEthernet0/2 is down, line protocol is down Inbound access list is not set Switch#

Switch#show interface fastethernet 0/2 switchport Name: Fastethernet0/2 Switchport: Enabled Administrative Mode: dynamic desirable Operational Mode: down Administrative Trunking Encapsulation: negotiate Negotiation of Trunking: On Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Administrative private-vlan host-association: none Administrative private-vlan mapping: none Operational private-vlan: none Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001 Protected: false Unknown unicast blocked: disabled Unknown multicast blocked: disabled Voice VLAN: none (Inactive) Appliance trust: none

Troubleshooting Inter-VLAN Routing
The first step in troubleshooting inter-VLAN routing is to ensure that routing is actually enabled using the show ip route command. If the routing table displays no entries, you need to enable IP routing with the ip routing global configuration command.

Summary

287

After verifying routing, ensure that the Layer 2 VLANs and Layer 3 IP addressing are as intended using the show ip interfaces brief command. This command also reveals whether routing is configured for an individual switch interface or an entire VLAN. If communication with a switch seems to be a problem, check that the switch’s IP address is in the appropriate VLAN and that the gateway is set. Assuming that the VLANs are appropriately addressed, it is useful to ensure that no Layer 2 problems exist by pinging within each VLAN and verifying that it is possible to reach the router interface with every VLAN. If communications within the VLAN are correct, but communications between the VLANs are not working, check the Layer 3 configuration. Be sure that the appropriate gateway is set on hosts and switch management interfaces. Also verify the IP network address and subnet mask. Any remaining routing issues are likely to be the result of incorrectly configured routing protocols or the somewhat-tricky native VLAN issue. In particular, take care to prescribe the native VLAN for a trunk link. No specific debug or troubleshooting commands help you identify problems with the native VLAN. Some Catalyst platforms, such as the Catalyst 6000, report an error when a port receives a tagged frame for a VLAN it was expecting to be untagged, but not all models behave this way. The best strategy for dealing with native VLAN trunking problems is to maintain an awareness of the issue and to take care with the configuration.

Summary
Inter-VLAN routing is an essential component of designing a scalable switched LAN. This chapter examined the three methods of routing between VLANs and provided guidelines for choosing between the alternatives. This chapter also demonstrated how to configure VLAN routing on both switch virtual interfaces and routed ports. It concluded with coverage of the commands needed to verify and troubleshoot inter-VLAN routing.

288

Chapter 4: Inter-VLAN Routing

Key Terms
default VLAN Upon initial switch configuration, all switch ports can be configured to be members of a particular VLAN other than VLAN 1. This particular VLAN is the default VLAN. When a user plugs a device into the switch, it automatically is associated with the default VLAN. If, upon initial switch configuration, not all switch ports are configured to be members of a VLAN other than VLAN 1, VLAN 1 is the default VLAN. management VLAN Most of today’s switches and routers can be accessed remotely via Telnet or SSH to the device’s management IP address. The recommended practice is to put these and other networking devices in their own VLAN, known as the management VLAN. The management VLAN should be a separate VLAN, independent of any user VLANs, the native VLAN, and VLAN 1. Multilayer Switch Feature Card (MSFC) MSFC1 and MSFC2 are daughter cards to the Catalyst 6000 Supervisor Engine. They provide multilayer switching functionality and routing services between VLANs. Multilayer Switch Module (MSM) A line card for Catalyst 6000 family switches that runs the Cisco IOS router software and directly interfaces with the Catalyst 6000 backplane to provide Layer 3 switching. native VLAN The IEEE committee that defined 802.1Q decided that, for backward compatibility, it was desirable to associate all untagged traffic on an 802.1Q link with a specific VLAN—the native VLAN. This VLAN is implicitly used for all the untagged traffic received on an 802.1Q-capable port. Policy Feature Card (PFC) Performs hardware-based Layer 2 to Layer 4 packet forwarding as well as packet classification, traffic management, and policy enforcement. route processor The main system processor in a Layer 3 networking device, responsible for managing tables and caches and for sending and receiving routing protocol updates. Route Switch Feature Card (RSFC) A daughter card to the Catalyst 5000/5500 Supervisor Engine IIG and IIIG that provides inter-VLAN routing and multilayer switching functionality. The RSFC runs Cisco IOS router software and directly interfaces with the Catalyst switch backplane. Route Switch Module (RSM) A line card that interfaces with the Supervisor Engine of a Catalyst 5000/5500 switch to provide inter-VLAN routing functionality. The RSM runs the Cisco IOS. router-on-a-stick A method of inter-VLAN routing consisting of an external router with a Fast Ethernet, Gigabit Ethernet, or EtherChannel trunk connecting to a switch, using ISL or 802.1Q. Subinterfaces on the trunk are created to correspond with VLANs in a one-to-one fashion.

Check Your Understanding

289

user VLAN A VLAN created to segment a group of users, either geographically or logically, from the rest of the network. User VLAN traffic is typically configured to be independent of VLAN 1, the native VLAN, and the management VLAN.

Check Your Understanding
Use the following review questions to test your understanding of the concepts covered in this chapter. Answers are listed in Appendix A, “Check Your Understanding Answer Key.”
1. Which of the following are options that are available for inter-VLAN routing? A. Adding a route processor to a chassis-based switch with a daughter card or module B. Router-on-a-stick C. One router-to-switch link per VLAN D. Fixed chassis (nonmodular) multilayer switch 2. What is required in a Layer 2 core with physical loops? A. Routing protocol B. HSRP C. STP D. VTP 3. What is the most scalable inter-VLAN routing option? A. Layer 2 switch B. Layer 3 switch C. Router D. Router-on-a-stick 4. Which of the following are examples of modules or daughter cards that provide routing

functionality in a chassis-based Catalyst switch?
A. Multilayer Switch Module B. Route Switch Feature Card C. Route Switch Module D. Multilayer Switch Feature Card

290

Chapter 4: Inter-VLAN Routing

5. Which of the following modules have embedded route processors? A. Catalyst 6500 Supervisor Engine 720 B. Catalyst 4006 Supervisor Engine II C. Catalyst 4500 Supervisor Engine III D. Catalyst 4500 Supervisor Engine IV 6. Which of the following are required for performing router-on-a-stick? A. Router B. IEEE 802.1Q or ISL C. Routing protocol D. Layer 2 switch port 7. A switch virtual interface is configured with what command(s)? A. Switch#vlan database B. Switch(vlan)#vlan C. Switch(config)#interface vlan D. Switch(config)#vlan 8. What command is required to configure a switch port on a multilayer Catalyst switch as

a routed port?
A. ip routing B. no shutdown C. interface vlan D. no switchport 9. Before Cisco IOS software Release 12.1(3)T, the native VLAN was configured on

which interface on a router?
A. Physical interface B. Subinterface C. Switch virtual interface D. Bridge virtual interface

Check Your Understanding

291

10. What Catalyst 3550 commands can be used to determine whether a port is a routed port

or a Layer 2 switch port?
A. show port routed B. show ip interface switchport C. show vlan D. show ip interface brief

Objectives
After completing this chapter, you will be able to perform tasks related to the following:
■ ■

List and understand the role of Multilayer Switching (MLS) components. Have a general understanding of the hardware platforms and Cisco IOS software Releases required for MLS and Cisco Express Forwarding (CEF). Explain MLS operation. Understand the advantages of CEF over MLS. Configure MLS and CEF. Verify MLS and CEF operation.

■ ■ ■ ■

Chapter 5 Multilayer Switching
The desire for high-speed networking motivates the development of new technologies. One of the bottlenecks in high-speed networking is the decision-making process within the router. Until recently, routers forwarded traffic without the aid of specialized hardware designed to rewrite Protocol Data Unit (PDU) headers to speed up the process. In recent years, technologies and accompanying hardware have enhanced the process of rewriting PDU headers to move traffic to its ultimate destination. A number of software and hardware combinations enable hardware-based PDU header rewrites and forwarding. Two of the methods used by Cisco devices are Multilayer Switching (MLS) and Cisco Express Forwarding (CEF). The hardware requirements for each of these technologies are strict, so it is important to do some research before making a purchase. This chapter clarifies the hardware and software requirements for supporting MLS and CEF. MLS is a technology used by a small number of older Catalyst switches to provide wire-speed routing. MLS is sometimes called “route once, switch many,” where the first packet of a flow is routed by the router in software, and the remaining packets are forwarded in hardware by the switch. CEF is the technology used by newer Cisco devices to provide wire-speed routing. MLS looks at the first packet in a flow and caches the requisite information to permit subsequent packets to be switched independent of the route processor. CEF lets packet switching circumvent the route processor altogether. This is accomplished by using specialized data structures that are dynamically updated by a communication process between the route processor and the switch processor. Therefore, the traditional routing of the first packet required by MLS is avoided. In general, CEF can be thought of as “route never, switch always,” where the packet is never routed by the router in software and is always forwarded in hardware by the switch.

294

Chapter 5: Multilayer Switching

This chapter shows how MLS and CEF work and how to configure these technologies. This chapter also covers verifying and troubleshooting MLS and CEF and interpreting the output of various show commands relating to MLS and CEF.

Multilayer Switching
The term multilayer switching is used for two distinct things. On one hand, it is a general network design term that refers to hardware-based PDU header rewriting and forwarding, based on information specific to one or more Open System Interconnection (OSI) layers. On the other hand, as characterized in this chapter, MLS refers to a specific technology employed by various Cisco devices to perform wire-speed PDU header rewrites and forwarding. To help differentiate between the two uses of the term multilayer switching, when the acronym MLS is used (as opposed to the expanded term), it refers to the Cisco-specific technology. MLS was the first technological step in solving the router-as-a-bottleneck issue. MLS is also responsible for blurring the lines with respect to using the OSI model as a means of delineating per-OSI layer functions. With MLS, Layer 3 switching speeds approximate those of Layer 2 switching. This has a dramatic impact on network design. The trend is to incorporate more and more Layer 3 functionality into what are traditionally Layer 2 devices. For example, the Catalyst 3550 access layer switch uses CEF by default, making it a true multilayer switch. The discussion of MLS in the following sections begins by detailing the hardware and software requirements, followed by an explanation of MLS components and operations.

MLS Hardware and Software Requirements
The requirements for running MLS in the network are specific. Many technologies are widely available on Cisco products. For example, most Cisco router platforms have Cisco IOS software releases that support Internetwork Packet Exchange (IPX). However, with MLS, widespread support is not the case, and options are limited. The following sections examine the multilayer switching hardware and software requirements for switch and router platforms running MLS and CEF.

MLS
Catalyst 5000 series switches comprise the majority of MLS deployments. For Catalyst 5000 switches, the MLS requirements are as follows:

Supervisor Engine III with NetFlow Feature Card (NFFC) or NFFC II, a Supervisor Engine IIG, or a Supervisor Engine IIIG (the IIG and IIIG have integrated NFFCs). The only NFFCs still available for purchase are the NFFC-A and NFFC II-A. The other NFFCs were last sold on April 30, 2000.

Multilayer Switching

295

Catalyst 5000 Route Switch Module (RSM), Catalyst 5000 Route Switch Feature Card (RSFC), Catalyst 6000 Multilayer Switch Feature Card (MSFC), or Catalyst 6000 Multilayer Switch Module (MSM). CatOS 4.1(1) or later. Cisco IOS software Release 12.0(3c)W5(8a) or later on the RSFC. Cisco IOS software Release 11.3(2)WA4(4) or later on the RSM.

■ ■ ■

Catalyst 2926G switches can also work in tandem with external Cisco routers to support MLS. Catalyst 2926G switches are fixed-configuration switches. They were last sold in May 2000 and have been replaced by the 2948G switches. The hardware and software guidelines for external routers are as follows:

Cisco 3600, 4500, 4700, 7200, or 7500 router or Catalyst 8500 switch router externally attached to the Catalyst 5000 series switch. The connection between the external router and the Catalyst 5000 series switch must be a Fast Ethernet or Gigabit Ethernet link, an Inter-Switch Link (ISL) or IEEE 802.1Q trunk, or a Fast or Gigabit EtherChannel. Cisco IOS software Release 11.3(2)WA4(4) or later on Cisco 4500, 4700, 7200, or 7500 routers. Cisco IOS software Release 12.0 is the earliest release available on 8500 series switch routers. Cisco IOS software Release 12.0(2) or later on Cisco 3600 series routers. Catalyst 6000 MSFC on a Supervisor Engine with CatOS 6.3. Catalyst 6000 MSM.

■ ■ ■

For Catalyst 6000 switches, the MLS hardware and software guidelines are as follows:

Catalyst 6000 family switches do not support an external Multilayer Switching Route Processor (MLS-RP). The MLS-RP must be a MSM or MSFC. As of July 6, 2000, the MSM is no longer available for purchase and has been replaced by the MSFC. MSFC, Policy Feature Card (PFC), and CatOS 5.1CSX or later. MSM, CatOS 5.2(1)CSX or later, and Cisco MSM IOS software Release 12.0(1a)WX5(6d) or later.

■ ■

CEF
Multilayer switching in the general sense is implemented with CEF in newer Catalyst 6500 products. In particular, Supervisor Engine II with Policy Feature Card 2 (PFC2), Multilayer Switch Feature Card 2 (MSFC2), and Supervisor Engine 720, comprise two standard configurations for newly purchased Catalyst 6500 switches. This configuration relies natively on CEF.

296

Chapter 5: Multilayer Switching

The Catalyst 4006 switch with the Layer 3 Services Module and the Catalyst 4500 switch with the Supervisor Engine III or Supervisor Engine IV also natively support CEF. The Catalyst 3550 switch with the Enhanced Multilayer Software Image also relies on a CEF-based routing architecture to deliver high-performance dynamic IP routing. Note that the 3550 does not support IPX or AppleTalk. With the hardware and software requirements clarified, it’s important to understand how MLS works. The following sections detail the concepts of MLS flow, MLS Switching Engine (MLS-SE), and MLS Route Processor (MLS-RP).

MLS Components
The idea of MLS is simple. MLS looks at the first packet in a flow of data and caches some header information describing the flow. Subsequent packets in the flow circumvent the router, because the switch has cached the data necessary to rewrite the packet header, which it does. This is known as wire-speed routing. MLS switches unicast IP data packet flows between IP subnets using advanced ASIC switching hardware, offloading processor-intensive packet routing from network routers. The packet forwarding function is moved to Layer 3 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 are still forwarded in software by routers. Standard routing protocols, such as Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP), Routing Information Protocol (RIP), and Intermediate System-to-Intermediate System (IS-IS), are used for route determination. IP is a connectionless protocol, and every packet is delivered independent of every other packet. However, actual network traffic consists of many end-to-end conversations, or flows, between users or applications. A flow is a unidirectional sequence of packets between a particular source and destination that share the same Layer 3 and Layer 4 information. For example, Telnet traffic transferred from a particular source to a particular destination is a flow separate from File Transfer Protocol (FTP) packets between the same source and destination. Communication from a client to a server, and from the server to the client, comprises separate and distinct flows. If a flow is defined administratively by destination IP address alone, traffic from multiple users or applications to that destination is included in that flow. The MLS Switching Engine (MLS-SE) is the set of hardware components on a Catalyst switch, excluding the route processor, necessary to support MLS. For example, a Catalyst 5000 with a Supervisor Engine IIIG is an MLS-SE. The MLS Route Processor (MLS-RP) is a Cisco device with a route processor that supports MLS. For example, a Cisco 3620 router is an MLS-RP. Only certain combinations of MLS-SEs and MLS-RPs can run MLS.

Multilayer Switching

297

MLS Flows
An MLS-SE maintains a Layer 3 switching table (the Layer 3 MLS cache) for Layer 3 switched flows. After the MLS cache is created, packets identified as belonging to an existing flow can be switched based on the cached information. The MLS cache maintains flow information for all active flows. The maximum size of the MLS cache is 128,000 entries. The larger the active cache, the greater the likelihood that a flow will not be switched by the MLS-SE and will get forwarded to the router. An MLS cache entry is created for the initial packet of each flow. Upon receipt of a packet that does not match any flow currently in the MLS cache, a new IP multilayer switching (IP MLS) entry is created. This first packet has special significance; it is detailed more in the next section. A flow’s state and identity are maintained while packet traffic is active. When traffic for a flow ceases, the entry ages out. The aging time for MLS entries kept in the MLS cache can be configured. If an entry is not used for the specified period of time, it ages out. The MLS-SE uses flow masks to determine how MLS entries are created. The flow mask is a set of criteria, based on a combination of source IP address, destination IP address, protocol, and protocol ports, that describes the flow’s characteristics. The MLS-SE learns the flow mask through Multilayer Switching Protocol (MLSP) messages from each MLS-RP for which the MLS-SE is performing Layer 3 switching. MLSP is the protocol used to communicate MLS information between the MLS-SE and MLS-RP. In particular, the MLS-SE populates its Layer 2 Content-Addressable Memory (CAM) table with updates received from MLSP packets. When the MLS-SE flow mask changes, the entire MLS cache is purged. The three flow masks are as follows:

destination-ip—The least-specific flow mask. The MLS-SE maintains one MLS entry for each destination IP address. All flows to a given destination IP address use this MLS entry. This mode is used if no access control lists (ACLs) are configured on any of the MLS-RP interfaces. source-destination-ip—The MLS-SE maintains one MLS entry for each source and destination IP address pair. All flows between a given source and destination use this MLS entry, regardless of the IP protocol ports. This mode is used if any of the MLS-RP interfaces has a standard access control list (ACL). ip-flow—The most-specific flow mask. The MLS-SE creates and maintains a separate MLS cache entry for every IP flow. An ip-flow entry includes the source IP address, destination IP address, protocol, and protocol ports. This mode is used if any of the MLS-RP interfaces has an extended ACL.

298

Chapter 5: Multilayer Switching

When a packet is Layer 3 switched from a source host to a destination host, the MLS-SE performs a packet rewrite based on information learned from the MLS-RP and stored in the MLS cache. If Host A and Host B are on different VLANs, and Host A sends a packet to the MLS-RP to be routed to Host B, the MLS-SE recognizes that the packet was sent to the MAC address of the MLS-RP. The MLS-SE checks the MLS cache and finds the entry matching the flow in question. When the MLS-SE receives the packet, it is formatted as shown in Figure 5-1.
Figure 5-1 The MLS-SE First Receives a Frame in a Flow with the Destination MAC Address of the MLS-RP Frame Header
Destination Source

IP Header
Destination Source TTL Checksum

Payload

Data MLS-RP MAC Host A MAC Host B IP Host A IP n calculation1

Checksum

The MLS-SE rewrites the Layer 2 frame header, changing the destination MAC address to the MAC address of Host B and the source MAC address to the MAC address of the MLSRP. These MAC addresses are stored in the MLS cache entry for this flow. The Layer 3 IP addresses remain the same, but the IP header Time-to-Live (TTL) is decremented, and the IP checksum is recomputed. 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 the virtual LAN (VLAN) of Host B, the destination VLAN is stored in the MLS cache entry, and Host B receives the packet. After the MLS-SE performs the packet rewrite, the packet is formatted as shown in Figure 5-2.
Figure 5-2 After a Frame Has Passed Through the MLS-SE and to the MLS-RP, It Returns to the MLS-SE with the Source MAC Address of the MLS-RP Frame Header
Destination Source

IP Header
Destination Source TTL Checksum

Payload

Data Host B MAC MLS-RP MAC Host B IP Host A IP n+1 calculation2

Checksum

Multilayer Switching

299

Figure 5-3 shows an IP MLS network topology. In this example, Host A is on Sales VLAN 1 (IP subnet 192.168.1.0), Host B is on Marketing VLAN 3 (IP subnet 192.168.3.0), and Host C is on Engineering VLAN 2 (IP subnet 192.168.2.0).
Figure 5-3 IP Addresses, MAC Addresses, Protocol Ports, and Destination VLANs Are Stored in the MLS Cache Source IP Address
192.168.1.1 192.168.1.1 192.168.2.1

Destination IP Address
192.168.3.1 192.168.2.1 192.168.1.1

Application

Rewrite Source/ Destination MAC Address
Db:Bb Db:Cc Db:Aa

Destination VLAN
Marketing Engineering Sales MAC = Bb

FTP HTTP HTTP MAC = Dd RSM

MAC = Aa

Host A
192.168.1.1

VLAN 1/Sales

VLAN 3
VLA

g /Marketin

Host B
192.168.3.1

N 2/M

arke

ting

MAC = Cc

Host C
Data 171.59.1.2:2000 Aa:Dd 192.168.2.1 Data 171.59.1.2:2000 Dd:Cc

When Host A initiates an FTP file transfer to Host B, an MLS entry for this flow is created as shown. The MLS-SE stores the MAC addresses of the MLS-RP and Host B in the MLS entry when the MLS-RP forwards the first packet from Host A through the switch to Host B. The MLS-SE uses this information to rewrite subsequent packets from Host A to Host B. Similarly, a separate MLS entry is created in the MLS cache for the HTTP traffic from Host A to Host C and for the HTTP traffic from Host C to Host A. The destination VLAN is stored as part of each MLS entry so that the correct VLAN identifier is used when encapsulating traffic on trunk links. MLS creates flows based on ACLs configured on the MLS-RP. IP MLS allows the network administrator to enforce ACLs on every packet of the flow without compromising IP MLS performance. When IP MLS is enabled, the MLS-SE handles standard and extended ACL permit traffic at wire speed. Traffic that is denied by an ACL is always handled by the MLS-RP, not the MLS-SE. Route topology changes and the addition or modification of ACLs are reflected in the IP MLS switching path automatically on the MLS-SE.

300

Chapter 5: Multilayer Switching

For example, when Host A wants to communicate with Host B, it sends the first packet to the MLS-RP. If an ACL is configured on the MLS-RP to deny access from Host A to Host B, the MLS-RP receives the packet, checks the ACL to see if the packet flow is permitted, and discards the packet based on the ACL. 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. If a flow is already being Layer 3 switched by the MLS-SE, and the ACL is created on the MLS-RP, the MLS-SE learns of the change through MLSP and immediately enforces security for the affected flow by purging it from the MLS cache. New flows are created based on the restrictions imposed by the ACL. Similarly, when the MLS-RP detects a routing topology change, the appropriate MLS cache entries are deleted in the MLS-SE. New flows are created based on the new topology.

MLS Operation
MLS operation consists of four distinct steps: Step 1 MLSP multicast hello packets are sent every 15 seconds to inform the MLS-SE(s) of the MLS-RP MAC addresses used on different VLANs and the routing and ACL information of the MLS-RP when the router boots or after changes in ACLs. When an MLS-SE hears the MLSP hello message indicating an IP MLS initialization, the MLS-SE is programmed with a unique 1-byte XTAG value for each MLS-RP and with the MLS-RP MAC addresses associated with each VLAN. Figure 5-4 illustrates this step.

Figure 5-4 Step 1: The Exchange of Hello Packets Identifying the MLS-RP to the MLS-SE Fast Ethernet 1/0

MLSP

Hello Packet

CAM XTAG 1 1 MAC 00-00-0C-11-11-11 00-00-0C-22-22-22 VLAN 1 2

1/1 Host A
CAM

2/1

3/1

Host B

Multilayer Switching

301

Step 2

In Figure 5-5, 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 destination MAC addresses and VLANs of the MLS-RP through MLSP. The MLS-SE learns the Layer 3 flow information (such as the destination IP address, source IP 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 MLS cache.

Figure 5-5 Step 2: The Creation of a Partial MLS Cache Entry Based on a Candidate Packet Fast Ethernet 1/0

Candidate Packet

Host A

Host B

The MLS-RP receives the packet, looks at its route table to determine how to forward the packet, and applies services such as ACLs and class of service (CoS) policy. The MLS-RP rewrites the MAC header, adding a new destination MAC address of Host B and its own MAC address, associated with Host VLAN, as the source. Step 3 The MLS-RP routes the packet to the destination host. When the switch receives the packet, the MLS-SE recognizes that the source MAC address belongs to the MLS-RP, that the XTAG matches that of the candidate packet, and that the packet’s flow information matches the flow for which the candidate entry was created. The MLS-SE considers this packet an enable packet and completes the MLS entry in the MLS cache. Figure 5-6 illustrates this step.

302

Chapter 5: Multilayer Switching

Figure 5-6 Step 3: Completion of the MLS Cache Entry Based on an Enable Packet Fast Ethernet 1/0

Enable Packet

Host A

Host B

Step 4

After the MLS entry has been completed, all Layer 3 packets in the same flow from the source host to the destination host are Layer 3/4 switched directly by the switch, bypassing the router. IP MLS is unidirectional. A separate Layer 3 switched path is created for traffic from Host B to Host A. Figure 5-7 illustrates this final step of MLS operation.

Figure 5-7 Step 4: The Layer 3 Switching of Subsequent Packets in the Same Flow Fast Ethernet 1/0

Shortcut and Rewrite Operation

NFF C Host A Host B

Finally, some Catalyst 5000 family switching line cards have onboard hardware that performs the rewrite (as opposed to rewrites on the Supervisor Engine), maximizing IP MLS performance. This performance enhancement is also used on the Catalyst 2926G series switch

Cisco Express Forwarding (CEF)

303

ports. When the line cards or individual ports perform the PDU header rewrites, this is called inline rewrite. With inline rewrite, frames traverse the switch bus only once. The Catalyst 5000 NFFC is a daughter card for the supervisor module that enables intelligent network services, such as high-performance multilayer switching and accounting and traffic management. The NFFC contains central rewrite engines (one per bus) to handle PDU header rewrites when inline rewrite is not an option. If the central rewrite engines are used, this means that a frame must traverse the bus twice—first with a VLAN tag for the source, on its way to the NFFC, and second with a VLAN tag for the destination, on its way to the egress port. To determine whether a port supports packet rewrite, use the show port capabilities command. If the port does not support inline rewrite, the packet rewrite is done in the Supervisor Engine. In summary, the basic MLS ingredients are the MLS-RP, MLS-SE, and MLSP. The MLS-SE creates flows in the MLS cache based on candidate and enable packets and ACLs configured on the MLS-RP. The result is wire-speed routing of packets based on criteria such as destination IP address, source IP address, and protocol port numbers.

Cisco Express Forwarding (CEF)
Cisco Express Forwarding (CEF) is a multilayer switching technology that allows for increased scalability and performance to meet the requirements of large enterprise networks. CEF has evolved to accommodate the traffic patterns realized by modern networks. These networks are characterized by an increasing number of short-duration flows. Shorter flows are common in environments with a high degree of web-based activity or other highly interactive types of traffic. As these types of applications continue to grow in popularity, a higher-performing and more scalable forwarding methodology is required to meet the needs of these environments. Figure 5-8 outlines the architectural model that CEF uses. The following sections compare MLS and CEF technologies and provide a detailed description of CEF operation.

Comparing MLS and CEF
MLS is a flow-based model that entails software path handling of the first packet in a given flow. This, in turn, creates a cache entry that can be used by subsequent packets in the flow for accelerated performance. Although this model works extremely well, it has been shown that in environments such as those found in the core of large enterprise networks, this model might not always prove optimal. Specifically, a flow-based model is suboptimal when an enterprise network has peering problems and when the number of flows is too great for the cache size.

304

Chapter 5: Multilayer Switching

Figure 5-8 CEF Architectural Model Cisco 7500 Series Router Running CEF

Route Processor
Routing Table Forwarding Information Base Adjacency Table

Interface Card E1 E2 E1

Interface Card E2 E1

Interface Card E2

Cisco Catalyst Switches

Anytime a large number of routers are controlled by a large number of independent organizations, you might encounter situations in which some devices negatively affect the stability of other devices. In this case (a peering relationship), router instability or flapping routes lead to the purging of previously cached data. In a flow-based model, the loss of cached entries requires that the first packet of a given flow be handled within the software path. In a peering situation, such as that required to support the core of an enterprise network, this means that potentially tens of thousands of flows would need to be relearned or cached by the software path to enable further hardware acceleration. However, it is difficult to scale software-based forwarding to simultaneously handle tens of thousands of concurrent flows per second. So stability, and the capability to withstand route flaps, are critical. The CEF-based forwarding model is designed to handle these situations gracefully and to minimize the impact of these events on network stability. Another area in which a flow-based model encounters scalability challenges is with respect to the actual number of flows that could be cached in the necessary lookup tables. Recall that a flow entry can be expressed in one of several ways, including destination-ip, source-destination-ip, and ip-flow. The greater the granularity selected, the more specific the flow information will be but the lower the access and storage efficiency. For example, multiple entries are likely to map to a given entry for a destination-ip flow (for example, many clients all accessing a single server). When an ip-flow mode is selected, full protocol and port information is stored in addition to the full source and destination IP addresses. This, in turn, reduces the likelihood that any two entries will be capable of sharing

Cisco Express Forwarding (CEF)

305

a given flow entry. In a large percentage of the enterprise networks in existence today, however, this is not cause for concern. The number of flows that must be supported increases as networks grow (such as in a service provider environment), consequently leading to a situation in which the number of entries exceeds the available flow cache table space. This flow cache table space limitation leads to suboptimal packet handling, in that packets not matched in the flow cache must be processed in software. One option to correct the problem is to change the flow mask to specify a less-specific mask, such as destination-ip. This solution increases cache efficiency, but it too has its limitations, beyond which software processing will be required. Although the simple answer to the problem of exceeding the size of the flow cache would appear to be increasing the number of possible entries available, in practice it is not so simple. There is a direct relationship between the speed of hardware-based forwarding and the size of the flow cache. Simply increasing the size of the flow cache does not guarantee that the appropriate lookup engine can parse the table sufficiently fast enough to forward flows in hardware at high speed. It would then seem logical to increase the speed of the lookup engine to work against the increased flow cache table. To a certain extent, this approach could be made to work, but network administrators would have to continually upgrade equipment, an extremely costly and inefficient solution. A cache-based forwarding model relies on actual traffic flows to establish cache entries for expedited forwarding. In a classical enterprise environment, this model has proven highly effective, because traffic patterns associate a large number of sources with a much smaller number of destinations. An example is a traditional centralized server farm, in which a large number of clients send traffic to and receive traffic from a much smaller number of servers. When comparing these traffic patterns to those of the Internet, it is far less likely to achieve the many-to-one ratio typified by the enterprise data center. Because the Internet is a global entity, it becomes increasingly difficult to maintain the flow cache and to ensure the integrity of the data therein. This means that a certain amount of cache flux must be expected in terms of the maintenance required to keep the state of the flow cache current. The variation in cache state is reflected in terms of CPU utilization. With flow-cached models, a complete forwarding table must be maintained for the proper handling of first packets by the CPU or packets that for some other reason are incapable of being processed in hardware. After the CPU makes a forwarding decision (part of which involves a lookup against the routing table), an entry is made in the flow cache table, and subsequent packets are handled in hardware. A CEF-based mechanism experiences greatly reduced challenges presented by flow caching models, resulting in an increase in scalability. All packets, including the first packet in a given

306

Chapter 5: Multilayer Switching

flow, are handled in hardware. A routing table is still maintained by the router CPU, but two additional tables are created in the CEF-based model:

Forwarding Information Base (FIB) table—The FIB table is a copy of the forwarding information from the routing table. The FIB table contains the minimum information from the routing table necessary to forward packets. The FIB table does not contain any routing protocol information. Adjacency table—The adjacency table maintains a database of node adjacencies (two nodes are said to be adjacent if they can reach each other through a single Layer 2 hop) and their associated Layer 2 MAC rewrite or next-hop information.

The NetFlow table is a third table. It isn’t required for CEF function, but it provides network accounting data and is updated in parallel with the CEF-based forwarding mechanism provided by the FIB and adjacency tables. By the router or switch performing a high-speed lookup against the FIB and adjacency tables, a forwarding decision along with the appropriate rewrite information can be accessed in a highly efficient and consistent manner, while also providing a mechanism offering a high degree of scalability.

CEF Support on Cisco Devices
Although high-end Cisco routers have offered support for CEF for several years now, some differences between the CEF implementations on Catalyst switches and Cisco routers exist. Specifically, both implementations provide the following:
■ ■ ■ ■

High-speed forwarding based on a “longest address match” lookup Equal-cost path load balancing Reverse Path Forwarding (RPF) checks Invalidation of less-specific routes

The CEF implementation on the Catalyst 6000 family also adds the following:
■ ■ ■

Support for IP multicast Support for IPX forwarding Hardware-based forwarding of rates up to 210 Mbps in distributed CEF mode

Supported features of the CEF implementation only on the Cisco routers include the following:
■ ■ ■ ■

The capability to turn off CEF-based forwarding CEF per-prefix and per-prefix-length accounting Accounting data from load-sharing paths Per-packet load balancing

Cisco Express Forwarding (CEF)

307

CEF is supported on the following Cisco devices:
■ ■ ■ ■ ■ ■ ■

Catalyst 8500 switch routers Catalyst 3550 switches Catalyst 2948G-L3 switches Catalyst 4000 switches Catalyst 6000 switches Cisco routers running Cisco IOS software Release 12.2 or later Some routers, such as the 7500 series, beginning with Cisco IOS software Release 12.0

The Catalyst 4000 switch supports CEF in the following combinations:
■ ■ ■

With the Layer 3 Services Module With the Access Gateway Module With Supervisor Engine III or Supervisor Engine IV

Figure 5-9 illustrates the CEF architecture for the Catalyst 4000 family Supervisor Engine III.
Figure 5-9 The Catalyst 4000 Family Supervisor Engine III and IV Provide CEF-Based Layer 2/3/4 Switching

Packet Memory

Spanning Tree Memory FFE FFE

Forward CAM

Forward Memory

Input CAM

Queue Memory

Multicast Expansion Table

Output CAM

CPU FFE = Fast Forwarding Engine

The remainder of this chapter focuses on CEF technology in the context of Catalyst 6000 family switches. In particular, the Catalyst 4000 Supervisor Engine III multilayer switching mechanism does rely on CEF, but the architecture and Layer 2/3/4 packet flow methodology are similar, but not identical, to that of the Catalyst 6000. For Catalyst 6000 family switches, the CEF hardware requirements are Supervisor Engine II, MSFC2, and PFC2, or a Catalyst 6500 series switch with Supervisor Engine 720.

308

Chapter 5: Multilayer Switching

CEF Operation
Understanding how CEF functions on a Catalyst 6000 Supervisor Engine II requires a basic understanding of the architecture of the Supervisor Engine II, shown in Figure 5-10.
Figure 5-10 The Catalyst 6000 Family Supervisor Engine II with the MSFC2 and PFC2 Have CEF-Based Architectures
GBIC GBIC MSFC 2 Packet Pursuing Blue I/F & EOBC IOS Router (R7000)

PFC 2
Adjacency Table

L2 Forwarding Table ACL Table TCAMs

Fabric & Bus Interface

FB Table

NetFlow Table

L3 CEF ASIC

L2 Forwarding Engine QoS/ACL Engine

L2L3 Multicast Replication ASIC

Pianancle LC-Rbus LC-Dbus

BUS I/F EOBC

NMP CPU Bus Interface ASIC

Supervisor 2 Base Board

Switch Fabric

The Supervisor Engine II consists of three primary components:

Supervisor base board—The Supervisor base board provides connectivity to the switching fabric, 32-Gbps bus, multicast replication ASIC, Network Management Processor (NMP), and two Gigabit Interface Converter (GBIC)-based Gigabit Ethernet ports. In addition, the base board offers connectors for attaching the PFC2 and MSFC2 daughter boards. Policy Feature Card 2 (PFC2)—PFC2 is a factory-installed daughter card of a Supervisor Engine II. It provides an array of ASICs to enable all hardware-based forwarding. The Layer 3 forwarding engine ASIC provides the actual CEF function via its inherent logic. It also provides access to the various Layer 3 tables (the FIB, adjacency table, and NetFlow table). In addition, the PFC2 daughter card also contains the ASICs that deliver hardware-based access control lists and QoS mechanisms. Multilayer Switching Feature Card 2 (MSFC2)—The MSFC2 is an optional daughter card that provides a CPU for the handling of all Layer 3 control-plane activities. The control plane is the portion of the hardware architecture that handles route calculations. The MSFC2 is responsible for handling any functions that cannot be handled in the

Cisco Express Forwarding (CEF)

309

hardware elements of the PFC2, as well as the processing of all routing protocol activities, such as OSPF and Border Gateway Protocol (BGP) routing updates. The MSFC2 is also responsible for populating the IP routing table, FIB table, and adjacency table. Of these three elements, the Supervisor base board and PFC2 are mandatory components, and the MSFC2 element is optional (although it is effectively required for Layer 3 switching, because it contains the CPU for the population of the CEF tables). The CPU on the MSFC2 daughter card runs all instances of whatever configured routing protocols are required. In addition, the CPU handles packets that cannot be processed in hardware. The MSFC2 is a Cisco IOS software-based router, and it is configured as such. The configuration parameters are identical to those on a Cisco 7200 series router. With the Supervisor Engine II, CEF is enabled by default. In fact, it cannot be disabled. For most common CEF functions, no specific configuration is required to enable CEF beyond the standard configuration of routing protocols, network interface addressing, and so on. When the router is initialized, a routing table is constructed based on information in the router software configuration (such as static routes, directly connected routes, and dynamically learned routes via routing protocol exchanges). After the routing table is constructed, the CPU creates the FIB and adjacency tables automatically. The FIB and adjacency tables represent the data present within the routing table in a manner in which optimal forwarding can be performed. Unlike a flow cache, which is based on traffic flow, the CEF table is based on the network topology. When a packet enters the switch, the switch Layer 3 forwarding engine ASIC performs a longest-match lookup based on the destination network and the most-specific netmask. For example, instead of switching based on a destination address of 172.31.10.3, the PFC2 looks for the network 172.31.10.0/24 and switches to the interface connecting to that network. This scheme is highly efficient and does not involve the software for anything other than the routing table and prepopulation of the FIB table. In addition, cache invalidation because of a route flap does not occur. As soon as a change in the routing table is made, all CEF tables are updated immediately. This makes CEF more adaptable to changes in the network topology.

CEF Forwarding Information Base
The CEF FIB table consists of a four-level hierarchical tree, as shown in Figure 5-11. The four levels are derived from the fact that IPv4 uses a 32-bit address. Each level of the hierarchy is based on 8 of the possible 32 bits. CEF relies on a longest-match forwarding algorithm, meaning that the tree is searched in descending order until the “longest match,” or greatest number of bits, is matched. The FIB tree is represented hierarchically, with the least-specific address at the top of the tree and the most-specific address at the bottom. Each leaf is based

310

Chapter 5: Multilayer Switching

on an 8-bit boundary, with more-specific entries in descending order. This tree (commonly known as a 256-way radix tree) provides a highly efficient mechanism for rapid lookups, which ensures that minimal latency is incurred during the lookup process. This tree also provides for a highly scalable architecture in that IPv4 addressing can be completely accounted for with a minimal trade-off of performance versus table efficiency. Each leaf offers a pointer to the appropriate next-hop entry in the adjacency table.
Figure 5-11 The CEF FIB Consists of a Four-Level Hierarchical Tree
Root 1.0.0.0

Leaf 1.1.0.0

Leaf 1.2.0.0

Leaf 1.3.0.0

1.1.10.0

1.3.12.0

Leaf 1.1.1.0

Leaf 1.2.2.32

Leaf 1.2.1.0

Leaf 1.3.1.0

Leaf 1.1.1.32

Leaf 1.2.2.0

Leaf 1.2.1.64

Leaf 1.2.1.96

Leaf 1.3.1.32

1.1.1.32

1.2.1.77

1.2.1.100

The CPU of the MSFC2 builds the FIB table from the IP routing table. The appropriate IP routing protocols first resolve the IP routing table, at which point the CEF process is invoked, and the corresponding FIB and adjacency tables are constructed. The FIB table is maintained separately from the routing table. The routing table contains additional information that is important for the purposes of routing protocols but not for the actual forwarding of packets. The FIB cannot determine which routing protocol created the route. The FIB and adjacency tables are optimized to provide only the information that is necessary for a forwarding decision to be made, and nothing more. It is also important to note that recursive routes are resolved when the FIB table is built. This resolution of recursive routes has classically been a CPUintensive event in non-CEF implementations. If the FIB table becomes full, subsequent entries are compared to the existing entries, and the more-specific entries are maintained at the expense of less-specific entries. This method is necessary to ensure that proper forwarding is maintained. For example, the less-specific route of 1.2.0.0 is not specific enough to ensure proper routing to 1.2.1.0. To view the contents of the FIB table, use the show ip cef detail command from the MSFC2.

Cisco Express Forwarding (CEF)

311

CEF Adjacency Table
The adjacency table contents are fundamentally a function of the Address Resolution Protocol (ARP) process, whereby Layer 2 addresses are mapped to corresponding Layer 3 addresses. When the router issues an ARP request, a corresponding reply is received, and a host entry is added to the adjacency table to reflect this. In addition, the router can glean next-hop routers from routing updates and make entries in the adjacency table to reflect this. This transaction lets the router build the next-hop rewrite information necessary for Layer 3 packet forwarding. By having this data already stored in a table, CEF can perform highly efficient and consistent forwarding, because no discovery process is required. Use the show ip cef command to view the contents of the CEF adjacency table from the MSFC2. Use the show ip cef summary command to display a brief overview of the CEF process. The output from this command shows information, such as the total number of adjacencies and routes. The third table used by CEF is the NetFlow table. It isn’t discussed here, because it compiles network accounting data and does not play a role in CEF’s PDU header rewrite mechanism.

Packet Flow for Layer 2 and Layer 3 Forwarding Decisions
This section details the data flow through the Layer 2 and Layer 3 forwarding process on a Catalyst 6000 Supervisor Engine II. The process is fundamentally unchanged between a Layer 2 and Layer 3 decision and is a function of whether the Layer 3 data exists. In other words, if the MSFC2 is present, the Layer 3 path is valid. Otherwise, forwarding decisions are made based purely on Layer 2 forwarding information. This discussion details the data path for Layer 2 and Layer 3 lookups. Figure 5-12 illustrates the CEF forwarding process. The following list describes each step in detail.
Figure 5-12 The Layer 3 Portion of CEF Relies on the FIB and Adjacency Tables
Adjacency Statistics 6b Layer 3 Forwarding 3a Adjacency Table 4a 3b 2b 5 4b 2e NoFlow Table 6c NoFlow Statistics 1 Constellation Bus Interface Data Bus Results Bus 1 7 6a 2c QoS TCAM 4c ACL TCAM Layer 2 Forwarding QoS/ACL

2a Layer 2 Table

2d FIB Table

312

Chapter 5: Multilayer Switching

Step 1 Step 2

The Layer 3 forwarding engine and Layer 2 forwarding engine ASICs receive the packet headers from the data bus. The following operations occur in parallel: a. The Layer 2 forwarding engine performs a lookup on the destination MAC address. b. The Layer 2 forwarding engine ASIC performs any necessary input security ACL lookups. c. The Layer 2 forwarding engine ASIC performs any necessary input QoS/ ACL lookups. d. The Layer 3 forwarding engine ASIC performs a FIB table lookup. e. The Layer 3 forwarding engine ASIC performs a NetFlow table lookup.

Step 3

The following operations occur in parallel: a. The input ACL and QoS results from the Layer 2 forwarding engine ASIC are forwarded to the Layer 3 forwarding engine ASIC. b. The Layer 3 forwarding engine ASIC sends the destination VLAN information for the packet to the Layer 2 forwarding engine ASIC.

Step 4

The following operations occur in parallel: a. The Layer 3 forwarding engine ASIC performs the adjacency lookup. b. The Layer 2 forwarding engine ASIC performs the outbound security ACL lookup. c. The Layer 2 forwarding engine ASIC performs the outbound QoS/ACL lookup.

Step 5 Step 6

The Layer 2 forwarding engine sends the results of the security and QoS/ACL lookups to the Layer 3 forwarding engine ASIC. The following operations occur in parallel: a. The Layer 3 forwarding engine ASIC generates the rewrite result and sends it to the Layer 2 forwarding engine ASIC. b. The Layer 3 forwarding engine ASIC updates the adjacency table statistics as necessary. c. The Layer 3 forwarding engine ASIC updates the NetFlow table statistics as necessary.

The Layer 2 forwarding engine looks up the destination MAC address received from the Layer 3 forwarding engine ASIC. The Layer 2 forwarding engine then chooses between a

Cisco Express Forwarding (CEF)

313

Layer 2 and a Layer 3 result and sends the result to the results bus, an out-of-band controlplane mechanism used for this purpose. Figure 5-13 summarizes the CEF process with a traffic flow from a source workstation (on the right side of the figure) to a destination workstation (on the left side of the figure). The critical elements of the diagram are the FIB and adjacency entries of the intermediate routers along the path. All of the IP addresses and MAC addresses referenced by the FIB and adjacency tables are indicated as the packet traverses the network.
Figure 5-13 Summarization of the CEF Process with Source-to-Destination Traffic Flow
Traffic Flow 172.17.9.1 172.17.9.2 172.18.8.2 172.18.8.1

E0
172.16.10.1

E1

E0

E1

E0

E1
172.19.7.2

FIB Entry 172.16.10 0/24 Nexthop Connected Destination IP Address 172.16.10.10 MAC Address 0080.AB12.C821 Adjacency D base 172.16.10.10 0080.AB12.C821 Router - 1 MAC Address or E1 0080.0C00.0001 IP Address of E1 172.17.9.1 IP Address of E0 172.16.10.1

FIB Entry 172.16.10 0/24 Nexthop 172.17.9.1 Adjacency D base 172.17.9.1 0080.0C00.0001 Router - 2 MAC Address or E1 0080.0C00.0002 IP Address of E1 172.18.8.2 IP Address of E0 172.17.9.2

FIB Entry 172.16.10 0/24 Nexthop 172.18.8.2 Adjacency D base 172.16.8.2 0080.0C00.0002 Router - 3 MAC Address or E1 0080.0C00.0003 IP Address of E1 172.19.7.2 IP Address of E0 172.18.8.1 Source: Sends IP Data to 172.16.10.10 MAC Destination 0800.0C00.0003

Additional Benefits of CEF-Based Forwarding
In addition to the benefits just described, CEF-based forwarding provides several other benefits:
■ ■ ■ ■ ■ ■

Enhanced scalability Availability Network stability Load balancing ACL processing Multicasting

Many of these benefits are supported only on the Catalyst 6500 series (a subset of the Catalyst 6000 family).

314

Chapter 5: Multilayer Switching

The following sections briefly describe some of these additional benefits.

Scalability
CEF increases scalability not only by the raw number of available FIB entries, but also by the replication of CEF-based forwarding technology on a per-slot basis. This distributed capability (dCEF), illustrated in Figure 5-14, allows the Catalyst 6500 series switches and Cisco 12000 series routers to provide sufficient forwarding capabilities for the largest of networks. The Catalyst 6500 series, when equipped with a Supervisor Engine II, can provide as many as 256,000 entries in the FIB table and 256,000 entries in the adjacency table. These entries are not stored via a traditional hashing algorithm, as is the case with MLS.
Figure 5-14 Cisco 12000 Series Routers Use Distributed CEF Cisco 12000 Series Router Running Distributed CEF Route Processor
Routing Table Forwarding Information Base Adjacency Table

IPC

Line Card FIB Adjacency Table FIB

Line Card Adjacency Table FIB

Line Card Adjacency Table

OC-12

OC-3

FE

SER

T3

FDDI

GSR

Cisco 7200 and Cisco 7500 Series Routers

Cisco 7200 and Cisco 7500 Series Routers

Availability
Although the Catalyst 6000 family offers a breadth of features to support high availability, the addition of CEF further increases the availability and stability demanded in today’s enterprise networks. As networks increase in size, a natural side effect is the increased chance of instability and change. Network instability, whether caused by failures, configuration changes, or bursty traffic patterns, can have a tremendous impact on routing implementations, which rely on heavy CPU computations for routing-table maintenance. Because CEF employs a mechanism by which the forwarding information is constructed based on the network topology rather

MLS and CEF Configuration Tasks

315

than a representation of traffic within the network, the CPU is no longer burdened by having to set up large numbers of entries. This also means that network availability is not directly linked to the actual size of the network.

Access Control Lists
Another manner in which various CEF implementations vary is with respect to their support of ACLs. In the case of the Catalyst 6500 series, ACLs can be handled in hardware for most common configurations. CEF-based forwarding does not have any impact on this functionality. The most notable ACL options that disable hardware processing for a given ACL are the use of the log keyword or enabling “IP unreachables” on a given interface (which enables the sending of Internet Control Message Protocol (ICMP) unreachable messages).

Multicasting
The CEF implementation on the Catalyst 6000 family also includes support for IP multicasting. The FIB table can hold as many as 16,000 IP multicast entries.

Summary of CEF Benefits
In conclusion, CEF provides high performance and high scalability for the largest and most demanding networks. The Supervisor Engine II offers the scalability and performance requirements necessary for both large enterprise and service-provider environments. Cisco has also managed to maintain the rich accounting support of the MLS model (using NetFlow features) while introducing CEF-based forwarding.

MLS and CEF Configuration Tasks
MLS configuration involves two components: configuring the MLS-RP and configuring the MLS-SE. CEF configuration is probably the easiest technology to configure on Cisco devices. Configuration involves only turning on the feature, and it is on by default on most platforms and with most newer IOS releases. This section also discusses monitoring and verifying MLS and CEF.

MLS-RP Configuration
Configuring MLS support on an MLS-RP has five basic steps: Step 1 Configure the MLS-RP to globally enable MLS. This is analogous to enabling IPX or multicast routing on a router. The global configuration Cisco IOS software command to enable MLS is mls rp ip. A Catalyst 6000 with Supervisor Engine I and an MSFC has IP MLS globally enabled by default.

316

Chapter 5: Multilayer Switching

Step 2

Determine which router interfaces will be used as IP MLS interfaces, and add those interfaces to the same VLAN Trunking Protocol (VTP) domain as the MLS-SE. Remember that router interfaces will be VLAN interfaces (not physical interfaces) on the RSM, RSFC, and MSFC. The complete syntax for the command to add an IP MLS interface to a VTP domain is mls rp vtp-domain [domain_name]. On ISL or 802.1Q trunks, enter the mls rp vtp-domain command on the primary interface (not on the individual subinterfaces). All subinterfaces on the primary interface inherit the VTP domain assigned to the primary interface. The command mls rp vtp-domain is also used on physical interfaces configured as access ports (ports with only one VLAN association). On the RSFC, RSM, and MSFC, this command is entered on each VLAN interface participating in MLS.

Step 3

For Layer 3 interfaces that are not trunk ports and on which IP MLS support is desired, start by verifying that the interface has been assigned to a VLAN (as an access port). Then assign a VLAN ID to the IP MLS interface with the mls rp vlan-id [vlan_id_num] interface command. Enable IP MLS on the interfaces participating in IP MLS with the mls rp ip command. This is the same command used in global configuration mode, but here it is applied at the interface level. In the case of an ISL or 802.1Q trunk, this command must be configured on all subinterfaces (it is not entered on the physical interface itself). On the MSFC, RSM, and RSFC, this command is entered on VLAN interfaces. Specify an MLS-RP interface as an MLS-RP management interface. MLSP runs on the management interface, sending hello messages, advertising routing changes, and announcing VLANs and MAC addresses of interfaces participating in MLS. At least one router interface must be configured as a management interface (more than one is permitted, but this introduces a proportional increase in overhead). If a management interface is not specified, IP MLS does not function.

Step 4

Step 5

Also, the MLS-SE must have an active port in at least one VLAN that has a corresponding router interface configured as a management interface. The interface command to specify an MLS-RP interface as a management interface is mls rp management-interface, as shown in Example 5-1. In the case of an ISL or 802.1Q trunk, this command is applied to a particular subinterface, not to the interface itself.

MLS and CEF Configuration Tasks

317

Example 5-1 Configuring MLS on an MLS-RP Is Fairly Complicated
! Step 1: Router(config)#mls rpip ! Step 2: Router(config)#interface fa2/0 Router(config-if)#mls rp vtp-domain Cisco ! Step 3: not applicable because interface fa2/0 is a trunk interface ! Step 4: Router(config-if)#interface fa2/0.1 Router(config-subif)#encapsulation dot1q 1 Router(config-subif)#ip address 10.1.1.1 255.255.255.0 Router(config-subif)#mls rip ip ! Step 5: Router(config-subif)#mls rp management-interface

Finally, configuring output ACLs on MLS-RP interfaces works seamlessly with MLS, meaning that MLS cache entries are created that reflect the desired behavior of the ACL while still providing wire-speed packet switching. On the other hand, input ACLs on MLS-RP interfaces force every packet to be routed by the MLS-RP. To enable MLS to cooperate with input ACL, enter the mls rp ip input-acl global configuration command.

MLS-SE Configuration
The configuration is platform-dependent for the MLS-SE. IP MLS is enabled by default on Catalyst 5000 family and Catalyst 2926G series switches. If the MLS-RP is an RSM or RSFC installed in the Catalyst 5000 chassis, there is no need to configure the switch for MLS. Configuration of the switch is required only in the following circumstances:

When an external router is the MLS-RP (this is always the case with Catalyst 2926G series switches) To change the IP MLS aging time parameters or packet threshold values To enable NetFlow Data Export (NDE) to monitor all IP MLS intersubnet traffic through the NFFC

■ ■

Similarly, IP MLS is enabled by default on Catalyst 6000 family switches. Recall that the Catalyst 6000 does not support an external MLS-RP. The only options for MLS-RP are

318

Chapter 5: Multilayer Switching

the MSM and the MSFC. Configuration of the switch is required only in the following circumstances:
■ ■

To specify MLS aging time parameters or packet threshold values To set the minimum IP MLS flow mask

Assuming that a Catalyst 5000 or Catalyst 2926G switch (which are CatOS, or set-based, switches) is connected to an external MLS-RP, the configuration proceeds as follows: Step 1 Enable MLS on the switch with the set mls enable command. When IP MLS is enabled on the switch, the switch (MLS-SE) starts to process MLSP messages from the MLS-RPs and starts Layer 3 switching. IP MLS is enabled by default on the MLS-SE, so this step is necessary only if MLS has been disabled with the set mls disable command. Specify the external router(s) participating in MLS. Before doing so, enter the show mls rp command on the router to identify the MLS-RP IP address. Use the displayed address when entering the set mls include ip_addr command on the switch, the command that specifies the external router(s) participating in MLS. The MLS-SE does not process MLSP messages from external routers that have not been included as MLS-RPs. Also, the MLS-SE configured in a scenario where the MLS-RP is not an external router doesn’t need the set mls include command, as shown in Example 5-2.

Step 2

Example 5-2 Configuring MLS on an MLS-SE Requires Just One or Two Commands, Depending on Whether the MLS-RP Is Internal or External
Switch> (enable)set mls enable Switch> (enable)set mls include 10.1.1.1

Configuring MLS Optional Parameters
In addition to the MLS-RP and MLS-SE commands discussed up to this point, a few optional MLS parameters are available. Two of these parameters let you configure MLS aging time and minimum flow mask. These values can be adjusted to tune MLS efficiency.

MLS Aging Time
The IP MLS aging time determines the time before an MLS entry is aged out. The default is 256 seconds. The aging time can be configured for a value in the range of 8 to 2032 seconds, in 8-second increments. Any aging-time value that is not a multiple of 8 seconds is adjusted to the closest one. For example, a value of 65 is adjusted to 64, and a value of 127 is adjusted to 128. Other events might cause MLS entries to be purged, such as routing changes or a change in link state (MLS-SE link down).

MLS and CEF Configuration Tasks

319

To specify the IP MLS aging time, use the CatOS set mls agingtime [agingtime] command in privileged mode. Another useful MLS cache aging parameter is the fast aging time. To specify the IP MLS fast aging time and packet threshold, use the command set mls agingtime fast [fastagingtime] [pkt_threshold] in privileged mode. The default fastagingtime value is 0 (no fast aging). The fastagingtime value can be set to 32, 64, 96, or 128 seconds. Any fastagingtime value that is not configured exactly as the indicated values is adjusted to the closest one. The pkt_threshold value can be set to 0, 1, 3, 7, 15, 31, or 63 packets. Typical values for fastagingtime and pkt_threshold are 32 seconds and 0 packets (no packets switched within 32 seconds after the entry is created). Cisco recommends keeping the number of MLS entries in the MLS cache to less than 32,000 entries. If the number of MLS entries amounts to more than 32,000, some flows are sent to the router. To help keep the MLS cache size below 32,000, enable the IP MLS fast aging time. The IP MLS fast aging time applies to MLS entries that have no more than pkt_threshold packets switched within fastagingtime seconds after it is created. A typical cache entry that is removed is the entry for flows to and from a Domain Name System (DNS) or TFTP server; the entry might never be used again after it is created. Detecting and aging out these entries saves space in the MLS cache for other data traffic. If IP MLS fast aging time needs to be enabled, initially set the value to 128 seconds. If the size of the MLS cache continues to grow over 32 KB, decrease the setting until the cache size stays below 32 KB. If the cache continues to grow over 32 KB, decrease the normal IP MLS aging time.

Minimum IP MLS Flow Mask
The minimum granularity of the flow mask for the MLS cache is configured on the MLS-SE. The actual flow mask used consists of the granularity specified. If a more-specific flow mask is configured, the number of active flow entries increases. To limit the number of active flow entries, you might need to decrease the MLS aging time. If ACLs are not configured on any MLS-RP, the IP MLS flow mask on the MLS-SE is destination-ip by default (as discussed in the earlier section “MLS Flows”). However, an administrator can force the MLS-SE to use a particular flow mask granularity by setting the minimum IP MLS flow mask using the set mls flow {destination | destination-source | full} command in privileged mode (again, these are CatOS commands). Depending on the MLS-RP configuration, the actual flow mask used might be more specific than the specified minimum

320

Chapter 5: Multilayer Switching

flow mask. For example, if the minimum flow mask of destination-source is configured, but an MLS-RP interface is configured with IP extended ACLs, the actual flow mask used is full (ip-flow). The set mls flow command purges all existing MLS cache entries and affects the number of active entries on the MLS-SE, so use this command carefully when applying it to a production environment.

MLS Configuration Example
This example details the configuration of IP MLS for the topology shown in Figure 5-15.
Figure 5-15 A 7505 Router (MLS-RP) Connects Via an 802.1Q Trunk to an MLS-SE (a Catalyst 5509 with a Supervisor Engine III and NFFC in This Case)
Cisco 7505 (MLS-RP)
Subinterface: fa2/0.1 10.1.1.1 fa2/0 10 10 1.10.1 fa2/0.20 10.1.20.1 fa2/0.30 10.1.30.1

fa2/0

Source S2 10.1.30.201

Catalyst 5505 (Switch B)
3/1 1/1

Catalyst 5509 with NFFC IEEE 802.1Q (Switch A, MLS-SE) Trunk Link
1/2 3/1 1/3

Catalyst 5505 (Switch C)
1/1

4/1

Source S1 10.1.10.100

IEEE 802.1Q Trunk Link

IEEE 802.1Q Trunk Link

3/1

Destination D1 10.1.30.200 VLAN 10 Subnet 10.1.10.0/24 Destination D2 10.1.20.200 VLAN 20 Subnet 10.1.20.0/24 VLAN 30 Subnet 10.1.30.0/24

A Cisco 7505 router serves as the MLS-RP, and a Catalyst 5509 with a Supervisor Engine III and an NFFC (Switch A) serves as the MLS-SE. An IEEE 802.1Q trunk connects the two devices participating in MLS. The IP MLS network topology shown in Figure 5-15 includes two Catalyst 5505 switches connecting via 802.1Q trunks to the MLS-SE (Switch B and Switch C). The 5505s do not play a role in MLS. The network is configured as follows:

There are four VLANs (IP subnetworks): — VLAN 1 (the management VLAN), subnet 10.1.1.0/24 — VLAN 10, subnet 10.1.10.0/24 — VLAN 20, subnet 10.1.20.0/24 — VLAN 30, subnet 10.1.30.0/24

MLS and CEF Configuration Tasks

321

The MLS-RP is a Cisco 7505 router with a Fast Ethernet interface (interface FastEthernet 2/0) The subinterfaces on the router interface have these IP addresses: — FastEthernet 2/0.1—10.1.1.1 255.255.255.0 — FastEthernet 2/0.10—10.1.10.1 255.255.255.0 — FastEthernet 2/0.20—10.1.20.1 255.255.255.0 — FastEthernet 2/0.30—10.1.30.1 255.255.255.0

A standard output ACL is configured on subinterface FastEthernet 2/0.20 (the interface in VLAN 20) on the MLS-RP. The ACL denies all traffic from VLAN 30. Switch A, the MLS-SE, is a Catalyst 5509 switch with Supervisor Engine III and the NFFC. Switch B and Switch C are Catalyst 5505 switches. Switch A is the VTP server in domain “Corporate.” Switch B and Switch C are VTP clients.

■ ■ ■

The next sections detail the inter-VLAN switching path both before and after IP MLS operation.

Operation Before IP MLS
The operation before IP MLS operation is characterized as follows:
1. Before IP MLS is implemented, when the source host S1 (on VLAN 10) transmits

traffic destined for server D1 (on VLAN 30), Switch B forwards the traffic (based on the Layer 2 forwarding table) to Switch A over the 802.1Q trunk link.
2. Switch A forwards the packet to the router over the 802.1Q trunk. 3. The router receives the packet on the VLAN 10 subinterface, checks the destination

IP address, and routes the packet to the VLAN 30 subinterface.
4. Switch A receives the routed packet and forwards it to Switch C. 5. Switch C receives the packet and forwards it to destination server D1. This process is

repeated for each packet in the flow between source host S1 and destination server D1.
6. When source host S2 sends traffic to destination server D2, Switch C forwards the

packets over the 802.1Q trunk to Switch A.
7. Switch A forwards the packet to the MLS-RP.

322

Chapter 5: Multilayer Switching

8. The MLS-RP receives the packet on the VLAN 30 subinterface. Because the standard

ACL configured on the outgoing VLAN 20 subinterface denies all traffic from VLAN 30, the router drops the traffic to Destination D2 from Source S2.
9. Any subsequent traffic from Source S2 for Destination D2 also reaches the router and is

dropped.

Operation After IP MLS
The operation after IP MLS operation is characterized as follows:
1. After IP MLS is implemented, when the source host S1 transmits traffic destined for

destination server D1, Switch B forwards the traffic (based on the Layer 2 forwarding table) to Switch A (the MLS-SE) over the 802.1Q trunk link.
2. When the first packet enters Switch A, a candidate flow entry is established in the MLS

cache. Switch A forwards the packet to the MLS-RP over the 802.1Q trunk.
3. The MLS-RP receives the packet on the VLAN 10 subinterface, checks the destination

IP address, and routes the packet to the VLAN 30 subinterface.
4. Switch A receives the routed packet (the enable packet) and completes the flow entry in

the MLS cache for destination IP address 10.1.30.200. Switch A forwards the packet to Switch C, where it is forwarded to destination server D1.
5. Subsequent packets destined for IP address 10.1.30.200 are multilayer-switched by the

MLS-SE based on the flow entry in the MLS cache. For example, subsequent packets in the flow from source host S1 are forwarded by Switch B to Switch A (the MLS-SE). The MLS-SE determines that the packets are part of the established flow, rewrites the packet headers, and switches the packets directly to Switch C, bypassing the router. Because a standard ACL is applied on subinterface FastEthernet 2/0.20, the MLS-SE must use the source-destination-ip flow mask for all MLS cache entries. When source host S2 sends traffic to destination server D2, Switch C forwards the packets over the 802.1Q trunk to Switch A. Switch A forwards the candidate packet to the MLS-RP, which receives it on the VLAN 30 subinterface. Because the standard ACL configured on the outgoing VLAN 20 subinterface denies all traffic from VLAN 30, the router drops the traffic to Destination D2 from Source S2. Switch A never receives the enable packet for the flow on VLAN 20, and no MLS cache entry is completed for the flow. Any subsequent traffic from Source S2 for Destination D2 also reaches the router and is dropped.

MLS and CEF Configuration Tasks

323

MLS-RP Configuration
Example 5-3 shows the MLS-RP configuration for the network shown in Figure 5-15, using the five steps outlined in the earlier section “MLS-RP Configuration.”
Example 5-3 The MLS-RP Configuration on the 7505 Router Is the Hardest Part of the MLS Configuration
! MLS-RP Step 1: Cisco7505(config)#mls rip ip Cisco7505(config)#access-list 1 deny 10.1.30.0 0.0.0.255 Cisco7505(config)#access-list 1 permit any Cisco7505(config-if)#interface fastethernet 2/0 Cisco7505(config-if)#speed 100 Cisco7505(config-if)#full-duplex ! MLS-RP Step 2: Cisco7505(config-if)#mls rp vtp-domain Corporate Cisco7505(config-subif)#interface fastethernet2/0.1 Cisco7505(config-subif)#encapsulation dot1q 1 Cisco7505(config-subif)#ip address 10.1.1.1 255.255.255.0 ! MLS-RP Step 4: Cisco7505(config-subif)#mls rp ip ! MLS-RP Step 5: Cisco7505(config-subif)#mls rp management interface Cisco7505(config-subif)#interface fastethernet2/0.10 Cisco7505(config-subif)#encapsulation dot1q 10 Cisco7505(config-subif)#ipo address 10.1.10.1 255.255.255.0 ! MLS-RP Step 4: Cisco7505(config-subif)#mls rip ip Cisco7505(config-subif)#encapsulation dot1q 20 Cisco7505(config-subif)#ip address 10.1.20.1 255.255.255.0 Cisco7505(config-subif)#ip access-group 1 out ! MLS-RP Step 4: Cisco7505(config-subif)#mls rp ip Cisco7505(config-subif)#interface fastethernet2/0.30 Cisco7505(config-subif)#encapsulation dot1q 30 Cisco7505(config-subif)#ip address 10.1.30.1 255.255.255.0 ! MLS-RP Step 4: Cisco7505(config-subif)#mls rip ip

324

Chapter 5: Multilayer Switching

Switch A, B, and C Configuration
In some Cisco IOS software releases, traffic on the IEEE 802.1Q native VLAN is not routed. The default native VLAN on Catalyst switches is VLAN 1. If the Cisco IOS software release being used does not route traffic on the native VLAN and an administrator wants to route traffic on VLAN 1, he or she must change the native VLAN on the switch-to-router trunk link to an unused VLAN. In the Switch A, Switch B, and Switch C configuration examples, the native VLAN on all the 802.1Q trunk links is set to an unused VLAN: VLAN 5. Example 5-4 shows the configuration for Switch A, Example 5-5 shows the configuration for Switch B, and Example 5-6 shows the configuration for Switch C.
Example 5-4 The Catalyst 5509 Is the MLS-SE
SwitchA>(enable) set vtp domain Corporate mode server VTP domain Corporate modified SwitchA>(enable) set vlan 5 Vlan 5 configuration successful 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 trunk 1/1 on dot1q Port(s) 1/1 trunk mode set to on. Port(s) 1/1 trunk type set to dot1q SwitchA>(enable) set port name 1/2 SwitchBLink Port 1/2 name set. SwitchA>(enable) set trunk 1/2 desirable dot1q Port(s) 1/2 trunk mode set to desirable Port(s) 1/2 trunk type set to dot1q SwitchA>(enable) set port name 1/3 SwitchCLink Port 1/3 name set SwitchA>(enable) set trunk 1/3 desirable dot1q Port(s) 1/3 trunk mode set to desirable Port(s) 1/3 trunk type set to dot1q SwitchA>(enable) set vlan 5 1/1-3 VLAN 5 modified VLAN 1 modified

MLS and CEF Configuration Tasks

325

Example 5-4 The Catalyst 5509 Is the MLS-SE (Continued)
VLAN ---5 Mod/Ports --------1/1-3

! MLS-SE Step 1: SwitchA>(enable) set mls enable IP Multilayer switching is enabled ! MLS-SE Step 2: SwitchA>(enable) set mls include 10.1.1.1 IP Multilayer switching enabled for router 10.1.1.1 SwitchA>(enable) set port name 3/1 DestinationD2 Port 3/1 name set. SwitchA>(enable) set vlan 20 3/1

Example 5-5 Switch B is a Catalyst 5505 Switch
SwitchB>(enable) set port name 1/1 SwitchALink Port 1/1 name set SwitchB>(enable) set vlan 5 1/1 VLAN 5 modified VLAN 1 modified VLAN ---5 Mod/Ports --------1/1

SwitchB>(enable) set vlan 10 3/1 VLAN 10 modified VLAN 1 modified VLAN ---10 Mod/Ports --------3/1

Example 5-6 Switch C is a Catalyst 5505 Switch
SwitchC>(enable) set port name 1/1 SwitchALink Port 1/1 name set SwitchC>(enable) set vlan 5 1/1 VLAN 5 modified VLAN 1 modified

continues

326

Chapter 5: Multilayer Switching

Example 5-6 Switch C is a Catalyst 5505 Switch (Continued)
VLAN ---5 Mod/Ports --------1/1

SwitchC>(enable) set port name 3/1 DesintationD1 Port 3/1 name set SwitchC>(enable) set vlan 30 3/1 VLAN 30 modified VLAN 1 modified VLAN ---30 Mod/Ports --------3/1

SwitchC>(enable) set port name 4/1 SourceS2 Port 4/1 name set SwitchC>(enable) set vlan 30 4/1 VLAN 30 modified VLAN 1 modified VLAN ---30 Mod/Ports --------3/1 4/1

MLS Verification
The show mls rp command displays the following information:
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Whether MLS switching is globally enabled or disabled The MLS ID for this MLS-RP The MLS IP address for this MLS-RP The MLS flow mask The name of the VTP domain in which the MLS-RP interfaces reside Statistical information for each VTP domain The number of management interfaces defined for the MLS-RP The number of VLANs configured for MLS The ID of each VLAN configured for this MAC address The number of MLS-SEs to which the MLS-RP is connected The MAC address of each switch

MLS and CEF Configuration Tasks

327

Each MLS-RP is identified to the switch by both the MLS ID and the MLS IP address of the route processor. The MLS ID is the MAC address of the route processor. The MLS-RP automatically selects the IP address of one of its interfaces from MLS-enabled interfaces and uses that IP address as its MLS IP address. The MLS-SE uses the MLS ID in the process of populating the MLS cache. This MLS IP address is used in the following situations:

By the MLS-RP and the MLS-SE when sending MLS statistics to a data collection application In the included MLS-RP list on the switch

To display IP MLS information about a specific interface, use the show mls rp interface type number command. Example 5-7 shows the output of this command for interface VLAN 10.
Example 5-7 Displaying Specific Information for an IP MLS Interface
Router#show mls rp interface vlan 10 als active on Vlan10, domain Corporate Router#

The show mls rp vtp-domain domain-name command displays IP MLS information for a specific VTP domain on the MLS-RP, as shown in Example 5-8.
Example 5-8 Displaying IP MLS Information Specific to a VTP Domain
Router#show mls rp vtp-domain Corporatevlan domain name: Corporate current flow mask: ip-flow current sequence number: 80709115 current/maximum rety count: 0/10 current domain state: no-change current/next global purge: false/false current/next purge count: 0/1 domain uptime: 13:07:36 keepalive timer expires in 8 seconds retry timer not running change timer not running fcp subblock count = 7 1 management interface(s) current defined: vlan 1 on Vlan1 7 mac-vlan(s) configured for multi-layer switching: mac 00e0.fefc.6000

continues

328

Chapter 5: Multilayer Switching

Example 5-8 Displaying IP MLS Information Specific to a VTP Domain (Continued)
vlan id(s) 1 10 91 92 93 95 100 router currently aware of following 1 switch(es): switch id 0010.1192.b5ff

On the Catalyst 6000 MSFC, the show mls status command displays basic MLS information, as shown in Example 5-9.
Example 5-9 Displaying Basic MLS Information on a Catalyst 6000 Family Switch MSFC
Router#show mls status MLS global configuration status: global mls ip: global mls ipx: global mls ip multicast: current ip flowmask for unicast: current ipx flowmask for unicast: Router# enabled enabled disabled destination only destination only

The show mls output provides the following information:
■ ■ ■ ■ ■ ■ ■ ■

Whether MLS is enabled on the switch The aging time, in seconds, for an MLS cache entry The fast aging time, in seconds, and the packet threshold for a flow The flow mask Total packets switched The number of active MLS entries in the cache Whether NetFlow data export is enabled and, if so, for which port and host The MLS-RP IP address, MAC address, XTAG, and supported VLANs

To display MLS information on an MLS-SE, enter the show mls command in privileged mode. Example 5-10 shows the results of this command.
Example 5-10 Displaying MLS Information on an MLS-SE Running Catalyst OS
Console>(enable) show mls

Multilayer switching enabled Multilayer switching aging time = 256 seconds

MLS and CEF Configuration Tasks

329

Example 5-10 Displaying MLS Information on an MLS-SE Running Catalyst OS (Continued)
Multilayer switching fast aging time = 0 seconds, packet threshold = 1 Desintation-ip flow Total packets switched = 101892 Active entries = 2153 Netflow data export enabled Netflow data export configured for port 8010 on host 10.0.2.15 Total packets exported = 20

MLS-RIP IP

MLS-Rp ID

Xtag ---2

MLS-RP

MAC-Vlans

-----------------------172.20.25.2 00008080cece

-------------------------00-00-80-ec-e0 00-00-80-ec-e1 00-00-80-ec-e2 00-00-80-ec-e3 00-00-80-ec-e4 1-20 21-30 31-40 41-50 51-60

172.20.27.1

00008080cece

3

00-00-80-12-14 00-00-80-12-15 00-00-80-12-16

1-20, 31-40 21-30 41-50

To display information about a specific MLS-RP, enter the show mls rp [ip_addr] command. This command displays information used by the switch with regard to Layer 3 switched packets, as demonstrated in Example 5-11.
Example 5-11 Displaying MLS-RP Information on an MLS-SE Running Catalyst OS
Console>(enable) show mls rp 166.122.20.2

MLS-RP IP

MLS-Rp ID

Xtag ---2

MLS-RP

MAC-Vlans

-----------------------166.122.20.2 00008080cece

------------------------00-00-80-ec-e0 00-00-80-ec-e1 00-00-80-ec-e2 00-00-80-ec-e3 00-00-80-ec-e4 1-20 21-30 31-40 41-50 51-60

330

Chapter 5: Multilayer Switching

Arguably, the most useful show commands for MLS are those that display the MLS cache entries or that use the show mls entry command or one of its four variations:
■ ■ ■ ■

show mls entry rp show mls entry destination show mls entry source show mls entry flow

To display all MLS entries on the switch, simply enter the command show mls entry, or use an option to get more specific information, as shown in Example 5-12.
Example 5-12 Displaying MLS Cache Entries on an MLS-SE Running Catalyst OS
Console>(enable) show mls entry destination 172.20.22.14/24

Destination IP

Source IP

Port

DstPrt

SrcPrt

Destination Mac

Vlan

Port

MLS-RP 172.20.25.1: 172.20.22.14 172.20.25.10 TCP 6001 Telnet 00-60-700-6c-fc-22 4 2/1

MLS-RP 172.20.25.1: 172.20.22.16 172.20.27.139 TCP 6001 Telnet 00-60-700-6c-fc-24 4 2/3

Finally, just as an administrator occasionally needs to clear ARP cache entries, contentaddressable memory (CAM), or the routing table, sometimes there is a need to remove entries from the MLS cache. To do so, enter the clear mls entry command. Here’s the full syntax of this command when used for IP flows:
clear mls entry ip [destination ip_addr_spec] [source ip_addr_spec] [flow protocol src_port dst_port] [all]

The all keyword clears all MLS entries. Other than the all keyword option, the syntax parallels that of the show mls entry command. Example 5-13 shows the output of a prescriptive use of the clear mls entry ip command.
Example 5-13 Removing MLS Cache Entries on an MLS-SE Running Catalyst OS
Console>(enable) clear mls entry ip destination 172.20.26.22 source 172.20.22.113 flow tcp 1652 23

MLS IP entry cleared

MLS and CEF Configuration Tasks

331

CEF Configuration and Verification
CEF configuration is straightforward. However, there are many options for verifying and monitoring CEF operation.

CEF Configuration
One of CEF’s most appealing features might be its configuration. CEF for PFC2 on a Catalyst 6500 is permanently enabled on Supervisor Engine II with the PFC2 and MSFC2, so no configuration is required. However, some platforms allow CEF to be disabled or don’t default to enabling CEF. On Catalyst 3550 switches, CEF is enabled globally by default. If for some reason it is disabled, you can reenable it by using the ip cef global configuration command. To enable dCEF on line cards so that the route processor can handle routing protocols or switch packets from legacy interface processors, issue the ip cef distributed global configuration command. When CEF or dCEF is enabled globally, all interfaces that support CEF are enabled by default. An administrator might want to disable CEF or dCEF on a particular interface, because that interface is configured with a feature that CEF or dCEF does not support. For example, policy routing and CEF cannot be used together. Sometimes one interface is configured to support policy routing and the other interfaces support CEF. In this case, enable CEF globally, but disable it on the interface configured for policy routing. This allows all but one interface to express forward. To disable CEF or dCEF on an interface, use the no ip route-cache cef command in interface configuration mode. When CEF or dCEF is disabled, Cisco IOS software switches packets using the next fastest switching path. In the case of dCEF, the next fastest switching path is CEF on the route processor. If CEF or dCEF is disabled on an interface, an administrator can reenable it by using the ip route-cache cef command while in interface configuration mode.

Verifying CEF
You can view the contents of the FIB table by issuing the show ip cef detail command from the MSFC2 or Supervisor Engine 720. Example 5-14 shows the output from this command.

332

Chapter 5: Multilayer Switching

Example 5-14 Displaying the FIB Table on a Catalyst 6500 MSFC2 or Supervisor Engine 720
MSFC2#show ip cef detail IP CEF with switching (Table Version 477965) 445 routes, 0 reresolve, 0 unresolved (0 old, 0 new) 446 leaves, 76 nodes, 132560 bytes, 477966 inserts, 477520 invalidations 0 load sharing elements, 0 bytes, 0 references 1 CEF resets, 2 revisions of existing leaves refcounts: 15824 leaf, 15038 node

Default 192.35.86.0/24 0.0.0.0/32, version 0, receive 10.1.0.0/16, version 121980, attached, connected 0 packets, 0 bytes via Vlan10, 0 dependencies valid glean adjacency 10.1.0.0/32, version 121982, recieve 10.1.0.44/32, version 433624, connected, cached adjacency 10.1.0.44 0 packets, 0 bytes via 10.1.0.44, Vlan10, 0 dependencies next hop 10.1.0.44, Vlan10 valid cached adjacency 10.1.0.84/32, version 122675, connected, cached adjacency 10.1.0.84 0 packets, 0 bytes via 10.1.0.84, Vlan10, 0 dependencies next hop 10.1.0.84, Vlan10 valid cached adjacency 10.1.0.107/32, version 471278, connected, cached adjacency 10.1.0.107 0 packets, 0 bytes via 10.1.0.107, Vlan10, 0 dependencies next hop 10.1.0.107, Vlan10 valid cached adjacency 10.1.0.152/32, version 450780, connected, cached adjacency 10.1.0.152 0 packets, 0 bytes via 10.1.0.152, Vlan10, 0 dependencies

MLS and CEF Configuration Tasks

333

Example 5-14 Displaying the FIB Table on a Catalyst 6500 MSFC2 or Supervisor Engine 720 (Continued)
next hop 10.1.0.152, Vlan10 valid cached adjacency 10.1.0.158/32, version 447262, connected, cached adjacency 10.1.0.158 0 packets, 0 bytes via 10.1.0.158, Vlan10, 0 dependencies next hop 10.1.0.158, Vlan10 valid cached adjacency 10.1.0.162/32, version 471313, connected, cached adjacency 10.1.0.162 0 packets, 0 bytes via 10.1.0.162, Vlan10, 0 dependencies next hop 10.1.0.162, Vlan10 valid cached adjacency <output omitted>

Use the show ip cef command to view the contents of the CEF adjacency table from the MSFC2 or Supervisor Engine 720, as shown in Example 5-15. The show ip cef summary command, shown in Example 5-16, provides a brief overview of the CEF process with information such as the total number of adjacencies and routes.
Example 5-15 Displaying the Contents of the CEF Adjacency Table on a Catalyst 6500 MSFC2 or Supervisor Engine 720
MSFC2#show ip cef 0.0.0/32 10.1.0.0/16 10.1.0.0/32 10.1.0.44/32 10.1.0.84/32 10.1.0.107/32 10.1.255.253/32 10.1.255.254/32 10.1.255.255/32 10.2.0.0/16 10.2.0.0/32 10.2.0.12/32 receive attached receive 10.1.0.44 10.1.0.84 10.1.0.107 10.1.255.253 receive receive attached receive 10.2.0.12 Vlan2 Vlan2 Vlan10 Vlan10 Vlan10 Vlan10 Vlan10

334

Chapter 5: Multilayer Switching

Example 5-16 Displaying a Brief Overview of the CEF Process on a Catalyst 6500 MSFC2 or Supervisor Engine 720
MSFC2#show ip cef summary IP CEF with switching (Table Version 477965) 445 routes, 0 reresolve, 0 unresolved (0 old, 0 new) 446 leaves, 76 nodes, 132560 bytes, 477966 inserts, 477520 invalidations 0 load sharing elements, 0 bytes, 0 references 1 CEF resets, 2 revisions of existing leaves refcounts: 15824 leaf, 15038 node

Default 192.35.86.0/24

Lab 5.4.1 Monitoring Cisco Express Forwarding

In this lab exercise, you monitor the default behavior of CEF.

Summary
MLS and CEF are Cisco multilayer switching technologies. CEF is newer than MLS and is supported by all the newer devices, such as the Catalyst 4000 Supervisor Engine III and IV, the Catalyst 6500 with MSFC2 and PFC2, the Catalyst 6500 Supervisor Engine 720, and Cisco routers with Cisco IOS software Release 12.2 and later. CEF has been supported on some routers since Cisco IOS software Release 12.0, such as the Cisco 7500.

Key Terms

335

Key Terms
adjacency table One of three tables used by CEF. The adjacency table is a database of node adjacencies (two nodes are said to be adjacent if they can reach each other via a single Layer 2 hop) and their associated Layer 2 MAC rewrite or next-hop information. Each leaf of the FIB tree offers a pointer to the appropriate next-hop entry in the adjacency table. aging time The IP MLS aging time determines the amount of time before an MLS entry is aged out. The default is 256 seconds. You can configure the aging time in the range of 8 to 2032 seconds in 8-second increments. candidate packet When a source initiates a data transfer to a destination, it sends the first packet to the MLS-RP through the MLS-SE. The MLS-SE recognizes the packet as a candidate packet for Layer 3 switching, because the MLS-SE has learned the MLS-RP’s destination MAC addresses and VLANs through MLSP. The MLS-SE learns the candidate packet’s Layer 3 flow information (such as the destination address, source address, and protocol port numbers) and forwards the candidate packet to the MLS-RP. A partial MLS entry for this Layer 3 flow is created in the MLS cache. central rewrite engine The Catalyst 5000 NFFC contains central rewrite engines (one per bus) to handle PDU header rewrites when inline rewrite is not an option. If the central rewrite engines are used, this means that a frame must traverse the bus twice—first with a VLAN tag for the source (on its way to the NFFC) and second with a VLAN tag for the destination (on its way to the egress port). Cisco Express Forwarding (CEF) A Cisco multilayer switching technology that allows for increased scalability and performance to meet the requirements for large enterprise networks. CEF has evolved to accommodate the traffic patterns realized by modern networks, characterized by an increasing number of short-duration flows. Content-Addressable Memory (CAM) Memory that is accessed based on its contents, not on its memory address. Sometimes called associative memory. enable packet When an MLS-SE receives a packet from the MLS-RP that originated as a candidate packet, it recognizes that the source MAC address belongs to the MLS-RP, that the XTAG matches that of the candidate packet, and that the packet’s flow information matches the flow for which the candidate entry was created. The MLS-SE considers this packet an enable packet and completes the MLS entry created by the candidate packet in the MLS cache. fast aging time The IP MLS fast aging time is the amount of time before an MLS entry is purged that has no more than pkt_threshold packets switched within fastagingtime seconds after it is created.

336

Chapter 5: Multilayer Switching

flow A unidirectional sequence of packets between a particular source and destination that share the same Layer 3 and Layer 4 PDU header information. flow mask A set of criteria, based on a combination of source IP address, destination IP address, protocol, and protocol ports, that describes the characteristics of a flow. Forwarding Information Base (FIB) One of three tables used by CEF. The FIB table contains the minimum information necessary to forward packets; in particular, it does not contain any routing protocol information. The table consists of a four-level hierarchical tree, with 256 branch options per level (reflecting four octets in an IP address). inline rewrite Some Catalyst 5000 family switch line cards have onboard hardware that performs PDU header rewrites and forwarding, maximizing IP MLS performance. When the line card performs the PDU header rewrites, this is called inline rewrite. With inline rewrite, frames traverse the switch bus only once. MLS Route Processor (MLS-RP) A Cisco device with a route processor that supports MLS. For example, a Catalyst 3620 router is an MLS-RP. MLS Switching Engine (MLS-SE) A set of hardware components on a Catalyst switch, excluding the route processor, necessary to support MLS. For example, a Catalyst 5000 with a Supervisor Engine IIIG is an MLS-SE. MLS-RP Management Interface The MLS-RP interface that sends hello messages, advertises routing changes, and announces VLANs and MAC addresses of interfaces participating in MLS. Multilayer Switch Feature Card (MSFC) MSFC1 and MSFC2 are daughter cards to the Catalyst 6000 Supervisor Engine that provide multilayer switching functionality and routing services between VLANs. Multilayer Switching (MLS) A specific multilayer switching technology employed by various Cisco devices to perform wire-speed PDU header rewrites. The first packet in a flow is routed as normal, and the MLS-SE switches subsequent packets based on cached information. Multilayer Switching Protocol (MLSP) A protocol used to communicate MLS information between the MLS-SE and MLS-RP. In particular, the MLS-SE populates its Layer 2 CAM table with updates received from MLSP packets. NetFlow Feature Card (NFFC) A daughter card for a Catalyst 5000 Supervisor module that enables intelligent network services, such as high-performance multilayer switching and accounting and traffic management. NetFlow table One of three tables used by CEF. The NetFlow table provides network accounting data. It is updated in parallel with the CEF-based forwarding mechanism provided by the FIB and adjacency tables.

Check Your Understanding

337

wire-speed routing The routing of packets using a combination of hardware and data structures so that routing table lookups are circumvented and header rewrites and forwarding are handled independent of the route processor. XTAG A 1-byte value that the MLS-SE attaches per VLAN to all MAC addresses learned from the same MLS-RP via MLSP.

Check Your Understanding
Use the following review questions to test your understanding of the concepts covered in this chapter. Answers are listed in Appendix A, “Check Your Understanding Answer Key.”
1. Which of the following describe multilayer switching? A. It’s hardware-based. B. It performs PDU header rewrites and forwarding. C. It’s platform-independent. D. It uses Layer 2, Layer 3, and Layer 4 header information. 2. Which of the following device combinations support Cisco Express Forwarding? A. Cisco 7500 router running IOS 12.0 B. Catalyst 4500 Supervisor Engine III C. Catalyst 6500 MSFC2 D. Cisco routers running IOS 12.2 or later 3. Which of the following are MLS components? A. MLSP B. MLS-RP C. MLS cache D. MLS-SE 4. Which of the following are MLS flow masks? A. destination-ip B. protocol-flow C. source-destination-ip D. ip-flow

338

Chapter 5: Multilayer Switching

5. After an IP MLS flow has been created, which of the following fields change in a frame

traversing the MLS-SE as part of the same flow?
A. Source MAC address B. Destination MAC address C. TTL D. Source IP 6. In addition to the routing table, what tables are created in the CEF-based model? A. Routing table B. Forwarding Information Base C. Content-flow table D. Adjacency table 7. How many leaves are possible in a CEF FIB? A. 32 B. 64 C. 128 D. 256 8. How many MLS-SE commands are required to configure MLS when the MLS-RP is an

external router?
A. 1 B. 2 C. 3 D. 4 9. What is the default MLS flow mask when no ACLs are configured on the MLS-RP? A. destination-ip B. protocol-flow C. source-destination-ip D. ip-flow

Check Your Understanding

339

10. What global configuration command enables CEF? A. cef run B. enable cef C. cef enable D. ip cef

Objectives
After completing this chapter, you will be able to perform tasks related to the following:

Explain the types of redundancy in a multilayer switched network, including hardware and software redundancy Implement redundant Supervisor modules in Catalyst switches Implement redundant Supervisor uplink modules in Catalyst switches Implement redundant distributed forwarding cards in Catalyst switches Explain how router redundancy operates Describe, configure, and verify Hot Standby Router Protocol (HSRP) Describe Virtual Router Redundancy Protocol (VRRP) Describe and verify Gateway Load Balancing Protocol (GLBP) Describe Single Router Mode (SRM) redundancy Describe and verify Server Load Balancing (SLB) Troubleshoot router redundancy using HSRP, VRRP, GLBP, SRM, and SLB

■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Chapter 6 Redundancy
Because many organizations are now seeking the economic benefits of campus networks for mission-critical communications, high reliability is becoming increasingly crucial. Within the campus network, much attention has been focused on providing a network infrastructure that is available 100 percent of the time. One of the greatest challenges comes not from the network infrastructure but from the workstations and network equipment at the user level. High network availability rates rely on two key items:
■ ■

Elimination of any single point of failure Distribution of intelligence throughout the architecture

Availability can be increased by adding redundant components, including redundant network devices and connections to multiple WAN links, as illustrated in Figure 6-1. With the proper design, no single point of failure affects overall system availability. The best practice is a design based on modular and hierarchical building blocks that can be replicated to support growth. The infrastructure must also be able to detect and respond quickly to any possible service, link, device, server, or software failure. Users and applications do not notice failures, because optimized resiliency technologies ensure fast convergence upon failure. To achieve optimal, fast convergence, multiple networking technologies need to interoperate and complement each other to ensure fast recovery. The objective of this chapter is to provide an overview of hardware and software redundancy operation and implementation on the Cisco Catalyst series of switches. The Cisco-proprietary Hot Standby Router Protocol (HSRP) feature is the main focus of this module. Other redundancy technologies, such as Virtual Router Redundancy Protocol (VRRP), Gateway Load Balancing Protocol (GLBP), and Server Load Balancing (SLB) are also explored.

342

Chapter 6: Redundancy

Figure 6-1 A Well-Designed Network Always Includes Redundancy Cache Engine Cisco Secure PIX Firewall Distributed Director Distributed Director

ISP 1 Internet Corporate Network ISP 2

Alternate Commerce Site

Catalyst 6500

Local Director Web Servers

Database Servers

Implementing Module Redundancy in a Multilayer Switched Network
Hardware redundancy takes on many presentations with Cisco Catalyst switches. These include redundant Supervisor Engines, redundant uplink modules, redundant forwarding cards, and redundant power supplies. This section details each of these options.

Implementing Redundant Supervisor Engines in Catalyst Switches
The Catalyst 6000 family switches rely on a Supervisor Engine to manage the other modules in the chassis, as shown in Figure 6-2. Dual Supervisor Engines provide hardware redundancy for the forwarding intelligence of the Catalyst 6000 family. Catalyst 6000 family switches can support two Supervisor Engine I or II modules only in slots 1 and 2. The Catalyst 6500 can support two Supervisor Engine 720 modules only in slots 1 and 2 in a three-slot chassis, slots 5 and 6 in a six- or nine-slot chassis, and slots 7 and 8 in a 13-slot chassis. One Supervisor serves as the running, or active, Supervisor, and the other serves as the standby Supervisor. The active Supervisor Engine is the first one to come online. This can be confirmed by the “Active” Light Emitting Diode (LED) externally on the Supervisor or by entering the show module command at the console. The active Supervisor processes all administrative and management functions, such as Simple Network Management Protocol (SNMP), command-line interface (CLI) console, Telnet, Spanning Tree Protocol (STP), Port Aggregation Protocol (PAgP), Cisco Discovery Protocol (CDP), Dynamic Trunking Protocol (DTP), and VLAN Trunking

Implementing Module Redundancy in a Multilayer Switched Network

343

Protocol (VTP) functions. Redundant Supervisor Engines must be of the same type with the same model feature card. If an active Supervisor is taken offline or fails, the standby Supervisor takes over control of the system.
Figure 6-2 Catalyst Switch Supervisor Engines Manage All Other Modules in the Chassis

The two Supervisor Engines in a redundant configuration have distinct functions. The active Supervisor is responsible for controlling the system bus and all line cards. All protocols are running on the active Supervisor, and it performs all packet forwarding. The standby Supervisor does not communicate with the line cards. The standby Supervisor receives packets from the network and populates its forwarding tables with this information. However, the standby Supervisor does not participate in any packet forwarding or provide any load sharing. The relevant protocols on the system are initialized, but not active, on the standby Supervisor. The Catalyst 6500 series Supervisor Engines are hot-swappable. This means that the standby Supervisor Engine can be installed on an active system without affecting network operation. The active Supervisor provides all the packet forwarding intelligence for the system. If the active Supervisor fails, the standby Supervisor maintains the same system load. The standby Supervisor can be removed and installed without service interruption. The standby Supervisor polls the active Supervisor on a regular interval using an out-of-band channel. The active Supervisor Engine might go offline for the following reasons:
■ ■ ■ ■ ■

Hardware failures System overload conditions Memory corruption issues Removal from chassis Operator reset

344

Chapter 6: Redundancy

The standby Supervisor detects these types of failures and becomes the active Supervisor. The software on the Supervisor Engine is responsible for restoring the protocols, line cards, and forwarding engines to normal operation. This restoration takes place using a fast switchover or a high-availability switchover.

Implementing Redundant Supervisor Uplink Modules in Catalyst Switches
Catalyst 5000 family Supervisor Engine IIG uplink ports are modular, as shown in Figure 6-3. Modularity lets the administrator install the uplink module to deliver current bandwidth requirements. Modularity also ensures an easy migration path. Available options are as follows:
■ ■ ■ ■ ■

Four-port autosensing 10/100 Fast Ethernet (RJ-45) Four-port 100BASE-FX (MT-RJ) Two-port autosensing 10/100 Fast Ethernet (RJ-45) Two-port 100BASE-FX (SC) Two-port Gigabit Ethernet SX, LX/LH (SC), or Gigabit Interface Converter (GBIC)

Any Fast Ethernet uplink port can use Fast EtherChannel technology. Fast EtherChannel provides up to 800 million packets per second (Mpps) of wire-speed, resilient, and scalable bandwidth for data center and backbone implementations.
Figure 6-3 The Catalyst 5000 Family Supervisor IIG Supports Modular Uplinks

Implementing Module Redundancy in a Multilayer Switched Network

345

The Catalyst 4006 Supervisor Engine III (shown in Figure 6-4), Catalyst 4500 Supervisor Engine IV (shown in Figure 6-5), and Catalyst 6500 Supervisor Engine I and II (shown in Figure 6-6) support 1000BASE-SX, 1000BASE-LX/LH, and 1000BASE-ZX uplinks via insertion of GBICs into accommodating slots on these devices.
Figure 6-4 The Catalyst 4006 Supervisor Engine III Delivers a 64-Gbps Switching Fabric with 48-Mpps Forwarding Rate in Hardware for Both Layer 2 and Layer 3/4 Traffic

Figure 6-5 The Catalyst 4000/4500 Supervisor Engine IV Delivers Integrated Resiliency and CEF-Based Layer 2/3/4 Switching at 48 Mpps

346

Chapter 6: Redundancy

Figure 6-6 The Catalyst 6000 Family Supervisor Engine I Supports the Policy Feature Card (on the Left) and the Multilayer Switch Feature Card (on the Right)

The Catalyst 6500 Supervisor Engine 720, shown in Figure 6-7, has three physical uplink ports:

Two Gigabit Ethernet Small Formfactor Pluggable (SFP) ports supporting 1000BASE-SX and 1000BASE-LX/LH One 10/100/1000 RJ-45 port

Only two of the three ports can be active at any one point in time.
NOTE The Catalyst 6500 supports 10 Gigabit Ethernet modules. Up to eight 10 Gigabit Ethernet ports can participate in a single 10 Gigabit EtherChannel, providing 160 Gbps of bandwidth. Figure 6-7 The Catalyst 6500 Series Supervisor Engine 720 Delivers CEF-Based Forwarding at 400 Mpps/720 Gbps

Any Gigabit Ethernet uplink port can use Gigabit EtherChannel technology. With additional Gigabit Ethernet line cards, Gigabit EtherChannel can provide up to 16 Gbps of wire-speed, resilient, and scalable bandwidth for data center and backbone implementations.

Implementing Module Redundancy in a Multilayer Switched Network

347

Implementing Redundant Distributed Forwarding Cards in Catalyst Switches
The distributed forwarding card (DFC) for the Catalyst 6500 series, shown in Figure 6-8, delivers high-speed distributed services and forwarding for deployment in data center backbones and server farm aggregation. The DFC complements the centralized forwarding of the Catalyst 6500 Supervisor Engine II by distributing the centralized forwarding intelligence to each DFC-enabled line card module. This capability provides localized forwarding and service decisions on each line card and accelerates the forwarding performance of the Catalyst 6500 series.
Figure 6-8 The DFC Is Installed in DFC-Enabled Line-Card Modules That Perform Distributed Forwarding, Supported by the Catalyst 6500 Supervisor Engine II

The DFC works with the Switch Fabric Module, Supervisor Engine II with Multilayer Switch Feature Card 2 (MSFC2) and fabric-enabled cards to provide a framework for a distributed CEF-based forwarding architecture, as shown in Figure 6-9. Although classic line cards cannot directly participate in distributed forwarding, CEF capabilities can still be used based on the centralized capabilities offered by Supervisor Engine II. The Catalyst 6500 DFC-3 is installed in DFC-enabled line-card modules that perform distributed forwarding supported by the Catalyst 6500 Supervisor Engine 720 as a field upgrade. When the DFC-3 is installed, modules that are DFC-enabled make forwarding decisions locally, leaving the Supervisor Engine free to perform routing and management functions. The DFC-3 replicates Layer 2 and Layer 3 forwarding logic of the Supervisor 720’s Policy Feature Card 3 (PFC-3) on each DFC-3-equipped line card. This enables hardware acceleration of IPv6, Multiprotocol Label Switching (MPLS), Generic Routing Encapsulation (GRE), quality of service (QoS), access control list (ACL) policy enforcement, and more. The DFC3-equipped interface modules are backward-compatible with all other Catalyst 6500 interface modules. However, the modules must be used with a Supervisor 720, and any other modules that will use distributed forwarding must also be DFC-3-equipped.

348

Chapter 6: Redundancy

Figure 6-9 Local Forwarding Is Provided by the DFC Architecture

Master FIB Table Adjacency Table

Routing Table

MSFC

Slave FIB Table

Adjacency Table

Slave FIB Table

Adjacency Table

ASIC Line Card Multigigabit Crossbar Fabric

ASIC Line Card

Implementing Redundant Power Supplies
To meet the need for power redundancy, Cisco has added redundant power as an option across a broad range of devices. Redundant power supplies are appropriate in situations that are considered mission-critical. In systems with redundant power supplies, both power supplies must be of the same wattage. The Catalyst 6000 family switches allow mixing of AC-input and DC-input power supplies in the same chassis. With redundancy enabled and two power supplies of equal wattage installed, the total power drawn from both supplies is at no time greater than the capacity of one supply. If one supply malfunctions, the other supply can take over the entire system load. When two power supplies of equal wattage are used, as shown in Figure 6-10, each provides approximately half of the required power to the system. Load sharing and redundancy are enabled automatically. No software configuration is required. With redundancy enabled and two power supplies of unequal wattage installed, both power supplies come online, but a syslog message says that the lower-wattage power supply will be disabled. If the active power supply fails, the lower-wattage power supply comes online and modules are powered down, if necessary, to accommodate the lower-wattage power supply. In a nonredundant configuration, the power available to the system is the combined power capacity of both power supplies. The system powers up as many modules as the combined capacity allows. However, if one supply fails and there is not enough power for all previously powered-up modules, the system powers down some modules. These modules are marked as power-deny in the show module status field.

Implementing Router Redundancy in a Switched Network

349

Figure 6-10 Redundant Power Supplies Are Recommended for Any Chassis-Based Catalyst Switch

You can reconfigure the configuration of the power supplies from redundant to nonredundant at any time. When switching from a redundant to a nonredundant configuration, both power supplies are enabled even if a lower-wattage power supply is present. When switching from a nonredundant to a redundant configuration, both power supplies are initially enabled. If they are of the same wattage, they remain enabled. If the power supplies are of different wattages, a syslog message appears, and the lower-wattage supply is disabled.

Implementing Router Redundancy in a Switched Network
An evolution has taken place with respect to technologies enabling router redundancy from the access and distribution layers. Proxy ARP was one of the first solutions designed to provide dynamic access to preferred routers on a given LAN. Other solutions over the years have included Gateway Discovery Protocol (GDP), multiple default gateways, routing protocols running on workstations, dynamic host configuration protocol (DHCP), Internet Control Message Protocol (ICMP) Router Discovery Protocol (IRDP), HSRP, VRRP, and GLBP. Many of these remain viable options. This chapter focuses mostly on HSRP, but the other options are also described.

350

Chapter 6: Redundancy

Router Redundancy Operation
IP routing redundancy is a key component of high-availability strategy for any network, because it is a critical component of delivering reliable data, voice, and video integration. The goal of IP routing redundancy is to protect against first-hop router failure when a source host is unable to dynamically learn the IP address of an alternate first-hop router. Some options for redundant access to routers include the following:
■ ■ ■ ■

Proxy Address Resolution Protocol (ARP) Multiple default gateways Dynamic routing protocols running on workstations DHCP

Each of these options permits a host some flexibility with respect to where traffic originating from the host exits on the local LAN segment. The focus at this point is providing redundancy to hosts, rather than to network devices, such as switches or routers.

Proxy Address Resolution Protocol
Some IP hosts use proxy ARP to select a router. When a host runs proxy ARP, an ARP request is sent with the IP address of the remote host. A router on the network replies on behalf of the remote host and provides its own MAC address. With proxy ARP, the host assumes it is connected to the same segment of the network as the remote host. If Router A fails, the host continues sending packets to Router A’s MAC address. Those packets are lost until the host ARP table is updated by way of a new ARP request acquiring the MAC address of another router on the local segment. It is possible that for a significant period of time the host will be unable to communicate with the remote host, even though the routing protocol has converged, and Router B is prepared to transfer packets that would otherwise go through Router A.

Default Gateways
Specifying a default gateway on a host allows the workstation to simply send the packet to the default gateway. Some operating systems might have only one default gateway specified. When this gateway fails, as shown in Figure 6-11, the workstation cannot reach remote subnets. Although the network infrastructure can quickly recover and reconverge, the host does not know about a new default gateway. With operating systems that support multiple default gateway entries, such as Microsoft Windows, failover between the entries is not dynamic. The operating system sends an echo to each gateway entry in order on bootup. The first gateway to reply is used as the default gateway. Using another listed gateway, in the event of a router failure, requires a restart of the host.

Implementing Router Redundancy in a Switched Network

351

Figure 6-11 A Single Static Default Gateway on Hosts Does Not Provide an Adequate Failover Mechanism I need to get to File Server A, but my default gateway is down. I can route packets to File Server A. Router 1 172.16.10.82 0010.f6b3.d000 Subnet A 172.16.50.0 Router 2 172.16.10.169 0010.0b79.5800 Subnet B 172.16.51.0

Core File Server A

Dynamic Routing Protocol
Some IP hosts run a dynamic routing protocol, such as Routing Information Protocol (RIP) or Open Shortest Path First (OSPF), to discover routes. Running a dynamic routing protocol on every host might not be feasible for numerous reasons:
■ ■ ■

Administrative and processing overhead Security issues Lack of a protocol implementation for some platforms

Dynamic Host Configuration Protocol
DHCP provides a mechanism for passing IP configuration information to hosts on a TCP/IP network. A host joining the network requests IP configuration information from the DHCP server. The configuration information typically consists of an IP address and a default gateway.
Interactive Media Activity Point and Click: Router Redundancy Operation

After completing this activity, you will understand basic router redundancy operation.

352

Chapter 6: Redundancy

ICMP Router Discovery Protocol (IRDP)
Some newer IP hosts use ICMP Router Discovery Protocol (IRDP), defined in RFC 1256, to find a new router when a route becomes unavailable. A host that uses IRDP listens for hello multicast messages from the router that the host is configured to use. The host switches to an alternate router when it no longer receives those hello messages. IRDP has a default advertisement rate of once every 7 to 10 minutes. The default lifetime is 30 minutes. These default timer values mean that IRDP is not suitable to detect first-hop failures.

Enabling IRDP Processing
The only required task for configuring IRDP routing on a specified interface is to enable IRDP processing on an interface. Use the command ip irdp in interface configuration mode. When enabling IRDP processing, the default parameters apply. When enabled, IRDP uses the following defaults:
■ ■ ■ ■

Broadcast IRDP advertisements Maximum interval between advertisements—600 seconds Minimum interval between advertisements—450 seconds Preference—0

To display IRDP values, use the command show ip irdp.

Troubleshooting IRDP
Use the debug ip icmp command to display information on ICMP transactions. This command helps determine whether the router is sending or receiving ICMP messages. Use this command when troubleshooting an end-to-end connection problem. The no form of this command disables debugging output.

Hot Standby Router Protocol (HSRP)
One way to achieve near-100-percent network uptime is to use Hot Standby Router Protocol (HSRP) (see RFC 2281). HSRP provides network redundancy for IP networks, ensuring that user traffic immediately and transparently recovers from first-hop failures in network edge devices or access circuits. By sharing an IP address and a MAC address, a set of two or more routers can operate as a single router called a virtual router. This set of routers is known as an HSRP group or a standby group. A single router elected from the group is responsible for forwarding the packets that hosts send to the virtual router. To minimize network traffic, only the active and standby routers send periodic HSRP messages as soon as the protocol has completed the election process. If the local segment has only two routers, one is the active router and one is the

Implementing Router Redundancy in a Switched Network

353

standby router, as shown in Figures 6-12 and 6-13. If the active router fails, the standby router takes over as the active router, as shown in Figures 6-14 and 6-15. If the standby router fails or becomes the active router, another router is elected as the standby router. Hosts continue to forward IP packets to a consistent IP and virtual MAC address. The changeover between routes is transparent to the end workstation.
Figure 6-12 In a Stable Network, an Active Router Forwards All Traffic for an HSRP Group

Active
.4 10.88.1.1 .3

Standby

GW.1
10.88.1.0/24 .7 .5 .6

GW.1

GW.1

GW.1

Figure 6-13 The Active Router Is Assigned the Virtual MAC Address

VIP: 10.88.1.1 MAC: 0000.0c12.3456 VMAC: 0000.0c07.ac00

VIP: 10.88.1.1 MAC: 0000.0c78.9abc

Active
.4 10.88.1.1 .3

Standby zzzzzz (Snore)
10.88.1.0/24

GW.1

.7

.5

.6

GW.1 VIP = Virtual IP Address VMAC = Virtual MAC Address

GW.1

GW.1

354

Chapter 6: Redundancy

Figure 6-14 When the Active Router Goes Down, the Standby Router Immediately Takes Over

VIP: 10.88.1.1 MAC: 0000.0c12.3456

VIP: 10.88.1.1 MAC: 0000.0c78.9abc VMAC: 0000.0c07.ac00

Active
.4 10.88.1.1 .3

GW.1
10.88.1.0/24 .7 .5 .6

GW.1

GW.1

GW.1

Figure 6-15 The New Active Router Is Assigned the Virtual MAC Address

VIP: 10.88.1.1 MAC: 0000.0c12.3456

VIP: 10.88.1.1 MAC: 0000.0c78.9abc VMAC: 0000.0c07.ac00

Standby zzzzzz (Snore)
.4 10.88.1.1 .3

Active

GW.1
10.88.1.0/24

.7

.5

.6

GW.1

GW.1

GW.1

On a particular LAN, multiple hot standby groups might coexist and overlap. Each standby group emulates a single virtual router. The individual routers might participate in multiple groups. In this case, the router maintains separate states and timers for each group. Each standby group has a single virtual MAC and IP address. The HSRP MAC address is derived from the HSRP group number. The HSRP MAC address has the form 0000.0c07.acxx, where xx is the HSRP group number.

Implementing Router Redundancy in a Switched Network

355

Virtual Router Redundancy Protocol (VRRP)
Virtual Router Redundancy Protocol (VRRP) is an Internet Engineering Task Force (IETF) proposed standard (see RFC 2338) that is nearly identical to the Cisco-proprietary HSRP. As a standards-based solution introduced in 1998, VRRP is now being made available to provide interoperability using equipment from multiple vendors. IP routing redundancy is designed to allow for transparent failover at the first-hop router. Both HSRP and VRRP allow two or more devices to work together in a group, sharing a single virtual IP address. The virtual IP address is configured in each end-user workstation as a default gateway address and is cached in the host ARP cache. In an HSRP or VRRP group, one router is elected to handle all requests sent to the virtual IP address. An HSRP group has an active router, a standby router, and perhaps many listening routers. A VRRP group has one master router and one or more backup routers, as shown in Figure 6-16.
Figure 6-16 VRRP Uses a Master Router and Backup Routers, Similar to HSRP Active and Standby Routers VRRP Active IP: 10.0.0.254 MAC: 0000.0c12.3456 vIP: 10.0.0.10 vMAC: 00000.0c07.ac00 VRRP Backup IP: 10.0.0.253 MAC: 0000.0c78.9abc vIP: vMAC: VRRP Backup IP: 10.0.0.252 MAC: 0000.0cde.f123 vIP: vMAC: Gateway Routers R1 R2 R3

Clients

IP: 10.0.0.1 MAC: aaaa.aaaa.aa01 GW: 10.0.0.10 ARP: 0000.0c07.ac00

IP: 10.0.0.2 MAC: aaaa.aaaa.aa02 GW: 10.0.0.10 ARP: 0000.0c07.ac00

IP: 10.0.0.3 MAC: aaaa.aaaa.aa03 GW: 10.0.0.10 ARP: 0000.0c07.ac00

When a group initializes, messages are exchanged to elect the active or master router. Within these messages, information, such as group identifier, priority, virtual IP address, and hello advertisement interval, is exchanged. The routers in a group continue to exchange these messages at a configured interval. In HSRP, both the active and standby routers send periodic hello messages. In VRRP, only the master sends periodic messages, called advertisements.

356

Chapter 6: Redundancy

Using the information in these messages, a standby or backup router can determine whether it needs to take over the active or master role in a group. If a hello message is not received from the active or master router in the defined interval, the standby or backup router automatically assumes the role of active or master. When the original active or master router becomes available again, it sends out a hello or advertisement message and regains the lead IP packetforwarding role within the group. All this is transparent to the end user traversing this first-hop group. Connectivity is maintained with little or no loss of traffic and functionality. Cisco recommends using HSRP, because it is a proven technology that has superior convergence characteristics. Use VRRP only when local subnet interoperability is required with equipment from another vendor. VRRP is supported on Cisco 2600XM, 3600, and 3700 routers running Cisco IOS software Release 12.2T or later.

Troubleshooting VRRP
Customizing the behavior of VRRP is optional. As soon as a VRRP group is enabled, that group is operating. Always customize VRRP before enabling it. Otherwise, a router could become the master virtual router before the customization is complete.

Gateway Load Balancing Protocol (GLBP)
Like HSRP and VRRP, Gateway Load Balancing Protocol (GLBP) provides nonstop path redundancy for IP by sharing protocol and MAC addresses between redundant gateways. GLBP also allows a group of routers to share the load of the default gateway on a LAN. This load sharing improves performance by facilitating better use of network resources when multiple upstream paths are available and increases reliability and network availability by removing the single point of failure—the first-hop router. GLBP allows a router to automatically assume the forwarding function of another router in the group if a failure occurs in any other gateway router. The various GLBP components and concepts are defined as follows:

Active Virtual Gateway (AVG)—One virtual gateway within a particular GLBP group is elected the AVG. The AVG is responsible for the operation of protocol, such as allocating MAC addresses. Virtual Forwarder (VF)—An abstract entity within a GLBP gateway that might assume responsibility for a virtual MAC address. Active Virtual Forwarder (AVF)—One VF within a particular GLBP group is elected the AVF. The AVF is responsible for forwarding packets sent to a particular virtual MAC address.

Implementing Router Redundancy in a Switched Network

357

Primary Virtual Forwarder (PVF)—A PVF is a VF that has been assigned the virtual MAC address by the AVG. Secondary Virtual Forwarder (SVF)—An SVF is a VF that has learned the virtual MAC address from a hello message.

Cisco generally recommends the use of GLBP in place of HSRP when more than two routers reside on a single LAN segment because of its built-in load-balancing feature. GLBP performs a similar, but not identical, function for the user as the HSRP and the VRRP. HSRP and VRRP allow multiple routers to participate in a virtual router group configured with a virtual IP address. One member is elected as the active router to forward packets sent to the virtual IP address for the group. The other routers in the group are redundant until the active router fails. These standby routers have unused bandwidth that the protocol is not using. Although multiple virtual router groups can be configured for the same set of routers, the hosts must be configured for different default gateways, which results in an extra administrative burden. GLBP provides load balancing over multiple routers (gateways) using a single virtual IP address and multiple virtual MAC addresses. Each host is configured with the same virtual IP address, and all routers in the virtual router group participate in forwarding packets. Figures 6-17 to 6-20 illustrate the operation of GLBP. GLBP is supported on the following Cisco hardware platforms, with Cisco IOS software Release 12.2(15)T or later:
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

1700 series routers 2600 series routers 3620 routers 3631 routers 3640 routers 3660 routers 3725 routers 3745 routers 7100 series routers 7200 series routers 7400 series routers 7500 series routers Catalyst 6000 MSFC Catalyst 6500 Supervisor Engine 720

358

Chapter 6: Redundancy

Figure 6-17 GLBP Lets Distinct Hosts Receive Distinct ARP Replies, with Distinct MAC Addresses Associated with the Same Virtual IP Address 1 AVG/AVF
vIP 10.88.1.10 glbp 1 ip 10.88.1.10 vMAC 0000.0000.0001 glbp 1 ip 10.88.1.10 vMAC 0000.0000.0002

2 AVF

R1
.1

R2
.2

ARP Reply
10.88.1.0/24

.4

.5

A
ARPs for 10.88.1.10 Gets MAC 0000.0000.0001

B
ARPs for 10.88.1.10 Gets MAC 0000.0000.00002

Figure 6-18 Distinct MAC Addresses Associated with the Same Virtual IP Address Permit Load Balancing 1 AVG/AVF
vIP 10.88.1.10 glbp 1 ip 10.88.1.10 vMAC 0000.0000.0001 glbp 1 ip 10.88.1.10 vMAC 0000.0000.0002 .2 10.88.1.0/24

2 AVF

R1
.1

R2

.4

.5

A
ARPs for 10.88.1.10 Gets MAC 0000.0000.0001

B
ARPs for 10.88.1.10 Gets MAC 0000.0000.00002

Implementing Router Redundancy in a Switched Network

359

Figure 6-19 GLBP Has a Failover Mechanism, Just as VRRP and HSRP Do 1 AVG/AVF
vIP 10.88.1.10 glbp 1 ip 10.88.1.10 vMAC 0000.0000.0001 glbp 1 ip 10.88.1.10 vMAC 0000.0000.0002 .2 10.88.1.0/24

2 AVF

R1
.1

R2

.4

.5

A
ARPs for 10.88.1.10 Gets MAC 0000.0000.0001

B
ARPs for 10.88.1.10 Gets MAC 0000.0000.00002

Figure 6-20 During Failover, GLBP Shifts the Role of the Virtual MAC Address Used by One Host and Associated with the Virtual IP 1 AVG/AVF
vIP 10.88.1.10 glbp 1 ip 10.88.1.10 glbp 1 ip 10.88.1.10 vMAC 0000.0000.0002 vMAC 0000.0000.0001 .2 10.88.1.0/24

2 AVF

R1
.1

R2

.4

.5

A
ARPs for 10.88.1.10 Gets MAC 0000.0000.0001

B
ARPs for 10.88.1.10 Gets MAC 0000.0000.00002

360

Chapter 6: Redundancy

Troubleshooting GLBP
GLBP allows traffic from a single common subnet to go through multiple redundant gateways while using a single virtual IP address. GLBP provides the same level of first-hop failure recovery capability as that provided by HSRP and VRRP. Cisco IOS software contains show and debug commands to allow network operators to determine the status of GLBP. These commands are useful for verifying the operation of GLBP and verifying that the design goals are being met relative to tracked objects and forwarder states. Use the show glbp command to display GLBP operational information and statistics. To display debugging messages about GLBP conditions, use the debug condition glbp command.

Single Router Mode (SRM) Redundancy
Single Router Mode (SRM) redundancy provides an alternative to having both MSFCs in a chassis active at the same time. The designated MSFC is the MSFC that comes up first or has been up the longest. The designated MSFC can be the MSFC in slot 1 or the MSFC in slot 2. There is no mechanism to decide which MSFC is the designated one; the first to come online is the designated MSFC. Figure 6-21 shows two Catalyst 6500 switches, each with redundant MSFCs.
Figure 6-21 Single Router Mode Is the Preferred Redundancy Mechanism to Use with Dual MSFCs in a 6500 Chassis

AS 10

AS 20

192.168.1.2/24 VLAN 10

VLAN 20 192.168.2.2/24

AS 4
Port 3/2 Trunk Port 5/2 int vlan10: 192.168.1.1/24 int vlan20: 192.168.2.3/24 Port 4/2 int vlan10: 192.168.1.3/24 int vlan20: 192.168.2.1/24 Port 3/3

CAT 1
Slot 1: Sup 1/MSFC 1 Slot 2: Sup 2/MSFC 2

CAT 2
Slot 1: Sup 1/MSFC 1 Slot 2: Sup 2/MSFC 2

Implementing Router Redundancy in a Switched Network

361

Using SRM redundancy, only the designated MSFC is visible to the network at any given time. The nondesignated MSFC is booted up completely and participates in configuration synchronization, which is automatically enabled when entering SRM. The configuration of the nondesignated MSFC is exactly the same as the designated MSFC, but its interfaces are kept in a “line down” state and are not visible to the network. Processes, such as routing protocols, are created on the nondesignated MSFC and the designated MSFC. All nondesignated MSFC interfaces are in a “line down” state and do not send updates to or receive updates from the network. When the designated MSFC fails, the nondesignated MSFC changes its state to become the designated MSFC, and the interface states change to “link up.” The MSFC builds its routing table while the existing Supervisor Engine switch processor entries are used to forward Layer 3 traffic. After the newly designated MSFC builds its routing table, the entries in the switch processor are updated. SRM is Cisco’s recommended method of internal MSFC redundancy.

Server Load Balancing (SLB)
Server Load Balancing (SLB) is an IOS-based solution defining a virtual server that represents a group of real servers in a server farm, as shown in Figure 6-22.
Figure 6-22 SLB Permits Server Redundancy by Way of a Virtual Server Web Servers

1 Internet IOS SLB 2

3

This environment connects clients to the IP address of a single virtual server. The virtual server IP address, as shown in Figure 6-23, is configured as a loopback address, or a secondary IP address, on each of the real servers.

362

Chapter 6: Redundancy

Figure 6-23 SLB Relies on a Virtual Server with a Virtual IP Address Real Addresses Virtual Address 192.168.1.200 192.168.1.1 – 80 192.168.1.1 – 20

192.168.1.2 – 80

When a client initiates a connection to the virtual server, the SLB function chooses a real server for the connection based on a load-balancing algorithm. The network gains scalability and availability when virtual servers represent server farms. The addition of new servers and the removal or failure of existing servers can occur at any time without affecting the availability of the virtual server. SLB is supported on the following platforms:
■ ■ ■ ■ ■

Catalyst G-L3 series Catalyst 6000 series Cisco 7200 series Cisco 7400 series Cisco 10000 series

Troubleshooting SLB
To obtain and display runtime information when monitoring and maintaining IOS SLB, use the following commands in EXEC mode:

show ip slb conns [vserver virtserver-name] [client ip-address] [detail]—Displays all connections handled by IOS SLB or, optionally, only those connections associated with a particular virtual server or client. show ip slb dfp [agent ip_addr port] [detail] [weights]—Displays information about Dynamic Feedback Protocol (DFP) and DFP agents and about the weights assigned to real servers. show ip slb reals [vserver virtserver-name] [detail]—Displays information about the real servers defined to IOS SLB. show ip slb serverfarms [name serverfarm-name] [detail]—Displays information about the server farms defined to IOS SLB.

HSRP Operations

363

■ ■

show ip slb stats—Displays IOS SLB statistics. show ip slb sticky [client ip-address]—Displays information about the sticky connections defined to IOS SLB. show ip slb vservers [name virtserver-name] [detail]—Displays information about the virtual servers defined to IOS SLB.

The debug commands related to the IOS SLB feature are as follows:
■ ■

all—Displays all debug messages for IOS SLB. conns—Displays debug messages for all connections being handled by IOS SLB, including Wireless Session Protocol (WSP) events and states. dfp—Displays debug messages for Dynamic Feedback Protocol (DFP). To display debug messages for the DFP agent subsystem, use debug ip dfp agent. firewallfarm—Displays debug messages related to firewall load balancing. icmp—Displays all ICMP debug messages for IOS SLB. natpool—Displays debug messages related to the IOS SLB client NAT pool. probe—Displays debug messages related to probes. reals—Displays debug messages for all real servers defined to IOS SLB. replication—Displays debug messages related to IOS SLB stateful backup virtual servers. sessions—Displays debug messages for all sessions being handled by IOS SLB. vservers—Displays debug messages for all virtual servers defined to IOS SLB.

■ ■ ■ ■ ■ ■

■ ■

Having taken a brief tour of VRRP, GLBP, SRM, and SLB, we now return the focus to HSRP. The operation, configuration, and monitoring of HSRP are discussed. The detailed descriptions of VRRP, GLBP, SRM, and SLB operation, configuration, and monitoring are beyond the scope of this book and course.

HSRP Operations
The main components of HSRP are an active router, a standby router, and a virtual router. In Figure 6-24, the active router forwards data packets and transmits hello messages. The standby router monitors the active router’s status and quickly begins forwarding packets if the active router fails. The standby router also transmits hello messages to other routers in the HSRP group. The virtual router doesn’t really exist. It simply represents a consistently available router with an IP address and MAC address to the hosts on a network.

364

Chapter 6: Redundancy

Figure 6-24 HSRP Standby Groups Consist of Multiple Routers Performing Specific Roles

HSRP Group Standby Router Virtual Router Active Router

It is possible that several other routers exist in an HSRP standby group. These other routers monitor HSRP hello messages, but do not respond. They function as normal routers that forward packets sent to them but do not forward packets addressed to the virtual router. These additional HSRP routers remain in init state. How does the standby router know when the active router fails? The standby router stops receiving hello messages from the active router and takes on the role of the active router. Because the hosts are using a virtual IP and MAC address, the hosts see minimal or no service disruption. If both the active and standby routers fail, all other routers in the group contend for the active and standby roles. The router with the lowest MAC address becomes the active router unless an HSRP priority is configured. To facilitate load sharing, a single router might be a member of multiple HSRP standby groups on a single segment. Each standby group emulates a single virtual router. A LAN can have up to 255 standby groups. Multiple HSRP groups are also supported on VLAN, portchannel, and Bridge Group Virtual Interface (BVI) interfaces. In Figure 6-25, both Router A and Router B are members of Groups 1 and 2. Router A is the active forwarding router for Group 1 and the standby router for Group 2. Router B is the active forwarding router for Group 2 and the standby router for Group 1. Routers also can simultaneously provide redundant backup and perform load sharing across different IP subnets, as shown in Figure 6-26.

HSRP Operations

365

Figure 6-25 Routers Can Belong to Multiple Groups on the Same Subnet in a VLAN Active Router for Group 1 Standby Router for Group 2 Virtual Router Network 172.16.10.0 A VLAN 10 Group 2

Group 1

Virtual Router

B Router B

Standby Router for Group 1 Active Router for Group 2

Figure 6-26 Routers Can Belong to Multiple Groups in Multiple VLANs

Group 1 Virtual Router Network 172.16.10.0

Group 2 Virtual Router

VLAN 10

Network 172.16.20.0 Virtual Router Group 3 Virtual Router Group 4 VLAN 20

This is possible because for each standby group, an IP address and a single, well-known MAC address with a unique group identifier are allocated to the group.

366

Chapter 6: Redundancy

A group’s IP address is in the range of addresses belonging to the subnet in use on the LAN. However, the group’s IP address must differ from the addresses allocated as interface addresses on all routers and hosts on the LAN, including virtual IP addresses assigned to other HSRP groups. Initially, the standby group has no active router. Within the standby group, the router with the highest standby priority becomes the active router. The default priority for an HSRP router is 100, which can be configured. The active router responds to traffic for the virtual router. If an end station sends a packet to the virtual router MAC address, the active router receives and processes that packet. If an end station sends an ARP request with the virtual router IP address, the active router replies with the virtual router MAC address. In Figure 6-27, Router A has a priority of 200 and Router B has a default priority of 100. Router A assumes the active router role and forwards all frames addressed to the well-known MAC address of 0000.0c07.acxx, where xx is the HSRP group identifier. In Figure 6-27, the HSRP group number is 0x0a or 10. The well-known MAC address of 0000.0c07.acxx is used for all HSRP configurations, unless HSRP is configured to use a different MAC address.
Figure 6-27 The Router with the Highest HSRP Priority Becomes the Active Router. The Active Router Responds to ARP Requests with the MAC Address of the Virtual Router. I Need To Get To
172.16.3.127

Use MAC Address
0000.0c07.ac0a

Router A Priority 200
172.16.10.82 0010.f6b3.d000

Virtual Router
172.16.10.110

Router B Priority 100
172.16.10.169 0010.0b79.5800

Virtual Router

0000.0c07.ac0a

Virtual Router File Server A
172.16.3.127

Core

The Virtual Router MAC Address
In Figure 6-28, the MAC address used by the virtual router is made up of the following three components:
■ ■

Vendor ID—The first 3 bytes of the MAC address. HSRP code—2 bytes (always 07.ac) indicating that the MAC address is for an HSRP virtual router. Group ID—The last byte of the MAC address.

HSRP Operations

367

Figure 6-28 The HSRP Well-Known Virtual MAC Address Is Crucial to HSRP Operation Router#show ip arp HSRP Group 10 172.16.10.82 172.16.10.110 172.16.10.169

Protocol Internet Internet Internet

Address Age 172.16.10.82 172.16.10.169 172.16.10.110

(min) -

Hardware Addr 0010.f6b3.d000 0010.0b79.5800 0010.0c07.ac0a

Type ARPA ARPA ARPA

Interface vlan10 vlan10 vlan10

Vendor Code

HSRP Group Number HSRP Well-Known Virtual MAC Address

To display the virtual IP and MAC address, use the command show standby in privileged EXEC mode, as shown in Example 6-1.
Example 6-1 The show standby Command Is Very Useful in Monitoring HSRP and Verifying HSRP Operation
Router#show standby FastEthernet0/0 - Group 0 Local state is Active, priority 100 Hellotime 3 holdtime 10 Next hello sent in 00:00:00.630 Hot standby IP address is 10.1.1.1 configured Active router is local Standby router is 10.1.1.3 expires in 00:00:09 Standby virtual mac address is 0000.0c07.ac00 FastEthernet0/1 - Group 0 Local state is Standby, priority 100 Hellotime 3 holdtime 10 Next hello sent in 00:00:01.542 Hot standby IP address is 10.1.3.1 configured Active router is 10.1.2.3 expires in 00:00:08 Standby router is local Standby virtual mac address is 0000.0c07.ac00

368

Chapter 6: Redundancy

HSRP Messages
All routers in a standby group send or receive HSRP messages. These messages are used to determine and maintain the router roles within the group. HSRP messages are encapsulated in the data portion of User Datagram Protocol (UDP) packets (see Figure 6-29) and use port number 1985. HSRP messages use the interface IP address, not the virtual IP address, as the source IP address. The HSRP messages are sent to the destination multicast address (224.0.0.2). This is the multicast address used to communicate with all routers. The Time-To-Live (TTL) on the packet is set to 1.
Figure 6-29 HSRP Messages Use the Data Portion of the UDP Segment

1 Octet
Version Holdtime

1 Octet
Op Code Priority

1 Octet
State Group Authentication Data Authentication Data Virtual IP Address

1 Octet
Hello Time Reserved

The HSRP message fields are as follows:
■ ■

Version—Indicates the version of HSRP. Op Code—Describes the type of message contained in this packet: — Hello = 0 Messages are sent to indicate that a router is running and can become either the active or standby router. — Coup = 1 Messages are sent when a router wants to become the active router. — Resign = 2 Messages are sent when a router no longer wants to be the active router.

State—Describes the current state (active, standby, init) of the router sending the message. Hellotime—Meaningful only in hello messages. This field stores the approximate period, in seconds, between the hello messages that the router sends. Holdtime—Meaningful only in hello messages. This field stores the amount of time that the current hello message should be valid. The time is given in seconds. Priority—Used to elect the active and standby routers. When the priorities of two different routers are compared, the router with the numerically higher priority wins. In the case of routers with equal priority, the router with the higher IP address wins. Group—Identifies the standby group. Values of 0 to 255 are valid. Reserved—An 8-bit field reserved for future use.

■ ■

HSRP Configuration

369

■ ■

Authentication Data—Contains a clear-text eight-character reused password. Virtual IP Address—Contains the IP address of the virtual router used by this group.

Internally, each router in the standby group implements a state machine. Only the active and standby routers send periodic HSRP messages after the protocol has completed the election process.

HSRP States
HSRP defines six HSRP states in which an HSRP-enabled router can exist:

Initial—The state from which the routers begin the HSRP process. This state indicates that HSRP is not running. It is entered via a configuration change or when an interface first comes up. Learn—The router has not determined the virtual IP address and has not yet seen an authenticated hello message from the active router. In this state, the router is still waiting to hear from the active router. Listen—The router knows the virtual IP address but is neither the active router nor the standby router. It listens for hello messages from those routers. Routers other than the active and standby router remain in the listen state. Speak—The router sends periodic hello messages and actively participates in the election of the active or standby router. A router cannot enter Speak state unless it has the virtual IP address. Standby—The router is a candidate to become the next active router and sends periodic hello messages. Excluding transient conditions, there must be at most one router in the group in Standby state. Active—The router is currently forwarding packets that are sent to the group virtual MAC address. The router sends periodic hello messages. Excluding transient conditions, there must be at most one router in Active state in the HSRP group.
Interactive Media Activity Drag and Drop: HSRP States

After completing this activity, you will have a basic understanding of HSRP states.

HSRP Configuration
To configure a router as a member of an HSRP standby group, enter the following interface configuration command:
standby group-number ip virtual-ip-address

370

Chapter 6: Redundancy

group-number—Optional. The HSRP group to which this interface belongs. Specifying a unique group number in the standby command lets you create multiple HSRP groups. The default group is 0. virtual-ip-address—The IP address of the virtual HSRP router.

In Cisco IOS software Release 12.1.3.T and later, HSRP has been changed to support ICMP redirect. Prior versions of IOS require disabling of ICMP redirects. While running HSRP, it is important that the end-user stations cannot discover the actual MAC addresses of the routers as the destination MAC for the default gateway. Any protocol that tells a host the router’s actual address must be disabled. To ensure that the actual addresses of the participating HSRP routers are not discovered, enabling HSRP on a Cisco router interface automatically disables ICMP redirects on that interface. The standby ip command changes the interface to the appropriate state. Figure 6-30 shows an example of the state message, automatically generated upon successful enabling of HSRP.
Figure 6-30 Console Messages Indicate HSRP State Changes

Backbone
FastEthernet 0/1

HSRP Group 50
FastEthernet 0/1

Virtual Router

A
FastEthernet 0/0 10.1.1.2 10.1.1.1

B
FastEthernet 0/0 10.1.1.3

IP Address: 10.1.1.50 Default Gateway 10.1.1.1

1w0d: %STANDBY-6-STATECHANGE: Standby: 50: FastEthernet0/0 state Speak -> Standby 1w0d: %STANDBY-6-STATECHANGE: Standby: 50: FastEthernet0/0 state Standby -> Active

Output from the show running-config command shows the following:
■ ■ ■

Interface FastEthernet 0/0 is a member of HSRP standby Group 50. The virtual router IP address is 10.1.1.1. ICMP redirects are disabled.

HSRP Configuration

371

To remove an interface from an HSRP group, enter the no standby group ip command.

How HSRP Addresses Redundancy Issues
HSRP provides a way for end nodes to keep communicating between networks even if individual local routers become unavailable. HSRP routers on a LAN segment or VLAN communicate among themselves to designate three possible router states:
■ ■ ■

Active Standby Init

If an end node sends a packet to the virtual MAC address, the active router receives that packet and processes it. If an end node sends an ARP request, the active router replies with the virtual MAC address. The routers participating in HSRP can be configured to respond with their burned-in MAC address (BIA) instead of a virtual MAC address. In Figure 6-31, Anderson is configured to use the virtual router as the default. Only the virtual router appears in the Anderson configuration. Broadway is not listed. Upon booting, the routers might elect Broadway as the active router so that Broadway will deliver packets from Anderson. If Broadway or its LAN interface goes offline, Central Park takes over as the active router, continuing with the delivery of Anderson packets. The changes taking place in the network remain transparent to Anderson. If a third HSRP router is added to the LAN segment, this router begins acting as the new standby router but remains in init state.
Figure 6-31 Only the IP Address of the Virtual Router Appears on the Anderson TCP/IP Configuration Broadway To ISP

HSRP Router Anderson To ISP Central Park

HSRP also works for proxy ARP. When an active HSRP router receives an ARP request for a node that is not on the local LAN, it replies with the virtual MAC address. If the router that originally sent the ARP reply later loses its connection, the new active router can still deliver

372

Chapter 6: Redundancy

the traffic. Although HSRP works with proxy ARP configurations, it is not a recommended configuration for administrative and security reasons.

HSRP Standby Priority
Each standby group has its own active and standby routers. The network administrator can assign a priority value to each router in a standby group. This lets the administrator control the order in which active routers for that group are selected. To set a router’s priority value, enter the following command in interface configuration mode:
standby group-number priority priority-value
■ ■

group-number—Optional. The HSRP standby group. The range is 0 to 255. priority-value—The number that prioritizes a potential hot standby router. The range is 0 to 255. The default is 100.

The router in an HSRP group with the highest priority becomes the forwarding router. The tiebreaker for matching priorities is the higher IP address. Figure 6-32 shows that Router A FastEthernet 0/0 has a priority value of 150 in HSRP standby Group 50.
Figure 6-32 The Priority Value Determines the Active HSRP Router for an HSRP Group

Backbone

HSRP Group 50

FastEthernet 0/1

Virtual Router

FastEthernet 0/1

A
FastEthernet 0/0 10.1.1.2

B
10.1.1.1
FastEthernet 0/0 10.1.1.3

IP Address: 10.1.1.50 Default Gateway 10.1.1.1

A (config-if) #standby 50 priority 150

HSRP Configuration

373

HSRP Standby Preempt
The standby router assumes the active router role when the active router fails or is removed from service. This new active router remains as the forwarding router even when the former active router with the higher priority regains service in the network. The former active router can be configured to resume the forwarding router role from a router with a lower priority. To make a router resume the forwarding router role, enter the command standby group-number preempt in interface configuration mode. When the standby preempt command is issued, the interface changes to the appropriate state, as shown in Figure 6-33.
Figure 6-33 The preempt Option Permits a Router to Immediately Take Over as the Active Router Whenever the Priority Is Higher

Backbone

HSRP Group 50

FastEthernet 0/1

Virtual Router

FastEthernet 0/1

A
FastEthernet 0/0 10.1.1.2

B
10.1.1.1
FastEthernet 0/0 10.1.1.3

IP Address: 10.1.1.50 Default Gateway 10.1.1.1

A (config-if) #standby 50 preempt

The following message is automatically generated as soon as the router becomes active in the network:
3w1d : %STANDBY-6-STATECHANGE: STANDBY: 50: FastEthernet0/0 state standby Active

HSRP Hello Timers
An HSRP-enabled router sends hello messages to indicate that it is running and that it can become either the active or standby router. The hello message contains the router’s priority, as

374

Chapter 6: Redundancy

well as a hellotime and holdtime value. The hellotime value indicates the interval between the hello messages what the router sends. The holdtime value specifies how long the current hello message is considered valid. If an active router sends a hello message, receiving routers consider that hello message valid for one holdtime. The holdtime value should be at least three times the value of the hellotime. The hellotime and holdtime parameters can be configured. To configure the time between hellos and the time before other group routers declare the active or standby router “down,” enter the following command in interface configuration mode:
standby group-number timers hellotime holdtime

group-number—Optional. The group number on the interface to which the timers apply. The default is 0. hellotime—The hello interval in seconds. This is an integer from 1 to 255. The default is 3 seconds. holdtime—The time before the active or standby router is declared down. This is an integer from 1 to 255. The default is 10 seconds.

In Figure 6-34, the hellotime is set to 5 seconds, and the holdtime is set to 15 seconds. To reinstate the default standby timer values, enter the no standby group timers command.
Figure 6-34 The HSRP Hello and Hold Timers Can Be Configured

Backbone

HSRP Group 50

FastEthernet 0/1

Virtual Router

FastEthernet 0/1

A
FastEthernet 0/0 10.1.1.2

B
10.1.1.1
FastEthernet 0/0 10.1.1.3

IP Address: 10.1.1.50 Default Gateway 10.1.1.1

A (config-if) #standby 50 timers 5 15

HSRP Configuration

375

HSRP Interface Tracking
In many situations, an interface’s status directly affects which router needs to become the active router, particularly when each router in an HSRP group has a different path to resources within the campus network. In Figure 6-35, Routers A and B reside in a branch office. These two routers each support a FastEthernet link to the backbone. Router A has the higher priority and is the active forwarding router for standby Group 50. Router B is the standby router for that group. Routers A and B exchange hello messages through their FastEthernet 0/0 interfaces.
Figure 6-35 The HSRP Interface Tracking Option Lets the Standby Router Become Active When an Uplink Fails on the Active Router

Backbone

HSRP Group 50

FastEthernet 0/1

Virtual Router

FastEthernet 0/1

A
FastEthernet 0/0 10.1.1.2

B
10.1.1.1
FastEthernet 0/0 10.1.1.3

IP Address: 10.1.1.50 Default Gateway 10.1.1.1

A (config-if) #standby 50 track fastethernet 0/1 55

If Router A FastEthernet 0/1 goes down, Router A loses the direct connection to the backbone. Although this doesn’t prevent traffic from reaching the backbone, it does lead to an inefficient traffic flow. The FastEthernet 0/0 interface on Router A is still active, so packets destined for the core are still sent to Router A and are forwarded in turn to Router B, regardless of HSRP. The standby track option can be used to prevent this situation (in conjunction with the standby preempt command). To configure HSRP tracking, enter the following command in interface configuration mode:
standby group-number track type number interface-priority

376

Chapter 6: Redundancy

The value indicated by the standby track command is the value that gets decremented from the node’s priority if the specified interface goes down. Multiple standby track commands can be used to list multiple interfaces. If multiple interfaces fail, the decrement values are cumulative. For example, if the FastEthernet 0/0 interface on Router A goes down, the router’s HSRP priority is lowered by 55. Because this is lower than the default priority being used by Router B, Router B takes over as the active router, providing optimal flow to the backbone.

Verify HSRP Configuration
To display the status of the HSRP router, enter the following command in privileged mode:
show standby type-number group brief

type-number—Optional. The target interface type and number for which output is displayed. group—Optional. A specific HSRP group on the interface for which output is displayed. brief—Optional. Displays a single line of output summarizing each standby group.

■ ■

If none of the optional interface parameters are used, the show standby command displays HSRP information for all interfaces, as shown in Example 6-2.
Example 6-2 The show standby Command Displays Useful HSRP Information
ISP#show standby FastEthernet0/0 - Group 50 Local state is Active, priority 95, may preempt Hellotime 3 holdtime 10 Next hello sent in 00:00:00.782 Hot standby IP address is 10.1.1.1 configured Active router is local Standby router is 10.1.1.3 expires in 00:00:09 Standby virtual mac address is 0000.0c07.ac32 Tracking interface states for 1 interface, 0 up: Down FastEthernet0/1 Priority decrement: 55

Lab 6.5.1 Hot Standby Router Protocol

In this lab exercise, you configure HSRP on a pair of routers to provide redundant router services to a network.

HSRP Configuration

377

Lab 6.5.2 Multigroup Hot Standby Router Protocol

In this lab exercise, you configure Multigroup Hot Standby Router Protocol (MHSRP) on a pair of routers to provide redundant router services to a network.

HSRP over Trunk Links
To configure HSRP over an Interswitch Link (ISL) between VLANs, follow these steps: Step 1 Step 2 Step 3 Define the encapsulation format. Define an IP address. Enable HSRP.

HSRP is also supported over 802.1Q trunks. Figure 6-36 and Example 6-3 illustrate the configuration for two HSRP-enabled routers participating in two separate VLANs using ISL. 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 ISL, you can eliminate situations in which a single point of failure causes traffic interruptions.
Figure 6-36 Network Topology for Configuring HSRP over Trunk Links VLAN 10 VLAN 20 VLAN 10 VLAN 20

ISL Link Carrying Both VLAN 10 and 20 Traffic ISL Link Carrying Both VLAN 10 and 20 Traffic A A ISL Link Carrying Both VLAN 10 and 20 Traffic B

172.16.10.110 Virtual Router for VLAN 10

172.16.20.120 Virtual Router for VLAN 20

Example 6-3 A Complete HSRP Configuration Involves HSRP Groups, Priority, and Preempt Options
! Configuration for Router A: interface FastEthernet 1/1.10 encapsulation isl 10 ip address 172.16.10.2 255.255.255.0 standby 1 ip 172.16.10.110

continues

378

Chapter 6: Redundancy

Example 6-3 A Complete HSRP Configuration Involves HSRP Groups, Priority, and Preempt Options (Continued)
standby 1 priority 105 standby 1 preempt interface FastEthernet 1/1.20 encapsulation isl 20 ip address 172.16.20.2 255.255.255.0 standby 2 ip 172.16.20.120 standby 2 priority 50 ***Production, insert 2-point rule here. ! Configuration for Router B: interface FastEthernet 1/1.10 encapsulation isl 10 ip address 172.16.10.3 255.255.255.0 standby 1 ip 172.16.10.110 standby 1 priority 50 interface FastEthernet 1/1.20 encapsulation isl 20 ip address 172.16.20.3 255.255.255.0 standby 2 ip 172.16.20.120 standby 2 priority 105 standby 2 preempt

Troubleshooting HSRP
To enable HSRP debugging, the debug standby command is used to enable output of HSRP state and packet information for all standby groups on all interfaces. A debug condition was added in Cisco IOS software Release 12.0(2.1) that allows the output from the debug standby command to be filtered based on interface and group number. This command uses the debug condition paradigm introduced in Cisco IOS software Release 12.0:
debug condition standby interface group

The interface specified must be a valid interface that can support HSRP. The debug conditions can be set for groups that do not exist, thereby allowing debug information to be captured during the initialization of a new group. The standby debug order must be configured for any debug output to be produced. If no standby debug conditions are specified, output is produced for all groups on all interfaces. Configuring at least one standby debug condition causes the output to be filtered.

Summary

379

Summary
The resiliency and availability features supported by the Cisco Catalyst family of switches are well-suited to campus LAN designs that achieve high availability through a combination of device-level and network-level redundancy. The network resiliency features span Layer 2 and Layer 3 boundaries and may be deployed where needed throughout the three-tiered Access, Distribution, Core design model. With some care in configuring the redundant network and tuning the protocol timers within the switches, interruption of network services caused by network infrastructure failures can be held in the range of 0 to 10 seconds. With these short failover times, very high network availability can be achieved by controlling the overall network failure rate. After completing this chapter, you should be able to
■ ■ ■ ■ ■

Implement hardware redundancy on the Catalyst series of switches Identify the virtual router for a given set of switch block devices Configure HSRP on the switch block devices to ensure continual inter-VLAN routing Maintain packet forwarding by configuring the active and standby HSRP router roles Ensure the role of the active router by assigning a preempt status

380

Chapter 6: Redundancy

Key Terms
default gateway Provides a definitive location for IP packets to be sent in case the source device has no IP routing functionality built into it. This is the method most end stations use to access nonlocal networks. The default gateway can be set manually or learned from a DHCP server. Gateway Load Balancing Protocol (GLBP) A Cisco-proprietary protocol that protects data traffic from a failed router or circuit, like HSRP and VRRP, while allowing packet load sharing between a group of redundant routers. hello interval The time that elapses between the sending of HSRP hello packets. The default is 3 seconds. holdtime The time it takes before HSRP routers in an HSRP group declare the active router to be down. The default is 10 seconds. Hot Standby Router Protocol (HSRP) The Layer 3 Cisco-proprietary protocol that allows a set of routers on a LAN segment to work together to present the appearance of a single virtual router or default gateway to the hosts on the segment. HSRP enables fast rerouting to alternate default gateways should one of them fail. HSRP group Routers on a subnet, VLAN, or subset of a subnet participating in an HSRP process. Each group shares a virtual IP address. The group is defined on the HSRP routers. HSRP state The descriptor for the current HSRP condition for a particular router interface and a particular HSRP group. The possible HSRP states are Initial, Learn, Listen, Speak, Standby, and Active. ICMP Router Discovery Protocol (IRDP) Hosts supporting IRDP dynamically discover routers to access nonlocal networks. IRDP allows hosts to locate routers (default gateways). Router discovery packets are exchanged between hosts (IRDP servers) and routers (IRDP clients). preempt An HSRP feature that lets a router with the highest priority immediately assume the active role at any time. priority An HSRP parameter used to facilitate the election of an active HSRP router for an HSRP group on a LAN segment. The default priority is 100. The router with the greatest priority for each group is elected as the active forwarder for that group. proxy ARP Proxy ARP allows an Ethernet host with no knowledge of routing to communicate with hosts on other networks or subnets. Such a host assumes that all hosts are on the same local segment and that it can use ARP to determine their hardware addresses. The proxy ARP function is handled by routers.

Check Your Understanding

381

Server Load Balancing (SLB) Balances services across numerous servers at speeds of millions of packets per second. Commonly deployed with the Cisco IOS software on Catalyst 6000 family of switches. SLB is a software solution using the advanced application-specific integrated circuits (ASICs) on the Catalyst 6000. Single Router Mode (SRM) Addresses the drawback of the previous HSRP-based MSFC redundancy scheme (designated MSFC versus nondesignated MSFC). When SRM is enabled, the nondesignated router is online, but all its interfaces are down. Thus, it does not hold any routing table information. This means that if the DR fails, there will be some delay before the nondesignated router coming online has a complete route table. To help account for this, the information being used before the failure by the Supervisor for Layer 3 forwarding is maintained and updated with any new information from the new designated router. tracking This HSRP feature allows you to specify other interfaces on the router for the HSRP process to monitor. If the tracked interface goes down, the HSRP standby router takes over as the active router. This process is facilitated by a decrement to the HSRP priority resulting from the tracked interface line protocol going down. Virtual Router Redundancy Protocol (VRRP) Provides functions equivalent to HSRP but is supported by multiple vendors. It is designed to eliminate a single point of failure that is unavoidable in static default routing environments.

Check Your Understanding
Use the following review questions to test your understanding of the concepts covered in this chapter. Answers are listed in Appendix A, “Check Your Understanding Answer Key.”
1. With redundant Supervisor Engines and MSFCs in a Catalyst 6500 switch running

SRM, which of the following statements is accurate?
A. The nondesignated MSFC is active and has the same configuration as the designated

MSFC.
B. The nondesignated MSFC is inactive and has the same configuration as the desig-

nated MSFC.
C. The nondesignated MSFC is inactive and has a configuration distinct from the

designated MSFC.
D. The nondesignated MSFC is active and has a configuration distinct from the des-

ignated MSFC.

382

Chapter 6: Redundancy

2. The GLBP router responsible for allocating MAC addresses is which of the following? A. Active virtual gateway B. Active virtual forwarder C. Primary virtual forwarder D. Secondary virtual forwarder 3. The GLBP router responsible for forwarding packets sent to a particular MAC address

is which of the following?
A. Active virtual gateway B. Active virtual forwarder C. Primary virtual forwarder D. Secondary virtual forwarder 4. Which IETF standard introduced in RFC 2338 parallels the Cisco-proprietary HSRP? A. HSRP 2 B. IRDP C. GLBP D. VRRP 5. How many virtual MAC addresses are used per HSRP group? A. 1 B. 2 C. 3 D. 4 6. SLB is an IOS-based solution defining a virtual server that represents a group of what? A. Real servers in separate intranets B. Virtual servers in a server farm C. Real servers in a server farm D. Virtual servers in separate intranets

Check Your Understanding

383

7. How many standby routers can there be in a given HSRP group? A. 1 B. 2 C. 3 D. 4 8. HSRP can be configured on distribution layer Catalyst 3550 switches using switch

virtual interfaces. However, on distribution layer routers, multigroup HSRP is configured on trunk links using what?
A. Null interfaces B. Loopbacks C. Bridge virtual interfaces D. Subinterfaces 9. When configuring HSRP, each HSRP router interface must be configured with which of

the following? (Select all that apply.)
A. A virtual MAC address B. A real MAC address C. A virtual IP address D. A real IP address 10. Which HSRP option(s) is/are used to guarantee an immediate change to active state on

an HSRP router?
A. preempt B. tracking C. priority D. hello time

Objectives
After completing this chapter, you will be able to perform tasks related to the following:

Describe some of the major components of a Cisco AVVID (Architecture for Voice, Video, and Integrated Data) network solution. Explain how Layer 2 multicast addresses map to Layer 3 multicast addresses. Explain the role of Internet Group Management Protocol (IGMP) in multicasting. Understand the purpose of IGMP snooping and Cisco Group Management Protocol (CGMP) with switched traffic. Understand the operation of shared trees versus source trees in multicast routing. List the major multicast routing protocol solutions. Describe the role of the auxiliary virtual LAN (VLAN) with voice traffic. Explain the role of class of service (CoS), type of service (ToS), and Differentiated Services Code Point (DSCP) in traffic classification. Understand the importance of quality of service (QoS) with IP Telephony solutions.

■ ■ ■

■ ■ ■ ■

Chapter 7 Cisco AVVID
Traditionally, separate networks have been designed and implemented within the enterprise for data, voice, and video applications. These have been deployed in parallel and operated in isolation, often implemented and managed by separate teams. In the past, networking vendors typically offered similar enterprise network architectures that were, almost without exception, proprietary, closed, and nonhierarchical. These separate networks encompass enterprise local and wide-area networks. They have been built to interconnect private branch exchange (PBX) equipment, H.320 videoconferencing equipment, and routers. The networks have been provisioned over dedicated leased lines for PBX and H.320 video, with a combination of leased lines, Frame Relay, and ATM for data. As client/server networking grew, the needs of enterprises were also evolving. Applying technology to business practices such as sales, support, customer response management, accounting, and supply chain was reaping tremendous benefits in increased efficiency and lower costs. Many of these new technologies supported entirely different business models (for example, businessto-consumer e-commerce, business-to-business online exchanges, and so on). In other cases, these technologies were used to reengineer existing business practices. In all cases, the needs for reliability, performance, and ease of deployment and management remain crucial, because these applications have become more critical to an enterprise’s success (whether profit-making or service-oriented). In networking today, corporations are looking for strategies to integrate disparate networking technologies over a single common network infrastructure. This trend started many years ago in the internetworking area when corporate networks began the migration of delay-sensitive, mission-critical Systems Network Architecture (SNA) data traffic across an IP infrastructure. Now, people are examining the existing and often separate data, voice, and video network infrastructures and determining the most efficient ways of bringing them together.

386

Chapter 7: Cisco AVVID

Most corporations have voice networks anchored around PBX systems connected to a Public Switched Telephone Network (PSTN), but most data networks are IP-based and anchored around switches and routers. Where traditional telephony in fixed 64-kbps bandwidth increments is carried across a circuit-switched PBX infrastructure, other dynamic data applications are consolidated over an intelligent IP-based backbone.

Introduction to Cisco AVVID
The Cisco Architecture for Voice, Video, and Integrated Data (AVVID) is composed of a holistic network design infrastructure. IP Telephony, campus LAN switching, wireless networks, security, storage networking, and multicasting are major components addressed by AVVID. This section discusses AVVID at a high level, describing how it is applied in production networks.

Examining the Cisco AVVID Framework
With today’s separate infrastructures, two strategic directions toward the convergence of data, voice, and video are possible, as illustrated in Figures 7-1 and 7-2.
Figure 7-1 A Typical Network Infrastructure Separates the Voice and Data Components Voice Network PSTN IP Data Network IP WAN

PBX

Catalyst Backbone Gigabit Ethernet

Proprietary Digital Phones

End-User PC 100 M Ethernet

Introduction to Cisco AVVID

387

Figure 7-2 A Converged Voice and Data Network Is Now Common in Enterprise Networks Coverage of Network (Data Over Voice) PSTN IP WAN OR Coverage of Network (Data Over Voice) PSTN IP WAN

PBX

Catalyst Backbone Gigabit Ethernet Switches Routers

IP Telephony to the Desktop

Video Desktop

One approach calls for the use of the PBX to support the kinds of interfaces and bandwidth required by today’s IP-based data applications. This means interfaces such as Ethernet, Fast Ethernet, Gigabit Ethernet, and others on PBX platforms. Most data desktops are now connected at speeds of 10 or 100 Mbps, making this a strategy without merit. Fundamentally, the PBX is a time-division multiplexing (TDM) system built on 64-kbps time slots with aggregate capacity in the tens of megabits per second. Although this is adequate for voice only, any attempt to drive data bandwidths shows that a whole new breed of platform would be required beyond the PBX. It is also interesting to look back in history at other attempts to accomplish this integration. In the 1980s, when a 2400-bps modem was standard and a 9600-bps modem was almost unheard of, Integrated Services Digital Network (ISDN) at 64 kbps per channel was being touted as the next high-speed desktop technology. Naturally this was well-suited to be terminated on the PBX, given its conformance to the bandwidth hierarchy of the PBX systems. Interestingly, this still did not take the marketplace by storm, even before technologies such as Ethernet were on the radar screen. Vendor investment in traditional PBX technology has not scaled to meet the demands of a converged network. Most of the networking innovation during the last ten years has been developed around IP networks because of the pervasiveness and rapid development of the Internet. This includes

388

Chapter 7: Cisco AVVID

World Wide Web technology, streaming video, IP Telephony, higher-speed IP transport mechanisms, and more intelligence in the network to cope with new classes of delay-sensitive, mission-critical applications. This has all lead to the future of integrated networks, one in which data, voice, and video share a common IP data network. Naturally, things will need to be done to prepare for this eventuality. The first step is to understand the architecture that will make this convergence a reality and some of the more specific considerations in the data networking infrastructure that will make this migration easier. The Cisco solution for the convergence of data, voice, and video is Cisco AVVID. Cisco AVVID has three fundamental components, as shown in Figure 7-3:

Clients are the user end stations or appliances that are used to communicate with the network or other users. Some examples are PCs, telephone devices, and video cameras. Applications for Cisco AVVID are written to an open-standards environment and, as such, will be supplied by both Cisco and third-party application developers. Some examples are interactive voice response (IVR), call center, and unified messaging. Infrastructure is the network on which both the clients and applications reside. The network is IP-based using intelligence inherent in the platforms to provide the flexibility and scalability to support the convergence of different media. Examples of network devices are Catalyst switches, Cisco routers, and voice gateways, as shown in Figure 7-4.

Cisco AVVID Network Infrastructure
Cisco AVVID network infrastructure, illustrated in Figure 7-5, is the network foundation that is recommended for rapid and seamless deployment of emerging technologies and new Internet business solutions into the retail environment.
Figure 7-3 Cisco AVVID Is Distributed, Adaptive, Open, and Manageable Clients
Se rv ice
Internet Application Technologies

Infrastructure Cisco IP Fabric

Su

Applications
ppo rt

Management

Directory

Policy

Cisco CallManager Servers Message Servers Telephony Application Servers Directory Servers

Cisco SoftPhone

Network Services

Video PCs IP Phones Gateway

Platform

Switch

Router

Content Servers

Introduction to Cisco AVVID

389

Figure 7-4 The Cisco AVVID Framework Integrates IP Networks for Large Organizations Supply Chain Internet Business Integrators Internet Middleware Layer EDS Customer Care Cap Gemini Ernest & Young E-Learning Internet Commerce IBM Workforce Optimization KPMG

Cisco Systems

Messaging Contact Center Multimedia Voice Call Processing

Collaboration Video on Demand Personal Productivity

Policy Management Security Content Distribution SLA Management Address Management

Intelligent Network Classification
Management Intelligent Network Services Accounting Real Time Services Load Balancing Cisco Systems Multicast DNS Services Caching Security

QoS

Network Platforms Clients

Figure 7-5 The Cisco AVVID Network Infrastructure Integrates Traditional WAN Technologies with Modern Metropolitan-Area Network (MAN) Technologies, Such as Dense Wavelength Division Multiplexing (DWDM) VM/UM

Router Metro PoS, DWDM DPT

Branch Office West Coast Headquarters IP WAN ATM, LL, FR

Rest of World

East Coast Headquarters

390

Chapter 7: Cisco AVVID

As with any architecture, Cisco AVVID relies on a strong and stable foundation. This foundation is built on the multiprotocol routers and multilayer LAN switches that are used as building blocks for enterprise networks, as shown in Figure 7-6.
Figure 7-6 Cisco AVVID Provides a Cohesive, Integrated, and Optimized Network Campus 1 Campus 2

Cisco 6500s

Cisco 6500s

Campus 3 Internet Router

Cisco 6500s Cisco 7200s Frame Relay

Internet

Cisco 2600 Branch Office

Cisco 2600 Branch Office

Branch Office 1 – 120

Although best-of-breed solutions might promise high performance for a specific device or application, performance is limited by the network’s weakest link. Only a cohesive, integrated, optimized network can ensure the best network performance. The Cisco AVVID network infrastructure is not only tailored to the enterprise’s characteristics, but it is also thoroughly lab tested and documented to provide the following benefits:

Speed—A defined architectural framework and consistent services allow rapid deployment of new applications and let an enterprise quickly address change without reengineering the network. Reliability—A consistent architectural approach increases network dependability. Flexibility—The architecture allows easy transitions to changing business requirements.

■ ■

Introduction to Cisco AVVID

391

Interoperability—All equipment and software are configured for the ideal fit that allows seamless operation. Multiple solutions work together based on a common architectural approach. Simplification—Products are strategically deployed in alignment with the architectural framework, resulting in streamlined processes. Reduced cost—The predefined architecture minimizes the resources and time required to implement network strategies, measurements, and Resource Reservation Protocol (RSVP) signaling for admission control and reservation of resources. Security—Ensures network security through authentication, encryption, and failover. Security features include stateful, application-based filtering (context-based access control), defense against network attacks, per-user authentication and authorization, and real-time alerts. High availability—Optimizes the design and tools to ensure end-to-end availability for services, clients, and sessions.

Cisco AVVID Intelligent Network Services
The Cisco AVVID network infrastructure consists of the e-business infrastructure (physical layer) and intelligent network services, which is composed of numerous networking technologies and topologies with a corresponding large number of possible designs and architectures. Cisco lab-tested these various full-scale network designs at Research Triangle Park, North Carolina. The results are captured in Solution Reference Network Design Guides. The net result is a blueprint of optimal blending of equipment, features, and management tools that match business criteria. In addition to the physical layer, Cisco deploys Intelligent Network Services, such as quality of service (QoS) and security, to keep the network at peak performance. QoS manages a network’s delay, delay variation (jitter), bandwidth, and packet loss parameters to meet the diverse needs of voice, video, and data applications. QoS features provide value-added functionality, such as network-based application recognition (NBAR) for classifying traffic on an application basis, a service assurance agent (SAA) for end-to-end QoS measurements, and RSVP signaling for admission control and reservation of resources. Figure 7-7 illustrates queuing that prioritizes voice traffic. Low-latency queuing introduces priority queuing (PQ) for voice traffic and relies on Weighted Fair Queuing (WFQ) for the remaining traffic classes.

392

Chapter 7: Cisco AVVID

Figure 7-7 Low-Latency Queuing Introduces a Priority Queue for Voice Traffic and Relies on Weighted Fair Queuing for Remaining Traffic Classes Router VoIP (High) Data (Low) Data (Low) Data (Low) 3 3 1 1 V V 1 1 WAN Circuit 3 3
WFQ

2 2

PQ

4

3

2

1

4 4

4 4

Security must be treated as an integral element of any Cisco AVVID network. An organization’s communications network is the basic environment connecting all users, servers, applications, and service providers. Implementing a robust security suite provides the best defense against possible information loss, tampering, or productivity disruption. Cisco’s security suite emphasizes three key areas:

Internal network security—Ensuring that the internal network is secure includes tracking physical, endpoint, application, and Layer 2 security issues. External network security—External network security focuses on securing the interface between an organization’s internal network and the outside world (the Internet edge). Network identity—In considering a network’s overall security scheme, it is essential to establish a framework that allows the network administrator to implement identitybased network access control and policy enforcement, right down to the user and individual access port level.

Cisco AVVID network infrastructure capabilities present an array of both device-based and server-based security applications and features. Access control lists (ACLs), firewalls, serverbased authentication, intrusion detection systems (IDSs), and virtual private network (VPN) capabilities can be integrated into a seamless security environment. Figure 7-8 illustrates these technologies as implemented in a network.

Introduction to Cisco AVVID

393

Figure 7-8 The Cisco AVVID Network Infrastructure Integrates an Impressive Array of Security Technologies Focused Layer 4-7 Analysis Host IDS Local Attack Mitigation SMTP Content Inspection

Spoof Mitigation Basic Filtering To Edge Distribution

ISP A

Stateful Packet Filtering Basic Layer 7 Filtering Host DoS Mitigation

Spoof Mitigation (D)DoS RateTo Limiting VPN/Remote Access Broad Layer 4-7 Analysis

Focused Layer 4-7 Analysis Inspect Outbound Traffic for Unauthorized URLs

High Availability
High availability optimizes design and tools to ensure end-to-end availability for services, clients, and sessions. Tools include reliable, fault-tolerant network devices to automatically identify and overcome failures. Also, resilient network technologies, such as Hot Standby Router Protocol (HSRP), bring resilience to the critical junction between hosts and backbone links. Simple Server Redundancy Protocol (SSRP) communicates between router and ATM switch groups to detect device failures and initiate automatic reroutes within one second of failover time. Determining how resilient a network is to change or disruption is a major concern for network managers. This assessment of network availability is critical. It is essential that every network deployment emphasize, availability as the very first consideration in a baseline network design.

394

Chapter 7: Cisco AVVID

Availability must be viewed from the user’s perspective. To the user, the network is down regardless of whether an application fails, a router dies, or a piece of fiber is cut. Here are some key availability issues to address:

Hardware redundancy—This is often the first level of redundancy in the network. Cisco offers, in its modular products, for example, options for redundant supervisor engines and dual in-line power supplies. This often provides the first backstop against a network failure. Protocol resiliency—Good design practices dictate how and when to use protocol redundancy, including load sharing, convergence speed, and path redundancy handling. Contrary to popular belief, if some redundancy is good, more redundancy is not necessarily better. Network capacity design—Good design practices include capacity planning. How much traffic can a connection handle in the worst case? You must consider whether a link can handle double the traffic when a redundant link fails. Capacity planning must be included during the network design phase to ensure the smooth integration of new technologies (such as videoconferencing). Figure 7-9 shows redundant links as commonly deployed. Management—Includes the LAN Management Solution for advanced management of the Catalyst multilayer switches; the Routed WAN Management Solution for monitoring, traffic management, and access control to administer the routed infrastructure of multiservice networks; the Service Management Solution for managing and monitoring service-level agreements; and the VPN/Security Management Solution for optimizing VPN performance and security administration. Multicasting—Provides bandwidth-conserving technology that reduces traffic by simultaneously delivering a single stream of information to thousands of corporate recipients and homes. Multicasting enables distribution of videoconferencing, corporate communications, distance learning, distribution of software, and other applications. Multicast packets are replicated in the network by Cisco routers enabled with Protocol-Independent Multicast (PIM) and other supporting multicast protocols, resulting in the most efficient delivery of data to multiple receivers.

Introduction to Cisco AVVID

395

Figure 7-9 Capacity Planning Must Be Included During the Network Design Phase to Ensure the Smooth Integration of New Technologies Network Design IP WAN

End-User PC 100 M Ethernet

Cisco AVVID Network Solutions
Cisco AVVID network solutions include IP Telephony, IP videoconferencing, wireless LANs, security, VPNs, content networking, contact centers, and storage networking. The following sections discuss these technologies in greater detail.

IP Telephony
Built on the Cisco AVVID network infrastructure, a Cisco AVVID IP Telephony solution brings the promise of high-quality IP voice and fully integrated communications to reality. Through IP Telephony, single-site and multisite enterprises can use IP as a primary voice path with the traditional Public Switched Telephone Network (PSTN) serving as a redundant voice path. The easy-to-deploy, standards-based system delivers high voice quality while decreasing the reliance on the PSTN and significantly reducing costs (see Figure 7-10).

396

Chapter 7: Cisco AVVID

Figure 7-10 Cisco’s IP Telephony Solution Provides an Integrated Voice and Data Network CallManager Cluster Applications (VMail, IVR, ICO,...)

GK

V

V

PSTN West Coast Headquarters (with SRST and APPs) Branch Office (with Call Processing and Apps)

IP WAN

Rest of World East Coast Headquarters

IP Videoconferencing
Using an IP-based videoconferencing solution makes it possible to run interactive video over an IP network, saving companies thousands of dollars a month by converging voice, video, and data traffic over a common path. H.323 builds on top of existing IP data networks, ultimately saving money and scaling to larger deployments. Distance learning and business meetings are two common applications that can be deployed with H.323 over IP data networks (see Figure 7-11).

Wireless LANs
Wireless LANs let users establish and maintain a wireless network connection throughout or between buildings, without the limitations of wires or cables, as illustrated in Figure 7-12.

Introduction to Cisco AVVID

397

Figure 7-11 The Cisco AVVID Infrastructure Supports IP Videoconferencing H.320 MCU

H.320 Endpoints Headquarters with one or more zones, and local PSTN and MCU access. MCU H.323 Terminals H.323 to H.320 Gateway H.323 Terminals PSTN ISDN H.323 to H.320 MCU Gateway

QoS Enabled IP WAN Gatekeeper Proxy

Gatekeeper Proxy

Large Branch with one or more zones, local PSTN, and MCU access.

Small Branch with no local gatekeeper, PSTN or MCU services, all services will be handheld at Headquarters site.

Cisco AVVID Security
Cisco offers a comprehensive array of enterprise network security solutions to make implementing and maintaining good network security easier and more cost-effective, as shown in Figure 7-13.

Virtual Private Networks
Enterprise VPN enables customer connectivity deployed on a shared (public) infrastructure with the same policies as a private network, where users expect the same application behavior, performance, and connectivity (see Figure 7-14).

398

Chapter 7: Cisco AVVID

Figure 7-12 Wireless LANs Are Now a Fundamental Component of Most Modern Networks Enterprise Central Site Enterprise WAN Service Provider Telecommuter/ SOHO

Enterprise Branch

Standalone Office

Single-Site Small-Medium Business (SMB) Enterprise

Multisite Large Enterprise

Figure 7-13 An Integrated Security Solution Is Critical in Modern Network Deployments Focused Layer 4-7 Analysis Host IDS Local Attack Mitigation SMTMP Content Inspection

Spoof Mitigation Basic Filtering To Edge Distribution

ISP A

Stateful Packet Filtering Basic Layer 7 Filtering Host DoS Mitigation

Spoof Mitigation (D)DoS RateTo Limiting VPN/Remote Access Broad Layer 4-7 Analysis

Focused Layer 4-7 Analysis Inspect Outbound Traffic for Unauthorized URLs

Introduction to Cisco AVVID

399

Figure 7-14 VPNs Are an Ideal Solution for Remote Users and Telecommuters Site-to-Site VPN Large/Small Branch

Central Site

Service Provider/ Internet VPN Concentrator or Headend SOHO VPN (Small Office Home Office)

Remote Access (SW Client)

Content Networking
Content Networking, shown in Figure 7-15, allows enterprises to maximize the impact of communicating topology using the web by overcoming the modern-day bandwidth issues of delivering rich media to the desktop. Content Networking solutions guarantee that quality video, rich audio, and large graphics, as well as other high-bandwidth files, can be delivered with speed, accuracy, and consistency, dramatically increasing the impact of the communications programs.

IP Contact Center
An integral part of Cisco AVVID is the Cisco IP Contact Center (IPCC), which delivers intelligent call routing, network-to-desktop computer telephony integration (CTI), and multimedia contact management to contact center agents over an IP network. By combining software automatic call distribution (ACD) functionality with IP Telephony in a unified solution, IPCC lets companies rapidly deploy a distributed contact center infrastructure to support their global e-sales and e-service initiatives.

400

Chapter 7: Cisco AVVID

Figure 7-15 Content Networking Is a Relatively New Technology That Will Soon Be a Standard Component of Enterprise Networks

Internet WAN: Branch Offices, SOHO, SMB Services_ 1: Media On Demand 2: Live Broadcast 3: Re-Broadcast Internet Edge Campus Network: Large Users Groups

WAN

IPTV Archive Server Content Engines Content Switches Content Distribution Manager IPTV Broadcast Server Benefits_ 1: Bandwidth Optimization 2: Application Scalability 3: Reduced Response Time

Data Center Headquarters: Server Farms: Critical and Origin Servers

Storage Networking
The Cisco Storage Networking strategy, shown in Figure 7-16, is composed of four complementary technology areas:
■ ■

IP access to storage—High-speed access to block storage over IP networks Network attached storage—High-performance access, data protection, and disaster recovery for file-based storage over an IP network Storage over metro optical—Extension of storage networks across metropolitan-area networks (MANs) using an optical network infrastructure Storage over WAN—Fast, secure, and highly available storage networks interconnect over WANs

As an element of AVVID, Cisco Storage Networking allows customers to adopt a strategy for accessing, managing, and protecting their growing information resources across a consolidated IP, Gigabit Ethernet, Fiber Channel, and optical network infrastructure.

Introduction to Cisco AVVID

401

Figure 7-16 Storage Networking Is Another Relatively New Technology That Provides High-Speed IP Access to Storage
LAN/WAN iSCSI: Storage pooling in NT/ Open Storage System environment WAN FCIP: Connectivity between Fiber Channel SAN islands over IP

Fiber Channel SAN

iSCSI-enabled Server Pool Fiber Channel SAN Catalyst 6500 FCIP IP Network
MAN Metro Optical: Connectivity betwen Fiber Channel SAN islands over DWDM

iSCSI Storage

iSCSI 5420

Optical MAN
Fiber Channel SAN Storage Pool Metro 15540 Fiber Channel SAN

Primary Site

Disaster Recovery Site

Interactive Media Activity Matching: Cisco AVVID Network Solutions

This Interactive Media Activity helps you better understand the Cisco AVVID network.

Cisco AVVID Network Implementation Example
Figure 7-17 illustrates a typical deployment of a converged network combining data, voice, and video over a single infrastructure. The network is composed of a single or several large headquarters sites, a larger number of branch offices, and individual telecommuter sites. From a telephony point of view, whether a physical handset or a softphone application on a PC, the devices are treated as IP endpoints on an IP infrastructure typically serving Ethernet to the end user. Voice calls inside a site traverse the IP LAN until the exit point from the site where, as a first choice, the calls cross the IP WAN backbone to save on public network toll costs. If for some reason this IP WAN is “full” or unavailable, the call is automatically rerouted across the PSTN. Either way, the call’s path is transparent to the end user. Gateways are used at the edge of each site to provide a path to the PSTN, which is also the primary path

402

Chapter 7: Cisco AVVID

for local inbound and outbound calls. This level of integration allows for very simple coordinated dial plans in which an entire enterprise can use four- or five-digit dialing, as appropriate, for internal calls.
Figure 7-17 A Converged Voice, Video, and Data Cisco AVVID Solution Relies on Cisco CallManager Cisco CallManager

Router/Gateway Cisco CallManager
V

Voice Messaging
V

Cisco CallManager PSTN

V

IP WAN Router/Gateway

V

Router/Gateway Router/Gateway

V

Telecommuter

Branch Office

The technology used in the IP WAN allows for tremendous flexibility in the design of the intranet. Because the IP protocol is the underlying carrier of data, voice, and video, any technology such as PPP, Frame Relay, ATM, dark fiber (installed but unused fiber), digital subscriber line (DSL), Synchronous Optical Network (SONET), or wavelength division multiplexing (WDM) can be used to construct the network. This allows for maximum flexibility and agility on the part of a network manager to take advantage of new high-speed WAN services from carriers, without making major changes to the converged IP network. However, routers at the edge of the WAN must employ the proper QoS techniques to ensure that voice traffic remains high-quality, even in congested conditions. Techniques such as low-latency queuing, weighted fair queuing, and priority queuing are examples of necessary technologies in a converged network.

Introduction to Cisco AVVID

403

Familiar applications, such as voice messaging, are also easily integrated into this converged networking environment. Because the voice being carried across the network is encoded in IP, a new breed of IP-enabled unified-messaging solutions allows users to access both voice mail and e-mail from a common server. This can be accomplished with either the e-mail application or through a next-generation IP Telephony handset. Figure 7-18 illustrates unified messaging.
Figure 7-18 Unified Messaging Allows Faxes and Voice Messages to Be Accessed Through a User’s E-Mail Application

Although the nirvana of a converged network has widespread appeal to many, the reality is that every corporation already has existing voice and data networks, a scenario that requires finding simple ways to migrate to a converged network.

Legacy Migration
Although building a converged network with Cisco AVVID has obvious advantages, some existing legacy voice and video systems require a seamless migration into the New World. One example might be a scenario where an existing PBX has reached capacity and its growth is dependent on IP Telephony. In some cases, the existing voice mail system still has the capacity to sustain the additional users and it is desired to maintain the existing system in production. In Figure 7-19, a voice mail system is connected to the PBX using multiple analog voice ports to carry voice traffic and a signaling line called a Simple Messaging Desktop Interface (SMDI) that passes information, such as whose mailbox greeting to play on which particular voice port, to the voice mail system. This is one of many ways to network voice mail to a PBX.

404

Chapter 7: Cisco AVVID

Figure 7-19 An Intricate Process Is Required to Migrate from a Legacy PBX Network to a Cisco AVVID Network Cisco CallManager Legacy Voice Mail SMDI SMDI Voice Path

V

VM Gateway

T1 PRI
V

PSTN

Gateway Transparent Migration AVVID Network Legacy PBX

The first part of the migration to consider is establishing uniform dialing plans that are the same on both the legacy and Cisco AVVID networks. This migration is easily achieved using either a standalone gateway or one of the many router/gateway combinations available from Cisco. Regardless of which side of the network the user is on, the incoming and outgoing calls from the outside world appear exactly the same (whether direct inward dial or an operator and extensions are used). Internal dialing using a shorter dial plan (perhaps four or five digits) can also be maintained. From a voice mail perspective, Cisco CallManager also supports SMDI for control of a voice mail system. Coupled with analog gateways connecting to the same voice mail, calls on either side of the network appear exactly the same to voice mail. In the video world, it is common to have H.320-based videoconferencing systems, each with its own PSTN network connections. LAN-based H.323 video systems also are commonly deployed in many companies, such as Microsoft NetMeeting, which uses H.323 for videoconferencing and shared collaboration. Again, the Cisco AVVID solution provides several different ways to preserve an investment in legacy systems while investing in converged network solutions. Figure 7-20 illustrates two different scenarios.

Introduction to Cisco AVVID

405

Figure 7-20 A Video Gateway or a Video Terminal Adapter Can Be Used to Migrate from a Legacy H.320 Network to a Converged Video Network Legacy H.320 Network Legacy H.320 Endpoint

PSTN

Video Gateway

Video Terminal Adapter

Converged Video Network (H.323)

Converged Video Network (H.323)

On the left side of Figure 7-20, there might be a whole network of H.320 systems deployed by the corporation or customers. Using a Cisco video gateway enables communication between the converged H.323 network and the legacy video network. Using a Cisco video gateway would also allow customers or vendors who have only H.320 systems to communicate with a new network of H.323-only systems. Additionally, on the right side of Figure 7-20, individual H.320 endpoints can be networked seamlessly in an H.323 network with the use of a Cisco video terminal adapter. The fact that every major networking vendor has announced plans for IP Telephony solutions leads to the conclusion that the convergence of data, voice, and video networks is inevitable. The only possible convergence solution is to merge the existing voice and video networks onto the IP data network. For this to succeed, many aspects of the intelligence of the IP data network need to be exercised. Lastly, tools that aid in the migration from legacy voice and video networks toward networks converged on IP make it possible for mass deployment of networks based on the Cisco AVVID architecture. The next section introduces IP multicast technology.

406

Chapter 7: Cisco AVVID

Examining Multicast in a Multilayer Switched Network
Multicasting is the process of sending a stream of data from a single source to several recipients without having to replicate a unicast stream for each recipient. Some Layer 2 and Layer 3 multicast addresses are formally associated, as described in the upcoming section “Layer 2 Multicast Addressing.” IGMP is used to allow hosts to request participation in or leave particular multicast sessions. CGMP is a Cisco legacy technology used on low-end Layer 2 Catalyst switches to optimize multicast traffic flow through the switches. It has largely been replaced by a newer technology called IGMP snooping.

Multicast Overview
Most campus networks today support intranet applications that operate between one sender and one receiver. However, this paradigm is rapidly changing. In the emerging campus network, a demand exists for intranet and multimedia applications in which one sender transmits to a group of receivers simultaneously. These types of applications include the following:
■ ■ ■ ■ ■ ■

Transmitting a corporate message to employees Video and audio broadcasting Interactive video distance learning Transmitting data from a centralized data warehouse to multiple departments Communication of stock quotes to brokers Collaborative computing

For example, an internal technical support facility might use multicast file transfer software to send software updates to multiple users in the campus simultaneously in one stream of data. Many corporations and industries are now realizing the potential of multimedia applications. Video and voice conferencing applications generate much of the multicast traffic today. Many websites offer video streams that transmit multicast traffic. Companies are experiencing a marked increase in multicast traffic from internal users. Because of the proliferation of multicast applications, network administrators are charged with installing and configuring devices and implementing policy to manage traffic associated with these applications. Many network designs deal efficiently with unicast traffic but neglect the impact of multicast traffic within the network. Unfortunately, this can severely affect a well-designed unicast network. Again, it should be reiterated that it is critical in network design to take a proactive approach to controlling multicast traffic in the network. The default behavior of a switch is to flood multicast frames out all ports except the originating port. This is usually not the desired effect. Cisco has implemented the proprietary Cisco Group Management Protocol (CGMP)

Examining Multicast in a Multilayer Switched Network

407

and the nonproprietary Internet Group Management Protocol (IGMP) snooping to help administer multicast traffic in the network. CGMP and IGMP snooping run on switches and routers and work hand-in-hand with IGMP, running on routers, to control the flooding of multicast traffic in a network. To control multicast traffic, either CGMP or IGMP snooping would be used, but not both. Multicast traffic originates at sources that need to distribute the same information to multiple recipients, as illustrated in Figure 7-21.
Figure 7-21 Using Multicast Technology Greatly Reduces Unnecessary Replication of Data Traffic Without Multicast Network

Server

Clients

With Multicast Network

Server

Clients

When a source creates multicast traffic, it uses special Layer 2 and Layer 3 addresses so that routers and switches know how to route or switch the frame. By default, routers do not forward multicast traffic unless they are multicast-capable and have a multicast routing protocol, such as Distance Vector Multicast Routing Protocol (DVMRP) or Protocol-Independent Multicast (PIM) enabled. DVMRP and PIM are interrouter protocols. Therefore, hosts and switches do not participate in messages for these protocols. By default, a switch floods multicast traffic within a broadcast domain. This consumes bandwidth on both access links and trunk links. Depending on the host TCP/IP stack implementation and network interface card (NIC) attributes, the multicast frame can cause a CPU interrupt. The reason a switch floods multicast traffic is that it has no entry in the bridge table for the destination address. Multicast addresses never appear as source addresses. Therefore, the bridge/ switch cannot dynamically learn multicast addresses; they must be manually configured. IGMP is a multicast protocol that directly affects hosts. IGMP allows hosts to inform routers that they want to receive multicast traffic for a specific multicast group address.

408

Chapter 7: Cisco AVVID

Many older switches don’t understand IGMP messages. As a result, Cisco developed the proprietary CGMP, which lets routers inform switches about hosts and their interest in receiving multicast traffic. This modifies the Catalyst switch default behavior of flooding the multicast frame to all hosts in the broadcast domain. Rather than flooding the frame to all hosts, the Catalyst switch limits the flooding scope to hosts in the broadcast domain that registered with the router through IGMP. If a host does not register with the router, it does not receive a copy of the multicast frame. This helps preserve access-link bandwidth. Newer switches understand IGMP requests from hosts and implement IGMP snooping. IGMP snooping constrains the flooding of multicast traffic by dynamically configuring the interfaces so that multicast traffic is forwarded only to interfaces associated with IP multicast devices. The LAN switch snoops on the IGMP traffic between the host and the router and keeps track of multicast groups and member ports. When the switch receives an IGMP join report from a host for a particular multicast group, the switch adds the host port number to the associated multicast forwarding table entry. When the switch receives an IGMP leave group message from a host, the switch removes the host port from the table entry. After the switch relays the IGMP queries from the multicast router, the switch deletes entries periodically if it does not receive any IGMP membership reports from the multicast clients.

Multicast Addressing
Whenever an application needs to send data to more than one station but wants to restrict the distribution to stations interested in receiving the traffic, the application typically uses a multicast destination address. Whereas a broadcast targets all users in a domain, multicast addresses target a select group of stations in the network, as shown in Figure 7-22. On the other hand, if the source transmits unicast frames, it has to send multiple copies of the frame, one addressed to each intended receiver. This is a very inefficient use of network resources and does not scale well as the number of receivers increases. The disadvantage of broadcasts, on the other hand, is that even if a host is not interested in receiving the broadcast, it still has to process each frame. By using multicast addresses, the source transmits only one copy of the frame onto the network, and routers distribute the multicast message to the other segments where interested receivers reside. As discussed previously, multicast addresses appear at Layer 2 and Layer 3. A network administrator assigns the multicast Layer 3 address for an application. The Layer 2 multicast address is then calculated from the Layer 3 multicast address. When configuring a multicast application, the NIC adds the multicast address to its list of valid Media Access Control (MAC) addresses. Usually this list consists of the built-in MAC address plus any user-configured addresses. Whenever the station receives a frame with a matching multicast destination address, the receiver sends the frame to the CPU.

Examining Multicast in a Multilayer Switched Network

409

Figure 7-22 A Multicast Server Sends a Single Data Stream to Multiple Clients Using a Special Destination Address

Video Server

1.5 Mb

1.5 Mb

1.5 Mb

1.5 Mb

1.5 Mb

1.5 Mb

Receiver

Receiver

Receiver

Not A Receiver

Layer 3 Multicast Addressing
IP multicast addresses at Layer 3 are characterized as Class D addresses. The first 4 bits of IP Class D addresses are 1110. This means that IP multicast addresses have a valid range from 224.0.0.0 to 239.255.255.255. Note that multicast addresses from 224.0.0.0 to 224.0.0.255 are reserved. The following reserved addresses are specifically relevant to multicasting:
■ ■ ■ ■ ■ ■ ■ ■

224.0.0.1—All multicast-capable hosts on the segment 224.0.0.2—All multicast-capable routers on the segment 224.0.0.4—All DVMRP routers on the segment 224.0.0.5—All Open Shortest Path First (OSPF) routers 224.0.0.6—All OSPF designated routers 224.0.0.9—All Routing Information Protocol version 2 (RIPv2) routers 224.0.0.10—All Enhanced Interior Gateway Routing Protocol (EIGRP) routers 224.0.0.13—All PIM routers

Usually, a network administrator assigns a multicast address to the application and must select an address not used by other applications or processes. The administrator should not use a multicast address in the reserved range.

410

Chapter 7: Cisco AVVID

The IP multicast address space is subdivided into several formal categories. These include reserved link local addresses, globally scoped addresses, limited scope addresses, and GLOP addressing. The following sections address each of these categories in greater detail.

Reserved Link Local Addresses
The Internet Assigned Numbers Authority (IANA) has reserved addresses from 224.0.0.0 to 224.0.0.255 to be used by network protocols on a local network segment:
■ ■ ■ ■ ■ ■ ■ ■ ■ ■

224.0.0.1—All systems on this subnet 224.0.0.2—All routers on this subnet 224.0.0.5—OSPF routers 224.0.0.6—OSPF designated routers 224.0.0.9—RIPv2 routers 224.0.0.10—EIGRP routers 224.0.0.12—Dynamic Host Configuration Protocol (DHCP) server/relay agent 224.0.0.13—All PIM routers 224.0.0.22—IGMP 224.0.0.25—Router-to-switch (such as Router-Port Group Management Protocol [RGMP])

Packets with these link local addresses should never be forwarded by a router. They must remain local on a particular LAN segment and are always transmitted with a time-to-live of 1. Network protocols use these addresses for automatic router discovery and to communicate important routing information. For example, OSPF uses 224.0.0.5 and 224.0.0.6 to exchange link state information.

Globally Scoped Addresses
The address range from 224.0.1.0 to 238.255.255.255 is known as globally scoped addresses. This range can be used to multicast data between organizations and across the Internet. Some of these addresses have been reserved for use by multicast applications through IANA. For example, 224.0.1.1 has been reserved for Network Time Protocol (NTP), used to synchronize clocks on network devices. The IANA also assigned the two group addresses 224.0.1.39 and 224.0.1.40 for Auto-RP, a PIM sparse-mode mechanism that is discussed in the section “Configure Auto-RP (Optional).”

Examining Multicast in a Multilayer Switched Network

411

Limited Scope Addresses
The addresses in the range of 239.0.0.0 to 239.255.255.255 are known as limited scope addresses or administratively scoped addresses. These are defined by RFC 2365 to be constrained to a local group or organization. Routers are typically configured with filters to prevent multicast traffic in this address range from flowing outside an autonomous system (AS) or any user-defined domain. Within an autonomous system or domain, the limited scope address range can be further subdivided so that local multicast boundaries can be defined. This subdivision also allows for address reuse between these smaller domains.

GLOP Addressing
RFC 2770 proposes that the 233.0.0.0/8 address range be reserved for statically defined addresses, called GLOP addresses, by organizations that already have an AS number reserved. The term GLOP was coined by the RFC’s author and is not an acronym. The domain’s AS number is embedded in the second and third octets of the 233.0.0.0/8 range. For example, AS 62010 is written in hex as F23A. Separating the two octets F2 and 3A results in 242 and 58 in decimal. This provides for a subnet of 233.242.58.0 that would be globally reserved for AS 62010 to use.

Layer 2 Multicast Addressing
When a Layer 3 multicast address is assigned, a Layer 2 address is automatically generated from the IP address. To calculate the Layer 2 address, the host copies the last 23 bits of the IP address into the last 24 bits of the MAC address. The high-order bit is set to 0. The first 3 bytes (24 bits) of the multicast MAC address are 0x01-00-5E. This is a reserved value that indicates a multicast application. More generally, any Ethernet multicast or broadcast frame has a 1 in the last bit of the first octet. Consider the following example: The IP address 224.1.10.10, assigned by an administrator, has a low 23-bit value of 1.10.10. In hexadecimal format, this is 0x01-0A-0A. The MAC address takes the last 23 of the 24 bits and places them in the MAC field. The complete MAC address in this case is 01-00-5E-01-0A-0A. Figure 7-23 illustrates another example. In this case, the IP address 224.10.8.5 translates into a MAC address of 01.00.5E.0A.08.05.

412

Chapter 7: Cisco AVVID

Figure 7-23 Layer 3 Multicast Addresses Map to Layer 2 Multicast Addresses in a 32-to-1 Ratio Multicast Address: 224 10 8 5

111 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 1

Ethernet Address: 01 00 5E 0A 08 05

0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 11 0 1111 0 0 0 0 0 1 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 1

Interactive Media Activity Drag and Drop: Multicast Addressing

In this Interactive Media Activity, you gain familiarity with the key ranges of IP multicast addresses and associated terminology.

IGMP
IGMP grew out of the Host Membership Protocol. The first version, IGMPv1, was defined in RFC 1112. The most recent version, IGMPv2, was ratified in November 1997 as a standard by the Internet Engineering Task Force (IETF) and is covered in RFC 2236. IGMP messages are used primarily by multicast hosts to signal their local multicast router when they want to join a specific multicast group and begin receiving group traffic, as shown in Figure 7-24. Hosts can also (with IGMPv2) signal to the local multicast router that they want to leave an IP multicast group and are no longer interested in receiving multicast group traffic. Using information obtained through IGMP, routers maintain a list of multicast group memberships on a per-interface basis. A multicast group membership is active on an interface if at least one host on that interface has signaled its desire, using IGMP, to receive the multicast group traffic.

IGMP Version 1
IGMP Version 1 (IGMPv1) messages are transported within IP datagrams to transmit information about multicast groups. The datagram consists of a 20-byte IP header and an 8-byte IGMP message (see Figure 7-25).

Examining Multicast in a Multilayer Switched Network

413

Figure 7-24 IGMP Allows Hosts to Interactively Subscribe to and Leave IP Multicast Groups Multicast Source

Does Anyone Still Want to Receive Multicast Traffic? Host Membership Report

Host Membership Query

I Want to Receive Multicast Traffic for Group 239.225.160.171

Figure 7-25 IGMP Version 1 Messages Include a Message Type Field 0 IGMP Version 3 IGMP Message Type 7 Unused 15 16-Bit Checksum 31

IP Multicast Group Address

The first field of the message, IGMP Version, indicates what version of IGMP generated the message. For Version 1, this value must be 1. The IGMP Message Type field specifies the message type. Version 1 defines two messages:
■ ■

A host membership query A host membership report

The Checksum field carries the checksum computed by the source; the source computes the checksum for the entire IGMP message. The receiving device examines the checksum value to determine if the message was corrupted during transmission. If the checksum value doesn’t

414

Chapter 7: Cisco AVVID

match, the receiver discards the message. Finally, the IP Multicast Group Address field indicates the multicast destination group address targeted by the message. When a host on the segment wants to receive multicast traffic, it issues an unsolicited host membership report targeting the intended multicast group. The destination MAC address targets the multicast group it intends to join. If this were the only information in the frame to identify the group, any of 32 groups might be desired because of the address ambiguity discussed earlier. However, the Layer 3 address is included in both the IP header and the IGMP header. The Layer 3 multicast group desired by the host is 239.255.160.171; this Layer 3 multicast address is equivalent to the 32 Layer 3 multicast addresses in the ranges 224 to 239.255.160.171 and 224 to 239.127.160.171. This translates to a MAC address of 01-00-5E-7F-A0-AB. All multicast-capable devices on the shared media receive the membership report. In this situation, however, only the router is interested in the frame. The frame tells the router, “I want to receive any messages for this multicast group.” The router now knows that it needs to forward a copy of any frames with this multicast address to the segment where the host that issued the report lives. A device issues an IGMP membership report under two conditions:

Whenever the device first intends to receive a multicast stream—When enabling the multicast application, the device configures the NIC, and the built-in IGMP processes send an unsolicited membership report to the router, requesting copies of the multicast frames. In response to an IGMP membership query from the router—This is a solicited membership report that helps the router confirm that hosts on the segment still want to receive multicast traffic for a particular multicast group.

Routers periodically issue host membership queries. The query period might be configured from 0 seconds to a maximum of 65,535 seconds. The default is 60 seconds. Only one router on each segment issues the membership query message. If the segment uses IGMP Version 1, the designated router for the multicast routing protocol issues the query. If the segment uses IGMP Version 2, the multicast router with the lowest IP address on the segment issues the queries. The host membership query message targets the all-multicast-hosts address, 224.0.0.1, in the Layer 3 address field. The Layer 2 address is 01-00-5E-00-00-01. The IGMP header uses a group address of 0.0.0.0. This translates to a query for all multicast hosts on all groups on the segment. A host for each active multicast group must respond to this message. When multicast hosts receive the host membership query, and if the host wants to continue receiving multicast frames for a multicast group, the multicast host starts an internal random timer with an upper

Examining Multicast in a Multilayer Switched Network

415

range of 10 seconds. The host waits for the timer to expire, and then it sends a membership report for each multicast group it wants to continue receiving. If another station sends a membership report before the local timer expires, the host cancels the timer and suppresses the report. This behavior prevents a segment and router from experiencing host membership report floods. Only one station from each multicast group needs to respond for each group on the segment. If the router does not receive a membership report for a particular multicast group for three query intervals, it assumes that no hosts remain that are interested in that group multicast stream. The router stops forwarding the multicast packets for this group and tells upstream routers to stop sending frames. This process defines an implicit leave from the multicast group. No special leave mechanism is defined in IGMPv1. Instead, IGMPv1 hosts leave the group passively, without any notification to the router. A router learns that such a host is not interested in participating in a multicast group if the host does not respond to repeated queries from the router relating to that group.

IGMP Version 2
Looking at the format of IGMP Version 2 (IGMPv2) messages in Figure 7-26, notice that the IGMP Message Type field has been merged with the IGMPv1 Version field and now occupies a full octet. The values assigned to the various message types have been chosen carefully to provide backward compatibility with IGMPv1. Another field added to IGMPv2 that is not found in IGMPv1 is Maximum Response Time.
Figure 7-26 IGMP Version 2 Messages Include a Maximum Response Time Field 0 IGMP Version 7 Maximum Response Time 15 16-Bit Checksum 31

IP Multicast Group Address

IGMP Version 2 adds two messages not found in IGMPv1 to streamline the join and leave process. RFC 2236 added a Version 2 membership report and a leave group message. The complete list of messages now consists of the following:
■ ■ ■ ■

0x11—Membership query 0x12—Version 1 membership report 0x16—Version 2 membership report 0x17—Leave group

416

Chapter 7: Cisco AVVID

The membership query and Version 1 membership report carry over from IGMPv1. However, the membership query can now target specific multicast groups. In Version 1, the query message is a general query with the group address set to 0.0.0.0. All active groups respond to the general query. Version 2 allows a multicast query router to target a specific multicast group. A multicast host running Version 2 responds with a Version 2 membership report. Other multicast groups ignore the group-specific query if it is not directed at their group. The groupspecific membership query works only for Version 2 systems. If a Version 2 host leaves a multicast group, it sends an unsolicited leave group message to inform the query router that it no longer wants to receive the multicast stream. The router maintains a table of all hosts in the multicast group on the segment. If other hosts still want to receive the multicast stream, the router continues to send the multicast frames onto the segment. However, if the membership report arrives from the last host on the segment for the multicast group, the router terminates the multicast stream for that group. In Figure 7-27, consider the multicast group shown. Hosts H2 and H3 are currently members of multicast group 224.1.1.1, although Host H2 wants to leave the group.
Figure 7-27 Host 2 Announces Its Desire to Leave the Multicast Group H1 H2 H3

Leave to #1 224.0.0.2

Group Specific Query to 224.1.1.1 #2

The sequence of events for Host H2 to leave the group is as follows:
1. Host H2 multicasts an IGMPv2 leave group message to the all-routes (224.0.0.2) multi-

cast group to inform all routers on the subnet that it is leaving the group.
2. The router hears the leave group message from Host H2. However, because routers

keep a list of only the group memberships that are active on a subnet, not individual hosts that are members, the router sends a group-specific query to determine whether any hosts remain for Group 224.1.1.1. Because this is a group-specific query, only hosts that are members of the group respond.

Examining Multicast in a Multilayer Switched Network

417

3. Host H3 is still a member of Group 224.1.1.1 and responds to the query with an IGMPv2

membership report to inform the routers on the subnet that a member of this group is still present. Host H3 is now the last remaining member of the group.
4. If Host H3 decides to leave, Steps 1 and 2 are repeated. However, when the router

issues a group-specific query, no hosts respond. As a result, the router times out the group and stops forwarding packets for the group onto the subnet. If the router wants to confirm the need to send a stream, it can transmit a general or groupspecific query onto the segment. If the router does not receive any responses to a couple of query messages, it assumes that no more hosts want to receive the multicast stream. Another feature added to IGMPv2 is the multicast router’s ability to specify the hosts’ response timer range. Remember that when a host receives a membership query, the host starts a random timer. The timer value is in the range of 0 to maximum response time, with the maximum response time specified in the router query message. Version 2 limits the timer’s upper range to a maximum of 25 seconds. The default in a router is 10 seconds.

IGMP Version 1 and Version 2 Interoperability
The first possible combination of versions might involve hosts with a mix of versions and a Version 1 router, as shown in Figure 7-28. All IGMP operations in this scenario are driven by the version that the query router uses. When such a combination exists, the hosts must use Version 1 messages. The router does not understand Version 2 membership reports, nor does it understand Version 2 leave messages. A second case is when the router supports IGMPv2 but hosts use IGMPv1. Although the router understands more message types than the hosts, it ultimately uses only Version 1 messages. When the Version 2 router receives the Version 1 membership report, it remembers that they are present and uses only Version 1 membership queries. Version 1 queries use the group address 0.0.0.0 and do not generate group-specific queries. If they generated group-specific queries, the Version 1 hosts would not recognize the message and would not know how to respond. What if both Version 1 and Version 2 hosts are on the segment, with a Version 2 router? As in the previous case, the router must remember that there are Version 1 hosts and, therefore, must issue Version 1 membership queries. Additionally, if any of the Version 2 hosts send a leave message, the router must ignore it. The router ignores the message because it must still issue general queries in case a Version 1 member is still active on the segment.

418

Chapter 7: Cisco AVVID

Figure 7-28 IGMP Version 2 Routers Can Operate with Both IGMP Version 1 and Version 2 Hosts IGMP Version 1

V1

V2

V1

V2

ALL Hosts Run IGMP Version 1 IGMP Version 2

V1 V1 V2 V2 Hosts Run Either IGMP Version 1 or IGMP Version 2

If two routers attach to the segment where one supports Version 1 and the other Version 2, the Version 2 router must be administratively configured as a Version 1 router. The Version 1 router has no way to detect the presence of the Version 2 router. Because the two versions use different methods of selecting the query router, they might not reliably agree on the query router.

IGMP Version 3
IGMP Version 3 (IGMPv3) is the next step in the evolution of IGMP. IGMPv3 adds support for source filtering, which lets a multicast receiver host signal to a router the groups from which it wants to receive multicast traffic, and from which sources this traffic is expected. This membership information lets Cisco IOS software forward traffic from only sources from which receivers requested the traffic. Among other things, this added feature can prevent rogue multicast servers from monopolizing the bandwidth on a segment; receivers must specifically request the servers from which multicast traffic is desired. IGMPv3 helps conserve bandwidth by allowing hosts to specify the sources of multicast traffic.

Examining Multicast in a Multilayer Switched Network

419

IGMPv3 supports applications that explicitly signal sources from which they want to receive traffic. With IGMPv3, receivers signal membership to a multicast host group in the following two modes:

INCLUDE mode—In this mode, the receiver announces membership to a host group and provides a list of source addresses (the INCLUDE list) from which it wants to receive traffic. EXCLUDE mode—In this mode, the receiver announces membership to a multicast group and provides a list of source addresses (the EXCLUDE list) from which it does not want to receive traffic. The host receives traffic only from sources whose IP addresses are not listed in the EXCLUDE list. To receive traffic from all sources, which is the behavior of IGMPv2, a host uses EXCLUDE mode membership with an empty EXCLUDE list.

As shown in Figure 7-29, Host H1 wants to join group 224.1.1.1 but wants to receive traffic only from Source 1.1.1.1. The IGMPv3 host can signal the designated router, R3, that it is only interested in multicast traffic from Source 1.1.1.1 for Group 224.1.1.1. Router R3 could then potentially “prune” the unwanted source, 2.2.2.2.
Figure 7-29 With IGMP Version 3, a Host Can Specify Which Source(s) It Wants to Receive Multicast Traffic from for a Particular Multicast Group Source = 1.1.1.1 Group = 224.1.1.1 Source = 2.2.2.2 Group = 224.1.1.1

H1 wants to receive only S = 1.1.1.1 and no other. With IGMPv3, specific sources can be joined. S = 1.1.1.1 in this case.

R3

IGMPv3 Join: 224.1.1.1 Include: 1.1.1.1 H1 – Member of 224.1.1.1

IGMP Snooping
Layer 2 switches need some degree of multicast awareness to avoid flooding multicasts to all switch ports. IGMP snooping requires the LAN switch to examine, or “snoop,” some Layer 3 information in the IGMP packets sent between the hosts and the router. When the switch

420

Chapter 7: Cisco AVVID

hears the IGMP host report from a host for a particular multicast group, it adds the host’s port number to the associated multicast table entry. When the switch hears the IGMP leave group message from a host, it removes the host’s port from the table entry. When IGMP snooping is enabled, the switch responds to periodic multicast router queries to all virtual LANs (VLANs) with only one join request per MAC multicast group. Also, the switch creates one entry per VLAN in the Layer 2 forwarding table for each MAC multicast group for which it receives an IGMP join request. All hosts interested in this multicast traffic send join requests and are added to the forwarding table entry. Because IGMP control messages are transmitted as multicast packets, they are indistinguishable from multicast data at Layer 2. A switch running IGMP snooping must examine every multicast data packet to check if it contains any pertinent IGMP control information. Enabling IGMP snooping on a low-end switch could severely affect performance when data is transmitted at high rates. Figure 7-30 shows the processes required on switches using IGMP snooping. CGMP, discussed later in this chapter, is an ideal alternative for low-end legacy switches.
Figure 7-30 IGMP Snooping Is Now the Preferred Mechanism to Avoid Unnecessary Flooding to All Switch Ports

PIM

Requirements and processes related to IGMP snooping are as follows:
■ ■

Switches become IGMP-aware IGMP packets are intercepted by the Network Management Processor (NMP) or by special hardware ASICs The switch must examine the contents of IGMP messages to determine which ports want what traffic: — IGMP membership reports — IGMP leave messages

Impact on the switch: — It must process all Layer 2 multicast packets. — The administrative load increases with the multicast traffic load. — It requires special hardware to maintain throughput.

Examining Multicast in a Multilayer Switched Network

421

Configuring IGMP Snooping on a Catalyst IOS-Based Switch
By default, IGMP snooping is globally enabled. When it is globally enabled or disabled, it is also enabled or disabled in all existing VLAN interfaces. By default, IGMP snooping is enabled on all VLANs, but it can be enabled and disabled on a per-VLAN basis. If IGMP global snooping is disabled, VLAN snooping might not be enabled. If global IGMP snooping is enabled, snooping might be enabled or disabled on a VLAN basis. To globally enable IGMP snooping, enter the global configuration command ip igmp snooping. The global command no ip igmp snooping vlan vlan-id disables IGMP snooping on a particular VLAN. To specify the next-hop interface to the multicast router, use the global configuration command ip igmp snooping vlan vlan-id mrouter interface interface-id. When IGMP immediate-leave processing is enabled, the switch immediately removes a port from the IP multicast group when it detects an IGMPv2 leave message on that port. Immediate-leave processing allows the switch to remove an interface from the forwarding table after receiving a leave message without first sending group-specific queries from the interface. The immediate-leave feature should be implemented only when a single receiver is present on every port in the VLAN. The immediate-leave feature is disabled by default. Use the ip igmp snooping vlan vlan-id immediate-leave global configuration command to enable IGMP immediate-leave processing on a VLAN interface. Example 7-1 shows a sample configuration for IGMP snooping.
Example 7-1 IGMP Snooping Can Be Configured on Catalyst 2950, 3550, 4500, and 6500 Switches
Switch(config)#ip igmp snooping Switch(config)#ip igmp snooping vlan 1 immediate-leave Switch(config)#ip igmp snooping vlan 2 immediate-leave Switch(config)#exit Switch#show ip igmp snooping

vlan 1 ---------IGMP snooping is globally enabled IGMP snooping is enabled on this vlan IGMP snooping immediate-leave is enabled on this vlan IGMP snooping mrouter learn mode is pim-dvmrp on this vlan

continues

422

Chapter 7: Cisco AVVID

Example 7-1 IGMP Snooping Can Be Configured on Catalyst 2950, 3550, 4500, and 6500 Switches (Continued)
vlan 2 ---------IGMP snooping is globally enabled IGMP snooping is enabled on this vlan IGMP snooping immediate-leave is enabled on this vlan IGMP snooping mrouter learn mode is cgmp on this vlan vlan 3 ---------IGMP snooping is globally enabled IGMP snooping is enabled on this vlan IGMP snooping immediate-leave is disabled on this vlan IGMP snooping mrouter learn mode is cgmp on this vlan

The switch might be configured to either snoop on Protocol-Independent Multicast/Distance Vector Multicast Routing Protocol (PIM/DVMRP) packets or to listen to CGMP self-join packets. By default, the switch snoops on PIM/DVMRP packets on all VLANs. PIM and DVMRP are discussed later in this chapter. To learn of multicast router ports through only CGMP self-join packets, use the following global configuration command:
Switch(config)#ip igmp snooping vlan vlan-id mrouter learn cgmp

When this command is used, the router listens only to CGMP self-join packets and no other CGMP packets. To learn of multicast router ports through only PIM/DVMRP packets, use the following global configuration command:
Switch(config)#ip igmp snooping vlan vlan-id mrouter learn pim-dvmrp

To view the Layer 2 multicast entries for the switch or for a VLAN, use the following command:
Switch#show mac-address-table multicast [vlan vlan-id] [user | igmp-snooping] [count]

The user option displays only the user-configured multicast entries.

CGMP Operation
CGMP is a Cisco-proprietary protocol that allows switches to learn about the existence of multicast clients from Cisco routers and older IOS-based switches. CGMP is based on a client/server model. The router is considered a CGMP server, with the switch taking on

Examining Multicast in a Multilayer Switched Network

423

the client role. The basis of CGMP is that the IP multicast router sees all IGMP packets and, therefore, can inform the switch when specific hosts join or leave multicast groups. The switch then uses this information to construct a forwarding table. When the router sees an IGMP control packet, it creates a CGMP packet. This CGMP packet contains the request type, a join or a leave, the multicast group address, and the client’s MAC address. The packet is sent to a well-known address to which all switches listen. Each switch then interprets the packet and creates the proper entries in a forwarding table, as illustrated in Figure 7-31.
Figure 7-31 CGMP Is Used on Older Catalyst Switches, Such as the Catalyst 1900, 2820, 2900XL, 3500XL, and 5000
Device 0000.0c12.3456 wants to join Group 234.10.8.5.

I can reach device 0000.0c12.3456 out of Port 1. I will add 234.10.8.5 to my switch forwarding table.
ge sa es

0000.0c12.3456

CGMP can run on an interface only if PIM is configured on the same interface. CGMP is disabled on a router by default. To enable CGMP on the router, enter the ip cgmp command in interface configuration mode. This command enables the CGMP for IP multicasting on a router and triggers a CGMP join message. The running configuration indicates if a specific router interface has been configured for CGMP. For CGMP to operate correctly on a switch, the switch must have a network connection to a router running CGMP. A CGMP-capable IP multicast router detects all IGMP packets and informs the switch when specific hosts join or leave IP multicast groups. When the CGMPcapable router receives an IGMP control packet, it creates a CGMP packet that contains the request type, the multicast group address, and the host’s MAC address. The router then sends the CGMP packet to a well-known address to which switches listen, as illustrated in

CG

I have no knowledge of device 0000.0c12.3456.

CG M P M

M

es

P

sa

M

ge

424

Chapter 7: Cisco AVVID

Figure 7-32. CGMP is no longer supported on the new series of Catalyst switches, including the 2950 and 3550 series. IGMP snooping has replaced CGMP on these models.
Figure 7-32 CGMP Frames Are Sent to a Well-Known Multicast Address
CGMP Commands

PIM
IGMP

Requirements and processes related to CGMP are as follows:
■ ■

CGMP runs on both the switches and the router. The router sends CGMP multicast packets to the switches at a well-known multicast MAC address: 0100.0cdd.dddd. The CGMP packet contains the following: — Type field (join or leave) — MAC address of the IGMP client — Multicast address of the group

The switch uses CGMP packet information to add or remove an entry for a particular multicast MAC address.

Routing Multicast Traffic
The campus network is composed of a collection of subnetworks connected by routers. When the source of a video data stream is located on one subnet and the host devices are located on different subnets, there needs to be a way of determining how to get from the source to the destinations. This is the function of IP. Each host on the Internet has an IP address that identifies the host’s location. Part of the address identifies the subnet on which the host resides and part identifies the individual host on that subnet. Routers periodically send routing update messages to adjacent routers, conveying the network’s state as perceived by that particular router. This data is recorded in routing tables that are then used to determine optimal transmission paths for forwarding messages across the network. Unicast transmission involves transmission from a single source to a single destination. The transmission is directed toward a single physical location that is specified by the host address. This routing procedure is relatively straightforward because of the binding of a single address to a single host.

Routing Multicast Traffic

425

Routing multicast traffic is a more complex problem. A multicast address identifies a particular transmission session, rather than a specific physical destination. An individual host can join an ongoing multicast session by using IGMP to communicate this desire to the subnet router, as illustrated in Figure 7-33.
Figure 7-33 Multicast Transmissions Are Particularly Useful with IP Video Transmissions Unicast Video Server
100 Copies

Multicast Video Server
1 Copy

Switch
100 Copies

Switch
1 Copy

Router
33 Copies 33 Copies 34 Copies

Router
1 Copy 1 Copy 1 Copy

Router
33 Copies 33 Copies 34 Copies

Router
1 Copy 1 Copy 1 Copy

Switch
33 Clients 33 Clients 34 Clients

Switch
33 Clients 33 Clients 34 Clients

Because the number of receivers for a multicast session can potentially be quite large, the source should not need to know all the relevant addresses. Instead, the network routers must somehow be able to translate multicast addresses into host addresses. The basic principle involved in multicast routing is that routers interact with each other to exchange information about neighboring routers.

Distribution Trees
To deliver multicast packets to all receivers, designated routers construct a tree that connects all members of an IP multicast group. A distribution tree specifies a unique forwarding path between the subnet of the source and each subnet containing members of the multicast group. A distribution tree has just enough connectivity so that there is only one, loop-free path between every pair of routers. Because each router knows which of its lines belong to the tree, it can copy an incoming multicast datagram onto all the outgoing branches. This action generates the minimum needed number of datagram copies. Because messages are replicated

426

Chapter 7: Cisco AVVID

only when the tree branches, the number of copies of the messages transmitted through the network is minimized. Because multicast groups are dynamic, with members joining or leaving a group at any time, the distribution tree must be dynamically updated. Branches that contain new members must be added. Branches in which no listeners exist must be discarded, or pruned. As Figure 7-34 illustrates, there are two basic tree construction techniques:
■ ■

Source-specific trees Shared or center-specific trees

Figure 7-34 Source Distribution Trees and Shared Distribution Trees Are Used with IP Multicast Routing
Source

Source Tree (Shortest Path Tree)

Shared Tree from RP

Receiver

Source Distribution Tree
The simplest form of a multicast distribution tree is a source tree, whose root is the source of the multicast traffic and whose branches form a spanning tree through the network to the receivers. Because this tree uses the shortest path through the network, it is also often called a shortest-path tree (SPT). Figure 7-35 shows an example of an SPT for Group 224.1.1.1 rooted at the source, Host A, and connecting two receivers, Hosts B and C. The special notation of (S,G), pronounced “S comma G,” enumerates an SPT, where S is the IP address of the source and G is the multicast group address. Using this special notation, the SPT in Figure 7-35 would be written as (192.1.1.1, 224.1.1.1). The (S,G) entries are stored on the multicast routers.

Routing Multicast Traffic

427

Figure 7-35 Source Distribution Trees Are Indicated with the (S,G) Notation
Source Host A 192.1.1.1 Notation: (S, G) S = Source G = Group

A 224.1.1.1 Traffic

B

D

F

C

E

192.2.2.2 Receiver Host B Receiver

192.3.3.3 Host C

Notice that this notation implies that a separate SPT exists for every individual source originating a stream for a multicast group. Therefore, if Host B is also sending traffic to Group 224.1.1.1 and Hosts A and C are receivers, a separate (S,G) SPT would exist with a notation of (192.2.2.2, 224.1.1.1).

Shared Distribution Tree
Unlike source trees, which have their roots at the source, shared trees use a single common root placed at some chosen point in the network. Depending on the multicast routing protocol, this root is often called a rendezvous point (RP) or core, which lends itself to other common names of shared trees: RP Trees (RPT) or Core-Based Trees (CBT). Figure 7-36 shows a shared tree for Group 224.2.2.2 with the root located at Router D. When using a shared tree, sources must send their traffic to the root for the traffic to reach all receivers. In this example, multicast group traffic from source Host A and Host D travels to the root (Router D) and then down the shared tree to two receivers, Hosts B and Host C. Because all sources in the multicast group use a common shared tree, a wildcard notation written as (*,G), pronounced “star comma G,” represents the tree. In this case, * means all sources, and G represents the multicast group. Therefore, the shared tree shown in Figure 7-36 would be written (*,224.2.2.2). The (*,G) entries are stored on the multicast routers.

428

Chapter 7: Cisco AVVID

Figure 7-36 Shared Distribution Trees Are Indicated with the (*,G) Notation
Source Host A 192.1.1.1 Notation: (*, G) * = Source G = Group

Source 2 Host D

A 224.2.2.2 Traffic

B

D (Shared Root)

F

C

E

192.2.2.2 Receiver Host B Receiver

192.3.3.3 Host C

Managing Delivery of Multicast Packets
In a campus network, limiting high-bandwidth traffic to specific LANs or regions within the network is essential to containing or eliminating unnecessary consumption of resources. One method of containing multicast traffic is to impose constraints on the forwarding of that traffic by using the Time-To-Live (TTL) field in the IP packet. As in unicast routing, the multicast TTL field controls the packet’s lifetime. The function of TTL is to prevent packets from being looped forever because of routing errors. However, the TTL field in multicasting also carries the concept of a “threshold.” Multicast-enabled routers have a TTL threshold assigned to each interface. Packets with a TTL greater than the interface threshold are forwarded, and packets with a TTL equal to or less than the interface threshold are discarded. The packet TTL is compared to the interface threshold first. The router then decrements the packet TTL by a value of 1 as the packet is sent out the interface (see Figure 7-37). A multicast packet with a TTL of less than 16 is restricted to the same department, or site, and should not be forwarded across an interface to other sites in the same region. Defining the scope of a “site” or “region” is the responsibility of the network administrator.

Routing Multicast Traffic

429

Figure 7-37 Assigning a TTL Threshold to Each Interface Limits the Scope of Multicast Transmission

ACME Manufacturing, Inc. Human Resources Personnel Payroll Engineering

TTL Threshold = 15

TTL Threshold = 31

TTL Threshold = 127 Assigning a TTL Threshold to Each Interface Limits the Scope of Multicast Transmission

A multicast router forwards a multicast packet across an interface only if the TTL field in the IP header is greater than the TTL threshold assigned to the interface. If the TTL field in the packet’s IP header is equal to or less than the TTL threshold assigned to the interface, the packet is discarded. If the interface has no assigned TTL threshold, the packet is forwarded. In Figure 7-38, the interfaces on the router have been configured with the following TTL thresholds:
■ ■ ■

E1—TTL Threshold = 16 E2—TTL Threshold = 0 (none) E3—TTL Threshold = 64

An incoming multicast packet for Group XYZ is received on Interface E0 with a TTL of 24. The outgoing interface list for Group XYZ contains Interfaces E1, E2, and E3. The TTL threshold check is performed on each outgoing interface as follows:
■ ■ ■

E1—TTL (24) > TTL Threshold (16). FORWARD E2—TTL (24) > TTL Threshold (0). FORWARD E3—TTL (24) < TTL Threshold (64). DROP

The TTL is then decremented to 23 by normal router IP packet processing.

430

Chapter 7: Cisco AVVID

Figure 7-38 Distinct TTL Thresholds Can Be Configured on Independent Interfaces Multicast Packet w/TTL = 24 Group XYZ

E0 E1 E3 E2

E1: (TTL Threshold = 16) E2: (TTL Threshold = 0) E3: (TTL Threshold = 64)

Reverse Path Forwarding (RPF)
Reverse Path Forwarding (RPF) is a fundamental concept in multicast routing that lets routers correctly forward multicast traffic down the distribution tree. RPF uses the existing unicast routing table to determine the upstream and downstream neighbors. A router forwards a multicast packet only if it is received on the upstream interface. This RPF check helps guarantee that the distribution tree is loop-free.

RPF Check
When a multicast packet arrives at a router, the router performs an RPF check on the packet. If the RPF check is successful, the packet is forwarded. Otherwise, it is dropped. For traffic flowing down a source tree, the RPF check procedure works as follows:
1. The router looks up the source address in the unicast routing table to determine if it has

arrived on the interface that is on the reverse path back to the source.
2. If the packet has arrived on the interface leading back to the source, the RPF check is

successful, and the packet is forwarded.
3. If the RPF check in Step 2 fails, the packet is dropped.

Figure 7-39 shows an example of an unsuccessful RPF check.

Routing Multicast Traffic

431

Figure 7-39 Packets That Fail the RPF Check Are Discarded Multicast Packet from Source 151.10.3.21

S0 S1

S2

E0

Packet Arrived on Wrong Interface! Discard Packet Multicast Route Table
Network 151.10.0.0/16 198.14.32.0/24 204.1.16.0/24 Interface S1 S0 E0

A multicast packet from source 151.10.3.21 is received on interface S0. A check of the unicast route table shows that the interface this router would use to forward unicast data to 151.10.3.21 is S1. Because the packet arrives on S0, it is discarded. Figure 7-40 is an example of a successful RPF check.
Figure 7-40 Packets That Pass the RPF Check Are Forwarded Multicast Packet from Source 151.10.3.21

S0 S1

S2

E0

Packet Arrived on Correct Interface! Multicast Route Table
Network 151.10.0.0/16 198.14.32.0/24 204.1.16.0/24 Interface S1 S0 E0

432

Chapter 7: Cisco AVVID

This time the multicast packet arrives on S1. The router checks the unicast routing table and finds that S1 is the correct interface.

Multicast Routing Protocols
A multicast routing protocol is responsible for constructing multicast delivery trees and enabling multicast packet forwarding. Different IP multicast routing protocols use different techniques to construct multicast spanning trees and forward packets. IP multicast routing protocols generally follow one of two basic approaches, depending on the distribution of multicast group members on the network:

Dense-mode routing protocols: — DVMRP — PIM Dense Mode (PIM-DM) — Multicast Open Shortest Path First (MOSPF)

Sparse-mode routing protocols: — CBT — PIM Sparse Mode (PIM-SM)

Dense-Mode Routing Protocols
The dense-mode routing protocol approach is based on the assumption that the multicast group members are densely distributed throughout the network and bandwidth is plentiful, meaning that almost all hosts on the network belong to the group. These dense-mode multicast routing protocols rely on periodic flooding of the network with multicast traffic to set up and maintain the distribution tree. To reiterate, dense-mode routing protocols include the following:
■ ■ ■

DVMRP PIM-DM MOSPF

Dense-mode protocols employ only SPTs to deliver (S,G) multicast traffic using a push principle. The push principle assumes that every subnet in the network has at least one receiver of the (S,G) multicast traffic, and, therefore, the traffic is pushed or flooded to all points in the network. This process is analogous to a radio or TV broadcast that is transmitted over the air to all homes within the coverage area. Receivers simply need to tune in to the broadcast to receive the program. The DM protocols are most appropriate in environments with densely clustered receivers and the bandwidth to tolerate flooding. An example of when a DM protocol might be used is

Routing Multicast Traffic

433

when a CEO of a company wants to broadcast a message to all employees within the headquarters campus network.

Distance Vector Multicast Routing Protocol
DVMRP was the first true multicast routing protocol to see widespread use. DVMRP is similar in many ways to Routing Information Protocol (RIP), with some variations added to support multicast. Described in RFC 1075, DVMRP is widely used on the Internet multicast backbone (MBONE). The key characteristics of DVMRP are as follows:
■ ■ ■ ■

Distance vector-based (similar to RIP) Periodic route updates (every 60 seconds) Infinity = 32 hops Classless

DVMRP uses reverse-path flooding. When a router receives a packet, it floods the packet out all paths except the one that leads back to the packet source. This technique allows a data stream to reach all LANs. If a router is attached to a set of LANs that do not want to receive a particular multicast group, the router can send a prune message back up the distribution tree to stop subsequent packets from traveling where there are no members. DVMRP periodically floods packets to reach any new hosts that want to receive traffic from a particular multicast group. There is a direct relationship between the time it takes for a new receiver to get the data stream and the frequency of flooding. DVMRP implements its own unicast routing protocol to determine which interface leads back to the source of the data stream. This unicast routing protocol is similar to RIP and is based purely on hop counts. As a result, the path that the multicast traffic follows might not be the same as the path that the unicast traffic follows.
NOTE Cisco routers run PIM. They know enough about DVMRP to successfully forward multicast packets to and receive packets from a DVMRP neighbor. Cisco routers can also propagate DVMRP routes into and through a PIM cloud. However, only the PIM protocol uses this information. Cisco routers do not implement DVMRP to forward multicast packets.

Protocol-Independent Multicast Dense Mode
Protocol-Independent Multicast (PIM) gets its name from the fact that it is IP routing protocol-independent. That is, regardless of which unicast routing protocol(s) is/are used to populate the unicast routing table (including static routes), PIM uses this information to perform multicast forwarding; hence, it is protocol-independent. Although PIM is typically referred to as a multicast routing protocol, it actually uses the existing unicast routing table to perform the RPF check function instead of maintaining a separate multicast route table. Because PIM doesn’t have to maintain its own routing table, it doesn’t send or receive multicast route updates like other protocols, such as MOSPF and DVMRP. By not having to send multicast route updates, the PIM overhead is significantly reduced in comparison to other multicast protocols.

434

Chapter 7: Cisco AVVID

PIM-DM is similar to DVMRP, as you can see from the following list of key characteristics:
■ ■ ■ ■

Protocol-independent (uses a unicast route table for RPF check) No separate multicast routing protocol (as with DVMRP) Flood-and-prune behavior (3-minute cycle) Classless (as long as classless unicast routing is in use)

PIM-DM works best when numerous members belong to each multimedia group. PIM floods the multimedia packet to all routers in the network and then prunes routers that do not support members of that particular multicast group. PIM-DM is most useful when
■ ■ ■ ■

Senders and receivers are in close proximity to one another There are few senders and many receivers The volume of multicast traffic is high The stream of multicast traffic is constant

PIM-DM is no longer a widely deployed protocol because PIM-SM has proven to be the more efficient multicast solution.

Multicast Open Shortest Path First
NOTE Cisco routers do not support MOSPF.

Described in RFC 1584, Multicast Open Shortest Path First (MOSPF) is intended for use within a single routing domain, such as a network controlled by a single organization. MOSPF is dependent on the use of OSPF as the accompanying unicast routing protocol. Figure 7-41 shows how MOSPF works by including multicast information in OSPF link-state advertisements. An MOSPF router learns which multicast groups are active on which LANs. MOSPF is best suited for environments that have relatively few (S,G) pairs active at any given time. This protocol works less well in environments that have many active sources or unstable links.

Sparse Mode Routing Protocols
The second approach to multicast routing is based on the assumption that the multicast group members are sparsely distributed throughout the network and bandwidth is not necessarily widely available. It is important to note that sparse mode does not imply that the group has few members, just that they are widely dispersed. In this case, flooding would unnecessarily waste network bandwidth and could cause serious performance problems. Therefore, sparse-mode multicast routing protocols must rely on more selective techniques to set up and maintain multicast trees. Sparse-mode protocols begin with an empty distribution tree and add branches only as the result of explicit requests to join the distribution.

Routing Multicast Traffic

435

Figure 7-41 MOSPF Operation OSPF Area Member N8 X MOSPF N1 Member MOSPF Member N9 Y Member

MOSPF Source 2

N2

A MOSPF

B MOSPF

N3

D MOSPF N4 MOSPF N5

E MOSPF N6

F MOSPF N7

Source 1

Source 1

Member

Member

To reiterate, sparse-mode routing protocols include the following:
■ ■

CBT PIM-SM

Because sparse-mode protocols assume that relatively few routers in the network will be involved in each multicast, these protocols are more appropriate in WAN environments.

Core-Based Trees
RFC 2201 describes CBT. The CBT protocol constructs a single tree that is shared by all members of the group. Multicast traffic for the entire group is sent and received over the same tree, regardless of the source. This use of a shared tree can provide significant savings in terms of the amount of multicast state information that is stored in individual routers. A CBT shared tree has a core router that is used to construct the tree, as shown in Figure 7-42. Routers join the tree by sending a join message to the core. When the core receives a join request, it returns an acknowledgment over the reverse path, thus forming a branch of the tree. Join messages need not travel all the way to the core before being acknowledged. If a

436

Chapter 7: Cisco AVVID

join message encounters a router on the tree before the message reaches the core, that router terminates the join message and acknowledges it. The router that sent the join is then connected to the shared tree.
Figure 7-42 The CBT Protocol Core Router Constructs a Single Tree Shared by All Members of the Group

Source 1 Core Router Source 2 Join Message

Join Message I am already a branch of that tree. I will acknowledge the join message.

I have a member who wants to join Group XYZ.

The CBT multicast routing protocol is truly a work in progress and has been so for several years. The original version, CBTv1, was superseded by CBTv2 (defined in RFC 2189), which, unfortunately, is not backward-compatible with CBTv1. However, because CBTv1 was never really implemented in any production networks to speak of, backward compatibility is not an issue. CBTv2 also has not seen significant deployment to date, which is probably good, because a new draft specification for CBTv3 is already out that supersedes and is not backward-compatible with CBTv2!

PIM-SM
Protocol-Independent Multicast Sparse Mode (PIM-SM) is optimized for environments that have many multipoint data streams. Sparse multicast is most useful when
■ ■

A group has few receivers The type of traffic is intermittent

Routing Multicast Traffic

437

In sparse mode, each data stream goes to a relatively small number of segments in the campus network. Instead of flooding the network to determine the status of multicast members, PIM-SM defines a rendezvous point. When a sender wants to send data, it first sends to the rendezvous point. When a receiver wants to receive data, it registers with the rendezvous point. When the data stream begins to flow from sender to rendezvous point to receiver, the routers in the path optimize the path automatically to remove any unnecessary hops. PIM-SM assumes that no hosts want the multicast traffic unless they specifically ask for it. PIM can simultaneously support dense mode for some multicast groups and sparse mode for others.

Configure IP Multicast Routing
The IP multicast routing tasks are divided into basic and advanced tasks. The basic tasks that must be performed to set up a multicast session are as follows:
■ ■ ■ ■ ■ ■ ■

Enabling IP multicast routing Enabling PIM on an interface Configuring a rendezvous point (optional) Configuring a TTL threshold (optional) Joining a multicast group (optional) Changing the IGMP version (optional) Enabling CGMP or IGMP snooping (optional)

The first two basic tasks in the list are required to configure IP multicast routing; the remaining tasks are optional.
NOTE

Configuring PIM-SM is really quite straightforward. On each router in the network, IP multicast routing must be enabled by using the ip multicast-routing global configuration command, first introduced in Cisco IOS Release 10.1. Then, it is best to enable PIM-SM on every interface in every router in the network using the ip pim sparse-mode interface command. The final step is to configure each of the routers in the network with the RP’s IP address using the following global configuration command:
Router(config)#ip pim rp-address rp-address

This command tells the router where to send the (*,G) joins when it needs to join the shared tree in sparse mode. The reason for turning on multicast on every interface is that IP multicast routing is upsidedown routing that forwards (or does not forward) multicast packets based on where the packets came from (source IP address) as opposed to where they are going (multicast group address). Consequently, the control mechanism for multicast traffic paths is not quite the same as the control mechanism for unicast routing.

Another method of enabling multicast on an interface is the use of the ip pim sparsedense-mode command. This command allows the router to use either dense or sparse mode, depending on the existence of RP information for each multicast group. This makes it much easier to switch the entire network from dense mode to sparse mode (or vice versa) as needed. PIM sparsedense mode is the recommended mode to use when deploying AutoRP, as discussed later.

438

Chapter 7: Cisco AVVID

Not turning on multicast routing on every interface is a common mistake when network administrators are first enabling multicast routing. Failure to enable multicast on every interface often results in RPF failures, because the RPF interface for a particular source of multicast traffic is the interface that would be used if the router sent traffic to this particular source.

Verify PIM Configuration
To display information about interfaces configured for PIM, enter the show ip pim interface [type number] [count] privileged mode command, as shown in Example 7-2.
Example 7-2 Displaying the IP Address of the Next-Hop Multicast Router, as Well as the Interface’s PIM Mode, Can Be Useful
Router#show ip pim interface Address Interface Version/Mode Nbr Query Count Intvl 10.1.1.2 192.168.1.1 0.0.0.0 Router# FastEthernet0/0 Serial0/0 Serial0/1 v2/Sparse-Dense v2/Sparse-Dense v2/Sparse-Dense 0 0 0 30 30 30 10.1.1.2 0.0.0.0 0.0.0.0 DR

The output in Example 7-2 displays the following items:
■ ■

The IP address of the next-hop router The interface type; on a Route Switch Module (RSM), this value is the VLAN designation The PIM version and mode configured on each interface How many PIM neighbors have been discovered through this interface The frequency, in seconds, of PIM router-query messages The IP address of the designated router on the LAN

■ ■ ■ ■

Designated Router Selection
NOTE DR election is necessary only on multiaccess networks. It is not required for pointto-point links, because the connected router is effectively the DR for directly connected host systems.

Cisco routers use the PIM routing protocol to forward multicast traffic. Two PIM routers are neighbors if there is a direct connection between them. Each multicast-enabled router is configured to know which interfaces will use PIM. These interfaces connect either to neighboring PIM routers in the network or to host systems on a LAN. If a LAN has multiple PIM routers, they are considered neighbors. The procedure for electing the designated router (DR) is the same for both PIM-SM and PIM-DM. Each PIM router connected to a multiaccess LAN issues periodic PIM router

Routing Multicast Traffic

439

queries onto the LAN. The PIM router with the highest IP address becomes the DR for the LAN. If the DR becomes inoperable, a new DR is elected from the alternate PIM routers on the LAN. Figure 7-43 illustrates the DR election process.
Figure 7-43 PIM Elects a DR on a LAN
172.16.41.143 172.16.41.144

PIM Router 1

PIM Router 2 Highest IP Address Elected as DR

PIM Query

PIM Query

On a multiaccess LAN, one router is selected to poll the LAN for host group membership. However, all PIM routers on a single subnet receive replies from the host. The router selected to poll the LAN is called the DR. The DR is responsible for sending IGMP host-query messages to all hosts on the LAN. A campus network can have many DRs, one for each leaf subnet of the distribution tree.

Displaying PIM Neighbors
Cisco IOS software can be used to discover the PIM neighbors in the network. To display a table of the neighboring routers from a specific router, enter this privileged mode command:
Router#show ip pim neighbor type number

Configure Auto-RP (Optional)
Manually configuring multiple rendezvous points in a large campus network can result in inconsistent RP configurations and can cause connectivity problems. Auto-RP is a Cisco-proprietary standalone protocol that automates the distribution of group-to-RP mappings in a network running sparse-mode PIM. Auto-RP facilitates the use of multiple RPs within a network to serve different group ranges. Auto-RP also allows load splitting among different RPs and the arrangement of RPs according to the locations of group participants. With the AutoRP mechanism, an rp-announce command must be entered on the router to act as an RP for a certain range of multicast group addresses. Multiple RPs can be used to serve different group ranges, or to serve as backups of each other. An RP mapping agent is assigned to a router to receive the RP announcement messages. The RP mapping agent then sends the

440

Chapter 7: Cisco AVVID

consistent group-to-RP mappings to all designated routers. This method allows all designated routers to automatically discover which RP to use for attached receivers and senders, as shown in Figure 7-44.
Figure 7-44 Auto-RP Enables the Propagation of Group-to-RP Mappings I would like to be the RP for Group XYZ. Router B

I would like to be the RP for Group ABC. Router A

Router A is the RP for Group ABC and Router B is the RP for Group XYZ. RP Mapping Agent

Campus Network

Designated Router

Designated Router

Designated Router

Auto-RP is disabled by default. To enable it on a router, enter the following global configuration mode command:
Router(config)#ip pim send-rp-announce type number scope ttl group-list access-list-number

To disable a router as a candidate RP, enter the no ip pim send-rp-announce command. As illustrated in Figure 7-45, candidate RPs send an Auto-RP RP announcement message to the well-known group CISCO-RP-ANNOUNCE (224.0.1.39). A router configured as an RP mapping agent listens on this well-known group address to determine which RPs act for the various ranges of multicast group addresses. The RP mapping agent then sends the RP-to-group mappings in an Auto-RP RP discovery message to the well-known group CISCO-RP-DISCOVERY (224.0.1.40). PIM DRs listen to this well-known group to determine which RPs to use. By default, a router is not configured as a PIM RP mapping agent. To configure a router to send Auto-RP RP discovery messages, enter the following global configuration mode command:
Router(config)#ip pim send-rp-discovery scope ttl

ttl is the Time-To-Live value that limits the scope of the discovery message.

Routing Multicast Traffic

441

Figure 7-45 Auto-RP Relies on the Well-Known Multicast Groups 224.0.1.39 and 224.0.1.40 RP Candidate RP Candidate

rp-announce Message

rp-announce Message

Well-Known Group 224.0.1.39

RP Mapping Agent rp-discovery Message

rp-discovery Message Well-Known Group 224.0.1.40 Well-Known Group 224.0.1.40

Designated Router

Designated Router

Designated Router

Designated Router

Designated Router

Designated Router

Example 7-3 shows that Nakagawa is an RP mapping agent. The scope of the discovery messages is 16 router hops.
Example 7-3 An RP Mapping Agent Is Used to Advertise the RP-to-Group Mappings
Nakagawa(config)#ip multicast-routing Nakagawa(config)#ip pim send-rp-discovery scope 16

To disable a router as an RP mapping agent, enter the no ip pim send-rp-discovery command.

Optional IP Multicast Routing Tasks
Optional IP multicast routing tasks include the following (as described in the following sections):
■ ■ ■

Defining the scope of delivery of multicast packets Joining a multicast group Changing IGMP versions

442

Chapter 7: Cisco AVVID

Defining the Scope of Delivery of Multicast Packets
The function of the TTL parameter on a multicast-enabled interface controls whether packets are forwarded out that interface.
NOTE Because the TTL field is used to limit the range, or scope, of a multicast transmission, configure the TTL threshold only on border routers. Routers on which a TTL threshold value is configured automatically become border routers.

Only multicast packets with a TTL greater than the interface TTL threshold are forwarded on the interface. Packets with a TTL equal to or less than the interface threshold are discarded. The packet TTL is compared to the interface threshold first. The router then decrements the packet TTL by a value of 1 upon sending the packet out the interface. The default value for the TTL threshold on an interface is 0. A value of 0 means that all multicast packets are forwarded on the interface. To change the default TTL threshold value, enter the following command in interface configuration mode:
Router(config-if)#ip multicast ttl-threshold ttl

ttl signifies the TTL value in router hops; this value can range from 0 to 255 hops. In Example 7-4, the TTL threshold is set to 16 router hops.
Example 7-4 The TTL Threshold Can Be Set Between 0 and 255
Router#show running-config

<output omitted>

interface FastEthernet0/0 ip address 10.1.1.2 255.255.255.0 no ip directed-broadcast ip pim sparse-dense-mode ip multicast ttl-threshold 16

<output omitted>

To restore the default value of 0, enter the following command in interface configuration mode:
Router(config-if)#no ip multicast ttl-threshold

Joining a Multicast Group
Cisco routers can be configured to be members of a multicast group. Being a member of a multicast group is useful in determining multicast reachability in a network. If a router is configured to be a member of a specific multicast group, that router can respond to commands,

Routing Multicast Traffic

443

such as ping and Internet Control Message Protocol (ICMP) echo requests, addressed to that group. A group member router can also participate in multicast Cisco IOS software traceroute actions. To have the router join a multicast group, enter the following command in interface configuration mode:
Router(config-if)#ip igmp join-group group-address

NOTE The term interface describes the primary interface on an attached network. If a router has multiple physical interfaces on a single network, this protocol needs to run on only one of the interfaces. Hosts, on the other hand, need to perform their actions on all interfaces that have memberships associated with them.

group-address is the address of the multicast group. The configuration shown in Example 7-5 places the router in multicast Group 224.1.1.1.
Example 7-5 A Router Interface Can Be Configured to Participate as a Host in a Distribution Tree
Router#show running-config

<output omitted>

interface FastEthernet0/0 ip address 10.1.1.2 255.255.255.0 no ip directed-broadcast ip pim sparse-dense-mode ip multicast ttl-threshold 16 ip igmp join-group 224.1.1.1

<output omitted>

Issuing a ping command specifying that multicast group address causes all routers in that group to respond. To cancel a router’s membership in a multicast group, enter the no ip igmp join-group group-address command.

Changing IGMP Versions
Cisco routers do not automatically detect the IGMP version of systems on the subnet and dynamically switch between versions. IGMP Version 2 mode is the default for all systems using Cisco IOS Release 11.3(2)T or later. IGMP Version 3 is available with Cisco IOS Release 12.0(15)S or later. To determine the current version setting for an interface, enter the following privileged command:
Router#show ip igmp interface type-number

444

Chapter 7: Cisco AVVID

type-number represents the name of the interface on which the IGMP protocol is configured. Example 7-6 shows sample output from the show ip igmp interface command to determine the IGMP version.
Example 7-6 Determining the IGMP Version on an Interface
Router#show ip igmp interface fast 0/0 FastEthernet0/0 is up, line protocol is up Internet address is 10.1.1.2/24 IGMP is enabled on interface Current IGMP version is 2 CGMP is disabled on interface IGMP query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP max query response time is 10 seconds Last member query response interval is 1000 ms Inbound IGMP access group is not set IGMP activity: 3 joins, 1 leaves Multicast routing is enabled on interface Multicast TTL threshold is 16 Multicast designated router (DR) is 10.1.1.2 (this system) IGMP querying router is 10.1.1.2 (this system)

To enable a specific IGMP version, enter the following interface configuration mode command:
ip igmp version {3 | 2 | 1}

To restore the default value of Version 2, enter the no ip igmp version command. Because of its unique capability to send out a single data stream to multiple clients, IP multicast technologies have become the transmission method of choice for most multimedia applications.

Cisco IP Telephony
Cisco AVVID was discussed earlier in this chapter. Cisco AVVID includes the Cisco IP Telephony solution. The chapter then changed gears and explored IP multicast, which is also part of the AVVID architecture. This chapter now looks at the Cisco IP Telephony solution in more detail.

Cisco IP Telephony

445

Voice over IP (VoIP) is probably the most feasible among today’s technologies for data, voice, and video integration. VoIP is the technology that uses IP to transmit voice conversations over a data network, such as an intranet or the Internet.

Introducing the Cisco IP Telephony Solution
The Cisco IP Telephony solution relies on the stable foundation of Cisco multiprotocol routers and Catalyst multilayer LAN switches, which are the building blocks in enterprise networks. Cisco CallManager is the heart of an IP Telephony solution. Figures 7-46, 7-47, and 7-48 illustrate alternative CallManager deployments used in Cisco IP Telephony deployments. The uOne Messaging System is composed of three components:
■ ■

A uOne GateServer Two back-end servers (the directory server and the message server)

These components run on a Sun Sparc server.
Figure 7-46 No Geographic Limitations Exist for Deploying CallManager Servers CallManager Cluster Applications (VMail, IVR, ICO,...)

GK

V

V

PSTN West Coast Headquarters (with SRST and APPs) Branch Office (with Call Processing and Apps)

IP WAN

Rest of the World East Coast Headquarters

446

Chapter 7: Cisco AVVID

Figure 7-47 CallManager Provides a Migration Path from Legacy to Pure IP Telephony Solutions

PSTN

Cisco CallManager Router
V

IP WAN

Figure 7-48 CallManager Clusters Can Be Used for Large-Scale IP Telephony Solutions Msg Store Msg Store

LDAP Directory

Cisco uOne GateServer

Cisco CallManager Cluster

IP WAN

PSTN Catalyst Backbone Catalyst Wiring Closet

Cisco IP Telephony

447

Cisco CallManager is the software-based call-processing component and essentially is the heart of the Cisco IP Telephony solution. The software extends enterprise telephony features and functions to packet telephony network devices such as IP Phones, media processing devices, voice over IP (VoIP) gateways, and multimedia applications. Additional data, voice, and video services such as unified messaging, multimedia videoconferencing, collaborative contact centers, and interactive multimedia response systems interact with the IP Telephony solution through Cisco CallManager’s open telephony application programming interface (API). The Cisco CallManager software includes a suite of integrated voice applications that perform ad hoc voice conferencing and browser-based attendant console functions. The key benefit of all these voice applications is that special-purpose voice processing hardware is not required. Supplementary and enhanced services such as hold, transfer, forward, conference, multiple line appearances, automatic route selection, speed dial, and last-number redial are available on Cisco CallManager. It also provides extension mobility. Users can log in to any IP Phone, and the extension and the individual’s dial privileges are applied to the phone regardless of his or her location. This lets users access all of their personal phone features, such as fast dials, personal contacts, voice mail, productivity applications, and more from any IP Phone when they are away from their desks. Multiple Cisco CallManager servers are clustered and managed as a single entity. The ability to cluster multiple call-processing servers on an IP network is unique in the industry and provides scalability for up to 10,000 users per cluster. By interlinking multiple clusters, system capacity can be increased to up to 100,000 users per multiple cluster system. Clustering aggregates the power of multiple distributed Cisco CallManager servers, enhancing the scalability and accessibility of the servers to phones, gateways, and applications. Triple server redundancy improves overall system availability. Call admission control ensures that voice QoS is maintained across constricted WAN links and automatically diverts calls to alternate PSTN routes when WAN bandwidth is unavailable. Figure 7-49 shows the availability and scalability of four Cisco hardware platforms when deployed in an IP Telephony environment. Figures 7-50, 7-51, and 7-52 show the various graphical user interface (GUI) components of CallManager and Cisco IP Phones.

448

Chapter 7: Cisco AVVID

Figure 7-49 Several Cisco Hardware Platforms Are Available to Enable Scalable IP Telephony Solutions

Figure 7-50 The CallManager GUI Allows for Easy Viewing of IP Phones on the Network

Cisco IP Telephony

449

Figure 7-51 The CallManager GUI Can Display the Configuration on an Individual IP Phone

Figure 7-52 Cisco IP Phones Have a Graphical Interface Used to Enable Easy Configuration and to Display Useful Information

450

Chapter 7: Cisco AVVID

Cisco IP Telephony Designs
The overall goals of an IP Telephony network are as follows:
■ ■

End-to-end IP Telephony IP WAN as the primary voice path between sites, with the PSTN as the secondary voice path Lower total cost of ownership with greater flexibility Enabling of new applications

■ ■

Currently, four general design models apply to the majority of implementations:
■ ■ ■ ■

Single-site model Multiple sites with independent call processing Multisite IP WAN with distributed call processing Multisite IP WAN with centralized call processing

The following sections summarize the design goals and implementation guidelines for each of these models.

Single-Site Model
The single-site model has the following design characteristics:
■ ■ ■

A single Cisco CallManager server or CallManager cluster A maximum of 10,000 users per cluster A maximum of eight servers in a Cisco CallManager cluster (four servers for primary call processing, two for backup call processing, one database publisher, and one Trivial File Transfer Protocol [TFTP] server) A maximum of 2500 users registered with a Cisco CallManager server at any time The PSTN only for all external calls Digital signal processor (DSP) resources for conferencing Voice mail and unified messaging components A G.711 codec for all IP phone calls (80 kbps of IP bandwidth per call, uncompressed) To guarantee voice quality, use Cisco LAN switches with a minimum of two queues.

■ ■ ■ ■ ■ ■

Figure 7-53 illustrates the single-site design model for a Cisco IP Telephony network.

Cisco IP Telephony

451

Figure 7-53 The Single-Site Model Uses a Single CallManager Server or CallManager Cluster Msg Store Msg Store LDAP Directory Cisco uOne GateServer

Cisco CallManager Cluster

IP WAN

PSTN Catalyst Backbone

Catalyst Wiring Closet

Multiple Sites with Independent Call Processing
The independent multiple sites model has the following design characteristics:

A Cisco CallManager server or CallManager cluster at each site to provide scalable call control A maximum of 10,000 IP Phones per cluster No limit on the number of clusters Use of the PSTN for networking multiple sites and for all external calls DSP resources for conferencing at each site Voice messaging or unified messaging components at each site Voice compression is not required

■ ■ ■ ■ ■ ■

Figure 7-54 illustrates the multiple site with independent call processing design model for a Cisco IP Telephony network.

452

Chapter 7: Cisco AVVID

Figure 7-54 Multiple Sites with Independent Call Processing Use a CallManager Server or Cluster at Each Site

V

PSTN
V

V

Multiple Sites with Distributed Call Processing
The multisite IP WAN with distributed call processing has the following design characteristics:

A Cisco CallManager server or CallManager cluster at each location (10,000 users maximum per site) Cisco CallManager clusters are confined to a single campus and might not span the WAN. IP WAN as the primary voice path between sites, with the PSTN as the secondary voice path Transparent use of the PSTN if the IP WAN is unavailable Cisco IOS gatekeeper for E.164 address resolution Cisco IOS gatekeeper for admission control to the IP WAN A maximum of 100 sites interconnected across the IP WAN using hub-and-spoke topologies

■ ■

■ ■ ■ ■

Cisco IP Telephony

453

■ ■ ■ ■ ■

Compressed voice calls are supported across the IP WAN. A single WAN codec is supported. DSP resources for conferencing and WAN transcoding at each site. Voice mail and unified messaging components at each site. The minimum bandwidth requirement for voice and data traffic is 56 kbps. For voice, interactive video, and data, the minimum requirement is 768 kbps. In each case, the bandwidth allocated to voice, video, and data should not exceed 75% of the total capacity. Remote sites can use Cisco IOS as well as gateways based on the Skinny Gateway Protocol.

Figure 7-55 illustrates the multisite IP WAN with a distributed call processing design model for a Cisco IP Telephony network.
Figure 7-55 Multiple Sites with Distributed Call Processing Use the Cisco IOS Gatekeeper for Admission Control

PSTN (Secondary Voice Path)

V

V

Site B

Site A

IP WAN (Primary Voice Path)

V

Cisco IOS Gatekeeper for Admission Control

Site C

454

Chapter 7: Cisco AVVID

Multisite IP WAN with Centralized Call Processing
The multisite IP WAN with centralized call processing has the following design characteristics:

The central site supports only one active Cisco CallManager server. A cluster can contain a secondary and tertiary CallManager server as long as all IP Phones served by the cluster are registered to the same CallManager server at any given time. This is called a centralized call processing cluster. Each centralized call processing cluster supports a maximum of 2500 users (there’s no limit on the number of remote sites). Multiple centralized call processing clusters of 2500 users at a central site can be interconnected using H.323. IP Phones at remote sites do not have a local Cisco CallManager server. The call admission control mechanism is based on bandwidth by location. Compressed voice calls across the IP WAN are supported. Manual use of the PSTN is available if the IP WAN is fully subscribed for voice traffic (the PSTN access code must be dialed after a busy signal). Dial backup is required for IP Phone service across the WAN in case the IP WAN goes down. Voice mail, unified messaging, and DSP resource components are available at the central site only. The minimum bandwidth requirement for voice and data traffic is 56 kbps. For voice, interactive video, and data, the minimum requirement is 768 kbps. In each case, the bandwidth allocated to voice, video, and data should not exceed 75 percent of the total capacity. Remote sites can use Cisco IOS, as well as gateways, based on the Skinny Station Protocol. If using voice mail, each site must have unique internal dial plan number ranges. Internal dial plans cannot be overlapped among remote sites if voice mail is required—no two sites can share 1XXX.

■ ■ ■ ■

Figure 7-56 illustrates the multisite IP WAN with a centralized call processing design model for a Cisco IP Telephony network.
Interactive Media Activity Checkbox: Cisco IP Telephony Designs

This Interactive Media Activity reinforces the goals of Cisco IP Telephony.

Voice Quality Issues

455

Figure 7-56 Multisite IP WAN with Centralized Call Processing Relies on a Centralized CallManager Cluster

V

Centralized Cisco Manager Cluster Site B

V

V

PSTN Site C

Site A

IP WAN

Telecommuter

V

Voice Quality Issues
Although VoIP is one of the most useful technologies in recent history, its effective deployment is strongly dependent on the quality of service implemented for the voice traffic. IP phones sit at the access layer, normally connected to Layer 2 switches. From the access layer to the WAN, QoS features must be implemented to optimize voice quality.

Common Voice Issues
Two major factors affect voice quality:

Delayed packets—Packet delay can cause either voice quality degradation because of the end-to-end voice latency or packet loss if the delay is variable. If the end-to-end voice latency becomes too long (250 milliseconds (ms), for example), the conversation begins to sound like two parties talking on a CB radio. If the delay is variable, there is a risk of jitter buffer overruns at the receiving end. Lost packets—Packet loss causes voice clipping and skips.

456

Chapter 7: Cisco AVVID

The next sections explore common voice issues in more detail.

Delay
One of the most important design considerations in implementing voice is minimizing oneway, end-to-end delay. Voice traffic is real-time traffic; if there is too long a delay in voice packet delivery, speech becomes unrecognizable. Delay is inherent in voice networking and is caused by a number of different factors, such as low-bandwidth links. An acceptable delay is less than 200 ms. Two kinds of delay are inherent in today’s telephony networks:

Propagation delay—Propagation delay is caused by the characteristics of the speed of light traveling via a fiber-optic-based or copper-based medium. Handling delay—Sometimes called serialization delay, handling delay is caused by the devices that handle voice information. Handling delays significantly degrade voice quality in a packet network. Delays caused by codecs are considered handling delays. Another handling delay is the time it takes to generate a voice packet. In VoIP, the DSP generates a frame every 10 ms. Two of these frames are then placed within one voice packet, so the packet delay is 20 ms. A third source of handling delay is the time it takes to move the packet to the output queue. Cisco IOS software expedites the process of determining packet destination and getting the packet to the output queue. The actual delay at the output queue is another source of handling delay and should be kept under 10 ms whenever possible by using queuing methods that are optimal for the network.

Jitter
Jitter is another factor that affects delay. Jitter is the difference between when a voice packet is expected to be received and when it actually is received, causing discontinuity in the realtime voice stream. Voice devices compensate for jitter by setting up a playout buffer to play back voice smoothly. Jitter can be caused by thermal noise, bandwidth limitations, improper impedance termination, asymmetries in clock cycles, and EMI problems.

End-to-End Delay
Figuring out the end-to-end delay is not difficult if the end-to-end signal paths/data paths, the codec, and the packets’ payload size are known factors. Adding the delays from the endpoints to the codecs at each end, the encoder delay (which is 5 ms for the G.711 and G.726 codecs and 10 ms for the G.729 codec), the packet delay, and the fixed portion of the network delay yields the connection’s end-to-end delay. Table 7-1 describes common codecs.

Voice Quality Issues

457

Table 7-1 Codecs Are Critical Variables in Configuring VoIP Solutions

Compression Codec Bit Rate (kbps) Framing Size Delay (ms)

G.711 PCM G.729 CS-ACELP G.729a CS-ACELP

64 8 8

0.125 10 10

5 15 15

Echo
Echo is voice feedback in the telephone receiver when talking. When timed properly, echo is reassuring to the speaker. But if the echo exceeds approximately 25 ms, it can be distracting and cause breaks in the conversation. In a traditional telephony network, echo is normally caused by a mismatch in impedance from the four-wire network switch conversion to the two-wire local loop and is controlled by echo cancellers. In voice-packet-based networks, echo cancellers are built into the low bitrate codecs and are operated on each DSP. Echo cancellers are, by design, limited by the total amount of time they will wait for the reflected speech to be received. This amount of time is called an echo trail. The echo trail is normally 32 ms. VoIP has configurable echo trails of 8, 16, 24, and 32 ms. Voice, as a class of IP network traffic, has strict requirements concerning packet loss, delay, and delay variation (also known as jitter). To meet these requirements for voice traffic, the Cisco IP Telephony solution includes QoS features such as classification, queuing, traffic shaping, scheduling, Compressed Real-Time Transport Protocol (CRTP), and Transmission Control Protocol (TCP) header compression. The QoS components of the Cisco AVVID IP Telephony solution are provided through the rich IP traffic management, queuing, and shaping capabilities of the Cisco AVVID network infrastructure.

Implementing QoS for Voice
Voice, video, and mission-critical data applications are important underlying productivity tools that make a business successful. Ensuring that these applications are effectively delivered requires skillful traffic management, particularly within the context of an integrated networking solution. QoS is a key Cisco AVVID network infrastructure enabling the capability for such an environment. Figure 7-57 shows various WAN environments for which VoIP QoS needs to be implemented.

458

Chapter 7: Cisco AVVID

Figure 7-57 QoS Configuration Is an Integral Piece of the Integration of Voice, Video, and Data Regional/HQ Office Cisco 7200 ATM/Frame Relay

Cisco 2600

Branch Office’s Cisco 3600

Pt to Pt Cisco 3600

Cisco 3600

QoS
In a converged environment, all types of traffic travel over a single transport infrastructure. Yet not all traffic types are the same. Data is bursty, loss-intolerant, and latency-insensitive. Voice, on the other hand, is nonbursty and has some tolerance to loss but is latency-sensitive. The challenge is in providing the required level of service for each of these traffic types. Running both voice and data on a common network requires the proper QoS tools to ensure that the delay and loss parameters of voice traffic are satisfied. These tools are available as features in IP phones, switches, and routers.

Application Considerations for QoS
The specific QoS requirements for given applications are generally determined by the three parameters of latency, jitter, and loss. Depending on the type of application to be implemented over a Cisco AVVID network infrastructure, the importance and effects of these considerations can differ. One-way latency for voice or videoconferencing should be no more than 150 to 200 ms, and streaming video can tolerate up to 4- to 5-second latency. Similarly, jitter is not an issue for streaming video, but it should be limited to 30 ms for voice and videoconferencing applications. Bandwidth effects also differ. For example, to support videoconferencing, the minimum bandwidth guarantee is the size of the videoconferencing session plus 20 percent. (For

Voice Quality Issues

459

example, a 384-kbps videoconferencing session requires 460 kbps of guaranteed priority bandwidth.) Voice requires 17 to 106 kbps of guaranteed priority bandwidth per call (depending on the sampling rate, codec, and Layer 2 overhead), and 150 bps (plus Layer 2 overhead) per phone of guaranteed bandwidth is required for voice control traffic. Although planning requirements certainly vary depending on the application, Cisco AVVID network infrastructure capabilities have the flexibility to concurrently support QoS requirements of voice, streaming video, video content distribution, videoconferencing, and missioncritical data traffic all carried over a common IP-based networking environment.

Traffic Classification Types
The goal of protecting voice traffic from being run over by data traffic is accomplished by classifying voice traffic as high-priority and then allowing it to travel in the network before low-priority traffic, as shown in Figure 7-58. Classification can be done at Layer 2 or Layer 3.
Figure 7-58 Prioritizing Voice Traffic Is Standard Operating Procedure with QoS Configuration Router VoIP (High) Data (Low) Data (Low) Data (Low) 3 3 1 1 V V 1 1 WAN Circuit 3 3
WFQ

2 2

PQ

4

3

2

4

4 4

4 4

Classification is the first step toward achieving QoS. Ideally, this step should be done as close to the source as possible, usually at the network’s access layer, and often at the edge of the network.

Trust Boundaries
The concept of trust is an important and integral one to implementing QoS. As soon as the end devices have a set class of service (CoS) or type of service (ToS), the switch has the option of trusting them or not. If the switch does not trust the settings, it must perform reclassification for appropriate QoS (see Figure 7-59); if the switch trusts the settings, it does not need to do any reclassification (see Figure 7-60).

460

Chapter 7: Cisco AVVID

Figure 7-59 The Switch Might Not Trust the Host Station’s CoS Configuration

PC Is Untrusted Phone ASIC Rewrites CoS = 0 CoS = 5 CoS = 5

CoS = 0

CoS = 7

Figure 7-60 A Switch May Be Configured to Trust a Host’s CoS Configuration

Trusted CoS = 5 CoS = 5

CoS = 7

CoS = 7

The notion of trusting or not trusting forms the basis of the trust boundary. Ideally, classification should be done as close to the source as possible. If the end device can perform this function, the trust boundary for the network is at the access layer in the wiring closet. If the device cannot perform this function, or the wiring closet switch does not trust the classification done by the end device, the trust boundary might shift. How this shift happens depends on the switch’s capabilities in the wiring closet. If the switch can reclassify the packets, the trust boundary remains in the wiring closet. If the switch cannot perform this function, the task falls to other devices in the network going toward the backbone. In this case, the rule of thumb is to perform reclassification at the distribution layer. This means that the trust boundary has shifted to the distribution layer. It is more than likely that a high-end switch is in the distribution layer with features to support this function. If possible, try to avoid performing this function in the network core.

Voice Quality Issues

461

Traffic Classification
Equally important as queuing, however, is a QoS mechanism called classification. It is important to differentiate at all points in the network between voice and data traffic so that queuing techniques can be applied in places such as the WAN edge. Therefore classification “marks” voice and data frames differently so that they can be treated differently by the other switches and routers that make up the intelligent IP network. Two standards-based methods are used:

At Layer 2, 802.1p defines classes of service pertaining to that Ethernet segment, as shown in Figure 7-61. At Layer 3, the IP layer, the IP ToS field can carry different values end to end through the network.

Figure 7-61 A Switch Can Reclassify CoS Values of Transit Voice and Data Traffic

CoS = 5 CoS = 5 CoS = 7 CoS = 2

Only "Reclassify" Data streams to 0-3...not 4-7, 2900, 3500 and 4000 will place "4" into voice queue.

Not Trusted: phone ASIC will rewrite CoS based on switch configuration e.g., extended COS = 2.

The capability to change the Layer 2 and Layer 3 classification parameters to values desired by the network designer is a function inherent in the Cisco AVVID architecture. It is available in the IP Phone integrated switch and some Catalyst switching platforms. The ability of the network manager to manipulate these values at different points in the network defines a parameter called the trust boundary. For example, if it is trusted that the end stations and phones will set their QoS values correctly so that end-to-end QoS can be maintained, the trust boundary includes the end stations. However, if it cannot be guaranteed that all end stations behave properly and set their own priority values correctly, the capability to properly manipulate these parameters is available in the Catalyst switch infrastructure.

462

Chapter 7: Cisco AVVID

Traffic Classification at Layer 2
Cisco IP Phones can mark voice packets as high-priority using CoS as well as ToS. By default, the phone sends 802.1Q tagged packets with the CoS and ToS set to a value of 5. Because most PCs do not have an 802.1Q-capable network interface card (NIC), they send the packets untagged without an 802.1Q field (see Figure 7-62). Unless the applications running on the PC send packets with a specific CoS value, this field is 0. A special case is where the TCP/IP stack in the PC has been modified to send all packets with a ToS value other than 0. Typically this does not happen, and the ToS value is 0.
Figure 7-62 IEEE 802.1Q Frames Include 3 Bits for IEEE 802.1p Tagging 6 802.1p (3 bits) 6 2 2 CoS CFI 2 VLAN ID 42~1500 Type/Length Destination Address Source Address Type = 8100 Tag Control Info

MAC DATA

IEEE 802.1Q Tag

PAD 4 FCS

Even if the PC is sending tagged frames with a specific CoS value, Cisco IP Phones can zero out this value before sending the frames to the switch. This is the default behavior. Frames coming from the phone have a CoS of 5, and frames coming from the PC have a CoS of 0. When the switch receives these frames, it can take into account these values for further processing based on its capabilities. The switch uses its queues (available on a per-port basis) to buffer incoming frames before sending them to the switching engine. (It is important to remember that input queuing comes into play only when there is congestion.) The switch uses the CoS value(s) to put the frames

Voice Quality Issues

463

in appropriate queues. The switch can also employ mechanisms such as Weighted Random Early Detection (WRED) to make intelligent drops within a queue (also known as congestion avoidance) and Weighted Round-Robin (WRR) to provide more bandwidth to some queues than to others (also known as congestion management). There might be times, however, when it is desirable to trust the PC CoS (if sending tagged packets), such as when there is absolute certainty that the PC CoS has the desired value. Or there might be times when it is desirable to assign a value other than 0. This can be achieved on Catalyst switches as well.

Traffic Classification at Layer 3
Using the 802.1p bits within the 802.1Q tag provides the desired QoS results at Layer 2. When traffic has to cross a Layer 3 boundary, however, it becomes imperative to implement these mechanisms using Layer 3 parameters, such as the 3 IP precedence bits (commonly called ToS) or the new Differentiated Services Code Point (DSCP) parameter, which uses the 6 most significant bits within the IP header’s ToS byte (see Figure 7-63 and Table 7-2). Traffic crosses a Layer 3 boundary when packets are routed between subnets by Layer 3 switches or routers. Traffic also crosses a Layer 3 boundary when packets need to go out of the campus network onto the WAN through edge routers. When this happens, Layer 2 classification does not help. Layer 3 classification is needed to achieve the desired level of QoS. All the QoS techniques employed by the routers (including the very important WAN QoS) rely on Layer 3 classification.
Figure 7-63 8 Bits for Differentiated Code Point Classification Are Included in the IPv4 ToS Byte Bits: 0 1 2 3 4 5 6 7 Bits: 0 1 2 3 4 5 6 7

DS-Field

DSCP

CU

IPv4 ToS Precedence Type of Service MBZ Byte

Class Selector Codepoints

Currently Unused

DTR – Bits RFC 1122 RFC 1349

Must Be Zero

Differentiated Services Codepoint (DSCP) RFC 2474

Table 7-2 lists IP Precedence and ToS values.

464

Chapter 7: Cisco AVVID

Table 7-2 IP Precedence and ToS Values

Bits (0 to 2): IP Precedence Defined

Bits (3 to 6): Type of Service Defined

111 (Network Control) 110 (Internetwork Control) 101 (CRITIC/ECP) 100 (Flash) 101 (Immediate) 001 (Priority) 000 (Routine)

0000 (all normal) 1000 (minimize delay) 0100 (maximize throughput) 0010 (maximize reliability) 0001 (minimize monetary cost)

Layer 3 classification can be achieved by using the appropriate platforms in the campus. Beginning with the IP phones, packets are already presented to the switch with CoS = ToS = 5. This Layer 3 classification is preserved even if the packets travel all the way through to the WAN edge router where the Layer 2 header is removed. So, if the trust boundary is at the source (IP phone), voice traffic has the ToS bits set to 5 and is presented to the network devices for appropriate treatment. WAN routers can use this classification to employ any of the queuing techniques. If the trust boundary is not at the source and packets need to be reclassified, the device performing this function should be able to do it at Layer 3 before it can cross a Layer 3 boundary.

Summary Recommendations for QoS Implementation

Create a trust boundary at the network edge in the wiring closet. Make ports trusted on the wiring closet switch where IP phones are attached. Reclassify ToS at the edge if devices cannot be trusted. Shrink the trust boundary to the distribution layer and reclassify ToS there if reclassification is not possible at the edge. Use a priority queue if possible for delay-sensitive traffic. Use QoS ACLs for more granular classification of packets using Layer 4 information. Use policing if necessary to limit traffic for individual flows as well as aggregate flows. Have traffic going to the WAN edge classified at Layer 3 so that the router can use it for advanced WAN queuing mechanisms. Use a WAN edge router as the classifier for very small remote site networks where a Layer 3-capable switch is unavailable.

■ ■

■ ■ ■ ■

Network Design Issues for Voice

465

Network Design Issues for Voice
Implementing an IP Telephony solution must be preceded by a major design effort. Issues to consider involve the method of powering IP phones, how voice and data traffic are categorized into VLANs, redundancy, and QoS. The following sections cover each of these considerations in greater detail.

IP Phone Physical Connectivity
Cisco IP Phones, which connect to a switch port, also provide connectivity for an attached computer. The phone electronics, which include a three-port switch, preserve the switched connectivity model for the computer and ensure quality of service for both the IP Phone and the downstream computer. Several options exist for physically connecting the IP Phone to the network. The first option is to connect the IP Phone to the switch and to connect the data device (computer or workstation) to the switched Ethernet port on the IP Phone. This is the most common connectivity option, and it helps with rapid deployment with minimal modifications to the existing environment. This arrangement has the advantage of using a single port on the switch to provide connectivity to both devices. Also, no changes to the cabling plant are required if the IP Phone is line-powered. In this case, the switch must be able to provide ample power to all the phones and must receive sufficient power from the AC outlet. The second option is to connect the IP Phone and the computer using different switch ports. Although this option doubles the switch port count for every user, it provides a level of redundancy for the user. If the IP Phone goes down, the PC is unaffected, and vice versa. Also, the IP Phone and PC ports can be connected on different modules, thus achieving another layer of redundancy by providing protection for one of the devices if either module goes down. The third option differs from the others in that the phone is not a hardware device, but a Java Telephony Application Programming Interface (JTAPI) application running on a computer. This option, the Cisco IP SoftPhone, could be particularly useful in environments where the need for a separate handset is minimal.

Power/Protection Options
Reliable power is vital to IP Telephony. An uninterruptible power supply (UPS) can be used to ensure a reliable and highly available infrastructure by protecting it from power failures. Each UPS has some amount of battery that keeps the equipment running for a certain period of time. The UPS can be configured with the appropriate amount of battery for desired results. Most Cisco AVVID products do not ordinarily come with a backup power supply.

466

Chapter 7: Cisco AVVID

Here are some common strategies for using a UPS:

Back up the wiring closet switches and downstream data center using UPS. Although this strategy ensures that power is maintained to the phones, wall-powered devices such as PCs can still go down. Back up the whole building using UPS. This protects all devices and equipment from power failures. Protecting PCs in this fashion is useful because of the new breed of highly available data applications. Provide a separate generator for power (besides the feed from the utility company) and use it as backup. In this case, a UPS should be added because it usually takes a few minutes for the generator to ramp up. The advantage of this strategy is that less battery time is needed for each UPS.

In addition, UPS can be configured with options such as Simple Network Management Protocol (SNMP), remote monitoring, alarm reporting, and so on.

Power to IP Phones
Cisco IP Phones support a variety of power options:

Inline power—The advantage of inline power is that it does not require a local power outlet. Power is provided by the Ethernet switch and is passed to the IP Phone through the four-pair unshielded twisted-pair (UTP) cabling. This also permits centralization of power management facilities. External patch panel power—If the switch does not have a power-enabled line card, or if one is not available for the switch being used, a Cisco power patch panel can be used. The power patch panel can be inserted in the wiring closet between the Ethernet switch and the Cisco IP Phone. The patch panel has a 250 W power supply and draws its power from a 110 volts alternating current (VAC) source. It can accommodate 48 ports and can supply power to each of the 48 ports at 6.3 W (see Table 7-3). A UPS is recommended for backup in the event of a power failure.

Table 7-3 Various Power Supplies Are Available to Handle Different Numbers of IP Phones

Power Supply (Watts)

IP Phones Supported at 6.3 W Per Phone

1050 1300 2500

60 IP Phones 96 IP Phones (two modules) 240 IP Phones (five modules)

Network Design Issues for Voice

467

The actual conductors used are pins 4 and 5 (pair 1) and pins 7 and 8 (pair 4) for power and ground return. This means that all four pairs in the Category 5 cable need to be terminated at the user’s desk and in the wiring closet.

Wall power—A third option is to power the Cisco IP Phone from a local transformer module plugged into a nearby outlet. The obvious drawback to individually powering the IP Phones is the absence of centralized power protection and backup.

A combination of these power options can provide redundant power to the Cisco IP Phone.

Infrastructure Considerations
Building an end-to-end IP Telephony system requires an IP infrastructure based on Layer 2 and Layer 3 switches and routers, with switched connections to the desktop. Network designers must ensure that the endpoints are connected using switched 10/100 Ethernet ports. The use of hubs for shared connectivity to the switches is not recommended, because they can interfere with the correct operation of the IP Telephony system.

High Availability
The distributed architecture of a Cisco IP Telephony solution provides the inherent availability that is a prerequisite for voice networking. Cisco IP Telephony solutions are also inherently scalable, allowing seamless provisioning of additional capacity for infrastructure, services, and applications. In the world of converged networking, in contrast to the world of the PBX, availability is designed into a distributed system rather than into a box. Redundancy is available in the individual hardware components for services such as power and supervisor modules. Network redundancy, however, is achieved with a combination of hardware, software, and intelligent network design practices. Network redundancy is achieved at many levels. Physical connections exist from the edge devices where IP phones and computers are attached to two spatially diverse aggregation devices. In the event that an aggregation device fails, or connectivity is lost for any reason (such as a broken fiber or a power outage), failover of traffic to the other device is possible. By provisioning clusters of Cisco CallManager servers to provide resilient call control, other servers can pick up the load if any device within the cluster fails. Advanced Layer 3 protocols such as HSRP or fast converging routing protocols, such as OSPF and EIGRP, can be used to provide optimum network layer convergence around failures.

468

Chapter 7: Cisco AVVID

Advanced tools are also available for the MAC layer (Layer 2). Tunable spanning-tree parameters and the new 802.1s standards allow fast convergence. Value-added features, such as UplinkFast and BackboneFast, allow intelligently designed networks to further optimize network convergence. High availability of the underlying network plays a major role in ensuring a successful deployment. This translates into redundancy, resiliency, and fast convergence.

IP Addressing and Management
Each IP phone requires an IP address, along with associated information such as subnet mask, default gateway, and so on. Essentially, this means that an organization’s need for IP addresses doubles as IP phones are assigned to all current PC users. This information can be configured statically on the IP phone or can be provided by DHCP. Figures 7-64 and 7-65 illustrate the private and public IP addressing options for IP phones.
Figure 7-64 Using Private Addressing for IP Phones IP Phone + PC on Same Switch Ports IP Phone + PC on Same Switch Ports
171.68.249.100

171.68.249.100

10.1.1.1

171.68.249.101 10.1.1.1

IP Phone Uses “10.0.0.0” Network

IP Phone Uses “10.0.0.0” Network

A straightforward solution to provide IP addresses to the IP phones might be to use the same subnet as data devices. However, many sites have IP subnets with more than 50 percent of subnet addresses already allocated. This would require the addition of address ranges or reallocation of the existing ranges.

Network Design Issues for Voice

469

Figure 7-65 Using Public IP Addressing with an IP Phone or Using the Same IP Address with a Cisco IP SoftPhone

IP Phone + PC on Same Switch Ports

IP Phone + PC on IP Phone + PC Same Switch Ports Share the Same Device 171.68.249.101 (Cisco IP Softphone)

171.68.249.100 171.68.249.100 171.68.249.101

Real IP Addresses

171.68.249.100

Real IP Addresses

IP phones can be placed on a separate IP subnet. The new subnet could be in a registered address space or a private address space, such as network 10.0.0.0. Using this scheme, the PC would be on a subnet reserved for data devices and the phone would be on a subnet reserved for voice. Configuration on the IP phone can be minimized by having the phone learn as much information dynamically as possible. Therefore, when the IP phone powers up, it should get its voice subnet automatically and then send a DHCP request on that subnet for an IP address. The automated mechanism by which the IP phone gets its voice subnet is provided through enhancements to the Cisco Discovery Protocol (CDP). Cisco IP Phones use CDP to interact with the switch so that it knows that an IP phone is connected to it. To provide this level of support, three new fields have been added to CDP:
■ ■ ■

A Voice VLAN ID (VVID) field for communicating the voice subnet to the IP phone A Trigger field for soliciting a response from the connected device A Power Requirement field for getting the exact power requirement from the phone

A VLAN (Layer 2) maps to a subnet (Layer 3) as a broadcast domain such that a VLAN is equivalent to a subnet. The VVID was introduced with Release 5.5 of the Catalyst software. This is the voice VLAN that the switch assigns to the IP phone inside the CDP message. It allows the IP phone to get its VLAN ID automatically when it is plugged into the switch if a VLAN is configured for the phone. If no VLAN is configured for the IP phone, the phone resides in the switch’s native VLAN (data subnet).

470

Chapter 7: Cisco AVVID

The Trigger field is used to force a response from the connected device. Under normal circumstances, a device sends CDP update messages at a configured interval (the default is 1 minute). If an IP phone is connected between CDP messages, it cannot receive its VVID. In this case, the IP phone issues a trigger in the CDP message it sends to the switch, forcing the switch to respond with a VVID. When the switch provides inline power to an IP phone, it has no way of knowing how much power the phone needs (this varies by model). Initially, the switch allocates 10 W and then adjusts the delivered power according to the requirements sent by the IP phone in the CDP message.

Implementing IP Telephony with Auxiliary VLANs
The new voice VLAN is called an auxiliary VLAN in the Catalyst software command-line interface (CLI). In the traditional switched world, data devices reside in a data VLAN. The new auxiliary VLAN is used to represent other types of devices collectively. Today, those devices are IP phones (hence, the notion of a voice VLAN), but in the future, other types of nondata devices will also be part of the auxiliary VLAN. Just as data devices come up and reside in the native VLAN (the default VLAN), IP phones come up and reside in the auxiliary VLAN if one has been configured on the switch. Figure 7-66 illustrates data and auxiliary VLANs used for a workstation and IP phone, respectively.
Figure 7-66 Auxiliary VLANs Can Be Used for Cisco IP Phones and Other Nondata Devices Phone VLAN = 200 PC VLAN = 3

When the IP phone powers up, it communicates with the switch using CDP. The switch then provides the phone with its configured VLAN ID (voice subnet), also known as the voice VLAN ID or VVID. Meanwhile, data devices continue to reside in the switch’s native VLAN (default VLAN). A data device VLAN (data subnet) is called a port VLAN ID (PVID).

Voice VLAN Configuration
The voice VLAN is disabled and the CoS value is not trusted by default on Catalyst IOS switches, such as the Catalyst 2950 and Catalyst 3550. Before you enable the voice VLAN, you should enable QoS on the switch by entering the mls qos global configuration command. You also must configure the port trust state to trust by entering the mls qos trust interface configuration command.

Network Design Issues for Voice

471

You configure the voice VLAN using the following interface configuration mode command:
switchport voice vlan {vlan-id | dot1p | none | untagged}

The argument and keyword options for this command are as follows:

vlan-id—The VLAN used for voice traffic. Valid IDs are from 1 to 4094. Do not enter leading 0s. dot1p—The phone uses priority tagging and VLAN 0 (the native VLAN). By default, the Cisco IP Phone forwards the voice traffic with an 802.1p priority of 5. none—The phone is not instructed through the CLI about the voice VLAN. The phone uses the configuration from the phone keypad. untagged—The phone does not tag frames and uses VLAN 4095.

To instruct the Cisco IP Phone to forward all voice traffic through a specified VLAN, use the interface command switchport voice vlan vlan-id. By default, the Cisco IP Phone forwards the voice traffic with an 802.1Q priority of 5. Valid VLAN IDs are from 1 to 4094. An alternative to specifying a particular voice VLAN on the switch is to instruct the switch port to use 802.1p priority tagging for voice traffic and to use the default native VLAN (VLAN 0) to carry all traffic. By default, if enabled, the Cisco IP Phone forwards the voice traffic with an 802.1p priority of 5. Use the interface command switchport voice vlan dot1p to specify 802.1p priority tagging of voice traffic. To display the voice VLAN for an interface, use the show interfaces interface-id switchport privileged EXEC command.

Connecting to the Network with Auxiliary VLANs
The following steps outline the process that takes place when an IP phone is powered up and plugged into the network:
1. The IP phone begins a CDP exchange with the switch. The phone issues a trigger CDP

to force a response from the switch. That response contains the phone’s VVID.
2. If the IP phone is configured to use DHCP (the default), it issues a DHCP request on

the voice subnet it got from the switch. This is the recommended mode of operation. Static addressing can be used, but it prevents mobility.
3. The IP phone gets a response from the DHCP server in the network. Along with the

DHCP response, which provides the IP address to the telephone, it is also possible to supply the address of the TFTP server from which the phone gets its configuration. This is done by configuring option 150 on the DHCP server and specifying the address of

472

Chapter 7: Cisco AVVID

the TFTP server; Cisco DHCP server supports this feature. Again, it is possible to specify the TFTP server address manually, but this would limit adds, moves, and changes, as well as remove some other benefits.
4. The IP phone contacts the TFTP server and receives a list of addresses of Cisco Call-

Manager servers. Up to three Cisco CallManager servers can be specified in the list. This provides redundancy in case the first Cisco CallManager server in the list is unavailable.
5. The IP phone contacts the Cisco CallManager server and registers itself, receiving in

return a configuration file and runtime code necessary for the phone to operate. For each configuration, the IP phone receives a directory number (DN) from the Cisco CallManager server to be used for calling that particular IP phone.
6. The IP phone is ready to make and receive calls.

Summary
Corporations are looking for strategies to integrate disparate networking technologies over a single common network infrastructure. This trend started many years ago. Cisco AVVID solutions are heavy in design and include the following:

IP Telephony, IP Video Conferencing, Wireless, Enterprise Mobility, Security, Virtual Private Networks Content networking IP Contact Centers Storage networking

■ ■ ■

Familiar applications, such as voice messaging, are also easily integrated into the AVVID environment. A new breed of IP-enabled unified-messaging solutions allows users to access both voice mail and e-mail from a common server. IP multicasting is the transmission of an IP data frame to a host group, which is identified by a single IP address. Because the host group is identified by a single IP address rule, the IP multicast contains a specific combination of the destination MAC address and a destination IP address.

Summary

473

Because of their unique capability to send a single data stream to multiple clients, IP multicast technologies have become the transmission methods of choice for most multimedia applications. Multicast routing protocols fall into two categories: dense mode (DM) and sparse mode (SM). DM protocols assume that almost all routers in the network will need to distribute multicast traffic for each multicast group. SM protocols assume that relatively few routers in the network will be involved in each multicast. The hosts belonging to the group are widely dispersed, as might be the case for most multicasts in the Internet. SM protocols are recommended for use in today’s networks. IGMP is used between hosts on a LAN and the router(s) on that LAN to track of which multicast groups the hosts are members. PIM is used between routers so that they can track which multicast packets to forward to each other and to their directly connected LANs. Cisco CallManager is the software-based call-processing component of the Cisco IP Telephony solution and essentially is the heart of the IP Telephony solution. The key benefit of CallManager and the supporting applications is that special-purpose voice-processing hardware is not required. Supplementary and enhanced services are seamlessly added without incurring major expense. IP Telephony designs include the following:
■ ■ ■ ■

Single-site model Multiple sites with independent call processing Multisite IP WAN with distributed call processing Multisite IP WAN with centralized call processing

A trust boundary should be maintained in the wiring closet. If necessary, move it to the distribution layer on a case-by-case basis, but avoid moving it to the network core. This advice conforms with the general guidelines to keep the trust boundary as close to the source as possible. IP phone connectivity, backup power, and IP addressing are considerations of IP Telephony design. You can purchase line cards that can apply power to the IP phone. If you deploy IP phones using the existing switches, you should install line cards that can apply power. Alternatively, you could use the external Cisco power patch panel to power the phones if powered line cards are not available for the switch. As a final option, you could use wall power.

474

Chapter 7: Cisco AVVID

The Catalyst software can be easily configured to support enhanced features, such as auxiliary/voice VLANs. Figure 7-67 summarizes Cisco AVVID technologies.
Figure 7-67 Cisco AVVID Provides a Complete, Integrated Solution for Voice, Video, and Data
Internet Business Solutions Real-Time Communications Supply Chain Messaging Customer Care Collaboration Internet Commerce Workforce Optimization Conferencing Video Demand Content Delivery

E-Learning

Personal Productivity Contact Routing

Telephone Processing

Unified Control Plane

Policy

Provisioning

Identity

Intelligent Network Services

Quality of Service

Security

Network Availability

Network Platforms

Clients

Key Terms

475

Key Terms
Auto-RP A PIM feature that automates the distribution of group-to-RP mappings. candidate RP A router that announces its candidacy to be an RP for a PIM-SM network via the Cisco-Announce group, 224.0.1.39. Cisco Group Management Protocol (CGMP) A Cisco-developed protocol that runs between Cisco routers and Catalyst switches to leverage IGMP information on Cisco routers to make Layer 2 forwarding decisions on Catalyst switches. With CGMP, IP multicast traffic is delivered only to Catalyst switch ports that are attached to interested receivers. classification Using a traffic descriptor to categorize a packet within a specific group to define that packet and make it accessible for QoS handling on the network. codec Coder-decoder. An integrated circuit device that typically uses pulse code modulation to transform analog signals into a digital bit stream and digital signals back into analog signals. In voice over IP, voice over Frame Relay, and voice over ATM, a codec refers to a DSP software algorithm used to compress/decompress speech or audio signals. Conjugate Structure Algebraic Code Excited Linear Prediction (CS-ACELP) A CELP voice compression algorithm providing 8 kbps, or 8:1 compression. Standardized in ITU-T Recommendation G.729. core In CBT, the router that serves as the root of the shared tree. Similar to PIM-SM’s RP. Core-Based Trees (CBT) A multicast routing protocol introduced in September 1997 in RFC 2201 CBT builds a shared tree like PIM-SM. CBT uses information in the IP unicast routing table to calculate the next-hop router in the direction of the core. Distance Vector Multicast Routing Protocol (DVMRP) The first multicast routing protocol, publicized in RFC 1075 in 1998. Unlike PIM, DVMRP builds a separate multicast routing table from the unicast routing table. distribution tree A unique forwarding path for a multicast group between the source and each subnet containing members of the multicast group. E.164 An ITU-T recommendation for international telecommunication numbering, especially in ISDN, BISDN, and SMDS. An evolution of standard telephone numbers. Also, the name of the field in an ATM address that contains numbers in E.164 format. G.711 Describes the 64-kbps PCM (Pulse Code Modulation) voice-coding technique. In G.711, encoded voice is already in the correct format for digital voice delivery in the PSTN or through PBXs. Described in the ITU-T standard in its G-series recommendations.

476

Chapter 7: Cisco AVVID

G.726 Describes Adaptive Differential Pulse Code Modulation (ADPCM) coding at 40, 32, 24, and 16 kbps. ADPCM-encoded voice can be interchanged between packet voice, PSTN, and PBX networks if the PBX networks are configured to support ADPCM. Described in the ITU-T standard in its G-series recommendations. G.729 Describes CELP compression in which voice is coded into 8-kbps streams. This standard has two variations (G.729 and G.729 Annex A) that differ mainly in computational complexity; both provide speech quality similar to 32-kbps ADPCM. Described in the ITU-T standard in its G-series recommendations. globally scoped addresses A multicast address space in the range from 224.0.1.0 to 238.255.255.255. These addresses can be used to multicast data between organizations and across the Internet. GLOP address RFC 2770 proposes that the 233.0.0.0/8 address range be reserved for statically defined addresses by organizations that already have an AS number reserved. The second and third octets are populated with the decimal equivalents of the first and second bytes of the hexadecimal representation of the AS number. H.320 A suite of ITU-T standard specifications for videoconferencing over circuitswitched media such as ISDN, fractional T1, and switched-56 lines. H.323 An extension of ITU-T standard H.320 that enables videoconferencing over LANs and other packet-switched networks, as well as video over the Internet. H.323 is a set of communications protocols used by programs such as Microsoft NetMeeting and equipment such as Cisco routers to transmit and receive audio and video information over the Internet. IGMP leave group message A message used by IGMPv2 to allow a host to announce its intention to leave a multicast group. The leave message is sent to the all-routers multicast address, 224.0.0.2. IGMP membership query A message used by IGMP and sent to the all-hosts multicast address, 224.0.0.1, to verify that at least one host on the subnet is still interested in receiving traffic directed to that group. Also referred to as a general query. IGMP membership report A message used by IGMP to indicate a host’s interest in receiving traffic for a particular multicast group. IGMP snooping A Layer 2 multicast constraining mechanism (like CGMP) used by switches, allowing only multicast traffic to be forwarded to those interfaces associated with IP multicast devices. The switch snoops on the IGMP traffic between the host and the router and keeps track of multicast groups and member ports. IGMP Version 1 A version of IGMP that relies solely on membership query messages and membership report messages.

Key Terms

477

IGMP Version 2 A version of IGMP that adds the ability of a host to proactively leave a multicast group and the ability of a router to send a group-specific query (as opposed to a general query). IGMP Version 3 A version of IGMP that adds support for source filtering. Internet Group Management Protocol (IGMP) A protocol used to allow hosts to communicate to local multicast routers their desire to receive multicast traffic. limited scope address Also called an administratively scoped address. It falls in the range from 239.0.0.0 to 239.255.255.255 and is limited for use by a local group or organization. link local address An IANA reserved multicast address space in the range from 224.0.0.0 to 224.0.0.255 to be used by network protocols on a local network segment. multicast backbone (MBONE) A multicast backbone across the public Internet, built with tunnels between DVMRP-capable Sun workstations running the mroute daemon (process). multicast group An arbitrary group of hosts that expresses an interest in receiving a particular data stream via multicast. This group has no physical or geographic boundaries. Hosts that are interested in receiving data flowing to a particular group must join the group using IGMP. Multicast OSPF (MOSPF) A multicast routing protocol specified in RFC 1584. MOSPF is a set of extensions to OSPF enabling multicast forwarding decisions. Network Time Protocol (NTP) Used to synchronize clocks on network devices. The multicast address 224.0.1.1 is reserved for NTP operation. PIM sparse-dense mode An alternative to pure dense mode or pure sparse mode for a router interface. Sparse-dense mode allows individual groups to be run in either sparse or dense mode, depending on whether RP information is available for that group. If the router learns RP information for a particular group, it is treated as sparse mode; otherwise, that group is treated as dense mode. Protocol-Independent Multicast (PIM) An IP multicast routing protocol that derives its information using RPF checks based on the unicast routing table. PIM has several variations, including dense mode, sparse mode, sparse-dense mode, source-specific mode, and bidirectional mode. Protocol-Independent Multicast Dense Mode (PIM-DM) A PIM variation that builds a source tree for each multicast source and uses flood-and-prune behavior.

478

Chapter 7: Cisco AVVID

Protocol-Independent Multicast Sparse Mode (PIM-SM) A PIM variation that builds shared trees. The root of the tree is called the rendezvous point, similar to CBT’s core. Reverse Path Forwarding (RPF) An algorithm used to forward multicast datagrams. It functions as follows:

If a router receives a datagram on an interface it uses to send unicast packets to the source, the packet has arrived on the RPF interface. If the packet arrives on the RPF interface, a router forwards the packet out the interfaces present in the outgoing interface list of a multicast routing table entry. If the packet does not arrive on the RPF interface, the packet is silently discarded to prevent loops.

Router-Port Group Management Protocol (RGMP) Lets a router communicate to a switch the IP multicast group for which the router wants to receive or forward traffic. RGMP is designed for switched Ethernet backbone networks running PIM. RP mapping agent A router that receives the RP-announcement messages from the candidate RPs and arbitrates conflicts. The RP mapping agent sends the group-to-RP mappings to all multicast-enabled routers via the Cisco-Discovery group, 224.0.1.40. shared tree A multicast distribution tree using a root placed at some chosen point in the network. PIM-SM and CBT both use shared trees. When using a shared tree, sources must send their traffic to the root for the traffic to reach the receivers. source filtering A capability added to IGMPv3 that lets a multicast host signal to a router the groups for which it wants to receive multicast traffic and the sources from which it wants to receive the traffic. source tree A multicast distribution tree with root at the source of the multicast traffic and whose branches form a spanning tree through the network to the receivers. Also called the shortest-path tree (SPT). For every source of a multicast group, there is a corresponding SPT. trust boundary When classifying traffic types in an enterprise network, a trust boundary must be established. The boundary is established by the access device, which either classifies traffic it allows into the network itself or trusts classification that has already been applied by an end station, such as an IP phone.

Check Your Understanding

479

Check Your Understanding
Use the following review questions to test your understanding of the concepts covered in this chapter. Answers are listed in Appendix A, “Check Your Understanding Answer Key.”
1. What type of VLAN is commonly used with Catalyst switches to support IP phones? A. User VLAN B. Native VLAN C. Auxiliary VLAN D. Management VLAN 2. Which of the following is an indispensable software-based call-processing component

required for a Cisco IP Telephony solution?
A. LDAP B. Gateserver C. IOS Gatekeeper D. CallManager 3. Different codecs have different encoding delays. These delays are added to the end-

point-to-codec delays to determine which of the following?
A. Propagation delay B. Latency C. Initialization delay D. End-to-end delay 4. A priority queue is established for what type of traffic when implementing QoS for an

IP Telephony solution?
A. TCP B. UDP C. Data D. Voice 5. Layer 2 traffic classification uses which of the following? A. Type of service B. Class of service C. Differentiated Services Code Point D. Voice queue

480

Chapter 7: Cisco AVVID

6. Layer 3 traffic classification uses which of the following? A. Type of service B. Class of service C. Differentiated Services Code Point D. Voice queue 7. What is used to ensure that multicast traffic is correctly forwarded down the distribu-

tion tree?
A. LCP B. CRTP C. RTP D. RPF 8. What are the two types of multicast distribution trees? A. CBT trees B. Shared trees C. Shortest-path trees D. Rendezvous trees 9. What Layer 2 multicast address corresponds to the Layer 3 multicast address

224.10.8.5?
A. FF.FF.FF.FF.FF.FF B. 01.00.22.44.10.05 C. 01.00.5E.0A.08.05 D. 01.00.5E.10.08.05 10. What multicast protocol is used to optimize multicast traffic between hosts and routers

participating in multicast traffic flows?
A. RGMP B. IGMP C. CGMP D. PIM-SM

Objectives
After completing this chapter, you will be able to perform tasks related to the following:
■ ■ ■

Understand loss, latency, and jitter Understand the quality of service (QoS) models Understand class of service (CoS), type of service (ToS), IP Precedence, and Differentiated Services Code Point (DSCP) Configure CoS trust and rewrite on Catalyst switches Describe and configure Committed Access Rate (CAR) Describe and configure Class-Based Weighted Fair Queuing (CBWFQ) Describe and configure Weighted Random Early Detection (WRED) Describe and configure Low Latency Queuing (LLQ) Describe and configure Generic Traffic Shaping (GTS) and Frame Relay traffic shaping Describe Link Fragmentation and Interleaving (LFI) Describe and configure Compressed Real-Time Transport Protocol (CRTP) Verify QoS configurations

■ ■ ■ ■ ■ ■ ■ ■ ■

Chapter 8 Quality of Service
Increasingly, data networks are being called on to support communications for traffic with varied delivery requirements. Previously an organization used separate networks for voice, video, and data traffic. Now, it is common practice to combine these into a single multiservice network in which the varied traffic types coexist. There are many circumstances in which these quality of service (QoS) requirements have not been met or even addressed at a rudimentary level:

The long delay in speech transmission when calling by way of an international satellite link Stop-start and choppy Internet streaming video performance Unclear audio when using an Internet-based IP phone Messenger applications

■ ■ ■

For applications such as file and print services, Internet browsing, e-mail, and peer-to-peer messaging products, the “best-effort” delivery attempts of the Internet and many corporate networks might be adequate. However, for organizations seeking to integrate their voice and data networks using voice over IP (VoIP), IP telephony, or high-quality streaming video for corporate communications, it is essential that QoS be built into the network design. To provide QoS within a network, it is critical that you understand the network characteristics that make up QoS and the QoS requirements of the varied traffic and applications using the network. As soon as you can state application and traffic requirements in QoS terms, you can use classification techniques to identify streams of traffic as having a particular QoS requirement. For example, you could use a standard access list to identify a user who requires priority access to network resources. After you have classified traffic into classes of service, you can use many scheduling and congestion management techniques to provide the desired service characteristics. The key to effective QoS design is knowing how these techniques operate and the benefits and limitations of each.

484

Chapter 8: Quality of Service

Quality of Service Requirements
QoS is affected by an array of variables, including loss, delay, and jitter. QoS requirements are unique to the type of traffic, such as voice, video, and data. This section defines QoS, the motivation behind it, and the specific requirements to optimize voice, video, and data traffic.

Quality of Service Defined
QoS refers to a network’s ability to provide improved service to selected network traffic over various underlying technologies, including Frame Relay, Asynchronous Transfer Mode (ATM), Ethernet and 802.3 networks, Synchronous Optical Network (SONET), and IP-routed networks. QoS can be applied in a central office or branch office or in between (see Figure 8-1), especially to support IP telephony.
Figure 8-1 QoS Can Be Applied to Networks Regardless of the Underlying Technology. IP Telephony Is a Major Motivator for Implementing QoS. Intranet Servers

VoIP Phones

Branch WAN Central Cisco CallManager VoIP Phones

QoS features provide improved and more predictable network service by offering the following services:
■ ■ ■ ■ ■ ■

Dedicated bandwidth Improved loss characteristics Congestion management Congestion avoidance Traffic shaping Traffic prioritization

Quality of Service Requirements

485

In a network, the goal is to move information from one point to another. The characteristics that define the quality of this movement are
■ ■ ■

Loss Delay or latency Delay variation (also called jitter)

The following three sections discuss each of these characteristics in greater detail.

Loss
Loss refers to the percentage of packets that fail to reach their destination. Loss can result from errors in the network, corrupted frames, and congested networks. With modern switched and optical-based networks, corrupted frames and packet losses caused by network noise, interference, and collisions are becoming rare. Many of the packets lost in an optimized network are deliberately dropped by networking devices to avoid congestion. For many Transmission Control Protocol/Internet Protocol (TCP/IP)-based traffic flows, such as those associated with file and print services, small numbers of lost packets are of little concern because TCP/IP’s retransmission mechanism ensures their eventual arrival. However, for User Datagram Protocol (UDP) traffic associated with real-time applications such as streaming media and voice, retransmission is not feasible and losses are less tolerable. As a guideline, a highly available network should suffer less than 1% loss. For voice traffic, the loss should approach 0 percent.

Delay or Latency
Delay or latency refers to the time it takes a packet to travel from the source to the destination. Delay is composed of fixed and variable delays. Fixed delays include such events as serialization and encoding/decoding. For example, a bit takes a fixed 100 nanoseconds (ns) to exit a 10-Mbps Ethernet interface. Variable delays are often the result of congestion. They include the time packets spend in network buffers waiting for access to the media. In general, delay resulting from bidirectional network traffic is a more significant problem, because it tends to be additive. Examples of bidirectional traffic include voice traffic and Telnet sessions to a remote host, in which delay manifests itself as the slow acceptance of keystrokes. The resulting latency makes it difficult to conduct a conversation without talking over the other party. As a design rule, a voice packet should cross the network in less than 150 milliseconds (ms).

486

Chapter 8: Quality of Service

Delay Variation or Jitter
Delay variation or jitter is the difference in the delay times of consecutive packets. A jitter buffer is often used to smooth out arrival times, but buffering capabilities have instantaneous and total limits. Any type of buffering used to reduce jitter directly increases total network delay. In general, traffic requiring low latency also requires a minimum variation in latency. As a design rule, voice networks cannot cope with more than 30 ms of jitter. Jitter greater than 30 ms results in degraded audio performance. Excessive jitter in a streaming video environment results in jerky motion, loss of video quality, or loss of video.

Network Availability
Providing QoS requires maximizing network uptime. Low loss, small delays, and minimal jitter are meaningless if the network is down. Redundancy, dynamic routing protocols, Hot Standby Router Protocol (HSRP), and Spanning Tree Protocol (STP) are all used to create a highly available network and to form the foundation of a network that can fulfill QoS requirements. Figure 8-2 illustrates the redundancy and maximizing of network availability as provided by HSRP and STP.
Figure 8-2 Maximizing Network Availability with STP and HSRP by Providing Layer 2 and Layer 3 Redundancy

ISP 1

ISP 2

Multihomed WAN or Redundant Core Layer

HSRP

STP

Quality of Service Requirements

487

Provisioning
You might find it surprising that bandwidth is not listed as an element of QoS. Inadequate bandwidth inflates latency as packets spend increasing amounts of time queued in network devices. In seriously congested networks, inadequate bandwidth results in loss of data as queues overflow. Meeting QoS requirements is impossible if network LAN and wide area network (WAN) links have insufficient bandwidth. Adding bandwidth, also known as overprovisioning, does not solve the problem. The possibility of an overprovisioned network becoming congested is reduced. If the network does become congested, it might not perform as well as a lower-bandwidth, lower-cost network that makes use of sophisticated QoS features. Figure 8-3 illustrates provisioning.
Figure 8-3 Sometimes a Lower-Bandwidth Network with Intelligent QoS Performs Better Than an Overprovisioned Network That Becomes Congested

Shared Burst Area Sold to Many Customers

C

D

Customer A

B

12 13

OC

E

-N
LA Vo N V ice oI Vid P In eo ter Da net ta

11
ATM Ethernet

STSNcDIP Pkts STSNcDATM Cells Ds3-Leased Line

TDM

IP

Ds1-Voice Ds1-Voice

Quality of Service Requirements for Data
Different applications, protocols, and traffic types have different QoS requirements in terms of the amount of loss, latency, and jitter they can tolerate. Recognizing these differences is an essential element in designing and configuring a network that delivers the required QoS. When addressing the QoS needs of data application traffic, profile the applications to get a basic understanding of the network requirements. It is not necessary to overengineer the

488

Chapter 8: Quality of Service

provisioning of bandwidth, because some traffic can usually tolerate lower QoS levels. Instead, use the proven relative priority model to divide traffic into no more than four classes:
■ ■ ■ ■

Gold (mission-critical)—Transactional and business software Silver (guaranteed bandwidth)—Streaming video, messaging, and intranet Bronze (best-effort and default class)—Internet browsing, e-mail Less-Than-Best-Effort (Optional; higher-drop preferences)—File Transfer Protocol (FTP), backups, and applications (such as Napster or KaZaa)

Quality of Service Requirements for Voice
Voice quality is directly affected by all three QoS factors—loss, delay, and delay variation. Recommended parameters are as follows:
■ ■ ■ ■

Loss should be no more than 1 percent One-way latency should be no more than 150 to 200 ms Average jitter should be no more than 30 ms 21 to 106 kbps of guaranteed priority bandwidth is required per call, depending on the sampling rate, codec, and Layer 2 overhead

Loss causes voice clipping and skips. Industry-standard codec algorithms can correct for up to 30 ms of lost voice. Cisco VoIP technology uses 20-ms samples of voice payload per VoIP packet. Only a single Real-Time Transport Protocol (RTP) packet can be lost at any given time. If two successive voice packets are lost, the 30-ms correctable window is exceeded, and voice quality begins to degrade. Delay can cause voice quality degradation if the delay exceeds 200 ms. If the end-to-end voice delay becomes too long, the conversation sounds as if the two parties are talking over a satellite link or a CB radio. The International Telecommunication Union (ITU) standard for VoIP, G.114, states that a 150-ms one-way delay budget is acceptable for high voice quality. With respect to delay variation, adaptive jitter buffers exist within IP Telephony devices that can usually compensate for 20 to 50 ms of jitter.

Quality of Service Requirements for Video
Streaming video applications have more-lenient QoS requirements because they are delay-insensitive. A video can take several seconds to cue up and is largely delay variationinsensitive because of application buffering. Streaming video might contain valuable content,

Quality of Service Requirements

489

as in the case of an e-learning application, and might require service guarantees using QoS. Streaming video would be appropriately provisioned in the “Silver” class of data traffic. When provisioning for streaming video, take into account the video content distribution requirements. Recommended QoS parameters for streaming video traffic are as follows:
■ ■ ■ ■ ■

Loss should be no more than 2 percent Latency should be no more than 4 to 5 seconds There are no significant jitter requirements Bandwidth requirements depend on the encoding and rate of the video stream Non-entertainment streaming video should be provisioned into the “Silver” data traffic class

Video file distribution is very similar to FTP traffic and can have a major impact on network performance because of the file size. Distribution traffic should be managed to avoid affecting the network using the following QoS parameters for video content transfers:
■ ■ ■ ■ ■

Streaming video content is delay- and delay-variation insensitive. Streaming video requires large file transfers. Try to restrict distribution to less-busy times of day. Provision as “less-than-best-effort” data. The minimum bandwidth guarantee is the size of the videoconferencing session plus 20 percent.

When addressing the QoS needs of videoconferencing traffic, the basic requirements are similar to those for voice (see Figure 8-4):
■ ■ ■ ■

Loss should be no more than 1%. One-way latency should be no more than 150 to 200 ms. The average jitter should be no more than 30 ms. Because of its bursty nature, the minimum bandwidth guarantee is the size of the videoconferencing session plus 20 percent.

As Figure 8-4 illustrates, this means that a 384-kbps videoconferencing session requires 460 kbps guaranteed priority bandwidth.

490

Chapter 8: Quality of Service

Figure 8-4 Videoconferencing Bandwidth Requirements for a 384-kbps Session Video conferencing Bandwidth Requirements for a 384-Kbps Session
"I" Frame (Full-Sample Video) 1024 to 1518 Bytes "I" Frame (Full-Sample Video) 1024 to 1518 Bytes 600 kbps

30 pps "P" and "B" Frames Differential/Predicted Frames 128 to 256 Bytes 15 pps 35 kbps

I = Intra-Frame P = Predictive B = Bidirectional

Quality of Service Mechanisms
After you’ve defined the network’s QoS requirements, the next step is to select an appropriate service model. A service model is a general approach or a design philosophy for handling the competing streams of traffic within a network. There are three service models from which to choose:
■ ■ ■

Best-effort Integrated Differentiated

The service model you select must be capable of meeting the network’s QoS requirements and integrating any networked applications.

Best-Effort Service
Best-effort is a single service model in which an application sends data whenever it must, in any quantity, without requesting permission or first informing the network. The characteristics of the best-effort service model are as follows:
■ ■ ■

Data is delivered if resources exist. All traffic has an equal chance of being dropped because of congestion. It is implemented using first-in, first-out (FIFO) queues.

Quality of Service Mechanisms

491

For best-effort service, the network delivers data if it can, without any assurance of reliability, delay bounds, or throughput. The Cisco IOS QoS feature that implements best-effort service is FIFO queuing. FIFO is the default method of queuing for LAN and high-speed WAN interfaces on switches and routers. Best-effort service is suitable for a wide range of networked applications, such as general file transfers, e-mail, and web browsing.

Integrated Services Model
The Integrated Services or IntServ architecture is a multiple-service model that can accommodate multiple QoS requirements. Its characteristics are as follows:
■ ■ ■ ■

An application makes an explicit request for network resources. An application must be QoS-aware. It is implemented using Resource Reservation Protocol (RSVP). It uses Guaranteed Rate Service or Controlled Load Service.

In this model, the application requests a specific kind of service from the network before it sends data. The request is made by explicit signaling. The application informs the network of its traffic profile and requests a particular kind of service that can encompass its bandwidth and delay requirements. The application is expected to send data only after it gets a confirmation from the network. The application is also expected to send data that lies within its described traffic profile. The network performs admission control based on information from the application and available network resources. The network also commits to meeting the application’s QoS requirements as long as the traffic remains within the profile specifications. The network fulfills its commitment by maintaining a per-flow state and then performing packet classification, policing, and intelligent queuing based on that state. The Cisco IOS IntServ model allows applications to make use of the Internet Engineering Task Force (IETF) RSVP, which applications can use to signal their QoS requirements to the router. However, the IntServ model does not scale well as additional streams are added. Each reservation is analogous to a phone call with a guaranteed end-to-end connection. Routers, in conjunction with RSVP, can use intelligent queuing mechanisms to provide two types of services:

Guaranteed Rate Service—Allows applications to reserve bandwidth to meet their requirements. Adaptive real-time applications, such as playback of a recorded conference, can use this kind of service. Controlled Load Service—Allows applications to have low delay and high throughput even during times of congestion. For example, adaptive real-time applications, such as playback of a recorded conference, can use this kind of service. Cisco IOS QoS uses RSVP with Weighted Random Early Detection (WRED) to provide this kind of service.

492

Chapter 8: Quality of Service

Differentiated Services Model
NOTE For additional information, go to Cisco.com and search for the document “Implementing DiffServ for End-toEnd Quality of Service Overview.”

The Differentiated Services or DiffServ architecture is an emerging standard from the IETF. Its characteristics are as follows:
■ ■ ■ ■ ■

Packets are classified upon entering the network. QoS is classified at Layer 2 using 802.1Q/p CoS. QoS is classified at Layer 3 using IP Precedence or DSCP. Network devices use the classification to queue, shape, and police traffic flows. Applications do not need to be QoS-aware.

The DiffServ architecture specifies that each packet is classified upon entry into the network. The classification is carried in the IP packet header using either IP Precedence or the preferred Differentiated Services Code Point (DSCP). These are represented using the first 3 or 6 bits of the Type of Service (ToS) field, respectively. Classification can also be carried in the Layer 2 frame in the form of the Class of Service (CoS) field embodied in ISL and 802.1Q frames. After packets are classified at the edge by access layer switches or border routers, the network uses the classification to determine how the traffic should be queued, shaped, and policed. Per-hop behaviors (PHBs) are often used to describe the DiffServ model. The default PHB specifies that a packet marked with a DSCP value of 000000 (recommended) receives the traditional best-effort service from a DiffServ-compliant node. Also, if a packet arrives at a DiffServ-compliant node, and the DSCP value is not mapped to any other PHB, the packet is mapped to the default PHB. Other PHBs include the Class Selector PHB, the Assured Forwarding PHB, and the Expedited Forwarding PHB. Unlike the IntServ model, DiffServ does not require network applications be QoS-aware.

Traffic Marking
To provide QoS to varying packets and frames, you must mark them to indicate their QoS requirements. Specific fields are used for QoS marking or classification in frames or packets, as shown in Figure 8-5. At the data-link layer, a raw Ethernet frame has no fields to signify its QoS requirements. If QoS marking is required, ISL or 802.1Q/p must be used because they provide a 3-bit CoS field. At the network layer, an IP packet contains a 1-byte ToS field, of which the first 3 bits form the IP-Precedence field and the first 6 bits form the DSCP fields. Either of these can be used to signify an IP packet’s QoS requirements.

Quality of Service Mechanisms

493

Figure 8-5 It Is Important to Understand That QoS Can Be Implemented at Both Layer 2 and Layer 3
Encapsulated Packet Layer 2 Header IP Header

Data

Layer 2 ISL Frame ISL Header (26 Bytes) Encapsulated Frame 1... (24.5 KB) 3 Bits Used for CoS Layer 2 802.1Q/p Frame Start Frame Delimiter FCS (4 Bytes)

Preamble

DA

SA

Tag

PT

Data

FCS

3 Bits Used for CoS (User Priority) Layer 3 IPv4 Packet Version Length ToS (1 Byte)

Len

ID

Offset

TTL

Proto

FCS

IP-SA

IP-DA

Data

IP Precedence or DSCP

The marking of traffic at Layer 2 or 3 is crucial to providing QoS within a network. Network devices use this marking to determine traffic’s relative priority. The decision of whether to mark traffic at Layers 2 or 3 or both is not trivial and should be made after considering the following points:
■ ■

Layer 2 marking of frames can be performed for non-IP traffic. Layer 2 marking of frames is the only QoS option available for switches that are not IP-aware. Layer 3 marking carries the QoS information end-to-end. Older IP equipment might not understand DSCP.

■ ■

Although it might seem confusing to have three options for marking traffic, in practice the way to proceed is often determined by the capabilities of hosts, switches, and routers within the network. In many instances, it might be necessary to use different marking techniques at different points within a network. For this reason, it is common to do both of the following:
■ ■

Use DSCP to mark the packets’ QoS requirements through the network’s routed layers Use CoS to mark the frames to allow Layer 2 devices, such as switches, to provide for the packets’ QoS requirements at the data-link layer

494

Chapter 8: Quality of Service

The 3-bit CoS field present in the Layer 2 ISL and 802.1Q/p frames allows eight levels of priority to be set for each frame. These values range from 0 for the lowest priority to 7 for the highest priority. Although the CoS field can be used to influence the QoS treatment of packets, it does not have the flexibility or end-to-end capability of the IP marking schemes using IP Precedence or DSCP. For this reason, it is common to have switches set a Layer 2 CoS value for traffic based on their ingress port and to have a router translate the CoS value into an equivalent IP Precedence or DSCP value. This Layer 3 ToS is then used to influence the QoS as the packet passes through network devices en route to its destination. Table 8-1 compares associating a packet with an IP Precedence to associating a packet with an IP DSCP QoS level.
Table 8-1 Packet Association: Comparing IP Precedence and IP DSCP QoS Level Associations

IP Precedence

IP DSCP QoS Level

Layer 3 QoS marking mechanism Relevant only to IP traffic Superseded by DSCP 3-bit field 0 = low priority 7 = highest priority

Layer 3 QoS marking mechanism Relevant only to IP traffic

6-bit field (the first 3 bits are ToS) 0 = low priority 63 = highest priority

Associating a packet with either IP Precedence level or an IP DSCP QoS level allows network devices to classify traffic based on the packet’s IP Precedence and IP DSCP value, depending on which value is marked. These markings can be used to identify traffic with similar QoS requirements within the network, and traffic classes can be created. Traffic types that have similar QoS requirements can be given equivalent treatment. The IP DSCP value is the first 6 bits in the ToS byte, and the IP Precedence value is the first 3 bits in the ToS value. The IP Precedence value is actually part of the IP DSCP value. Therefore, both values cannot be set simultaneously. If they are, the packet is marked with the IP DSCP value. Essentially, DSCP supersedes IP Precedence.

Quality of Service Mechanisms

495

If it is necessary to provide QoS through packet marking, and all the devices in the network support IP DSCP marking, it is best to use the IP DSCP marking. IP DSCP markings provide more packet-marking options than IP Precedence. DSCP marking might be undesirable because some older devices in the network do not support IP DSCP values. In this case it might be necessary to use the IP Precedence value to mark the packets. A maximum of eight different IP Precedence markings and 64 different IP DSCP markings may be set.

Modular QoS Command-Line Interface (MQC)
The Modular QoS command-line interface (MQC) is central to Cisco’s model for implementing IOS-based QoS solutions. The MQC breaks down the tasks associated with QoS into modules that
■ ■ ■ ■

Identify traffic flows. Classify traffic flows as belonging to a common class of QoS. Apply QoS policies to that class. Define the interfaces on which the policy should be enforced.

The modular nature of MQC allows the reuse of common traffic classes and policies, which provides the following benefits:
■ ■ ■

It simplifies the configuration. It makes it more efficient to implement changes. It reduces the chance of error.

MQC has three steps: Step 1 Step 2 Step 3 Classify traffic using the class-map command. Apply QoS policies to the traffic using the policy-map command. Apply policies to an interface using the service-policy command.

Using the class-map Command to Define Traffic Classes
The class-map command defines a traffic class. The purpose of a traffic class is to classify traffic that should be given a particular QoS. A traffic class contains three major elements:
■ ■ ■

A name A series of match commands If more than one match command exists in the traffic class, instructions on how to evaluate these match commands

496

Chapter 8: Quality of Service

The traffic class is named in the class-map command line. For example, if you enter the class-map cisco command while configuring the traffic class in the command-line interface (CLI), the traffic class is named cisco, as shown in Example 8-1.
Example 8-1 The class-map Defines a Traffic Class
Switch(config)#class-map cisco Switch(config-cmap)#

match commands specify various criteria for classifying packets. Packets are checked to determine whether they match the criteria specified in the match commands. If a packet matches the specified criteria, that packet is considered a member of the class and is forwarded according to the QoS specifications set in the traffic policy. Packets that fail to meet any of the matching criteria are classified as members of the default traffic class and are subject to a separate traffic policy. The actual criteria that can be used to establish a match vary considerably between hardware platforms and versions of Cisco IOS software. Table 8-2 compares the supported match commands on the Catalyst 2950 and Catalyst 3550.
Table 8-2 Several Match Parameters Are Available on the Catalyst 3550

Catalyst Match On 2950

Catalyst 3550 Description

access-group ip dscp ip precedence any class-map destination-address input-interface mpls protocol source-address vlan

✓ ✓

✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Access group A specific DSCP value or a list of values A specific IP Precedence value or a list of values Any packet A nested class map A destination MAC address Selects an input interface to match on Multiprotocol Label Switching values Matches on a protocol type A source MAC address VLAN ID

Quality of Service Mechanisms

497

In Example 8-2, any traffic that is permitted by the named ACL test is considered part of the traffic class known as cisco.
Example 8-2 The match Command Defines What Traffic to Permit
Switch(config)#class-map cisco Switch(config-cmap)#match access-group name test

The instruction on how to evaluate these match commands needs to be specified if more than one match statement exists in the traffic class. You specify the evaluation instruction with one of the following two options:
class-map match-any

NOTE The Catalyst 2950 has no match-any option. The default behavior of the 2950 is to match any. This can be overridden using the match-all command.

or
class-map match-all

If match-any is specified as the evaluation instruction, the traffic being evaluated by the traffic class must match one of the specified criteria. If match-all is specified as the evaluation instruction, the traffic being evaluated by the traffic class must match all the specified criteria. Example 8-3 illustrates the match-any option.
Example 8-3 The match-any Command Allows for a Match of Any Single Criteria in a List of Matchable Options
Switch(config)#class-map match-any cisco Switch(config-cmap)#match access-group name test Switch(config-cmap)#match input-interface fastethernet 0/1

If traffic matches a permit statement in the ACL test or the traffic originates from FastEthernet 0/1, it is considered part of the class of traffic known as cisco. On the Catalyst 3550 and Catalyst 6500 the MQC allows multiple traffic classes to be configured as a single traffic class; this includes nested traffic classes, also called nested class maps. This nesting can be achieved with the use of the match class-map command.

Defining the QoS Policy Using the Policy Map
The policy-map command is used to create a traffic policy. The purpose of a traffic policy is to configure the QoS features that should be associated with the traffic that has been classified in a user-specified traffic class. A traffic policy contains three elements:
■ ■ ■

Policy name Traffic class specified with the class command QoS policies to be applied to each class

498

Chapter 8: Quality of Service

The policy map shown in Example 8-4 creates a traffic policy named policy1. The policy applies to all traffic classified by the previously defined traffic class cisco and specifies that traffic in this example should be allocated bandwidth of 3000 kbps. Any traffic that does not belong to the class cisco forms part of the catchall class-default class and is given a default bandwidth of 2000 kbps.
NOTE The actual policies that can be implemented are platform-dependent. Example 8-4 is relevant for a Catalyst 3550 or Catalyst 6500; however, the Catalyst 2950 does not support the bandwidth command. Table 8-3 describes the QoS policy parameters for 2950s and 3550s. Example 8-4 The policy-map Command Creates a Traffic Policy That Configures the QoS Features
Switch(config)#policy-map policy1 Switch(config-pmap)#class cisco Switch(config-pmap-c)#bandwidth 3000 Switch(config-pmap-c)#exit Switch(config-pmap)#class class-default Switch(config-pmap-c)#bandwidth 2000 Switch(config-pmap-c)#exit

Table 8-3 QoS Policy Parameters on the Catalyst 2950 and 3550

Catalyst Action 2950

Catalyst 3550 Description

bandwidth set ip dscp set ip precedence trust cos trust dscp ip-precedence police ✓

✓ ✓ ✓ ✓ ✓ ✓ ✓

Limits bandwidth to kbps. Marks frames with a specific DSCP value. Marks frames with a specific IP Precedence value. Trusts the frame’s CoS. Trusts the packet’s DSCP. Trusts the packet’s IP Precedence. Enforces bandwidth and flow characteristics on traffic.

The MQC does not necessarily require that users associate only one traffic class to one traffic policy. When packets match more than one match criterion, multiple traffic classes can be associated with a single service policy.

Classification at the Access Layer

499

Applying the Policy to an Interface Using the Service Policy
The service-policy command attaches the traffic policy, as specified with the policy-map command, to an interface. Because the elements of the traffic policy can be applied to packets entering and leaving the interface, it is necessary to specify whether the traffic policy characteristics should be applied to incoming or outgoing packets. For instance, the service-policy output policy1 command shown in Example 8-5 attaches all the characteristics of the traffic policy named policy1 to the specified interface. All packets leaving the specified interface are evaluated according to the criteria specified in the traffic policy named policy1.
Example 8-5 The service-policy Command Attaches a Policy to an Interface
Switch(config)#interface fastethernet 0/1 Switch(config-if)#service-policy output policy1 Switch(config-if)#exit

Classification at the Access Layer
To be effective, QoS should be implemented end-to-end within a network. Best practice is to classify traffic as soon as possible and ideally at the network edge or access layer. Some network devices can signify their traffic’s QoS requirements directly, and others rely on access layer switches or border routers to perform this function on their behalf. Specifically: End devices can specify their own CoS, IP Precedence, and DSCP QoS parameters. or These parameters can be classified by the switch based on the ingress port. Frames and packets can be marked as important by using Layer 2 CoS settings in the User Priority bits of the 802.1p portion of the 802.1Q header or the IP Precedence/DSCP bits in the ToS byte of the Internet Protocol version 4 (IPv4) header. The following sections outline the various classification techniques that can be applied at the ingress port of an access layer switch.

Trusting the CoS
The 3-bit CoS field in an ISL or 802.1Q/p frame allows for a range of CoS values between 0 and 7, where 0 is the lowest priority and 7 is the highest priority. If the edge device, such as an IP phone or PC application, can set the CoS bits, the network designer must decide whether to trust the device. The default action is for a switch with QoS features activated not to trust

500

Chapter 8: Quality of Service

edge devices, and any frames that enter the switch have their CoS rewritten to the lowest priority of 0. If the edge device can be trusted, this default behavior must be overridden, and the access switch must be configured to switch the frame, leaving the CoS bits untouched, as shown in Figure 8-6.
Figure 8-6 Trusting the CoS of the Edge Devices Is One Option for Access Layer Switch Configuration

My traffic is delay and loss sensitive. I need CoS5.

OK, I trust you. I’ll forward your frame unchanged.

PC

Cisco 7960 IP Phone

Catalyst 2950 Switch

802.1Q/p Frame Header

CoS 5

Voice Payload

802.1Q/p Frame Header

CoS 5

Voice Payload

Configuring CoS Trust Using the IOS
Depending on the switch model, it might be necessary to first activate QoS using the global configuration command mls qos. The mls qos command is required on both the Catalyst 3550 and the Catalyst 6500. The Catalyst 2950 has QoS enabled by default. The trust is configured on the switch port using the interface command mls qos trust cos. Example 8-6 demonstrates configuring trust (with comments for each step) on Catalyst switches.
Example 8-6 Configuring Trust on Catalyst Switches Is Straightforward
switch(config)#mls qos ! Enables QoS functionality switch(config-if)#mls qos trust cos ! Allows the switch to pass CoS values without changing them switch(config-if)#mls qos cos default-cos ! Unmarked frame is given a default CoS when entering a port

Classification at the Access Layer

501

Any ISL or 802.1Q/p frames that enter the switch port now have their CoS passed, untouched, through the switch. If an untagged frame arrives at the switch port, the switch assigns a default CoS to the frame before forwarding it. By default, untagged frames are assigned a CoS of 0. This can be changed using the interface configuration command mls qos cos default-cos, where default-cos is a number between 0 and 7.

Assigning CoS on a Per-Port Basis
For most network devices, such as PCs and printers, switch access ports can be assigned a default port CoS value of 0, because they have no special QoS requirements. For devices requiring a specific QoS that are unable to set the CoS value, an appropriate CoS value should be applied to the switch port. After a switch port is configured with a default CoS, traffic that passes through the port is automatically tagged with the required CoS value. The CoS value assigned by the switch can be changed on a port-by-port basis using the interface configuration command mls qos cos default-cos. After you apply the mls qos cos default-cos command, and assuming that the switch has been configured to trust the frames’ existing CoS value, the switch’s behavior is as follows:
■ ■

If the incoming frame has no CoS, apply the default CoS. If the incoming frame has a CoS, maintain the same CoS.

Rewriting the CoS
In some cases, it might be desirable not to trust any CoS value that might be present in frames sourced from an edge device. For example, an office PC used for general applications, such as web browsing, e-mail, and file and print services, does not require special QoS treatment. Allowing it to request higher levels of QoS might adversely affect applications that require guarantees of bandwidth and latency, such as voice and video. For this reason, it is possible to use the override parameter to tell the switch to ignore any existing CoS value that might be in the frame and apply the default value. This effectively disables any trust configuration that might have been applied to the port previously. The CoS value assigned by the switch can be changed on a port-by-port basis using the interface configuration command mls qos cos override, as shown in Figure 8-7.

502

Chapter 8: Quality of Service

Figure 8-7 The CoS of Incoming Frames Can Be Overridden
cos 2 cos 5

Interface 0/1 mls qos cos 2 override Interface 0/2 mls qos cos 5 override

After you apply the mls qos cos override command, the switch rewrites the CoS value for all incoming frames to the configured default value, regardless of any existing CoS value, as shown in Figure 8-8.
Figure 8-8 It Might Be Prudent Not to Trust the CoS of Attached Devices

I want great service. I want CoS 5.

I don’t trust you. I will re-write your CoS to an acceptable level.

PC

Cisco 7960 IP Phone

Catalyst 2950 Switch

802.1Q/p Frame Header

CoS 5

Data Payload

802.1Q/p Frame Header

CoS 0

Data Payload

Using a MAC ACL to Assign a DSCP Value
Classifying a frame’s CoS based on an ingress port is not always possible. An example of where ingress port classification would be a problem is where an ingress port is connected to multiple hosts through a hub or a simple workgroup switch that does not support QoS classification, as shown in Figure 8-9.

Classification at the Access Layer

503

Figure 8-9 Not All Frames Can Be Meaningfully Assigned a CoS Based on the Ingress Port
What CoS should I apply to these frames?

I don’t understand CoS.

I need a CoS of 3.

A CoS of 0 will do for me.

An IP access list could be a way of identifying traffic; however, this practice would limit QoS classification to IP traffic. IP access lists are also problematic when equipment must move between VLANs or when the IP address is dynamically allocated, such as DHCP. In this case, a possible solution would be to use a Layer 2 MAC-based ACL. The syntax for a MAC ACL is similar to that required for an IP-based ACL. Use the global configuration command mac access-list extended name. Table 8-4 shows the syntax for creating MAC ACLs. In the QoS context, the permit and deny actions in the access control entries (ACEs) have different meanings than with security ACLs:

NOTE When creating an access list, remember that, by default, the end of the access list contains an implicit deny statement for everything if no match is found before the end is reached.

If a match with a permit action is encountered, known as the first-match principle, the specified QoS-related action is taken. If a match with a deny action is encountered, the ACL being processed is skipped, and the next ACL is processed. If no match with a permit action is encountered and all the ACLs have been examined, no QoS processing occurs on the packet. If multiple ACLs are configured on an interface, the lookup stops after the packet matches the first ACL with a permit action, and QoS processing begins.

504

Chapter 8: Quality of Service

Table 8-4 Named MAC ACLs Are Useful When Multiple Devices Are Connected to a Single Switch Port

Command/Parameters

Description

mac access-list extended name {deny | permit} {any | host source MAC address} {any | host destination MAC address} [aarp | amber | appletalk | decspanning | decnet-iv | diagnostic | dsm | etype-6000 | etype-8042 | lat | lavc-sca | mop-console | mop-dump | msdos | mumps | netbios | vines-echo | vines-ip | xns-idp]

From global configuration mode, defines an extended MAC access list using a name. In extended MAC access list configuration mode, permits or denies any source MAC address or a specific host source MAC address and any destination MAC address. (Optional) You can also enter the following non-IP options: aarp | amber | appletalk | dec-spanning | decnet-iv | diagnostic | dsm | etype-6000 | etype-8042 | lat | lavc-sca | mop-console | mop-dump | msdos | mumps | netbios | vines-echo | vines-ip | xns-idp Displays the access list configuration.

show access-lists [number | name]

After a traffic class has been defined with a MAC-based ACL, a policy can be attached to that class. A policy can contain multiple classes with different QoS actions specified for each of them. For classification purposes, the policy class can be used to set a CoS at Layer 2 or DSCP at Layer 3.
Lab 8.9.1 Classifying Traffic Using Class of Service at the Access Layer

This lab introduces the use of the Layer 2 CoS field as a means of classifying traffic entering the network at the access layer.

Configuring DSCP Using a MAC ACL
In Figure 8-10, a MAC ACL is used to set the DSCP field of packets coming from a single IP Phone, called receptionphone, within a switched network. Given that the MAC address of the IP Phone is known to be 000.0a00.0111, a MAC ACL can be configured to identify traffic sourced from this device.

Classification at the Access Layer

505

Figure 8-10 MAC ACLs Can Be Used As a Basis for DSCP Marking Switch(config)#mac access-list extended receptionphone Switch(config-ext-macl)#permit host 000.0a00.0111 any Switch(config-ext-macl)#exit DCSP 40

Any Port any VLAN

IP

Verify the access list configuration using the show access-lists command, as shown in Example 8-7.
Example 8-7 Verifying Access List Configuration
Switch#show access-lists Extended MAC access list receptionphone permit host 0000.0a00.0111 any permit host 0000.0a00.0111 any

After the traffic is identified, a class map is used to link the identified traffic to a particular class of service. In this case, a class of service called ipphone is created, as shown in Example 8-8.
Example 8-8 Traffic Defined by a MAC ACL Can Be Referenced in a Class Map
Switch(config)#class-map match-all ipphone Switch(config-cmap)#match access-group name receptionphone

Verify the class map configuration using the show class-map command, as shown in Example 8-9.

506

Chapter 8: Quality of Service

Example 8-9 Verifying Class Map Configuration
Switch#show class-map class map match-any class-default (id 0) match any class map match-all ipphone (id 2) match access-group name receptionphone

Now that the traffic is classified, a policy map is used to define the action that should be taken on any traffic that forms part of that class, as shown in Example 8-10. In this case, the policy is called inbound-accesslayer, and the action is to set DSCP for the packets to 40.
Example 8-10 A Policy Map Defines the Action to Take on the Traffic Defined by the MAC ACL
Switch(config)#policy-map inbound-accesslayer Switch(config-pmap)#class ipphone Switch(config-pmap-c)#set ip dscp 40

Verify the policy map configuration using the show policy-map command, as shown in Example 8-11.
Example 8-11 Verifying the Policy Map Configuration
Switch#show policy-map Policy Map inbound-accesslayer class ipphone set ip dscp 40

Now that the action to be taken on packets coming from the IP Phone is defined, the only remaining step is to tell the switch to apply the policy to the appropriate interface. In this case, the policy is applied to all the interfaces (as shown in Example 8-12) so that QoS is maintained regardless of the interface the IP Phone is connected to.
Example 8-12 Applying the Policy Map to All Interfaces
Switch(config)#interface range fastethernet 0/1 - 24 Switch(config-if-range)#service-policy input inbound-accesslayer

Determine the policies that are bound to a particular interface on the switch using the show mls qos interface command, as shown in Example 8-13.

Classification at the Access Layer

507

Example 8-13 Determining Policies Bound to an Interface
Switch#show mls qos interface fastethernet 0/1 FastEthernet0/1 Attached policy-map for Ingress: inbound-accesslayer trust state: not trusted trust mode: not trusted COS override: dis default COS: 0 pass-through: none trust device: none

Using an IP ACL to Define the DSCP or Precedence
Using the MQC, it is possible to classify traffic based on its IP or TCP properties, as shown in Figure 8-11.
Figure 8-11 A Named Extended IP ACL Is Commonly Used as a Basis for DSCP Marking
Switch(config)#ip access-list extended 100 Switch(config-ext-nacl)#permit tcp any any eq ftp

DCSP 0

Any Port FTP

Server

For instance, to prevent large FTP downloads from disrupting more critical services, the network administrator tags all FTP packets entering an access layer switch with either a low IP Precedence of 0 or a DSCP of 0 so that the traffic can be subjected to QoS policies within the network. In Figure 8-11, an IP ACL is used to identify the packets.

508

Chapter 8: Quality of Service

Using the MQC command class-map, a class can be defined; in this case it is called reducedservice, for traffic that does not require high levels of QoS. Traffic is classified as reducedservice if it is permitted by the access list, as shown in Example 8-14.
Example 8-14 A Class Map Classifies the FTP Traffic
Switch(config)#class-map reducedservice Switch(config-cmap)#match access-group 100

NOTE Both the Catalyst 2950 and the Catalyst 3550 support the setting of the DSCP. However, only the Catalyst 3550 supports the setting of Precedence. This is not a serious problem, because the IP Precedence field forms the first 3 bits of the DSCP. Therefore, by choosing and setting the appropriate DSCP value, you can still set the IP Precedence.

The MQC command policy-map is used in Example 8-15 to set the DSCP to 0 for this class of traffic.
Example 8-15 Setting the DSCP Value to 0
Switch(config)#policy-map inbound-accesslayer Switch(config-pmap)#class reducedservice Switch(config-pmap-c)#set ip dscp 0

Alternatively, the IP Precedence can be set using a policy map, as shown in Example 8-16.
Example 8-16 Setting the IP Precedence to 0 on a Catalyst 3550
Switch(config)#policy-map inbound-accesslayer Switch(config-pmap)#class reducedservice Switch(config-pmap-c)#set ip precedence 0

Now that the action to be taken on FTP packets is defined, the only remaining step is to tell the switch which interfaces to apply the policy to. In the case of Example 8-17, the policy is applied to all the interfaces so that QoS is maintained regardless of which interface an FTP source might be connected to.
Example 8-17 Applying the Policy Map to All Interfaces
Switch(config)#interface range fastethernet 0/1 - 24 Switch(config-if-range)#service-policy input inbound-accesslayer

Lab 8.9.2 Introduction to the Modular QoS Command-Line Interface

This lab introduces the concept of the DSCP, which is used to mark packets with a QoS identifier.

Policing and Marking

509

Policing and Marking
Traffic policing involves placing a constraint on the maximum traffic rate. When the traffic rate reaches the configured maximum rate, excess traffic is dropped or remarked. The result is an output rate that appears as a saw tooth with crests and troughs, as illustrated in Figure 8-12.
Figure 8-12 Policing Makes It Possible to Act on Nonconforming Packets, Such as by Dropping Them

Traffic

Policing

Time

Traffic

Traffic Rate

Traffic Rate

Time

Policers define bandwidth limits for traffic. Packets that exceed the limits are said to be “out of profile” or nonconforming. Each policer specifies the action to take for packets that are in or out of profile. These actions, carried out by the “marker,” include the following:
■ ■ ■

Passing the packet through the switch without modification Dropping the packet Marking down the packet with a new DSCP value that is obtained from the configurable policed-DSCP map

Figure 8-13 provides a useful flow chart that describes policing.

Individual Policers
Individual policers apply the bandwidth limits specified in the policer separately to each matched traffic class. This type of policer is configured within a policy map using the police policy map configuration command. The format of the police command on the Catalyst 3550 is as follows:
Switch(config-pmap-c)#police rate-bps burst-byte [exceed-action {drop | policed-dscp-transmit}]

The police command on an IOS-based router operates in a similar fashion, except that the actual DSCP values are specified as part of the command line rather than being specified as a separate translation table, as is the case on a Catalyst switch. IOS-based routers also permit IP Precedence to be set.

510

Chapter 8: Quality of Service

Figure 8-13 Policed Packets Can Be Passed Through, Marked, or Dropped
Start

Read the DSCP of the Packet

Is a Policer Configured for this DSCP? Yes Check if the Packet Is in Profile by Querying the Policer Yes

No

No

Pass Through

Check Out-Of-Profile Action Configured for this Policer Mark Modify DSCP According to the Policed-DSCP Map

Drop Drop Packet

Done

Aggregate Policers
Aggregate policers apply the bandwidth limits specified in an aggregate policer cumulatively to all matched traffic flows. You configure this type of policer by specifying the aggregate policer name within a policy map by using the police aggregate policy-map configuration command. Specify the policer’s bandwidth limits by using the mls qos aggregate-policer global configuration command. In this way, the aggregate policer is shared by multiple classes of traffic within a policy map. Example 8-18 demonstrates the operation of an aggregate policer.
Example 8-18 An Aggregate Policer on a Catalyst 3550 Applies Bandwidth Limits Cumulatively to All Matched Traffic
mls qos mls qos aggregate-policer pol_1mbps 1000000 16000 exceed-action drop !---Defines the ACLs to select taffic access-list 123 permit udp any any eq 111 access-list 145 permit tcp any eq 20 any !---Defines the traffic classes to be policed class-map match-all cl_udp111 match access-group 123 class-map match-all cl_tcp20 match access-group 145

Policing and Marking

511

Example 8-18 An Aggregate Policer on a Catalyst 3550 Applies Bandwidth Limits Cumulatively to All Matched Traffic (Continued)
!---Defines the QoS policy and attaches the policer to the traffic classes policy-map po_test class cl_udp111 polic aggregate pol_1mbps class cl_tcp20 polic aggregate pol_1mpbs

Token Bucket
Policing uses a token bucket algorithm. As the switch receives each frame, a token is added to the bucket. The bucket has a hole in it and leaks at a rate that is specified as the average traffic rate in bits per second. Each time a token is added to the bucket, the switch performs a check to determine if the bucket has enough room. If there is not enough room, the packet is marked as nonconforming, and the specified policer action is taken—dropped or marked down—as illustrated in Figure 8-14.
Figure 8-14 Token Buckets Are Often Used to Describe QoS Operation

Out-of-Profile Tokens

Incoming Tokens

Burst Size

In Profile Tokens Leaking at a Fixed Rate

How quickly the bucket fills is a function of the bucket depth, or burst-byte, the rate at which the tokens are removed (rate-bps), and the duration of the burst above the average rate. The bucket’s size imposes an upper limit on the burst length and determines the number of frames that can be transmitted back-to-back. If the burst is short, the bucket does not overflow, and no action is taken against the traffic flow. However, if a burst is long and at a higher rate, the bucket overflows and the policing actions are taken against the frames in that burst. The bucket depth, the maximum burst that is tolerated before the bucket overflows, is configured by using the burst-byte option of the police policy map class configuration command or the mls qos aggregate-policer global configuration command. The rate or average at which

512

Chapter 8: Quality of Service

tokens are removed is configured using the rate-bps option of the police policy map class configuration command or the mls qos aggregate-policer global configuration command.

Classification and Policing Using Committed Access Rate (CAR)
Committed Access Rate (CAR) is a multifaceted feature that implements both classification services and policing through rate limiting. This section describes its classification capability. CAR’s classification services allow traffic flow limits to be placed on incoming traffic. These limits specify the average rate, rate-bps, and the burst rate, burst-byte, that are permissible. Traffic that is nonconforming because it exceeds either the average rate or the burst rate specified can be marked down in terms of DSCP. As traffic flows through the network, networking devices can use the adjusted DSCP to determine how the traffic should be treated. For example, congestion management and avoidance techniques can