Cisco IOS Device Support Guide - Oracle · PDF fileContents Cisco IOS Device Support Guide – Fourth Edition vi Service Activator 5.2.4 Configuration of router EIGRP process .....63

Cisco IOS Device SupportGuide

Fourth EditionDecember 2008

Oracle Communications IP Service Activator™ Version 5.2.4

Copyright © 1997, 2008, Oracle. All rights reserved.

The Programs (which include both the software and documentation) contain proprietary information; they are provided under a license agreement containing restrictions on use and disclosure and are also protected by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly, or decompilation of the Programs, except to the extent required to obtain interoperability with other independently created software or as specified by law, is prohibited.

The information contained in this document is subject to change without notice. If you find any problems in the documentation, please report them to us in writing. This document is not warranted to be error-free. Except as may be expressly permitted in your license agreement for these Programs, no part of these Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose.

If the programs are delivered to the United States Government or anyone licensing or using the Programs on behalf of the United States Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial Computer Software--Restricted Rights (June 1987). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous applications. It shall be the licensee’s responsibility to take all appropriate fail-safe, backup, redundancy and other measures to ensure the safe use of such applications if the Programs are used for such purposes, and we disclaim liability for any damages caused by such use of the Programs.

The Programs may provide links to Web sites and access to content, products, and services from third parties. Oracle is not responsible for the availability of, or any content provided on, third-party Web sites. You bear all risks associated with the use of such content. If you choose to purchase any products or services from a third party, the relationship is directly between you and the third party. Oracle is not responsible for: (a) the quality of third-party products or services; or (b) fulfilling any of the terms of the agreement with the third party, including delivery of products or services and warranty obligations related to purchased products or services. Oracle is not responsible for any loss or damage of any sort that you may incur from dealing with any third party.

Oracle, JD Edwards, and PeopleSoft are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

Cisco IOS Device Support Guide – Fourth Edition Contents

Contents

Preface ................................................................................... xi

Before contacting Oracle Global Customer Support (GCS) ............................. xii

Contacting Oracle Global Customer Support (GCS) ...................................... xii

Downloading products and documentation .................................................. xii

Downloading a media pack ..................................................................xiii

Service Activator publications ...................................................................xiii

Chapter 1 Summary of Features Supported ...................................... 1

Overview of Cisco support ..........................................................................2

Supported IOS versions ........................................................................3

Supported interface types .....................................................................3

Driver support for Cisco features .................................................................5

QoS and access control support .............................................................5

Measurement support ...........................................................................6

MPLS VPN (RFC2547bis) support ............................................................6

Layer 2 Martini VPN support ..................................................................8

MPLS Label Switched Path (LSP) Support .................................................9

Chapter 2 Installation and Setup .................................................... 11

Installation details ................................................................................... 12

Command-line parameters ....................................................................... 12

Setting command-line options on component start-up ............................. 15

Setting command-line options while the component is running ................. 16

Chapter 3 Discovery and Configuration ........................................... 19

Communication and authentication ............................................................ 20

Discovering Cisco devices ......................................................................... 20

Discovery and representation of Catalyst switches .................................. 20

Service Activator 5.2.4 iii

Contents Cisco IOS Device Support Guide – Fourth Edition

Obtaining device capabilities ................................................................ 20

Applying Service Activator configuration ..................................................... 21

The virtual device state ....................................................................... 21

Check and force consistency ................................................................ 22

Dealing with manual configuration ........................................................ 22

Features and restrictions of the device driver .............................................. 23

Managing Configuration Thresholding .................................................... 24

Enable discovery of dialer interfaces with PPP encapsulation ..................... 25

Chapter 4 Manual Pre-Configuration ............................................... 27

Configuring SNMP ................................................................................... 28

Configuring SSH ..................................................................................... 28

Mandatory manual configuration for MPLS VPNs .......................................... 28

PE routers ......................................................................................... 28

P routers ........................................................................................... 30

CE routers ......................................................................................... 31

Optional pre-configuration for MPLS VPNs ................................................... 31

Pre-defined VRF tables ........................................................................ 31

External inbound and outbound BGP route-maps .................................... 32

Pre-defined VRF import maps ............................................................... 32

Pre-defined VRF export maps ............................................................... 33

Pre-defined prefix list filters ................................................................. 34

Manually pre-configured multi-AS VPNs ................................................. 36

Manual pre-configuration for SAA .............................................................. 37

Configuring CEF for NBAR ......................................................................... 37

Chapter 5 Configuration of MPLS VPNs ........................................... 39

Pre-requisites for VPN configuration ........................................................... 40

Pre-configuration of routers ................................................................. 40

Domain-level parameters .................................................................... 40

Discovery and role assignment ............................................................. 42

Configuring VRF tables and route targets .................................................... 42

VRF tables ......................................................................................... 42

Route distinguishers ........................................................................... 43

iv Service Activator 5.2.4


RD number per VPN ............................................................................ 44

VPN topology and route targets ............................................................ 44

Limiting the number of imported routes ................................................. 46

VRF reuse/reduction ........................................................................... 47

Co-existence with pre-defined VRF tables .............................................. 48

Previously-defined VRF import maps ..................................................... 49

Previously-defined VRF export maps ..................................................... 49

Interface-less VRFs ............................................................................. 49

Service Application Points .................................................................... 49

Configuring BGP network and aggregate statements .................................... 50

How network and aggregate statements are used ................................... 50

Sample VRF scenario .......................................................................... 51

Configuring PE-PE peering with iBGP .......................................................... 54

PE-PE community attributes ................................................................. 55

Co-existence with previously configured iBGP ......................................... 55

Maximum paths ................................................................................. 55

MD5 authentication ............................................................................ 56

Configuring IP unnumbered Private PE IP addresses ................................ 56

PE-CE configuration using eBGP ................................................................ 57

Allow AS in ........................................................................................ 57

AS override ....................................................................................... 58

PE-CE community attributes ................................................................ 58

Authentication ................................................................................... 59

Local preference ................................................................................. 59

Site of origin ...................................................................................... 59

Route prefix limits and filters ............................................................... 59

eBGP load sharing .............................................................................. 60

Route dampening ............................................................................... 60

Route redistribution into eBGP ............................................................. 61

Soft Reconfiguration ........................................................................... 62

PE-CE configuration using EIGRP ............................................................... 62

Cisco IOS support for EIGRP ................................................................ 63

Configuring EIGRP .............................................................................. 63

Service Activator 5.2.4 v


Configuration of router EIGRP process ................................................... 63


Site of origin ...................................................................................... 65

Route redistribution into EIGRP ............................................................ 65

PE-CE configuration using RIP ................................................................... 67

Route redistribution into RIP ................................................................ 68

Ignoring routes to prevent multi-home routing loops ............................... 69

PE-CE configuration using OSPF ................................................................ 71


Configuring Additional OSPF Area Types ................................................ 72

Route redistribution into OSPF ............................................................. 72

Router ID and OSPF ............................................................................ 73

PE-CE configuration using static routing ..................................................... 73

PE-CE configuration using eBGP and OSPF combined .................................... 76

PE-CE configuration using eBGP and RIP combined ...................................... 76

VRF-Aware IPsec connections to MPLS VPNs .......................................... 76

Chapter 6 Configuration of Layer 2 VPNs ........................................ 79

Layer 2 Martini VPNs ............................................................................... 79

Layer 2 Martini VPN devices and data types ........................................... 79

Overview of Layer 2 Martini VPN creation .............................................. 82

Discovering devices and assigning roles for VPN setup ............................. 82

Creating a customer ........................................................................... 84

Checking Interface Capabilities ............................................................. 84

Completing other pre-configuration for Layer 2 Martini VPNs .................... 85

Provisioning sub-interfaces for a Layer 2 Martini connection ..................... 86

Provisioning endpoints (VC IDs) for a Layer 2 Martini connection .............. 87

Checking sub-interface configuration on a device .................................... 88

Creating a Layer 2 Martini VPN ............................................................. 88

Modifying and Viewing Layer 2 Martini VPN attributes .............................. 89

Deleting provisioned sub-interfaces ...................................................... 91

Chapter 7 Configuration of QoS and Access Control Features ......... 93

Traffic classification ................................................................................. 94

vi Service Activator 5.2.4


Access lists ........................................................................................ 94

Class maps ........................................................................................ 96

Access control – Access rules .................................................................... 98

How access rules work ........................................................................ 99

Migrating from IP Precedence to DSCP .................................................. 99

Implementation ................................................................................. 99

Example configuration ...................................................................... 100

Packet marking using classification rules .................................................. 101

Marking using route maps ................................................................. 102

Marking using CAR ........................................................................... 104

Marking using policy maps ................................................................. 108

Policing using CAR ................................................................................. 114

How CAR policing works .................................................................... 114

Cisco commands .............................................................................. 115

Implementation ............................................................................... 117

Priority Queuing .................................................................................... 120

How Priority Queuing works ............................................................... 120

Cisco commands .............................................................................. 121

Implementation ............................................................................... 122

Example configuration ..................................................................... 123

Weighted Round Robin (Custom Queuing) ................................................ 125

How Custom Queuing works .............................................................. 125

Cisco commands .............................................................................. 125

Implementation ............................................................................... 126

Example configuration ..................................................................... 128

Flow-based Weighted Fair Queuing .......................................................... 129

How flow-based WFQ works ............................................................... 130

Cisco commands .............................................................................. 130

Implementation ............................................................................... 131


Class-based Weighted Fair Queuing and Low Latency Queuing ..................... 132

How class-based WFQ works .............................................................. 132

Cisco commands .............................................................................. 133

Service Activator 5.2.4 vii


Implementation .............................................................................. 136


WRED .................................................................................................. 142

How WRED works ............................................................................. 142

Cisco commands .............................................................................. 143

Implementation ............................................................................... 145

Example configuration – using defaults ............................................... 150

Example configuration – setting specific values .................................... 150

Example configuration - DiffServ compliant WRED ................................ 151

WRED on ATM PVCs .......................................................................... 152

Generic Traffic Shaping .......................................................................... 152

How GTS works ................................................................................ 153

Cisco commands .............................................................................. 153

Implementation ............................................................................... 153


Frame Relay Traffic Shaping ................................................................... 155

How Frame Relay Traffic Shaping works .............................................. 156

Cisco commands .............................................................................. 157

Implementation ............................................................................... 158

Example configurations ..................................................................... 161

Distributed Traffic Shaping ..................................................................... 163

How DTS works ................................................................................ 163

Cisco commands .............................................................................. 164


ATM Traffic Shaping ............................................................................... 166

How ATM Traffic Shaping works .......................................................... 166

Cisco commands .............................................................................. 167

Implementation ............................................................................... 167


Low Latency Queuing for Frame Relay ..................................................... 170

Implementation ............................................................................... 171


Configuration of MQC ............................................................................. 174

viii Service Activator 5.2.4


Classification of MQC traffic ............................................................... 176

Marking using MQC ........................................................................... 178

Policing using MQC ........................................................................... 183

WFQ and LLQ using MQC ................................................................... 189

Class-Based Shaping using MQC ......................................................... 190


Nesting MQC PHB groups ................................................................... 195

Implementation ............................................................................... 196


Class map naming on Frame Relay interfaces ............................................ 197

Chapter 8 Configuration of Measurement Features ....................... 199

NetFlow ............................................................................................... 200

Configuring NetFlow ......................................................................... 200


Service Assurance Agent ........................................................................ 204

Operation types ............................................................................... 204

Configuring the operation .................................................................. 204

Example SAA configurations .............................................................. 210

Chapter 9 Troubleshooting ............................................................ 221

Checking the Cisco audit logs .................................................................. 222

Communication problems ....................................................................... 223

Useful Cisco commands .......................................................................... 223

General configuration ........................................................................ 224

VPN configuration ............................................................................. 224

QoS configuration ............................................................................. 228

Measurement configuration ................................................................ 229

Debugging commands ...................................................................... 229

Chapter 10 Useful References ....................................................... 231

Cisco website ........................................................................................ 232

IETF RFCs ............................................................................................ 233

Service Activator 5.2.4 ix


Appendix A MPLS VPN Device Configuration ................................. 235

Sample network .................................................................................... 236

Base configurations ............................................................................... 237

Configuration of mgmtCE .................................................................. 237

Configuration of customer site routers using EBGP ................................ 239

Configuration of customer site routers using OSPF ................................ 240

Configuration of customer site routers using RIP ................................... 241

Configuration of customer site routers using static routing ..................... 242

Base configuration of 3600_PE1 ......................................................... 242

Base configuration of 3600_PE2 ......................................................... 245

Management VPN .................................................................................. 247

Configuration of 3600_PE1 ................................................................ 247


Management and customer VPN configuration ........................................... 258



Appendix B Protocols Supported by NBAR .................................... 269

Index ............................................................................................ 275

x Service Activator 5.2.4

Cisco IOS Device Support Guide – Fourth Edition Preface

Preface

The Cisco Device Driver Guide provides detailed technical information about the Cisco IOS device driver, including supported features, configuration requirements and detailed examples. It is intended for network managers and technical consultants responsible for implementing Oracle Communications Service Activator within a network using Cisco routers.

The Cisco IOS Device Support Guide consists of the following chapters:

Chapter 1: Summary of Features Supported explains the Cisco devices, IOS versions and specific features that are supported by Service Activator.

Chapter 2: Installation and Setup explains the installation process and details the device driver command-line parameters.

Chapter 3: Discovery and Configuration explains the way in which Service Activator configures devices and ensures consistency.

Chapter 4: Manual Pre-Configuration details the pre-requisites for running Service Activator, including setting up routers for MPLS VPNs.

Chapter 5: Configuration of MPLS VPNs explains how the device driver configures MPLS-based VPNs.

Chapter 6: Configuration of Layer 2 VPNs explains how the device driver configures Layer 2 VPNs.

Chapter 7: Configuration of QoS and Access Control Features explains how the device driver configures Cisco QoS and access control features, with example configurations.

Chapter 8: Configuration of Measurement Features describes how the device driver configures NetFlow and Service Assurance Agent (SAA) on devices.

Chapter 9: Troubleshooting includes hints and tips for diagnosing and fixing problems.

Chapter 10: Useful References includes suggestions for further reading and links to the Cisco website.

Appendix A: MPLS VPN Device Configuration provides example configuration of the routers involved in management and customer MPLS VPNs.

Appendix B: Protocols Supported by NBAR lists the protocols supported by NBAR (Network-Based Application Recognition).

Service Activator 5.2.4 xi

Before contacting Oracle Global Customer Support (GCS) Cisco IOS Device Support Guide – Fourth Edition

Before contacting Oracle Global Customer Support (GCS)

If you have an issue or question, Oracle recommends reviewing the product documentation and articles on MetaLink in the Top Technical Documents section to see if you can find a solution. MetaLink is located at http://metalink.oracle.com.

In addition to MetaLink, product documentation can also be found on the product CDs and in the product set on Oracle E-Delivery.

Within the product documentation, the following publications may contain problem resolutions, work-arounds and troubleshooting information:

— Release Notes

— Oracle Installation and User's Guide

— README files

Contacting Oracle Global Customer Support (GCS)You can submit, update, and review service requests (SRs) of all severities on MetaLink, which is available 24 hours a day, 7 days a week. For technical issues of an urgent nature, you may call Oracle Global Customer Support (GCS) directly.

Oracle prefers that you use MetaLink to log your SR electronically, but if you need to contact GCS by telephone regarding a new SR, a support engineer will take down the information about your technical issue and then assign the SR to a technical engineer. A technical support representative for the Oracle and/or former MetaSolv products will then contact you.

Note that logging a new SR in a language other than English is only supported during your local country business hours. Outside of your local country business hours, technical issues are supported in English only. All SRs not logged in English outside of your local country business hours will be received the next business day. In order to obtain the broadest access to skilled technical support, Oracle advises you to log new SRs in English.

Oracle GCS can be reached locally in each country. Refer to the Oracle website for the support contact information in your country. The Oracle support website is located at http://www.oracle.com/support/contact.html.

Downloading products and documentationTo download the Oracle and/or former MetaSolv products and documentation, go to the Oracle E-Delivery site, located at http://edelivery.oracle.com.

xii Service Activator 5.2.4

http://metalink.oracle.com

http://www.oracle.com/support/contact.html

http://edelivery.oracle.com

Cisco IOS Device Support Guide – Fourth Edition Service Activator publications

You can purchase a hard copy of Oracle product documentation on the Oracle store site, located at http://oraclestore.oracle.com.

For a complete selection of Oracle documentation, go to the Oracle documentation site, located at http://www.oracle.com/technology/documentation.

Downloading a media pack

To download a media pack from Oracle E-Delivery

1. Go to http://edelivery.oracle.com.

2. Select the appropriate language and click Continue.

3. Enter the appropriate Export Validation information, accept the license agreements and click Continue.

4. For Product Pack, select Oracle Communications Applications.

5. For Platform, select the appropriate platform for your installation.

6. Click Go.

7. Select the appropriate media pack and click Continue.

8. Click Download for the items you wish to download.

9. Follow the installation documentation for each component you wish to install.

Service Activator publicationsThe Service Activator documentation suite includes a full range of publications. Refer to the Service Activator Release Notes for more information.

Service Activator 5.2.4 xiii

http://oraclestore.oracle.com

http://www.oracle.com/technology/documentation

http://edelivery.oracle.com

Service Activator publications Cisco IOS Device Support Guide – Fourth Edition

xiv Service Activator 5.2.4

Cisco IOS Device Support Guide – Fourth Edition Summary of Features Supported

Chapter 1

Summary of Features Supported

This chapter summarizes Service Activator’s support for Cisco IOS-based devices. It includes the following:

Information about the Cisco hardware and software supported by this release of Service Activator, including information on devices, versions of IOS and interface types

Information about the Service Activator features that are supported by the Cisco IOS device driver, including MPLS VPNs, Layer 2 Martini VPNs, QoS and access control features and SLA measurement features

Service Activator 5.2.4 1

Summary of Features Supported Cisco IOS Device Support Guide – Fourth Edition

Overview of Cisco supportThe Cisco device driver is designed to be capable of configuring any Cisco device running IOS. However, the exact capabilities that can be supported depend on the device model, the version of IOS that it is running and the interface. It is not possible to explicitly test Service Activator’s functionality against all combinations of device and IOS.

Information about the capabilities of each device, IOS version and interface type supported by Service Activator are held by the Cisco device driver and reflect the platforms on which Service Activator’s features have been tested. Capability support details are compiled into the device driver and are therefore static.

You cannot configure devices, IOS versions or interfaces that are not explicitly defined as supported.

However, it is recognized that with the range of hardware and software available and the broad range of customer requirements, support for additional devices, IOS versions and interfaces may be required. Service Activator provides a means of overriding these statically-defined capabilities dynamically, using a set of files referred to as the ‘capabilities override files’.

The capabilities override files are as follows:

cisco.device.device_information.cfg details the supported device types.

cisco.interface.device_information.cfg details the supported interfaces.

cisco.os.device_information.cfg details the supported IOS versions.

cisco.postremove.device_information.cfg defines the Service Activator features that are not supported by a device type and IOS in combination, although they are independently supported by both the device type and IOS.

cisco.postadd.device_information.cfg defines the Service Activator features that are supported by a particular device type and IOS, where support is not already defined by the device and IOS separately.

When these files are supplied, the capabilities they record match those defined by the device driver supplied with that release of Service Activator. It is possible to edit the files to add temporary support for a feature or mechanism or a particular device interface or IOS version.

In order to read capabilities from the capabilities override files, the device driver needs to be passed a command-line parameter.

The capabilities override function is intended for use by Oracle Communications consultants or support engineers. If you need to make any amendments to supported features, Contacting Oracle Global Customer Support (GCS).

2 Service Activator 5.2.4


Supported IOS versions

The Cisco Device Driver is designed to be capable of configuring any Cisco device running IOS, and Oracle Communications has tested against a number of versions of IOS. The majority of Service Activator features are supported in Release 12.0 and above, but for full details you are advised to consult Cisco documentation.

Note the following:

For up-to-date information on functionality supported and for information on version deferrals, please see Cisco Connection Online (www.cisco.com).

Note that for MPLS VPN support, you must be running a Service Provider (p) or Enterprise (j) IOS feature set. On the 75xx series devices, a Provider/VIP feature set (PV) is needed.

If you require more information on specific support, please contact Contacting Oracle Global Customer Support (GCS) for more information.

Supported interface typesThe Cisco device driver supports a wide range of interface types, as summarized below:

ATM interface/sub-interface, including the PA-A3 VIP

Bridge (BRI) interface/subinterface

Channelized BRI interface/subinterface

Cable interface/subinterface

Dialer interface

Ethernet interface/subinterface

Fast Ethernet interface/subinterface

Gigabit Ethernet interface/subinterface

FDDI interface

HSSI interface/subinterface

Loopback interface

Multi-link interface

POS interface/subinterface

Serial interface/subinterface

Channelized Serial interface/subinterface

Switch interface/subinterface



Token Ring interface/subinterface

Tunnel interface

Virtual Template interface

VLAN interface/subinterface

For information about supporting any interface not on this list, please contact Contacting Oracle Global Customer Support (GCS).



Driver support for Cisco features

QoS and access control support

Service Activator feature IOS 12.2+

Policy rules Access rules

Classification rules

Policing rules

Marking DiffServ codepoints (0-63)

IPv4 Precedence field

IPv4 ToS bits

MPLS experimental bits

MPLS Topmost experimental bits

Traffic classification IP Address (source/destination)

IP Port (source/destination)

IP Protocol

Packet marking traffic type

URL traffic type

MIME traffic type

Application protocol traffic type

Domain Name traffic type

PHB groups Rate Limiting

WRED

WFQ

WRR

Priority Queuing

ATM Traffic Shaping

FRTS Traffic Shaping

MQC



For full details of features supported and the way they are implemented, see Configuration of QoS and Access Control Features on page 93.

Measurement support

For full details of features supported and the way they are implemented, see Configuration of Measurement Features on page 199.

MPLS VPN (RFC2547bis) support

Service Activator feature IOS 12.2

Service Assurance Agent (SAA)

ICMP Echo

UDP Echo

TCP Connect

Jitter

NetFlow v5

v8


VRF table User-defined VRF table name

VRF re-use/reduction

User-defined RD numbers

User-defined RT numbers

RDs per VPN

VRF route limit (max routes)

Co-existence with pre-defined VRFs

Pre-defined import and export maps



PE-PE peering (iBGP) iBGP peering optional

Maximum paths

Extended/standard community attributes

PE-PE MD5 authentication

PE to CE connectivity eBGP

OSPF

RIP

Static routing

IP Unnumbered interface addressing

eBGP configuration AS override

Allow AS in

Extended/standard community attributes

Local Preference

PE-CE authentication

Prefix filters

Prefix limit

Site of origin

Multi-path load sharing

Route dampening

Route redistribution into eBGP

OSPF Route redistribution into OSPF

RIP Route redistribution into RIP

Static configuration Global routes

Local routes

Permanent routes




For full details of features supported and the way they are implemented, see Configuration of MPLS VPNs on page 39.

Layer 2 Martini VPN supportService Activator supports the configuration of Layer 2 Martini MPLS VPNs on IOS 12.0+ for the following devices:

Non-switching IOS Cisco devices (Cisco 7200, 7500, 12000 and others)

Switching IOS Cisco devices (Cisco 7600 and others)

Layer 2 Martini VPNs are not supported on PPP and HDLC protocols. To determine if your combination of device and IOS are supported, contact Contacting Oracle Global Customer Support (GCS).

Depending on the device, Service Activator supports the encapsulation of a number of different data types, as indicated below.

For details about how features are implemented, see Configuration of Layer 2 VPNs on page 79.

Protocol or Encapsulation

type Endpoints

Non-switching IOS 12.2

Switching IOS

Ethernet (Port)

Any combination of VLAN interfaces

Ethernet interfaces

Ethernet (VLAN)

VLAN endpoints configured under Ethernet interfaces (subinterfaces)

VC identifiers configured under Ethernet sub-interfaces

Frame Relay Main interface with VC identifier

ATM Cell Sub-interface with VC identifier

ATM AAL5 Sub-interface with VC identifier



MPLS Label Switched Path (LSP) Support

Service Activator featureIOS 12.2

Tunnel Hold & Setup Priority

Affinity

IGP Metric

LDP

Protection Fast Re-Route

Node & Link Protection

Paths Primary & Secondary Paths

Next Hop Lists

Exclude Address Lists

Dynamic & Explicit Paths




Cisco IOS Device Support Guide – Fourth Edition Installation and Setup

Chapter 2

Installation and Setup

This chapter explains how to set up and run the Cisco IOS driver. It includes the following:

Installation details

Details of the command-line parameters that can be used when setting up the Cisco IOS device driver


Installation and Setup Cisco IOS Device Support Guide – Fourth Edition

Installation detailsThe Cisco IOS device driver is installed using Oracle Universal Installer on a Solaris server. In Custom installation type, on the Available Product Components window, select the Cisco IOS device driver for installation.

The Cisco device driver is always installed when you select the Proxy Agent install. For more information see the Setup Guide.

Command-line parametersThe following table summarizes the command-line parameters recognized by the Cisco device driver component.

Parameter Description

-ComponentName name Specifies the name of the Cisco device driver component as displayed in the user interface.

-ComponentLocation hostname

Specifies the hostname on which the Cisco device driver component is installed.

-TelnetPort Set the port the driver uses to communicate with the device. The default port is 23.

-NumRetries n Number of times to retry a socket connection attempt, where n is an integer. Default is 0.

-ConnectTimeout n Socket connection timeout, where n is an integer specifying number of seconds. Default is 30 seconds.

-ReadTimeout n Socket read timeout in seconds, where n is an integer specifying number of seconds. Default is 30 seconds.

-WriteTimeout n Socket write timeout in seconds, where n is an integer specifying number of seconds. Default is 30 seconds.

-NoCommandDelivery This flag indicates that no commands are to be sent to any devices. All commands are logged in the audit trail.



-FileInterface This flag indicates that the driver will not communicate with devices, but will read from configuration files instead. Filenames are of the form x.x.x.x (the IP address of the device).

-FileInterfaceDir path Specifies the location of the FileInterface files. The default is the base directory of the Service Activator install.

-ForceVpnRollback Tests VPN rollback. Causes the driver to issue all VPN commands, roll them all back and then re-issue them

-DisableVpnPreservation Can be used when Service Activator is used to apply all VPN configuration. Any manual VPN configuration detected on the device will be removed.

-VrfAliasesDisabled Disables the creation of VRF-related aliases (alias ip-vrf) on the router.

-MarkingStrategy method Specifies the method of packet marking implemented by the driver. The method can be one of the following:

RouteMap Specifies that the device driver is to use route maps to mark packets (the default).

CarIn Specifies that the device driver is to use CAR to mark inbound packets.

CarOut Specifies that the device driver is to use CAR to mark outbound packets.

For more details, see Marking using CAR on page 104.

-NoFrts Disables the use of Frame Relay map-classes. When used, the Frame Relay traffic shaping PHB group is not supported. In addition, custom-queue lists, priority-groups and policy maps cannot be applied to Frame Relay PVCs, but will instead be applied to the interface.




-ReverseEngineerFRTS When configuring WRR and Priority Queuing on Frame Relay interfaces, if Frame Relay Traffic Shaping is already configured, this flag causes the driver to extract any FRTS parameters from the existing map-class and include them in the new one.

-MapClassNamingStrategy {auto | concatenation | phbname}

There are three map-class naming strategies:

auto Auto-generate the name.

concatenation Concatenate the names of the PHB and MQC PHB groups that contribute to the map-class.

phbname Name the map-class after one of the PHB and MQC PHB groups that contribute to the map-class. Take the name from the following list in the specified order:

PHB group (if it exists)

outbound MQC PHB group (if it exists)

inbound MQC PHB group

Auto is the default value if the entire command line is omitted.

-ParserCmdTimeout time Specifies the configuration timeout period, in seconds. The driver retrieves the router’s configuration at this interval. This defaults to 10 seconds. Oracle recommends that you do not change this setting unless advised to do so by Global Customer Care.

-UseMechanismFile Forces the driver to use capabilities files rather than the statically compiled versions.

-MechanismDirectory path Specifies the location of the capabilities files.

-MechFailOnError When this flag is enabled, if an error is encountered in the capabilities files a failure is reported, otherwise the driver will ignore the error and continue processing.




There are also command-line parameters that control debugging logs for all Service Activator components. These are described in full in the Administrator’s Guide.

Command-line parameters are specified when the particular component is started up. Alternatively, it is possible to set the parameters ‘on the fly’ using a component parameters utility which is supplied with Service Activator.

Setting command-line options on component start-upThe device driver must be restarted for any changes to these command-line parameters to take effect.

To set command-line parameters on Solaris

Command-line options are specified in the cman.cfg file which is in the /opt/OracleCommunications/ServiceActivator/Config directory.

Using a text editor such as vi, edit the cisco entry in the cman.cfg file with the relevant option.

-AlwaysPass regex Regular expression containing patterns for all the extra return messages which should pass.

-AlwaysFail regex Regular expression containing patterns for all the extra return messages which should fail.

-NoPostConfigMessage The Cisco Device Driver normally terminates each session of configuration activity with a broadcast message to all users logged into the device:

OracleCommunications last configured on <timestamp>

The use of the -NoPostConfigMessage parameter inhibits this broadcast.

Note: Issue this command when the Cisco device driver is used in conjunction with the network processor.




To set command-line parameters on Windows

Command-line options are specified in the registry entry.

1. Start regedit.

2. Browse to the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\OracleCommunications\DPE\2.0\ Component Manager

3. In the right-hand pane, right-click on cisco and select Modify from the pop-up menu.

The Edit String dialog box opens.

4. Edit the Value data field to set the relevant option.

Setting command-line options while the component is runningIt is possible for command-line parameters can be passed to a component ‘on the fly’ using the Component Parameters utility which is supplied with Service Activator.

This is a command-line utility that can be run against any component.

To set command-line parameters on Solaris

Change to the Service Activator bin directory and type:

./ComponentParameters -ComponentName ciscohostname -set name value [-set name value ...]

For example, the following specifies that the Cisco driver is to read configuration from the device files rather than the devices directly (in the default location) and should also not write to any devices:

./ComponentParameters -ComponentName ciscoUSSOLW666 -set -FileInterface enabled -NoCommandDelivery enabled

To set command-line parameters on Windows

1. Open a command window.

2. Change to the Service Activator Program directory and type:

ComponentParameters -ComponentName ciscohostname -set name value [-set name value ...]



where:

hostname is the host location of the Cisco device driver

name is the name of the command-line option

value is the value that it is to be set to. For flag settings, the value can be enabled or disabled

The Component Parameters utility is only installed if the Extra applications option (Windows) or Utilities package (Solaris) is selected when Service Activator is installed. If the utility is not installed, re-run the installation program, selecting only Extra applications or Utilities for installation.




Cisco IOS Device Support Guide – Fourth Edition Discovery and Configuration

Chapter 3

Discovery and Configuration

This chapter explains how the Cisco device driver configures devices. It includes the following:

How the driver communicates and authenticates with devices

The discovery of Cisco IOS devices, including obtaining capabilities

How the device driver models and applies device configuration and ensures consistency of configuration

Features and restrictions of the device driver


Discovery and Configuration Cisco IOS Device Support Guide – Fourth Edition

Communication and authenticationThe Cisco device driver accesses devices via the command-line interface (CLI). Access is authenticated using an anonymous login using local passwords, via a TACACS+ server or via Secure shell (SSH). You must ensure that the authentication methods are correctly set up for all Cisco devices in your network. You can set the authentication method in the Security page on the Discovery dialog box to ensure it applies to all devices discovered, or set it for individual devices. Usernames and passwords can be set up at network level and are inherited to all devices.

Note that the Cisco device driver requires write access to devices in order to return capabilities. Therefore you need to ensure that the device security parameters are set up correctly before running a device discovery or capabilities fetch.

Discovering Cisco devicesThis section highlights important details about discovering Cisco devices.

Discovery and representation of Catalyst switchesIf a Catalyst switch has an MSFC card installed that runs IOS, the switch’s Layer 2 manageable entity and the MSFC card (Layer 3) are represented by Service Activator as two separate network devices. They have specific IP addresses and must be discovered separately.

Service Activator supports the discovery of VLANs and port assignment to VLANs on Catalyst switches running CatOS. Note that the VLANs are represented differently on the Layer 2 and Layer 3 entities:

On the Layer 2 entity, a VLAN is represented as a VLAN interface connected directly to the switch. The physical ports that are currently assigned to a given VLAN appear as children of the VLAN interface.

On an MSFC card, a VLAN is represented as a VLAN interface connected directly to the device that represents the MSFC card.

Obtaining device capabilitiesThe features supported on each device are dependent on the hardware and software combination and are indicated by a list of capabilities returned from each device. You should always check capabilities before configuring network devices.

Capabilities are obtained at two levels:

At device level, the capabilities specify the device’s support for NetFlow and SAA, such as the SAA operations that are supported and the versions of UDP format in which NetFlow data may be exported.



At interface, sub-interface and VC endpoint level, the capabilities indicate the QoS and MPLS features that can be configured on that interface.

The Cisco device driver requires write access to devices in order to return capabilities. Therefore you need to ensure device security parameters are set up correctly first. The Cisco device driver accesses devices via the command-line interface, authenticating access via local passwords, via SSH or via a TACACS+ server.

The device driver attempts to obtain the capabilities automatically at the end of the discovery process. If this fails – for example, because the device’s security settings are incorrect – you can initiate the process to fetch capabilities manually.

In addition, if the device capabilities have changed – for example, as a result of an operating system upgrade – You can reset and refetch capabilities, after ensuring the device is unmanaged.

For more details, see the Network Discovery and Basic Setup guide.

Applying Service Activator configuration

The virtual device stateThe Cisco device driver maintains a virtual version of the device state, consisting of the rules, PHB groups, VPN configuration, and so on that have been defined. The device maintains the real state, consisting of custom queue lists, access lists, and so on, in the active configuration. In Cisco terminology, the real state is the running-config.

Although the virtual state is an abstract representation of the real state, there is a direct mapping between the two. A real state can always be generated from a virtual state. For example, if the virtual state is a PHB group specifying WRR, the real state might be a custom queue list.

The device driver must ensure that the real state is a representation of the virtual state. It does this by extracting the real state of the device, comparing this with the virtual state and generating a set of commands that will ensure the real state matches the virtual state.

A sequence of steps is run every time the virtual state changes, that is, whenever a transaction is committed and changes are propagated.

The device driver extracts the real configuration from the device, and compares this with the virtual device state.

If configuration exists in the virtual state but not in the real state, it is installed.



If configuration exists in both, the device driver checks that it’s the same. If it is, it’s left alone. If it isn’t the same, the real state is updated.

If configuration exists in the real state but not in the virtual state the device driver’s action depends on the setting of the Manual Config Warning flag and the VPN preservation setting. See Dealing with manual configuration on page 22.

Check and force consistencyA check and force consistency process ensures that the configuration of each device always matches the virtual device state, even if it has gone down and configuration is lost.

At regular intervals, the proxy agent polls the devices controlled by the driver. If it finds that the device was down (if it has re-booted since the last time it was checked), the proxy agent tells the driver to check the consistency of the device configuration.

If the driver finds that the real state is not as expected, it immediately issues commands to the device to bring the real state into line. If the driver finds that the real state matches the virtual state, it does nothing.

In this way the system makes sure that if any changes are made to devices, or if devices fail and re-boot, that the configuration is automatically reset. This does not apply if connectivity is lost but there is no device reload.

Dealing with manual configurationWarn and delete: A warning message (3203 - Manual configuration detected) is output. Any unexpected manual configuration discovered by Service Activator is removed automatically, but manually configured VRF options are by default maintained.

Fail and don’t delete: A critical fault (3494 - Manual configuration detected -configuration not applied) is output, and the device status is set to Intervention Required. The manual configuration is not removed from the device, but the commands that would have been removed are saved in the device log file in the AuditTrails directory. No new configuration is applied.

Delete: If manual configuration is discovered, no warning or fault is raised. Any unexpected manual configuration discovered by Service Activator is removed automatically, but manually configured VRF options are by default maintained. This is the default setting.

The default driver behavior can be set on the Domain property page. It can be overridden for specific devices if required by a setting on the Device property page.

By default, the removal of manual configuration does not apply to VRF tables on the device, as it is possible for Service Activator’s MPLS VPN configuration to co-exist



with pre-defined VRF tables or manually-applied commands within the VRF address-families.

However, you can force Service Activator to automatically remove all pre-defined VRF configuration that may exist on devices, by using the device driver command-line parameter:

-DisableVpnPreservation

Note the following:

Manual configuration is only detected when the driver sends a configuration update to the device. If the virtual configuration does not change and the device never goes down, the driver will not update the device configuration and manual configuration will not be detected.

The device driver only detects changes to configuration relating to those features supported by Service Activator.

It is strongly recommended that manual configuration of QoS and other policy features controlled by Service Activator is not permitted.

Features and restrictions of the device driverThe following are features and restrictions of the device driver:

The device driver only ever changes the configuration of those interfaces controlled by Service Activator.

The driver removes existing configuration only if essential and at the last possible moment.

If configuration exists on an interface/device that conflicts with the virtual configuration, but which is essential for routing/device operation, it will not be removed or changed. For example, route maps are used by Service Activator for marking but are also used to determine routing policies. If a route map already exists on an interface and was not created by Service Activator, the driver will not remove or amend it. An error message will be issued.

Configuration installed by the device driver is identified in one of two ways. In some cases objects are given specific names (for example, Service Activator route maps are always called RouteMap_n). In other cases the driver writes an alias to the device. For example, the driver writes an alias specifying which numbered ACLs it used when it configured the device. It can then use this information to determine which ACLs are used by the driver and which are not.



Managing Configuration ThresholdingUse configuration thresholding to restrict the number of commands provisioned on devices in a single transaction.

About Configuration Thresholding

Configuration Thresholding provides a safety mechanism that blocks any device configuration action by Service Activator that exceeds certain user-specified parameters. The threshold is configured by means of two values - a regular expression (regex) against which to match commands, and the threshold value itself.

The regular expression uses a syntax based on the Boost regex library. See http://www.boost.org/libs/regex/doc for details.

Configuration Threshold setup

Refer to the Network Discovery and Basic Setup Guide for complete details on setting up Configuration Thresholding and configuring it at the network level.

Note: This feature is turned off by default. In other words, all Network and Device settings for the threshold are set to No Limit. The feature starts working when you change this setting for a Network or Device.

Customizing the Configuration Threshold settings for a device

By default, devices inherit Configuration Thresholding settings from the parent Network object. You can over-ride these settings for individual devices.

To do this, right-click on the device and select Properties from the pop-up menu. The settings available work in the same way as the settings at the Network level.

1. Right-click on a network, select Properties, and set the maximum number of removal commands per device session on the Network Properties dialog box, Device Management page. By default, devices and sub-networks inherit the configuration thresholding settings from their parent network. See above for guidelines on selecting the threshold level.

2. Set appropriate values for your network configuration including Inherit Network Settings, No Limit, Limit to and Match Expression.

3. Repeat for other devices as required to set the threshold values for each of them.


http://www.boost.org/libs/regex/doc


Enable discovery of dialer interfaces with PPP encapsulationBy default, Service Activator ignores the discovery of dialer interfaces with PPP (23) encapsulation. Perform the following steps to enable the discovery of dialer interfaces with PPP encapsulation:

1. Using a text editor, open the AutoDiscovery.cfg file.

The file default location of the file is <ServiceActivatorHome>\Config\

2. Comment out the following line by adding two back slashes (//) at the beginning of the line:

Ignore:9;23;Dialer.*;

3. Save and exit the file.



4. Restart Service Activator.


Cisco IOS Device Support Guide – Fourth Edition Manual Pre-Configuration

Chapter 4

Manual Pre-Configuration

This chapter describes the manual pre-configuration required by the Cisco device driver. It includes the following:

Configuring SNMP for Service Activator discovery

Configuring SSH

Pre-requisite manual pre-configuration for MPLS VPNs

How Service Activator can co-exist with manually configured MPLS VPN features

Manual pre-configuration for SAA

Manual pre-configuration for NBAR


Manual Pre-Configuration Cisco IOS Device Support Guide – Fourth Edition

Configuring SNMPSNMP must be enabled on all routers for the Service Activator discovery process to work. Ensure the following line is included in the configuration:

snmp-server community community-name RO

Note that the network discovery process uses a default community of public; you will need to amend the appropriate SNMP parameter in the Discovery dialog if you set a different read community on the devices.

Configuring SSH To use SSH authentication, you need to configure an SSH server on the device.

The device must have a hostname and domain-name.

In configuration mode, enter the following commands:

crypto key generate rsa

You are prompted for a modulus size for the key. The default is 512, but Cisco recommends the use of a minimum modulus size of 1024 bits.

ip ssh time-out 120

ip ssh authentication-retries 3

Note that on later versions of IOS, SSH is configured automatically when the device is booted. Check the Cisco documentation for details.

Mandatory manual configuration for MPLS VPNsBefore using Service Activator to set up VPNs, some manual configuration of routers is required.

The following pre-configuration is required for each device role.

PE routersOn all PE (gateway) routers in the core VPN, you should ensure the following configuration is present:

IP addresses

IP addresses must be correctly assigned.



Loopback interfaces

A loopback interface must be set up and allocated an IP address.

Configuring MPLS

Cisco Express Forwarding (CEF) or Distributed CEF (dCEF) is a prerequisite for label switching. The relevant Cisco commands are:

ip cef

ip cef distributed

MPLS must be enabled on all appropriate interfaces. On each of the appropriate interfaces, enable MPLS using one of the following commands:

On IOS 12.1 or earlier:

(config-if)tag-switching ip

On IOS 12.2:

(config-if)mpls ip

Note that the mpls ip command is new syntax for the tag-switching ip command, so in the running-config you will still see tag-switching ip.

On 7200, 7500 and 12000 series routers running IOS 12.2 you also need to run the following command to enable LDP:

(config)mpls label switching protocol

IGP

A suitable IGP (such as OSPF, IS-IS or EIGRP) must be implemented in order to distribute IP routes in the core. The IGP for PE-CE communication is configured by Service Activator.

iBGP

The device driver configures iBGP on the PE routers, but if the no synchronization or no auto-summary commands are required they should be added manually. In order to configure those commands you will need to configure the router bgp command:

router bgp asn

no synchronization

no auto-summary

For more details see Configuring PE-PE peering with iBGP on page 54.



P routersOn all P routers in the core VPN, the following manual configuration is required.

IP addresses

IP addresses must be correctly assigned.

Loopback interfaces

It is recommended that a loopback interface is set up and allocated an IP address.

Configuring MPLS

CEF or Distributed CEF is a prerequisite for label switching. The relevant Cisco commands are:

ip cef

ip cef distributed

MPLS must be enabled on all appropriate interfaces. On each of the appropriate interfaces, enable MPLS using one of the following commands.

On IOS 12.1 or earlier:

(config-if)tag-switching ip

or, on IOS 12.2:

(config-if)mpls ip

Note that the mpls ip command is new syntax for the tag-switching ip command, so in the running-config you will still see tag-switching ip.

On 7200, 7500 and 12000 series routers running IOS 12.2 you also need to run the following command to enable LDP:

(config)mpls label switching protocol

IGP

An Interior Gateway Protocol (IGP), such as OSPF, IS-IS or EIGRP must be implemented in order to distribute IP routes. These are required for creating Label Switched Paths (LSPs).



CE routersThe CE (access) routers at customer sites are not configured to control routing by Service Activator, since they may not be under the control of the network service provider. Therefore they need to be manually configured. You need to ensure the following are set up:

BGP, RIP, OSPF or static routing must be configured in order to advertise reachability information between the CE and the PE.

It is recommended that a loopback interface is set up on each CE router.

Examples of CE configuration are given in Base configurations on page 237.

Optional pre-configuration for MPLS VPNsYou can manually pre-configure routers with data which provide specific operational requirements for MPLS VPNs. Service Activator is able to incorporate the following pre-configured data into the device configuration.

Pre-defined VRF tablesYou can manually configure VRF tables on a PE router. When a pre-defined VRF table exists on a device, Service Activator can treat it in three different ways:

Service Activator has no control of the VRF table or its contents

Service Activator has control of the VRF table and preserves its contents

Service Activator has control of the VRF table and removes its contents

You specify the amount of control Service Activator has over a VRF table by setting certain site-specific values (on the VRF page of the Site dialog box). For more information, see Co-existence with pre-defined VRF tables on page 48.

Restrictions

VRF table name

The name of a user-defined VRF table must be unique on the device. It may consist of up to a maximum of 30 alphanumeric and underscore characters.

VRF table description

The description of a pre-defined VRF table can only be changed on the device. If the description is changed on the device, the description will not be affected by a propagated configuration update. If you want to transfer control of the VRF table description to Service Activator, you must manually delete its description field from the VRF table on the device.



Adding route targets and external features

It is possible to manually add route targets and parameters (for example, parameters that cannot be configured by Service Activator) to a pre-defined VRF table that is controlled by Service Activator. However, these parameters are preserved only until Service Activator either deletes the VRF table or merges it into another one. This normally occurs if you change the property settings of the relevant site, in which case the manually added route targets and parameters are no longer required.

Device driver restart

If the device driver has to be restarted, it must be reminded which VRF tables were created by Service Activator and which are pre-defined. This is implemented by re-propagating the configuration to the device driver. The configuration that you propagate must be the same as that propagated to the device since the last successful transaction before the device driver failed. The device driver responds to the update by classifying VRF tables on the device whose names match those in the user interface as Service Activator controlled, and the remaining VRF tables as uncontrolled. Any route targets or unknown parameters in a VRF table are preserved. If the configuration has changed since the last successful transaction, Service Activator cannot correctly identify all VRF tables on the device.

External inbound and outbound BGP route-mapsYou can choose to implement externally defined inbound and outbound BGP route-maps on a per-interface basis, or have Service Activator generate route-maps.

Specifying an external route map will result in the following command being configured within the ipv4-vrf level:

neighbor <ip-address> route-map <map-name> in|out

where the neighbor ip-address and map-name are taken from the Route Map property page on the Site dialog box.

Pre-defined VRF import mapsYou can manually pre-define import maps for VRFs on a PE router.

A VRF Import Map allows the site to selectively import routes learned elsewhere.

Note: Use a naming scheme different from Service Activator's for external inbound and outbound route-maps. Service Activator will remove route-maps with the same naming as those which it generates when the device is unmanaged and re-managed.



Note: If different import maps are provisioned against different interfaces in a site, the site will be provisioned using multiple VRFs since only a single VRF import map applies to a VRF.

As well, VRF reduction will not occur between sites with different provisioned import (or export) maps. VRF sharing occurs only if both sites have no import maps, or have the same import maps.

A manually defined import map can be assigned to a VRF table (on the VRF Export page of the Site dialog box).

Import Map names longer than the maximum supported by the device are truncated.

Pre-defined VRF export mapsYou can manually pre-define export maps for VRFs on a PE router. The export map only allows those routes in the VRF table whose route prefixes match those specified in the export map to be advertised to other PE routers. The exported routes are tagged with an RT value specified by the export map.

A manually defined export map can be assigned to a VRF table (on the VRF Export page of the Site dialog box).

Export Map names longer than the maximum supported by the device are truncated.

Configuring an export map

The following commands provide an example of configuring an export map.

access-list 1 permit 128.1.1.1

Defines access list 1 which accepts routes with IP address 128.1.1.1

access-list 2 permit any

Defines access list 2 which accepts any routes

route-map export-map-name permit sequence-number

match ip address 1

set extcommunity rt 100:94

Export map export-map-name attaches route target 100:94 to routes specified in access list 1. The sequence-number identifies the order in which the route-map is implemented.

route-map export-map-name permit sequence-number

match ip address 2

set extcommunity rt 100:26



Export map export-map-name attaches route target 100:26 to routes specified in access list 2. The sequence-number must be a higher value than the preceding sequence-number.

If an export map is used by a management VPN, the spoke sites are not required to export route targets. To prevent management spoke sites exporting route targets, set Spoke to None for the spoke site’s export policy route target on the MPLS page in the VPN dialog box, or alternatively, use the pre-defined export map configuration shown in the following example:

export map ‘ExpMapCust#1’

route-target export 1:1111



where ExpMapCust#1 is a pre-defined export map used by both management and customer VPN sites; 1:1111 is the route target of the management hub site, 1:1394 and 1:1614 are the route targets of the customer sites in the VRF table of each spoke site.

ip access-list extended ExpMap_Mng

deny ip 192.168.65.0.0.0.0.255 any

deny ip 20.20.20.0.0.0.0.255 any

permit ip any any

where deny ip 192.168.65.0.0.0.0.255 any rejects matching routes to the management hub site, deny ip 20.20.20.0.0.0.0.255 any rejects routes to the customer LAN, permit ip any any accepts all other routes.

route-map ExpMapCust#1 permit 10

match ip address ExpMap_Mng

set extcommunity rt 1:1394 1:1614

Export map ExpMapCust#1 attaches route targets 1:1394 and 1:1614 to routes permitted by access list extended ExpMap_Mng. Note that the management hub site route target 1:1111 is not attached to these routes.

Pre-defined prefix list filtersWhen eBGP is used as the CE-PE protocol, the number of routes that are received from, or sent to, a CE router can be selectively reduced using a manually pre-defined prefix list installed on the neighboring PE router. Routes whose prefixes match those in the prefix list will either be allowed or rejected by the PE router depending on their designation in the prefix list. You need to specify in the user interface that the prefix list is required to only filter routes that are either incoming (CE to PE) or outgoing (PE to CE).



A pre-defined prefix list can be used instead of an access list for configuring a pre-defined export map described in Pre-defined VRF export maps on page 33.

Creating a prefix list

You configure a prefix list using the commands described below in router configuration mode. You apply a pre-configured prefix list filter to a site by entering the name of the prefix list in the Prefix filters In or Out fields on the EBGP Adv. page of the Site dialog box.

If a route prefix received by the PE matches a prefix in the prefix list, that prefix will either be accepted or rejected depending on whether the entry is designated as permit or deny. The following conditions also apply:

A prefix is denied if it cannot be matched with any prefixes in the prefix list

If a prefix matches several prefixes in the prefix list, the prefix with the lowest sequence value is used

This command adds a single entry to a prefix list:

ip prefix-list list-name [seq sequence-value] deny|permit prefix|prefix-length [ge ge-value] [le le-value]

Sequence values are automatically generated by default. You only need to specify a sequence value if the automatic generation of sequence values is disabled. For more information, see Sequence values on page 35.

You must specify either deny or permit for the specified prefix to be either allowed or rejected by the PE router.

ge and le values specify a prefix length range, where:prefix length < ge-value <= le-value <= 32.

Examples: 198.0.0.0/8 ge 16 le 16 specifies all prefixes in the range 198.0.0.0/8 to 198.0.0.0/16.

198.0.0.0/0 ge 16 le 24 specifies all prefixes in the range 198.0.0.0/16 to 198.0.0.0/24.

If only the ge-value is specified, the prefix range is from ge-value to 32.

If only the le-value is specified, the prefix range is from the prefix-length-value to le-value.

Sequence values

Sequence values are generated automatically by default, but generation can be disabled using:

no ip prefix-list sequence-number



Sequence values are, by default, automatically generated in increments of 5, so that the first list entry has a value of 5 and the next entry has a value of 10 and so on.

Examples of configuring a prefix list:

Deny routes with prefixes 196.0.0.0/8 and prefix lengths greater than 25 up to 32 in network 192/8:

ip prefix-list filter1 deny 192.0.0.0/8 ge 25

Deny all routes in Class A network 22/8 by specifying prefix lengths from /8 to /32:

ip prefix-list filter1 deny 22.0.0.0/8 le 32

Deny routes with prefixes 100.70.1/ with prefix lengths from /24 to /25:

ip prefix-list filter1 deny 100.70.1.0/24 ge 25

Permit route 36.0.0.0/8:

ip prefix-list filter1 36.0.0.0/8

Permit routes with prefix lengths of 8 to 24; make list entry sequence value 5:

ip prefix-list filter1 seq 5 permit 0.0.0.0/0 ge 8 le 24

Manually pre-configured multi-AS VPNsYou can use Service Activator to manage manually pre-configured multi-AS VPNs.

PE routers in the same AS

iBGP peering must be manually pre-configured between PE routers that reside in the same AS.

For example:

router bgp 65057

no synchronization

no auto-summary

neighbor 10.52.0.1 remote-as 65057

neighbor 10.52.0.1 update-source 10.52.20.1

When managing multi-AS VPNs with Service Activator, the domain-level property Configure iBGP Peering must be de-selected in the user interface. For more information, see the Configuring VPN Services guide.



address-family vpnv4 unicast

neighbor 10.52.0.1 activate

neighbor 10.52.0.1 next-hop-self

neighbor 10.52.0.1 send-community extended

exit

Inter-AS PE routers

eBGP peering must be manually pre-configured between PE routers where each PE router resides in a different AS.

For example:

router bgp 65057

no synchronization

no auto-summary


neighbor 10.52.0.1 ebgp-multihop

neighbor 10.52.0.1 update-source 10.52.20.1

address-family vpnv4 unicast



neighbor 10.52.0.1 send-community extended

exit

Manual pre-configuration for SAAIf you wish an SNMP trap to be sent from a device when a threshold is breached, you must configure the trap type and destination:

snmp-server enable traps rtr

snmp-server host host [traps|informs][version {1 | 2c | 3 [auth | noauth | priv]}] community-string [rtr]

Configuring CEF for NBARPolicy maps, NBAR and WRED on some platforms requires CEF or dCEF to be enabled on the router. Since this may affect other aspects of router operation, the Cisco device driver does not configure it automatically.



To configure CEF:

ip cef

To configure dCEF:

ip cef distributed


Cisco IOS Device Support Guide – Fourth Edition Configuration of MPLS VPNs

Chapter 5

Configuration of MPLS VPNs

This chapter describes how Service Activator configures MPLS VPNs on Cisco devices. It includes the following:

A summary of the pre-requisites for configuring MPLS VPNs

Configuring VRF tables and route targets

Configuring BGP network and aggregate statements

Configuring PE-PE peering with iBGP and EIGRP

Configuring PE-CE routing using eBGP, OSPF, RIP and static routing


Configuration of MPLS VPNs Cisco IOS Device Support Guide – Fourth Edition

Pre-requisites for VPN configurationThe Cisco device driver configures the PE routers that define the membership of a VPN. The information set up on each PE router defines the VPNs to which connected sites belong and the routes to and from these sites that are to be distributed throughout the VPN.

Service Activator does not configure the CE routers or the provider core routers.

Before setting up VPNs you should ensure the following:

All routers are appropriately pre-configured

Domain-level parameters are appropriately set

All routers and their interfaces within the VPN are correctly assigned roles

Pre-configuration of routersSome pre-configuration of PE and P routers is required. For example, MPLS must be enabled and BGP must be configured. For full details of the pre-configuration required, see Mandatory manual configuration for MPLS VPNs on page 28.

Domain-level parametersA number of BGP parameters may be set up at the domain level on the VPN BGP, ASN and VPN MPLS property pages of the Domain dialog box:

You can specify whether you want Service Activator to set up iBGP peering on the PE devices. See Co-existence with previously configured iBGP on page 55.

The default is for Service Activator not to configure iBGP peering. If you leave this setting off, iBGP peering must already be configured correctly on your devices.

If Route Reflectors are used, iBGP peering must be deselected.

If Service Activator is to manage multi-AS VPNs, iBGP and eBGP peering must be configured on devices and Service Activator’s configure iBGP peering capability must remain deselected. See Manually pre-configured multi-AS VPNs on page 36.



Set up the ASN for the domain (set on the ASN property page of the Domain dialog box).

You can enable Allow AS in which allows PE devices to re-advertise route prefixes containing one or more instances of the same ASN in the AS_PATH attribute. You specify the maximum number of instances allowed for an incoming prefix to be permitted by the PE device. The PE device denies incoming prefixes having more than the number of instances specified. For more information, see Allow AS in on page 57.

You can enable AS Override which allows PE devices receiving route prefixes from the core, whose AS_PATH attributes have ASNs matching the ASN of their neighboring CEs, to substitute those ASN instances with the ASN of the service provider network. Prefixes with the substituted ASNs are then re-advertised to neighboring CEs. For more information, see PE-CE configuration using eBGP on page 57.

You can enable load-balancing between iBGP peers by setting a value for Maximum Paths. This controls the number of alternative routes to a given prefix that are maintained in a device’s routing table. By default, this option is disabled and no alternatives are held. To enable load-balancing, you specify the number of routes that are maintained.

You can define the community attributes (Extended and/or Standard) that are used for routes distributed from PE devices, both for PE-PE peering and PE-CE. See PE-PE community attributes on page 55 and PE-CE community attributes on page 58.

You can specify that the identity of iBGP peers and the integrity of data exchanged during iBGP sessions is to be verified using MD5 Authentication. See MD5 authentication on page 56.

OSPF Authentication of distributed route information is also supported at the per-interface level. See PE-CE configuration using OSPF on page 71.

You can specify which interface is configured as the loopback interface on devices in this domain. The default is 0.

For full information, see the Configuring VPN Services guide.

If there is no ASN already configured on the device, Service Activator configures the device with the ASN specified in the user interface. If an ASN is already configured on the device, Service Activator ignores the ASN specified in the user interface and uses the one found in the configuration instead. This enables Service Activator to support multi-AS VPNs.



Discovery and role assignmentIn an MPLS domain, the core provider network is assumed to use public addresses. All CE routers are assumed to use private addresses. An IP address or DNS name must be specified in order to discover all devices in the domain.

All devices within the network must be assigned the correct system-defined roles (that is, PE routers must be classified as Gateway devices, P routers as Core devices and CE routers as Access devices). Interfaces to be configured must also be assigned the correct roles. You can assign user-defined roles as well as the system-defined roles. The recommended way of assigning roles is by means of role assignment rules, which automatically assign roles during device discovery.

For full information on role assignment rules, see the Network Discovery and Basic Setup guide.

Configuring VRF tables and route targetsThe Cisco device driver configures the appropriate VRF (VPN Routing/Forwarding Instance) tables and associated route targets on the PE devices.

Each customer site connects to a PE interface or sub-interface. This interface is assigned to a VRF table, which defines the VPN membership of a customer site. (Interface-less VRFs are possible. See Interface-less VRFs on page 49.)

VRF tables hold routing information that defines how packets from a given site are routed across one or more VPNs to other sites. They are private routing tables containing IPv4 routes that have been learnt from CE routers using eBGP, RIP or OSPF and any explicitly defined static routes. They do not form part of the PE router’s own routing tables.

On the Service Activator user interface, data specific to the customer site and the PE interface are set up on the Site dialog box. Data relating to the VPN and its connectivity are set on the VPN dialog box.

VRF tablesThe following command is configured at the root level. The vrf-name is generated automatically unless a user-specified name has been defined.

ip vrf vrf-name

The following command is implemented on the appropriate interface to associate it with the specified VRF table:

ip vrf forwarding vrf-name



There is a separate set of commands for each VRF table configured on the device. Additional commands described in this section are configured within the VRF section.

VRF tables are generally given default names of the form IPSA_RD-number. However, you can define specific names for VRF tables on selected interfaces if you do not want to use the system-calculated ones. You must ensure that the name you enter does not match any user-defined VRF tables that may exist on the device if you want those VRF tables to be preserved. (See Co-existence with pre-defined VRF tables on page 48).

VRF names must be a maximum of 32 alphanumeric characters (31 if OSPF is used for the PE-CE link) and must be unique on the PE device.

By default, Service Activator automatically generates a site-specific VRF table name for each site that participates in a VPN. However, if you wish to apply the same RD number to all sites that participate in the VPN, the same VRF name will also apply (auto-generated or user-defined). See RD number per VPN on page 44.

Route distinguishersCustomer networks typically use private addresses. Addressing overlaps between customers may occur when they connect to the public Internet or to the provider’s NOC. To avoid this problem, iBGP prefixes a site identifier, known as a route distinguisher or RD number, to each route associated with a particular site. This ensures that VPN routes are unique within the Internet.

The new route is part of the VPN-IPv4 address family – a BGP address family added as an extension to the BGP protocol.

The RD number in Cisco IOS Software release 12.0 and later, can be configured in three different formats called decimal, hexadecimal, and AA:NN. By default, IOS uses the older decimal format. To configure and display in AA:NN, where the first part is the AS number and the second part is a 2-byte number, use the ip bgp new-format global configuration command.

Service Activator normally generates RD numbers automatically, using the ASN for the high-order-no and the unique system ID of the Site object for the low-order-no. For example:

1:3125

However you can override these defaults and specify your own RD numbers if you wish. The following command is configured at the VRF level:



rd rd-number

RD number per VPNBy default, Service Activator automatically generates a site-specific VRF table name and RD number for each site that participates in a VPN.

However, you can override the Service Activator default by specifying at the VPN level that the same VRF table name and RD number is applied to all sites that participate in the VPN. You can choose whether to use Service Activator-generated values or specify your own VRF table name and/or RD number. Sites that participate in the VPN must be set to inherit VRF/RD details from the VPN.

A site may be set to inherit VRF/RD details and be a member of more than one VPN that specifies VPN-wide VRF/RD details. In this situation, Service Activator’s default behavior is to generate VRF/RD details for the site to avoid any conflict. However, it is possible to specify that, where a site inherits VPN-wide VRF/RD details from multiple VPNs, user-defined details specified at site level are used instead.

On the user interface, these settings are specified on the VRF property page of the Site dialog box.

If a single RD number/VRF table name is set per VPN, the settings for VRF re-use/reduction must also be set at VPN level. See VRF reuse/reduction on page 47.

VPN topology and route targetsThe connectivity of the VPN can be one of the following:

Mesh – all sites have connectivity to all other sites

Hub and Spoke – one or more hub sites has access to all other sites; spoke sites can access the hub only

Management – works in the same way as hub and spoke, but is used to ensure connectivity to CE devices

Note that Service Activator does not validate that manually-generated RD numbers are unique, although system-generated RDs are always unique. This is to ensure compatibility with user-defined configuration.

Using a single RD number for all sites in a VPN is suitable only where a site belongs to one intranet VPN. If the site may become a member of an extranet VPN in the future, this method is not recommended.



When setting up a VPN, you have to set its connectivity, and for a hub and spoke or management VPN, select the hub site(s).

To create a fully-meshed VPN, each site’s VRF table imports and exports the same routes. In a hub and spoke or management VPN the VRF table at the hub site imports routes from all other hub sites and all spoke sites, and exports routes to other hub sites and to the spoke sites. VRF tables at spoke sites export routes only to the hub site and import routes only from the hub site.

A route target (RT) identifies a set of sites within a VPN to which a PE device distributes routes.

Route targets are used to create the VPN topology. Each VPN must have a unique route target number.

The RT is implemented as a BGP extended community. A BGP community groups a set of destinations that share a common property – in this case, a set of routes that are to be distributed to a set of CE sites. The RT is added to the route by the ingress PE device and used by the egress PE device to determine whether a received route is destined for a VPN that the PE services.

Service Activator creates one or more BGP communities per VPN, depending on the VPN topology:

If the VPN is fully-meshed, Service Activator creates one community – every site receives routing information from all other sites

If the VPN is a hub and spoke or management VPN, Service Activator creates two communities

In a hub and spoke topology, there are effectively two ‘sets’ of devices – one set that consists of the hub site or sites and another set consisting of the spoke sites. Routes from the spoke sites are only distributed to the hub site(s), routes from the hub site(s) are distributed to all spoke sites and imported by all other hub sites.

The RT number can be in either of the following formats:

32-bit IP address:16-bit number

16-bit ASN number:32-bit number

Service Activator normally generates RT numbers automatically, using the ASN for the high order number and the unique system ID of the VPN for the low order number. For example:

20:4926

In a hub and spoke VPN topology, Service Activator generates two RT numbers – one for the hub site(s), generated as indicated above, and one for all spoke sites, generated by incrementing the hub low order number by 1.



If you wish, you can specify your own RT numbers for hub, spoke or fully-meshed sites within a VPN if you do not want to use the system-generated default values. You can easily reassign RT numbers to sites within a VPN, if for example, it has been imported from a different system or it is to be exported to a different system.

You can specify any number of RT values per VPN and specify whether a value is used for VRF import, VRF export, or neither for hub, spoke and fully-meshed behaviors.

The route-target command configures a PE’s VRF table with an import and an export policy which allow RT values to be specified for VRF import and VRF export. Routes whose iBGP VPNv4 extensions have RT values matching those in the import policy are imported to the VRF table. All routes exported from the VRF table will have their VPNv4 extensions attached with RT values specified in the export policy ensuring that these private routes are only advertised to neighboring PE routers that share the same VPNs.

The following commands are configured at the VRF level:

route-target export rt-number

This command defines the routing information to be exported to the target VPN. The RT number identifies the VPN to which routes are exported.

route-target import rt-number

This command defines the routing information to be imported from the target VPN. The RT number identifies the VPN from which routes are imported.

Limiting the number of imported routesYou can specify the maximum number of routes that can be imported into the VRF table. Two alternative actions can be defined:

A warning message can be generated if the number of imported routes reaches the maximum, but with routes continuing to be accepted.

A warning message can be generated when the number of routes reaches a specified percentage of the maximum, with no further routes accepted when the maximum is reached.

Problems occur if spoke sites with separate VRF tables on a single PE device are added to a fully-meshed VPN while the device driver is down. The next time a transaction is committed after the driver has re-started the PE device is put into the ‘Intervention Required’ state and an error is raised. The problem does not occur if the VPN topology change is made after the device driver has re-started.



In Service Activator, the maximum route parameters can be set at domain-level, to apply by default to all VRF tables, and can be overridden for individual VRF tables.

If this option is set, the following command is configured at the VRF level:

max-routes maximum [threshold | warn-only]

where:

VRF reuse/reductionA VRF table is set up on the device for each PE interface that is a member of a VPN. However, if multiple VRF tables contain exactly the same routes (for example if one site connects to two interfaces, or there are two sites that are members of the same VPN) Service Activator will normally reduce them to just one, in order to minimize resource usage. This is known as VRF re-use or VRF reduction.

In some cases automatic VRF re-use may not be required. For example, you may want to provision dual links to customer sites in order to implement load balancing, requiring a separate VRF table for each connecting interface, or to reduce the impact of future re-configuration. In this case you can override VRF re-use by specifying that particular interfaces are always to have their own VRF table (the Force VRF install option). You can specify that other VRF tables are allowed to be merged with this VRF table by selecting Shareable VRF.

On the user interface, the Force Install and Shareable options can be selected per interface on the VRF property page of the Site dialog box.

Note that if you are setting up a single VRF table name/RD number per VPN, this setting is made at the VPN level. See RD number per VPN on page 44.

maximum specifies the maximum number of routes that can be imported to PE router VRF tables.

threshold specifies the percentage of the maximum at which a log warning message is generated. The VRF table will not accept any more routes if maximum is exceeded.

warn-only specifies that if the maximum is exceeded, a warning is generated but the VRF table continues to accept routes.

Specifying a user-defined VRF table name affects how Service Activator performs VRF reduction. Where system-defined VRF table names are used, VRF reduction is based on the site’s RD number and a site with a lower RD number takes precedence over a site with a higher RD number. Where user-defined VRF table names are used, Service Activator performs VRF reduction based on table names.



Co-existence with pre-defined VRF tablesIf an MPLS VPN has already been manually configured on a network, Service Activator is able to work with the pre-configured VRF tables that exist on devices. You can choose how Service Activator handles these tables:

Ignore – Service Activator leaves the pre-configured VRF table ‘as is’ and does not update it

Assume control of the VRF table and preserve existing content – Service Activator controls and updates the VRF table but leaves pre-existing content

Assume control of the VRF table but remove existing content – Service Activator controls and updates the VRF table and removes any pre-existing content

Service Activator’s handling of pre-configured VRF tables is controlled by several parameters which can be defined per site or per VPN.

* If a manually pre-configured VRF table has an RD that matches the RD of another manually pre-configured VRF table that is subsequently controlled by Service Activator, the first pre-configured VRF table is replaced by the second pre-configured VRF table.

† There is a small possibility that Service Activator may generate the same RD as that of the pre-configured VRF table. In this case, the VRF table will be controlled by Service Activator and its contents are preserved.

If the name of a VRF table follows the conventions of automatically generated VRF table names (e.g. IPSA_*:*) then it will never be preserved. If Service Activator does not require that table in the router then it will be removed.

Site or VPN property

Manually pre-configured VRF

No controlControl and

preserve contentControl and

remove content

VRF table name Use Service Activator VRF name

Specify pre-defined name

Specify pre-defined name

Route distinguisher

Use Service Activator RD*

Specify pre-defined RD

Use Service Activator RD†

Service Activator’s normal behavior is to maintain pre-defined VPN configuration. However, to automatically remove all VPN configuration on PE routers that are not controlled by Service Activator, you can use the -DisableVpnPreservation command-line parameter.



Previously-defined VRF import mapsYou can apply a user-defined import map to the export policy configured by Service Activator. A VRF Import Map allows the site to selectively import routes learned elsewhere.

Note: If different import maps are provisioned against different interfaces in a site, the site will be provisioned using multiple VRFs since only a single VRF import map applies to a VRF.

As well, VRF reduction will not occur between sites with different provisioned import (or export) maps. VRF sharing occurs only if both sites have no import maps, or have the same import maps.

Previously-defined VRF export mapsYou can apply a user-defined export map to the export policy configured by Service Activator.

The export map exports only the VRF table routes whose prefixes match those specified in the export map to other PE devices. The export map tags these routes with only the RT numbers of sites that need to receive those routes.

Export Map names longer than the maximum supported by the device are truncated.

For details on setting up an export map, see Pre-defined VRF export maps on page 33.

Interface-less VRFsService Activator supports the indirect creation of interface-less VRFs and therefore interface-less Sites. An interface-less VPN site models a VRF on a router where no interface points to the VRF.

For complete details, refer to the topic Interface-less VRFs and Sites in the Service Activator Online Help.

Service Application PointsWhen an interface-less Site and VRF are created, an object called a Service Application Point is modelled in the background and linked to the Site. The Service Application Point object behaves similarly to an interface (and has a role of Access for purposes of supporting the interface-less Site and VRF) but it is not accessible or modifiable through the GUI. The PE device is displayed in the Access Points folder for the site in order to represent the Service Access Point.



Note that Service Application Point objects are exposed in the EOM and are accessible through the OSS Integration Manager interface. Refer to the OSS Integration Manager Guide for details.

Configuring BGP network and aggregate statementsNetwork statements are used to advertise networks to other routers. For the information to be advertised by BGP, a route to the specified network must be present in the routing table. This routing information can come from connected routers and dynamic routing or static routing sources.

Aggregate statements summarize routes into a single advertisement that is sent to BGP peers. Aggregate statements use the summary-only keyword to create the aggregate route (for example, 75.*.*.*) and also suppress advertisements of specific routes to all neighbors. Only the aggregate route is advertised.

To configure network and aggregate statements, access the Service Activator GUI and navigate to the Site properties dialog box, BGP Networks page and the BGP Aggregate Address page. For instructions on how to configure these pages, see the Service Activator Online Help.

How network and aggregate statements are usedNetwork and aggregate addresses can be applied to any interface in a Virtual CE configuration, as long as there is at least one eBGP interface provisioned. They can also be applied to any PE interface participating in a MPLS VPN site, regardless of the routing protocol it uses to communicate with its peer. Sites can have two or more interfaces from the same router containing different network and aggregate data. In this case, the resulting configuration would have one VRF instance and a super set of all specified networks and aggregates for those interfaces.



The following example shows how network and aggregate statements are used in the context of a BGP statement. The highlighted code displays the syntax of supported commands:

router bgp 1

address-family ipv4 vrf Gn000

redistribute connected

redistribute static

redistribute rip


neighbor 213.181.39.23 description PEXAN01 Loopback6

neighbor 213.181.39.23 ebgp-multihop 10

neighbor 213.181.39.23 password <password>

neighbor 213.181.39.23 update-source Loopback6


neighbor 213.181.39.23 soft-reconfiguration inbound

neighbor 213.181.39.23 prefix-list belgacom_in in

neighbor 213.181.39.23 prefix-list belgacom_out out

neighbor 213.181.39.23 route-map set-belgacom-route-pref in

neighbor 213.181.39.23 route-map control_to_belgacom out

default-information originate

no auto-summary

no synchronization

network 212.183.145.224 mask 255.255.255.252

network 212.183.145.228 mask 255.255.255.252

aggregate-address 212.183.145.224 255.255.255.252 summary-only


exit-address-family

exit

Sample VRF scenarioIn this scenario, interface Serial3/0 and Serial4/0 act as redundant interfaces. Through redistribution router B learns all connected routes from router A.

Instead of advertising all learned routes, router B aggregates them and advertises only the summary for 75.0.0.0/8. Router B uses the network statement to override the incomplete route 32.0.0.0/8 learned from router A.



Router A - CE

Current configuration:

hostname RouterA

!

interface Loopback1

ip address 66.0.0.1 255.255.255.255

no clns route-cache

!

interface FastEthernet 0

ip address 75.0.0.1 255.255.192.0

ip route-cache

!

interface FastEthernet 1/0

ip address 75.0.65.1 255.255.192.0

ip route-cache

!


ip address 75.0.129.1 255.255.192.0

ip route-cache

!


ip address 75.0.197.1 255.255.192.0

ip route-cache

no clns route-cache

!


ip address 32.0.0.1 255.255.255.0

ip route-cache

no clns route-cache

!

interface Serial3/0

ip address 21.0.0.1 255.255.255.252

encapsulation hdlc



no clns route-cache

!

interface Serial4/0

ip address 21.0.0.5 255.255.255.252

encapsulation hdlc

no clns route-cache

!

router bgp 40



no auto-summary

no synchronization

!

Router B - PE

Current configuration:

hostname RouterB

!

ip vrf test

rd 1:1072


route-target import 1:1212

!

interface Loopback1

ip vrf forwarding test

ip address 66.0.0.2 255.255.255.255

no clns route-cache

!

interface Serial3/0


ip address 21.0.0.2 255.255.255.252

encapsulation ppp

no clns route-cache

!

interface Serial4/0




ip address 21.0.0.6 255.255.255.252

encapsulation hdlc

!

router bgp 1

address-family ipv4 vrf test


!


network 32.0.0.0 mask 255.0.0.0


no auto-summary

no synchronization

exit-address-family

Configuring PE-PE peering with iBGPiBGP is the protocol used for communication of VPN routes between PE devices in an MPLS VPN. In order for devices to exchange routing information, an iBGP session must be configured between the PE devices that comprise the VPN.

If the domain-level parameter Configure IBGP Peering is selected on the VPN BGP property page of the Domain dialog box, Service Activator configures adjacencies between PE devices depending on the VPN’s topology:

For fully-meshed VPNs, Service Activator creates a full mesh of iBGP adjacencies

For hub and spoke or management VPNs, Service Activator configures iBGP peering between each spoke and the hub site(s)

The following command is configured at the VRF level to configure iBGP:

router bgp asn

The following commands are entered at the bgp level:

neighbor ip-addr remote-as asn

This command is required for each PE router with which the router will peer. It specifies that the PE router is a member of the BGP routed network and identifies the address to which routing updates should be sent. The IP address is the loopback address of the PE router, and the ASN is the ASN of the core network.



neighbor ip-addr update-source loopback-if

This command tells BGP that the PE’s loopback interface is used for the iBGP neighbor TCP connection. The IP address is the IP address of the neighbor PE.

neighbor ip-addr next-hop-self

Advertises the local PE router as the next hop for an iBGP peer.

The following commands are configured at the root.bgp.vpnv4 level:

neighbor ip-addr activate

Activates iBGP peering in the vpnV4 address-family.

PE-PE community attributesYou can specify that routes advertised to the neighbor CE router contain the standard community attribute as well as the extended community attribute which is configured by default. The following commands are configured at the bgp level:

neighbor ip-addr send-community standard

neighbor ip-addr send-community extended

The extended community attribute, which includes Route Target and Site Of Origin, is always configured and should not be removed. The standard community attribute is optional. If both community attributes are required, both commands are configured separately rather than the send-community both command.

Co-existence with previously configured iBGPIf iBGP peering is already installed on PE routers, for example if Route Reflectors are used, the existing configuration can be preserved. On the Service Activator user interface, this is controlled by deselecting the Configure IBGP Peering option at the domain level.

Maximum pathsYou can enable load-balancing between iBGP peers by setting a value for Maximum Paths. This controls the number of alternative routes to a given prefix that are maintained in a device’s routing table. By default, this option is disabled and all identical routes learned from peer devices are dropped. To enable load-balancing, you can specify the number of routes that are maintained.

Note that if Configure iBGP Peering is deselected, the system will leave all iBGP configuration on the device untouched. Service Activator will not configure any iBGP commands, so you should ensure all configuration is correct.



In Service Activator, the maximum paths parameter is set at domain-level, and applies by default to all VPNs in the domain.

If this option is selected, the following command is configured at the bgp level:

maximum-paths max-paths

where:

MD5 authenticationThe identity of iBGP peers and the integrity of data exchanged during iBGP sessions can be verified using MD5 Authentication. This option uses the MD5 digital signature algorithm and a specified key of up to 255 characters to generate a checksum of the iBGP data that is to be sent from a PE device to its peer. The iBGP data and its checksum are then sent to the peer device using TCP. The recipient device uses MD5 and the same key to generate a checksum of the received iBGP data. If both checksums match, the identity of the sender and the integrity of the received iBGP data is verified.


neighbor ip-addr password private-key

Configuring IP unnumbered Private PE IP addressesService Activator supports IP unnumbered Private PE addressing for point-to-point IP interfaces linked to VPN sites on Cisco devices. This feature allows you to enable IP on an interface and use it in a VPN without having to assign an explicit Private PE IP address and mask. Instead, the IP address of the loopback address from the device is used.

IP unnumbered is configured on the Site properties - Addressing property page by selecting the Unnumbered checkbox for the Private PE IP address for the interface in the Site. Then, select the loopback interface which will provide an IP address for the interface from the adjacent dropdown list. This configures commands similar to:

interface Serial 0

ip unnumbered Loopback 0

For complete details on IP unnumbered refer to the Configuring VPN Services Guide.

max-paths specifies the maximum number of routes that can be imported to PE router VRF tables, in the range 1-6



PE-CE configuration using eBGPIn order to exchange information to and from customer sites in the VPN, each PE router also needs to communicate with each of its external neighbors – the CE routers to which it is connected.

The effect is to advertise network reachability information between the CE and the PE, which in turn converts IPv4 addresses to VPN-IPv4 addresses for traffic passing from the CE to the PE and vice versa.

The details here explain the configuration of the PE routers using eBGP. The corresponding configuration of the CE routers is not performed by Service Activator. See CE routers on page 31.

If eBGP is used, you need to specify:

The ASN of the site

The IP address of the corresponding interface on the CE router

You can optionally specify:

The number of times the same ASN can appear in an incoming prefix for it to be accepted by the site PE or all PEs in the domain

AS Override for the site

Authentication for a PE-CE session

Send community preferences for the site

Prefix limit for the site

Prefix filter for the site

Where multiple PE interfaces are associated with a site, you can set the local preference for each interface.

On the user interface, eBGP configuration is controlled by settings on the EBGP, EBGP Adv. and EBGP Damp. property pages on the Site dialog box.

Allow AS inYou can specify the maximum number of times the same ASN is allowed to occur in the AS_PATH attribute of a route prefix advertised to the PE device for the prefix to

As well as eBGP, Service Activator supports other routing protocols as well as static routing. See PE-CE configuration using EIGRP on page 62, PE-CE configuration using RIP on page 67, PE-CE configuration using OSPF on page 71 and PE-CE configuration using static routing on page 73.



be permitted and then re-advertised to neighboring CEs by the PE device. The value can be from 0 to 10; the default is 0.

Within Service Activator, the Allow AS in value can be specified at domain level, to apply to all sites, or set up for individual sites.

If this is selected, the following command is configured:

neighbor ip-addr allowas-in n

AS overrideYou can specify that the ASN of a provider is used to override the ASN of a site. When AS override is turned on, a PE device that receives route prefixes whose AS_PATH attributes have one or more ASNs matching the ASN of its neighboring CE devices, substitute those ASN instances with the ASN of the service provider network. Prefixes with the substituted ASNs are then re-advertised to neighboring CE devices. The PE device also adds its ASN to routes before exporting them to the CE device.

This allows CE devices to accept routes that have been re-advertised by devices having the same ASN, and which would otherwise be rejected. Normally, a CE device rejects routes whose AS_PATH attribute contains ASNs matching its own ASN, to prevent routing loops.

Within Service Activator, AS override can be specified at domain level, to apply to all sites, or set up for individual sites.

If this option is selected, the following command is configured:

neighbor ip-addr as-override

PE-CE community attributesYou can specify that routes advertised to the neighbor CE router contain the standard or extended community attribute or both.

The following commands are configured:

neighbor ip-addr send-community standard

neighbor ip-addr send-community extended

Note that if both community attributes are selected, both commands are configured separately rather than the send-community both command.



AuthenticationThe identity of eBGP peers and the integrity of data exchanged during eBGP sessions can be verified using authentication. If this option is selected, the following command is configured at the ipv4-vrf level:

neighbor ip-addr password private-key

Local preferenceWhere multiple PE interfaces are associated with a site, the local preference for an interface can be set. The preference value may be between 1-4294967295, and the higher the value the higher the priority. The default is Router Default (100). Local preference is configured by means of a route-map, which can include other conditions.

neighbor ip-addr route-map route-map-name in

route-map route-map-name permit sequence-number

set local-preference value

Site of originSite of Origin (SOO) is configured automatically for sites that have more than one CE to PE connection. It identifies the site from which the PE router learned the route and prevents routing loops from occurring when a site is multi-homed. SOO is configured by means of a route-map.

neighbor ip-addr route-map route-map-name in

route-map route-map-name permit sequence-number

set community extended soo soo-id

The unique ID is automatically generated by Service Activator.

Route prefix limits and filtersIf a prefix list file is specified, routes whose prefixes match those in the prefix list will either be allowed or rejected by the PE router depending on their designation in the prefix list.

neighbor ip-addr prefix-list list-name in

neighbor ip-addr prefix-list list-name out

The in and out arguments specify that the prefix list file applies to either incoming routes (CE-PE) or outgoing routes (PE-CE).

You can specify a maximum number of eBGP IP route prefixes that can be received by the PE router from its CE neighbor. You can specify a threshold percentage of the



maximum at which the PE router generates a warning log message. The PE router terminates the peering if maximum is exceeded. Alternatively you can request that a warning is issued, but routes are still accepted and the peering is not terminated.

neighbor ip-addr maximum-prefix maximum threshold

neighbor ip-addr maximum-prefix maximum warning-only

If you specify a maximum at which the PE router terminates the peering, you can optionally also specify a delay after which the PE router will automatically restart the peering.

neighbor ip-addr maximum-prefix maximum threshold restart delay-in-minutes

eBGP load sharingYou can enable load-balancing between eBGP peers by setting a value for Maximum Paths. This controls the number of alternative routes that are maintained in a device’s routing table. By default, this option is disabled and all identical routes learned from peer devices are dropped. To enable load-balancing, you can specify the number of routes that are maintained.

In the Service Activator user interface, the eBGP maximum paths parameter is set on the EBGP Adv. property page of the Site dialog box.

If this option is selected, the following command is configured at the IPv4 level:

maximum-paths eibgp max-paths

where:

Note that multi-path load sharing can affect VRF reduction – there is no VRF reduction if different Maximum Paths values are set on different interfaces.

Route dampeningRoute dampening is a mechanism that attempts to minimize network instability by suppressing the advertisement of poorly-behaved routes. Penalties are applied when a route is withdrawn, readvertised or changed. When a predefined penalty limit is reached, further advertisement of the route is suppressed. The penalty is reduced according to a defined “half-life” setting, and once the penalty decreases below a limit, the route can be readvertised.

Note that BGP dampening is applied globally on a router; that is, applying it to one IPv4 address family effectively applies it to all address families. (This is true even if it is implied that each address family can have its own dampening parameter set.)

max-paths specifies the maximum number of paths allowed, in the range 2-6.




bgp dampening half-life reuse suppress max_suppress_time

where:

Route redistribution into eBGPService Activator allows you to control the redistribution of routes into BGP from OSPF, RIP, static routing and directly connected networks.

Redistributing routes between protocols brings with it the risk of introducing routing loops and convergence problems. However, you can filter and refine the redistribution of routes by associating a manually pre-configured route map with redistributed routes.

The default route may also be distributed via iBGP to peers within the VPN.

Where a site is multi-homed, you can specify route distribution metrics per interface.

Route redistribution is set up on the Redist property page of the Site dialog box. You can specify the protocol-specific metric to apply to static routes redistributed into BGP, and define a manually pre-configured route map to apply to static routes redistributed into BGP

Depending on the route redistribution options selected, the following commands can be configured by Service Activator:

redistribute ospf match internal external 1 external 2 metric metric route-map route-map-name

Redistributes OSPF routes. The match commands determine what type of updates are distributed. These are configured to preserve weighting values previously allocated.

redistribute rip metric n route-map route-map

redistribute static metric n route-map route-map-name

redistribute connected metric n route-map route-map-name

half-life Time, in minutes, at which a penalty applying to a route is decreased by half. Range is 1-45.

reuse When the penalty applying to a route falls below this value, the route is unsuppressed. Range is 1-20000.

suppress A route is suppressed when its penalty exceeds this limit. Range is 1-20000.

max_suppress_time The maximum time, in minutes, that a route can be suppressed. Range is 1-20000.



Redistributes RIP, static routes and connected routes respectively into BGP. If metric values are not specified they default to 0 in all cases. Any route map specified must already be configured.

default-information originate

Specifies that the default route (0.0.0.0) is distributed via iBGP to peers within the VPN. Without this command, BGP will not propagate the default route.

Soft ReconfigurationSelecting the Soft Reconfiguration checkbox enables the EBGP soft reconfiguration setup command on Cisco and Juniper E-series devices.

Note that selecting this checkbox does not issue a soft reconfiguration reset action — it enables the support for the reset action.

PE-CE configuration using EIGRPService Activator supports the configuration and activation of Enhanced Interior Gateway Routing Protocol (EIGRP) as a routing protocol between PE and CE devices for MPLS VPN sites.

EIGRP may be deployed in conjunction with MPLS VPNs. As typically deployed, the MPLS VPN acts as a zero cost route distributing EIGRP routes as internal routes between the VPN sites, each of which is running EIGRP as the PE-CE routing protocol. This allows all sites to participate in a single routing domain represented by a single EIGRP ASN.

EIGRP route attributes (such as metrics), are transported across iBGP using community attributes, thereby enabling ‘tunnelling’ of EIGRP routes across MPLS VPNs.

For multi-homed sites, routing loops are prevented through the use of a Site of Origin which uniquely identifies the site from which a route originated, thereby allowing such routes to be ignored if they are re-advertised back to the original site. This functionality also may be applied when ‘backdoor’ routes exist between sites.

The details here explain the configuration of the PE routers using EIGRP. The corresponding configuration of the CE routers is not performed by Service Activator. See CE routers on page 31.

As well as EIGRP, Service Activator supports other routing protocols as well as static routing. See PE-CE configuration using eBGP on page 57, PE-CE configuration using RIP on page 67, PE-CE configuration using OSPF on page 71 and PE-CE configuration using static routing on page 73.



Cisco IOS support for EIGRPMPLS VPN Support for EIGRP between PE and CEs, and EIGRP MPLS VPN PE-CE Site of Origin support starts with certain versions of Cisco’s IOS. Refer to the Release Notes for specific IOS release numbers.

Configuring EIGRPIf EIGRP is used, you need to specify:

The ASN of the site

The IP address of the corresponding interface on the CE router

Configuration of router EIGRP process (EIGRP-ASN), which can either be done at the site level or inherited from the parent VPN

You can optionally specify:

Redistribution metrics and policy (route-map reference)

Site of Origin configuration including specification of Site of Origin, or selection of automatic generation, specification of Route Map Name

MD5 authentication using a pre-configured Key Chain, which can either be done at the site level or inherited from the parent VPN

Note: Although MD5 authentication is not supported on the Cisco IOS device driver, it is supported on the Cisco IOS cartridge managed by the Network Processor. Specifying MD5 parameters through the Cisco device driver will cause the object model validation to fail, whereas specifying the parameters with the Network Processor will allow object model validation.

In the Service Activator user interface, EIGRP configuration is controlled by settings on the Connectivity, EIGRP and Redist property pages on the Site dialog box.

Configuration of router EIGRP process EIGRP routing instances for a VPN are provisioned using vrf address families within a parent EIGRP instance identified by an EIGRP ASN. Since multiple EIGRP instances may be provisioned on a device (and it is not assumed that one has been provisioned) it is necessary to explicitly specify the EIGRP instance within which (all) vrf address families will be provisioned. Therefore, the EIGRP ASN value to be used for vrf-address-families is specified on a per-device basis.

When configuring EIGRP on a Site, you can configure the site to inherit the EIGRP ASN specified for the VPN (on the VPN dialog box, Connectivity property page), or you can override the inherited ASN and specify one for the site.



EIGRP Site of Origin is implemented as an explicit provisioning option instead of being automatically configured when multiple interfaces are included in a site (as is the case for BGP).

Note that auto-summarization is always disabled. Also, note that logging is always enabled.

The following commands are configured for EIGRP:

neighbor ip-addr as-override

router eigrp <router-as-number>

!

address-family ipv4 vrf <vrf-name>

redistribute bgp <bgp-asn> metric <bw> <delay> <reliability> <load> <mtu> [route-map <route-map-name>]

network <PE-CE subnet> 0.0.0.3

no auto-summary

autonomous-system <VPN-site-AS>

eigrp log-neighbor-changes

exit-address-family

MD5 authenticationEIGRP authentication is provisioned using key chains. Since key chains are not used uniquely for EIGRP, only a reference to a pre-existing Key Chain is supported within the VPN Site. This allows Key Chains to be defined manually on each device, through a script, or provisioned using a policy based mechanism. To simplify the provisioning of EIGRP authentication, the Key Chain reference is supported at the VPN level and may be inherited by each site in the VPN.

If this option is selected, the following commands are configured:

interface xxxxxx

…

ip authentication mode eigrp <vrf-address-family-eigrp-asn> md5

ip authentication key-chain eigrp <vrf-address-family-eigrp-asn> <key-chain-name>



Site of originThe enabling of Site of Origin configuration and specification of the route-map is done on the Site dialog box. The default Site of Origin value (if generated by Service Activator) is <Site-EIGRP-ASN >:<Site OID>.

The following commands are configured for the Route Map definition:

route-map <SoORouteMapName> permit 10

set extcommunity soo <<vrf-address-family-EIGRP-ASN >:<Site OID>>

exit

The following commands are configured for the route map attachment to the interface:

interface xxxxxx

ip vrf forwarding <vrf_name>

ip vrf sitemap <SoORouteMapName>

Route redistribution into EIGRPService Activator allows you to control the redistribution of routes into EIGRP from OSPF, RIP, static routing and directly connected networks. Where a site is multi-homed, you can specify route distribution metrics per interface.

Service Activator supports route-map references for redistribution.

Route redistribution is set up on the Redist property page of the Site dialog box.

Redistribution of Connected and Static Routes into EIGRP

redistribute static metric <bw> <delay> <reliability> <load> <mtu> [route-map <route-map-name>]

redistribute connected metric <bw> <delay> <reliability> <load> <mtu> [route-map <route-map-name>]

Redistribution between BGP and EIGRP


...

redistribute bgp <bgp-asn> metric <bw> <delay> <reliability> <load> <mtu> [route-map <route-map-name>]

router bgp <router-bgp-ASN>

...

redistribute eigrp <vrf-address-family-eigrp-asn>



Redistribution between OSPF and EIGRP


...

redistribute ospf <process-id> metric <bw> <delay> <reliability> <load> <mtu> [route-map <route-map-name>]

router ospf <process-id>

...

redistribute eigrp <vrf-address-family-eigrp-asn> metric <metric> subnets

Redistribution between RIP and EIGRP


...

redistribute rip metric <bw> <delay> <reliability> <load> <mtu> [route-map <route-map-name>]

router rip

redistribute eigrp vrf-address-family-eigrp-asn> metric <metric> [route-map <route-map-name>]



PE-CE configuration using RIPThis section explains the commands configured if RIP is used as the PE-CE routing protocol. The details here explain the configuration of the PE routers using RIP. The corresponding configuration of the CE routers is not performed by Service Activator. See CE routers on page 31.

When configuring RIP between PE and CE routers in an MPLS VPN, Service Activator takes different approaches for routers which support Cisco’s Default Passive Interface feature, depending on the existing RIP configuration (if any) on the device.

When no RIP configuration exists on the router, or it is set up for all interfaces to be passive by default:

In the case where no RIP configuration exists on the router, Service Activator sets up all interfaces to be passive on the router using the passive-interface default command. This puts all interfaces into passive mode unless specifically configured otherwise.

If the passive-interface default command already exists on the router, this configuration is left untouched. Again, all interfaces are put into passive mode unless specifically configured otherwise.

For specific interfaces in Service Activator, if Passive Interface is unchecked on the Site dialog box, RIP property page, the interface is configured with the no passive-interface command to turn off passive status. If Passive Interface is checked, no change is made — the default passive status for the interface is maintained.

When the router is set up for all interfaces to be active by default:

In the case where the RIP is configured on the router and interfaces are active by default, this configuration is left untouched. This puts all interfaces into active mode unless specifically configured otherwise.

For specific interfaces in Service Activator, if Passive Interface is unchecked on the Site dialog box RIP property page, no change is made — the default active status for the interface is maintained. If Passive Interface is checked, the interface is configured with the passive-interface command to enable passive status for that interface.

When no RIP configuration exists on the router, or it is set up for all interfaces to be passive by default, Service Activator installs the following configuration:

As well as eBGP, Service Activator supports other routing protocols as well as static routing. See PE-CE configuration using eBGP on page 57, PE-CE configuration using EIGRP on page 62, PE-CE configuration using OSPF on page 71 and PE-CE configuration using static routing on page 73.



router rip

Configures RIP on the specified router.

passive-interface default

Makes all interfaces passive by default (i.e. disables the sending of routing updates on all interfaces.)

network address

Specifies addresses of interfaces that run RIP.

no passive-interface {interface-type interface-number}

For interfaces on sites which have Passive Interface is unchecked on the Site dialog box RIP property page, over-rides the default setting to make the specific interface non-passive (i.e. enables the sending of routing updates on the specified interface.)

When the router is set up for all interfaces to be active by default, Service Activator installs the following configuration:

router rip version 2

Configures RIPv2 on the specified router.

network address

Specifies addresses of interfaces that run RIP.

passive-interface {interface-type interface-number}

For interfaces on sites which have Passive Interface is checked on the Site dialog box RIP property page, over-rides the default setting and specifies that the interface will not run RIP, even if selected by a network statement (i.e. disables the sending of routing updates on the specified interface.).

Route redistribution into RIPService Activator allows you to control the redistribution of routes into RIP from eBGP, OSPF, static routing and directly-connected networks.





Route redistribution is set up on the Redist property page of the Site dialog box. You can specify the protocol-specific metric and define a manually pre-configured route map to apply to routes redistributed into RIP.


redistribute bgp asn metric n route-map route-map-name

redistribute ospf metric n route-map route-map-name

redistribute static metric n route-map route-map-name

redistribute connected metric n route-map route-map-name

Redistributes BGP, OSPF, static routes and connected routes respectively into RIP. The metric value for BGP routes defaults to 1, for OSPF it defaults to 2, and for connected and static routes the metric defaults to 0.

Ignoring routes to prevent multi-home routing loopsService Activator allows RIP routing updates originating from a particular IP address to a particular site to be ignored. This is accomplished on the RIP property page of the Site dialog box using the Ignore Routes panel.

To apply, select the interface or sub-interface from the RIP configuration list, select the Ignore Routes From checkbox, and enter the IP address and mask for the route to be ignored.

Remove an existing IP address from which to ignore routes by clearing the Ignore Routes From checkbox.

When the Ignore Routes From checkbox is selected, an IP address and mask can be supplied. The site will be configured to ignore routing updates from this location. This can be used to prevent routing loops in multi-homed sites.

Note that the mask is provisioned as an inverse mask. Service Activator will translate the mask to an inverse (wildcard) mask as required by the router. A bit set to 1 in the inverse mask argument instructs the device to ignore the corresponding bit in the IP address value.

For example address 23.22.22.2 using mask 24 will be provisioned as 23.22.22.0 with an inverse mask 0.0.0.255 on the device.

Service Activator configures the Ignore Routes setting on the device by setting an administrative distance of 255 for the IP address / mask specified. To accomplish this, the following command is configured on the site’s interface:

distance 255 <ip-address> <wildcard-mask>

For example:



router rip

version 2

!

address-family ipv4 vrf Orch_1:3630

version 2

network 2.0.0.0

network 3.0.0.0

distance 255 145.45.0.0 0.0.127.127

distance 255 12.212.3.3 0.0.0.20

no auto-summary

exit-address-family



PE-CE configuration using OSPFThis section explains the configuration of PE routers using OSPF. The corresponding configuration of the CE routers is not performed by Service Activator. See CE routers on page 31.

The relevant Cisco commands for configuring OSPF on the PE router are configured automatically by Service Activator. They are as follows:

router ospf process-id vrf vrf

Configures OSPF in the context of the VRF table.

router-id id

This command is only configured if there is VRF reduction between two or more tables that use OSPF as the PE to CE protocol. The id is set to the IP address of the interface owning the VRF OSPF instance.

network ip-address mask area area-no

Specifies a network which identifies the interfaces that OSPF will run on. The PE-CE connection is always configured as area 0.

For examples of the use of the commands, see the example configuration files in MPLS VPN Device Configuration on page 235.

MD5 authenticationThe identity of OSPF peers and the integrity of data exchanged during OSPF sessions can be verified using MD5 authentication. This option uses the MD5 digital signature algorithm and a specified key of up to 255 characters to generate a checksum of the iBGP data that is to be sent from a PE device to its peer. The OSPF data and its checksum are then sent to the peer device using TCP. The recipient device uses MD5 and the same key to generate a checksum of the received OSPF data. If both checksums match, the identity of the sender and the integrity of the received OSPF data is verified.

Service Activator will always use key id of 100 for the MD5 key on the interface.

Example IP commands:

ip ospf message-digest-key 100 md5 7 151D1B02013E272D2636

As well as eBGP, Service Activator supports other routing protocols as well as static routing. See PE-CE configuration using eBGP on page 57, PE-CE configuration using EIGRP on page 62, PE-CE configuration using RIP on page 67 and PE-CE configuration using static routing on page 73.



ip ospf authentication message-digest

Configuring Additional OSPF Area TypesService Activator allows you to configure a number of different OSPF Area options for PE interfaces. Choices include:

Normal

Stub

Totally Stub

NSSA (Not So Stubby Area)

NSSA (Totally Stub)

When OSPF is used as a routing protocol to connect sites to an MPLS VPN, it is important to note a few key characteristics of this network topology:

Each VRF runs its own OSPF process

The MPLS VPN acts as the OSPF backbone area (Area 0), or if the PE-CE link is defined as an area 0, the MPLS VPN acts as an "MPLS VPN super backbone" which connects the area 0s into a single logical area 0.

The PE acts as an Area Border Router (ABR) as well as an Autonomous System Boundary Router (ABSR).

Configuration Examples

Normal:

default-information originate <metric> <metric-type> <route-map>

NSSA:

area <area-id> nssa

NSSA Totally Stub Area:

area <area-id> nssa no-summary

Route redistribution into OSPFService Activator allows you to control the redistribution of routes into OSPF from eBGP, RIP, static routing and directly connected networks.





Route redistribution is set up on the Redist property page of the Site dialog box. You can specify the protocol-specific metric to apply to routes redistributed into OSPF, and define a manually pre-configured route map to apply to routes redistributed into OSPF.


redistribute bgp asn metric n route-map route-map subnets

redistribute rip metric n route-map route-map

redistribute static metric n route-map route-map

redistribute connected metric n route-map route-map

Redistributes BGP, RIP, static routes and connected routes respectively via OSPF. The metric value defaults to 20 if not specified.

Router ID and OSPFThe VRF property page of the Site dialog box allows the specification of an IP address for the OSPF router-id.

For Cisco, the router-id applies only to the OSPF routing protocol and is optional. If not specified, a router-id is calculated as necessary. During VRF reduction, an explicitly configured router-id is always chosen over a calculated router-id. When reducing two sites which each have an explicitly configured router-id, the higher router-id is chosen.

PE-CE configuration using static routingIf static routing is required, you need to define the destinations that can be reached from each PE interface, that is, the CE device (the address of the loopback interface) and any connected networks.

Static routes can be configured in conjunction with eBGP, RIP and OSPF routing or used alone to define routing between the PE and CE.

In the Service Activator user interface, static routes are engaged on the Connectivity property page of the Site dialog box and set up on the Static Routing property page.

Redistribution of static routes

You can control whether or not static routes are redistributed into dynamic routing protocols. On the Connectivity property page of the Site dialog box, select



Redistribute Routes to redistribute static routes. Select Local Routes to have static routes remain local. This controls the following command:

redistribute static

Configuring how the Next Hop parameter is specified

A number of choices are available on the Static Route property page of the Site dialog box to control the way the next hop value will be specified in the ip route vrf command in the static route. From the Next Hop dropdown, choices are:

IP Address & I/F: specify next hop value using both the IP Address and the interface name

IP Address Only: specify next hop value using only the IP Address. This is applicable, for example, to configurations such as MLPPP where load sharing is needed over a set of interfaces.

I/F Only: specify next hop value using only the interface name. This can be used when configuring point-to-point links.

Null0I/F: specify the Null0 interface as the next hop. This filters out all traffic going to the specified destination address and drops it.

Configuring a Null0 static route

You can specify the Null0 interface as the Next Hop of a static route by selecting Null0I/F for the Next Hop parameter. See Configuring how the Next Hop parameter is specified on page 74.

Static routing commands

The relevant Cisco commands for configuring static routing on the PE router are configured automatically by Service Activator.

An ip route command is included for each static route defined. It has the following format:

ip route vrf vrf-name ip-addr mask next-hop interface [global] [distance] [permanent] [tag tag]

where:

vrf-name Matches that in the ip vrf forwarding command run on the specific interface

ip-addr The IP address of the defined static route

mask The mask of the defined static route



Commands reflecting the various Next Hop dropdown choices are as follows.

IP Address & I/F:

ip route vrf vrf-name prefix mask [next-hop-address] [interface {interface-number}] [global] [distance] [permanent] [tag tag]

IP Address Only: All fields and options are valid

ip route vrf vrf-name prefix mask [next-hop-address] [global] [distance] [permanent] [tag tag]

I/F Only:

.ip route vrf vrf-name prefix mask [interface {interface-number}] [global] [distance] [permanent] [tag tag]

Null0:

ip route vrf vrf-name prefix mask null0 [global] [distance] [permanent] [tag tag]

next-hop IP address of the next hop that can be used to reach the destination

interface Interface on which the VRF table is configured

global Specifies that the next-hop is an address that is in the routing table and not in the VRF table. A next-hop address that is non-global implies that the address is in the VRF table.

distance Cost metric of the router (1-255). Specifies the weighting of the route entry in the VRF IP routing table

permanent Indicates that the static route will not be removed, even if the interface shuts down.

tag Specifies a value in the range 1 to 4294967295 to identify the static route, allowing it to be used by route-map match statements controlling the redistribution of routes.

It is possible for Service Activator configuration to co-exist with manually-configured static routes. However, in some circumstances, for example, VRF reduction, the system may remove manually-configured static routes or non-supported parameters.



Note that the presence of the “global”, “permanent” and “tag” keywords are dependent on the selections made on the Connectivity and Static Route property pages of the Site dialog box in the Service Activator GUI.

For examples of the use of the commands, see the example configuration files in MPLS VPN Device Configuration on page 235.

PE-CE configuration using eBGP and OSPF combinedService Activator supports the simultaneous configuration of eBGP and OSPF by selecting EBGP & OSPF from the Routing Type dropdown in the Connectivity property page of the Site dialog box.

With this selection, both routing protocols are configured for the interface and the various property pages and fields to control configuration and redistribution parameters for the protocols are available on the Site dialog box.

When EBGP and OSPF are simultaneously configured, static routing is still supported.

PE-CE configuration using eBGP and RIP combinedService Activator supports the simultaneous configuration of eBGP and RIP by selecting EBGP & RIP from the Routing Type dropdown in the Connectivity property page of the Site dialog box.

With this selection, both routing protocols are configured for the interface and the various property pages and fields to control configuration and redistribution parameters for the protocols are available on the Site dialog box.

When EBGP and RIP are simultaneously configured, static routing is still supported.

VRF-Aware IPsec connections to MPLS VPNsService Activator supports VRF-Aware IPsec on certain Cisco devices. See the Release Notes for details on device and IOS support.

The VRF-Aware IPsec feature allows you to map IPSec tunnels that terminate on a shared public interface to specific Virtual Routing and Forwarding (VRF) instances, therefore allowing you to map IPSec tunnels to MPLS VPNs. This allows you to extend customer VPN access to users that are not directly reachable via dedicated WAN links.

For detailed configuration instructions refer to the VRF-Aware IPsec topics in the Online Help. Also, see Interface-less VRFs on page 49.



Public and customer oriented Configuration Policies are applied to sites in order to configure parameters for:

crypto map

ACL

isakmp profile

transform set

key ring

Configuration is performed using the Network Processor through the Cisco cartridge.

Service Activator MPLS VPN functionality is used to configure other components required for VRF-Aware IPsec such as the Front Door VPN and Site, and the Customer Site with interface-less VRF.

Example IPsec access configuration statements

The following are example statements configured by the public IPsec configuration policy applied.

crypto map corpcon-vpns 10 ipsec-isakmp

description description goes here

set peer 1.1.1.1

set security-association lifetime kilobytes 65535

set security-association lifetime seconds 3600

set transform-set 3des-md5

set pfs group2

set isakmp-profile cc-1

match address cc-1

ip access-list extended cc-1

permit ip 33.33.33.0 0.0.0.255 any

permit ip 22.22.22.0 0.0.0.255 any

crypto isakmp profile cc-1

vrf cc1-vrf

keyring cc-1

match identity address 1.1.1.1 255.255.255.255 [fvrfms]

crypto ipsec transform-set 3des-md5 esp-3des esp-md5-hmac



crypto keyring cc-1 [vrf fvrfms]

pre-shared-key address 1.1.1.1 key cc1-key


Cisco IOS Device Support Guide – Fourth Edition Configuration of Layer 2 VPNs

Chapter 6

Configuration of Layer 2 VPNs

This chapter describes how Service Activator configures Layer 2 VPNs on Cisco devices. It includes the following:

A summary of the Layer 2 Martini VPN functionality on Cisco Devices

pre-requisites for configuring Layer 2 VPNs

procedures for creating, modifying, and deleting a Layer 2 Martini VPN

Refer to the Configuring VPN Services Guide for a technical description of Layer 2 Martini VPNs.

Layer 2 Martini VPNsA Layer 2 Martini point-to-point connection is a pseudo-wire (or tunnel) configured between two endpoints across an IP network.

The connection uses MPLS labels to encapsulate and transport various Layer 2 data formats, including VLAN to VLAN, Ethernet, Frame Relay, ATM Cell and ATM AAL5, across an IP network. The tunnel provides a transparent connection, so users see no change in their Layer 2 data. (Note that the tunnel does not aim to meet QoS aspects of the connection, particularly in the ATM case.) The Martini endpoints can be interfaces, sub-interfaces, or other endpoint identifiers (VCI/VPI on ATM, DLCI on Frame Relay, or VLAN ID on Ethernet.

A Layer 2 Martini VPN is an association of Layer 2 Martini point-to-point connections.

Layer 2 Martini VPN devices and data typesThis topic gives an overview of the different devices and data encapsulations supported by Service Activator in the configuration of Layer 2 Martini VPNs. It also gives specific details for VPN types in which there are variations from the typical configuration.


Configuration of Layer 2 VPNs Cisco IOS Device Support Guide – Fourth Edition

Layer 2 Martini VPNs on Cisco routers and switches

Service Activator supports the configuration of Layer 2 Martini VPNs on Cisco IOS-based routers and switches which encapsulate and transmit a number of different types of data. The Martini endpoints can also be provisioned by Service Activator.

Cisco IOS-based equipment can be roughly categorized as either switching IOS or non-switching IOS.

Switching IOS equipment: Cisco equipment that supports Layer 2 (Ethernet) and Layer 3 (router) switching features, MAC learning, and VLAN bridging, typically in the Catalyst or Cisco 7600 range. Switching IOS equipment typically runs CatOS or Supervisor OS.

Non-switching IOS equipment: Cisco routers with none of the switching features described above. Devices in this category support standard IP routing between interfaces, run standard Cisco IOS, and are typified by equipment such as the 7200, 7500, 10700, and 12000.

Layer 2 Martini VPNs on switching IOS Cisco devices

The following data types can be encapsulated on Layer 2 Martini VPNs on switching IOS Cisco devices:

When creating an endpoint to support a Layer 2 Martini VPN encapsulating VLAN, the VLAN ID for that endpoint must match that of the corresponding CE interface.

Service Activator does not support the provisioning of interfaces on switching IOS Cisco devices. Interfaces must be pre-created manually on switching IOS Cisco devices.

For Ethernet (Port) encapsulation on switching IOS Cisco devices, a main interface is used. Endpoint VLAN IDs must be the same on both sides of the tunnel.

Encapsulated data Endpoints Comments

Ethernet (Port)

Any combination of VLAN interfaces

Martini VLAN ID header is stripped on the Martini VC-LSP (Martini tunnel) and re-applied (if required) on the exit interface.

Ethernet (VLAN)

VLAN endpoints configured under Ethernet interfaces (not sub-interfaces)

See the notes below this table.



For Ethernet (VLAN) encapsulation on switching IOS Cisco devices, sub-interfaces are not used as the Layer 2 Martini VPN endpoints. You must create new or use existing VLAN endpoints. The endpoint VLAN IDs on both sides of the tunnel must be the same.

Inter-operability between switching IOS and non-switching IOS devices

For inter-operability between switching IOS and non-switching IOS devices, VLAN mode (which retains the VLAN tag across the Martini VC-LSP) must be selected on the switched IOS devices. You must also connect to a VLAN VC identifier with the same VLAN ID.

Layer 2 Martini VPNs on non-switching IOS Cisco devices

The following data types can be encapsulated on Layer 2 Martini VPNs on non-switching IOS Cisco devices.

ATM Cell Layer 2 Martini tunnel endpoints must have the same VPI / VCI. The roles for ATM Cell Relay sub-interfaces should be set to Gateway.

ATM AAL5 tunnel endpoints are not required to have the same VPI / VCI.

Encapsulated data Endpoints Comments

Ethernet (Port)

Ethernet interfaces

All VLAN tags are preserved across the connection. Frames that enter the tunnel labelled VLAN n leave the tunnel labelled VLAN n.

Ethernet (VLAN)

VC identifiers configured under Ethernet sub-interfaces

Created via Provision sub-interface or created manually. The VC identifier value represents the VLAN ID. The same VLAN ID must be used at both ends of the connection.

ATM Cell Sub-interface with VC identifier

Created via Provision sub-interface or created manually

ATM AAL5 Sub-interface with VC identifier

Created via Provision sub-interface or created manually

Frame Relay

Main interface with VC identifier

The VC identifier value attached to the main interface (DLCI) is created using Create FR PVC, or created manually.



For Ethernet VLAN on non-switching IOS Cisco devices, VC identifiers configured on Ethernet sub-interfaces are used as the Layer 2 Martini VPN endpoints. The VC (Virtual Circuit) identifier values are created by Service Activator when the sub-interface is provisioned. This value is used to represent the VLAN ID. The same VLAN ID must be used at both ends of the connection.

For Frame Relay encapsulation on non-switching IOS Cisco devices, sub-interfaces are not used as the Layer 2 Martini VPN endpoints. You must create new or use existing PVCs (Permanent Virtual Circuits) off the main interface instead.

Sub-interfaces and PVCs on interfaces for use in Layer 2 Martini VPNs (and other concretes such as VPNS) can be created manually and then added to the Service Activator object model by re-discovering the device they reside on.

Overview of Layer 2 Martini VPN creationThis section summarizes the activities involved in creating Layer 2 Martini VPNs.

Pre-requisites for configuring a Layer 2 Martini VPN

Discover devices and assign roles

Create customers

Check interface capabilities

Complete other pre-configuration requirements

Create the Martini connection endpoints (provision sub-interfaces)

Create the Martini connection endpoints, which are sub-interfaces or VC interfaces supporting the required type of data encapsulation.

Check the sub-interface configuration on the device

Use Telnet to directly access the device and check that the expected sub-interfaces have in fact been provisioned on the device.

Create the Layer 2 Martini VPN

Add the Layer 2 Martini connections.

Set the options in the property page.

Assign the endpoints to the new Layer 2 Martini tunnel.

Discovering devices and assigning roles for VPN setupWhen you have set domain-level information, you can run the discovery process to find all the P and PE routers in the network and include their details in Service Activator's database.



All devices within the network must be correctly assigned system-defined roles, that is, PE routers must be classified as gateway devices, P routers classified as core devices and CE routers, if visible, classified as access devices. The recommended way of assigning roles is by means of role assignment rules, which automatically assign roles during device discovery.

All interfaces within the network must be correctly assigned system-defined roles:

On CE (access) devices, the interface connected to the PE device must be classified as an access interface. Interfaces connected to local segments must be classified as local interfaces.

On PE (gateway) devices, the interface connected to the CE device must be classified as an access interface. Interfaces connected to other PE devices or P (core) devices must be classified as core interfaces.

All interfaces on P (core) devices should be classified as core interfaces.

To discover the network

1. Choose Discover from the Discovery menu.

The Topology Discovery property dialog box is displayed.

2. On the Discovery page, Enter the DNS name of the IP address of each device to be discovered.

Optionally, set the Hops field to a value between 1 and 10.

3. Click OK. You are prompted to save the changes by choosing Save from the File menu. As soon as the changes are committed to the database, the device discovery process starts.

Hints and tips

The Discovery menu option is not available if there are unsaved changes in the user interface. You must either commit or save the current transaction before you can run a discovery.

In an MPLS domain, the core provider network is assumed to use public addresses, and the hop count can be used within the core network. All CE routers are assumed to use private addresses and an IP address or DNS name must be specified in order to discover them.

You may need to change the default settings on the SNMP page.

To assign roles to devices and interfaces

All devices within the network must be correctly assigned roles (i.e. PE routers classified as gateway devices, P routers classified as core devices and CE routers, if visible, classified as access devices.)



This will be done automatically if you have set up role assignment rules, otherwise you need to manually assign a role to each device and interface to be managed.

Hints and tips

You are advised to set up role assignment rules to classify devices and interfaces correctly.

To manage a device

Before a device can be managed by Service Activator, you also need to ensure the following:

All devices in the domain that are to be managed by Service Activator must be assigned to a proxy agent. Although it is possible to assign devices manually, it is generally performed automatically during device discovery.

All devices to be configured by Service Activator need to be set to Managed. When devices are first discovered, their status is set to Unmanaged. To set all devices to Managed, select the network and choose Manage All Devices from the pop-up menu

Creating a customerYou must create a customer before you can create a VPN.

To set up a customer

1. Choose the Customers folder on the Service tab in an explorer window and choose Add Customer from the pop-up menu. The Customer dialog box is displayed.

2. Enter the following:

Customer name: Specify an identifying Name for the customer.

Remarks: Additional comments (optional).

Reference: Customer reference number (optional).

3. Click OK to close the dialog box.

Checking Interface CapabilitiesBefore creating a Layer 2 Martini VPN, check the capabilities of the interfaces, sub-interfaces or provisioned sub-interfaces on the devices. You need to determine if they will support the endpoints for the Martini tunnel.

To check the interface capabilities for supporting a Layer 2 Martini VPN

1. Right click on the interface and select Properties…



2. Display the Capabilities property page.

3. Under Outbound Properties, expand Interface Creation Support.

4. Ensure that the type of encapsulation you wish to use in your Layer 2 Martini VPN is supported by the interface.

5. Confirm that the Role for the interface is set to Access.

Completing other pre-configuration for Layer 2 Martini VPNsEnsure that Cisco devices are pre-configured as described in this section, before configuring the Layer 2 Martini VPN.

MPLS must be enabled on all appropriate interfaces.

— mpls label protocol ldp - specifies the use of the LDP label distribution protocol

— tag-switching ldp router-id Loopback0 force - enable tdp tag-switching, force the Loopback0 address to be used as the router ID

The ip cef or ip cef distributed command must be manually configured in order to turn on CEF or dCEF.

On PE devices, an IGP such as OSPF or EIGRP must be configured in order to distribute IP routes. These are required for IP connectivity, and to enable labels to be allocated by the separate LDP (Label Distribution Protocol) or TDP (Tag Distribution Protocol).

Tag-switching of IPv4 packets on the WAN-facing (Core-facing) interfaces. (These are not the same interfaces on which sub-interfaces for the Layer 2 Martini VPN tunnel endpoints are to be configured.)

— interface <interface name> - specify WAN facing interface for next command.

— tag-switching ip - enables tag-switching of IPv4 packets on the specified interface and device

Devices used in Layer 2 Martini VPNs should be configured to use the Gateway role. Interfaces and sub-interfaces used as endpoints should be configured to use the Access role.

Specify LDP protocol on interfaces for Martini L2 connections

Specify the Label Distribution Protocol on each interface to be used for a Layer 2 Martini connection. If you do not specify LDP, tag distribution protocol (TDP) is used instead.

Log into the PE router and enter: mpls label protocol ldp



Assign LDP Router IDs to the PE Routers

To assign LDP router IDs to the PE routers, perform the following steps. Both PE routers require a loopback address that you can use to create a virtual circuit between the routers.

1. Enter interface configuration mode: interface loopback0

Note: The LDP router ID must be configured with a 32-bit mask to ensure proper operation of MPLS forwarding between PE routers.

2. Assign an IP address to the loopback interface: ip address <ip-address>

3. Assign the loopback IP address as the router ID:

mpls ldp router-id loopback0 force

Note: This command forces the loopback interface to be the LDP router ID on each PE router. Without “force”, the router can assign a different router ID, thereby preventing the establishment of Virtual Circuits between PE routers.

Provisioning sub-interfaces for a Layer 2 Martini connectionLayer 2 Martini VPNs provide a tunnel between two endpoints which carries encapsulated data. The encapsulation is done at the endpoints, or sub-interfaces. If the objects which are to act as Martini endpoints do not already exist, you must create provisioned sub-interfaces supporting the required type of data encapsulation.

Note: Service Activator supports the creation of provisioned sub-interfaces (which creates them in the object model and provisions them on the device). Service Activator does not support modification of provisioned sub-interfaces. When Service Activator is used to delete a provisioned sub-interface, it is removed from the object model but not from the device.

Note: Refer to Layer 2 Martini VPN devices and data types on page 79 for details about the different devices and data encapsulations supported by Service Activator for Layer 2 Martini VPNS, the Martini endpoints required, and details about VPN types for which there are variations from the typical configuration.

Note: If you are provisioning a Layer 2 Martini VPN encapsulating Frame Relay data on Cisco, sub-interfaces are not used. You must create VC interfaces instead. Refer to Provisioning endpoints (VC IDs) for a Layer 2 Martini connection on page 87.

Hints and tips

To confirm that the parent interface is capable of supporting the sub-interface you wish to provision, right-click on the parent interface and select Properties

— On the Interface dialog box, display the Capabilities property page.

— Under Outbound Properties, expand Interface Creation Support.



— Confirm that the type of sub-interface you wish to create to support the Layer 2 Martini VPN is shown.

To check that newly configured sub-interfaces are correctly represented in the object model, re-discover affected devices and then check the User Interface to confirm that the new sub-interfaces have been discovered. You may want to run this optional step at the end of your day to confirm the status of the object model.

Sub-interfaces for use as endpoints in Layer 2 Martini VPNs can be configured through Service Activator. For information on how to do this, refer to the Online Help topic Interface Configuration Management Module. Alternatively, you can configure sub-interfaces manually on the devices.

Provisioning endpoints (VC IDs) for a Layer 2 Martini connection

If you are provisioning a Layer 2 Martini VPN encapsulating Frame Relay, Ethernet or VLAN data on Cisco equipment, sub-interfaces are not used.

The following Layer 2 Martini connection requires VC identifiers as endpoints when encapsulating:

Frame Relay (on non-switching IOS Cisco equipment)

The following Layer 2 Martini connections require interfaces with configured VLAN IDs as endpoints when encapsulating:

Ethernet (on switching IOS Cisco equipment)

Ethernet VLAN (on switching IOS Cisco equipment)

Note: The endpoints for Layer 2 Martini VPN encapsulating Ethernet or VLAN on switching Cisco equipment must be configured manually outside of the Service Activator UI. In addition, modification or removal of these endpoints can't be performed inside Service Activator - you must modify or remove them manually.

Note: Refer to Layer 2 Martini VPN devices and data types on page 79 for details about the different devices and data encapsulations supported by Service Activator for Layer 2 Martini VPNS, the Martini endpoints required, and details about VPN types for which there are variations from the typical configuration.

To create a VC identifier for a Layer 2 Martini VPN encapsulating Frame Relay data on non-switching Cisco devices:

1. In the hierarchical tree, expand the device containing the interface on which you are provisioning the PVC. Alternatively, double click the device and the interface in the topology map.

2. Double click the interface to display the Details window.



3. Log into the device and configure the following commands manually on the device:

interface <interface>encapsulation frame-relay ietfframe-relay intf-type dceexit

connect fr1 <interface> <PVC identifier> l2transportexit

4. Rediscover the device in the Service Activator GUI.

To create a VLAN endpoint for a Layer 2 Martini VPN encapsulating Ethernet (port) or Ethernet VLAN data on switching Cisco devices:

Configure the VLAN endpoint manually on the device. The required configuration is as follows:

Ethernet (port):interface <ethernet port>encapsulation dot1Q <vlan id>exit

Checking sub-interface configuration on a device1. Commit the transaction that creates sub-interfaces on the device.

2. Using a Telnet session, access each device to check that it has received the configuration data for Martini tunnel endpoints.

3. To display the sub-interface configuration on a device, issue the command: show interfaces

4. Rediscover each affected device into Service Activator so that the new Layer 2 endpoint objects are visible.

5. Confirm creation by checking that the sub-interface creation concretes are visible in the Service Activator GUI.

You can now proceed to use these sub-interfaces as endpoints for the Layer 2 Martini VPN service.

Creating a Layer 2 Martini VPN

Pre-requisites:

Martini endpoints have already been created with the correct encapsulation for the type of Layer 2 Martini VPN you are creating. Refer to Overview of Layer 2 Martini VPN creation on page 82 for an overview of pre-requisite tasks.



To create a Layer 2 Martini VPN:

1. Create the Layer 2 Martini VPN object: On the Service tab, open the relevant customer folder, select the Point-to-Points folder, right click, and select Add L2 Martini-Pt-Pt from the drop-down menu.

The L2 Martini Pt-Pt dialog opens. For details on this dialog, refer to the L2 Martini Properties topic in the Online Help.

2. On the L2 Martini Pt-Pt page:

Name: specify a name for the Layer 2 Martini VPN. The name may contain alphanumeric characters only, and may not include spaces.

Remarks: add any additional remarks (optional)

Type: choose the appropriate encapsulation type, matching the encapsulation selected when you provisioned the sub-interface endpoints

— ATM AAL5

— ATM Cell

— Ethernet

— Ethernet VLAN

— Frame

Martini VC ID: if Automatic is checked, Service Activator provides a VC ID for you. Otherwise, leave it unchecked and specify a VC ID.

3. If you wish to restrict access to the Layer 2 Martini VPN object, select the Ownership page and specify the details.

4. Add the previously configured Martini endpoints (interfaces, sub-interfaces, provisioned sub-interfaces or VC interfaces) to the Layer 2 Martini VPN by dragging the desired Martini endpoint objects into the new Layer 2 Martini VPN object. This selects them as the Martini endpoints.

Modifying and Viewing Layer 2 Martini VPN attributesYou can modify the attributes of an existing Layer 2 Martini VPN and the appropriate configuration changes will be made on the devices involved.

Note: For complete dialog box and property page descriptions, refer to the Online Help..

To modify the properties of an existing Layer 2 Martini VPN



1. In the hierarchical tree, select the Service tab, and expand the relevant customer folder.

2. Expand the Point to Points folder and locate the Layer 2 Martini VPN to be modified in the hierarchy, or double-click the Point to Points folder and locate the Layer 2 Martini VPN in the Details window.

3. Right-click the Layer 2 Martini VPN and select Properties.

The L2 Martini Pt-Pt dialog box is displayed.

4. Make changes to one or more of the following fields on the L2 Martini Pt-Pt property page: Name, Remarks, Martini VC ID.

For details on these fields, refer to the L2 Martini Pt-Pt Properties topic in the Online Help.

You can also make changes on the Ownership property page. For details on these fields refer to the L2 Martini Pt-Pt Properties (Ownership Page) topic in the Online Help.

5. Click OK, and commit your changes.

Viewing the properties of an endpoint in an existing Layer 2 Martini VPN

1. In the hierarchical tree, select the Service tab, and expand the relevant customer folder.

2. Expand the Point to Points folder and locate the Layer 2 Martini VPN in the hierarchy.

3. Expand the Layer 2 Martini VPN and locate the endpoint to be modified in the hierarchy, or double-click the Layer 2 Martini VPN and locate the endpoint in the Details window.

4. Right-click the endpoint and select Properties.

The properties page for the endpoint is displayed. The actual page displayed depends on the type of encapsulation configured in the tunnel, and the type of endpoints in use. Endpoints can be provisioned sub-interfaces with VCI/VPI IDs, a Frame Relay interface with VC identifier, an Ethernet interface with a VLAN ID specified, etc.

Provisioned sub-interfaces cannot be modified in the Service Activator User Interface.



Deleting provisioned sub-interfacesNote: Service Activator does not allow the deletion of a sub-interface if it is part of an existing Layer 2 Martini VPN or is otherwise still in use.

You should not delete sub-interfaces that were created manually (outside of Service Activator).

To delete a provisioned sub-interface:

To delete a provisioned sub-interface from the object model, navigate to its object in the GUI and remove it. Follow these steps:

1. On the Topology tab, open the relevant device, and double click on the parent interface for the sub-interface to be deleted.

The Details window displays the interface.

2. On the Details windows, select the Provisioned Topology tab.

3. Perform one of the following:

Right click on the sub-interface in the Provisioned Topology window, then choose Delete from the pop-up menu.

Choose Delete from the Edit menu.

Click on the Delete button on the toolbar.

Note: The provisioned sub-interface has been removed from Service Activator, but not from the device.

4. If you wish, manually remove the sub-interface from the device, or re-discover the device to import the still existing sub-interface back into Service Activator as a manually provisioned sub-interface.

Hints and tips

To remove a sub-interface that was created directly on a device (rather than provisioned using the Service Activator GUI), first log into the device and remove the sub-interface. Then remove the sub-interface from the Service Activator GUI. If you do not first remove the sub-interface from the device, it will re-appear in the Service Activator GUI the next time the device is discovered.

Provisioned sub-interfaces can only be deleted from the Provisioned Topology window as described. The delete button is disabled if trying to delete from

When you delete a provisioned sub-interface from the object model, Service Activator does not remove the sub-interface from the device.



another location, for example the hierarchical tree. When you right click a provisioned sub-interface in the hierarchical tree, “Delete” does not appear in the pop-up menu.


Cisco IOS Device Support Guide – Fourth Edition Configuration of QoS and Access Control Features

Chapter 7

Configuration of QoS and Access Control Features

This chapter provides detailed information on the QoS and access control features configured by the Cisco device driver. This includes the following:

Classification of traffic – performed by all policy rules and MQC PHB groups

Access rules – used for access control (permitting and denying traffic)

Classification rules – used for packet marking

Policing rules – used for policing traffic

Standard PHB groups – used for controlling queuing, shaping and congestion management, configuring Custom Queuing, Priority Queuing, Generic Traffic Shaping, Weighted Fair Queuing, Low Latency Queuing, WRED, ATM Traffic Shaping, Frame Relay Traffic Shaping and Distributed Traffic Shaping

MQC PHB groups – used to manage Cisco’s Modular QoS CLI features, including classification, LLQ, CB-WFQ, single-rate and two-rate policing, shaping, marking and congestion management.

For each technique, this chapter includes details of implementation, a summary of the Cisco commands and examples of configurations, highlighting the commands added by Service Activator.


Configuration of QoS and Access Control Features Cisco IOS Device Support Guide – Fourth Edition

Traffic classificationThis section explains the Cisco techniques for identifying and classifying traffic used by Service Activator. In most cases the Cisco device driver uses access lists to classify traffic. Class maps are used when MQC is implemented, or when Network-Based Application Recognition (NBAR) is supported.

Access listsAccess lists (or access control lists) are used to control the transmission of packets on an interface. They can be used to filter traffic by explicitly denying or permitting identified traffic.

An access list is a sequential list of permit and deny conditions that apply to IP packets. The Cisco IOS tests packets against the conditions in an access list one by one. The first match determines whether the software accepts or rejects the packet. Because the software stops testing conditions after the first match, the order of the conditions is critical. If no conditions match, the packet is rejected.

Classification using access lists

Access lists can filter packets according to the following criteria:

Source/destination address

IP protocol (Service Activator Port traffic type)

Source/destination port number (Service Activator Port traffic type)

Packet marking – IP precedence and ToS bits (Service Activator Packet Marking traffic type)

Presence of the ACK bit in the “Established” keyword in TCP packets

An access rule can be added so that the Cisco Device driver inspects TCP packets for the presence of the ACK bit in the “Established” keyword. For example:

access-list 101 permit tcp 'ip addr-range' 'ip addr-range' gt 1023 established

Service Activator uses access lists to identify traffic to which marking, policing, custom queuing (WRR), priority queuing, CB-WFQ and GTS will be applied. IOS 11.2 and above support IP access lists identified by name rather than by number (note that named access lists are not supported on the 1600 router).

Cisco commands

The Cisco IOS command to set up a named access list is as follows:

(config)#ip access-list extended name



(config-ext-nacl)# { permit | deny } protocol source [operator] destination [precedence precedence] [tos tos]

where:

For MQC classification, it is possible to specify your own access list names/numbers.

For named access lists, if a name is not specified by the user, the driver allocates names of the form NamedAcl_n, starting at zero.

The Cisco IOS command to set up a numbered extended access list is as follows:

(config)#access-list ACLnumber { permit | deny } protocol source [operator] destination [precedence precedence] [tos tos]

For numbered access lists, if a name is not specified by the user, the driver uses unused numbers in the range 100-199 and, for versions of IOS that support extended numbers, those in the range 2000-2699. When setting up numbered lists, the device driver configures an alias command identifying the numbers used, and checks this on each configuration.

protocol identifies an IP protocol, or ip to match any protocol.

source identifies the source network or host from which the packet is being sent. Can also specify the source port, or a range of ports.

operator compares source or destination ports. Possible operands include lt (less than), gt (greater than), eq (equal), neq (not equal), and range (inclusive range). If the operator is positioned after source, it must match the source port. If the operator is positioned after destination, it must match the destination port.

destination identifies the network or host to which the packet is being sent. Can also specify the destination port, or a range of ports.

precedence Cisco IP precedence value, one of: routine, priority, immediate, flash, flash-override, critical, internet, network.

tos Cisco Type of Service, one of: normal, max-reliability, max-throughput, min-delay.



Class mapsClass maps are used to identify traffic to be classified when configuring MQC PHB groups, or when configuring policy rules when NBAR is supported. The QoS policy (marking, traffic shaping, etc.) to be applied to the identified traffic is set up by means of a policy map, which is then associated with a particular interface.

Class maps are used in conjunction with access-lists for certain types of classification.

NBAR classification

Network-Based Application Recognition (NBAR) is a Cisco classification engine that recognizes a wide variety of applications, including web-based protocols and those that use dynamic TCP/UDP port assignments.

On devices that support NBAR, the Cisco device driver can classify as follows:

IP traffic can be classified by recognized application protocol name (Service Activator Application traffic types)

HTTP traffic can be classified by URL or by MIME-type (Service Activator URL or MIME traffic types)

NBAR can classify IP traffic by checking the TCP/UDP packet contents as well as by looking at the packet header. This means that traffic can be classified by methods other than port numbers and IP addresses.

For MIME type matching, the MIME type can contain any user-defined text-string.

For URL matching, NBAR recognizes HTTP GET packets containing the URL and classifies all packets that are sent to the source of the HTTP GET request.

NBAR can classify the following three types of protocols:

Non-UDP and non-TCP IP protocols

TCP and UDP protocols that use statically assigned port numbers

TCP and UDP protocols that dynamically assign port numbers

NBAR is only supported on a limited set of Cisco routers and IOS versions. For details, consult Cisco documentation.



A complete list of supported protocols is given in Appendix B on page 269.

Example configurations

Classifying by application

The match protocol command is used to specify the protocol to be matched, for example:

class-map ClassMap_0

match protocol realaudio

Classifying by URL

URL classifications are mapped to the match protocol http host and match protocol http url statements.

Assuming a class of service called COS2 is set up as follows:

CoS: COS2

Classification: Home Page

URL Traffic Type: HOME Page

URL: http://www.home.com/index.html

The resulting configuration is as follows:

class-map COS2

match protocol http host www.home.com

match protocol http url index.html

Classifying by MIME

MIME classifications are mapped to the match protocol http mime statement.


CoS: COS3

Classification: JPEG Images

MIME Traffic Type: JPEG Images

MIME: *jpeg

NBAR requires Cisco Express Forwarding (CEF) to be enabled on the router. Since this may affect other aspects of router operation, the Cisco device driver does not configure it automatically. See Configuring CEF for NBAR on page 37.



The above settings result in the following configuration:

class-map COS3

match protocol http mime *jpeg

Classifying by packet marking

In pre-12.2(13)T IOSs, packet marking classifications are mapped to the following class map match commands:

match ip dscp

match mpls experimental

match fr-de or not match fr-de

match atm-clp or not match atm-clp

In IOS 12.2(13)T and later, the commands are as follows:

match dscp

match mpls experimental topmost

match fr-de or not match fr-de

match atm-clp or not match atm-clp

Note the not keyword allows classification on FR DE and ATM CLP bits set to 0.


CoS: COS4

Classification: CLP Not Set

Packet Marking Traffic Type: CLP Not Set

CLP: 0

The above settings result in the following configuration:

class-map COS1

match not atm-clp

Access control – Access rulesWithin Service Activator, access rules are used to permit and deny access to identified traffic inbound and/or outbound on a particular interface.



How access rules workAccess rules are implemented on Cisco devices by means of access lists. Each access rule translates directly to a permit or deny line. Where an access rule applies to both inbound and outbound traffic, two lines will be configured.

Access rules may be applied to traffic identified by any of the following methods:

Source and/or destination IP address

Source and/or destination port number (Port traffic type)

IP protocol (Port traffic type)

Packet marking (DiffServ codepoints/IP Precedence, MPLS Experimental bits or MPLS Topmost Experimental bits)

Note that the device driver has a limit of 255 access rules per interface.

For details and command syntax, see Access lists on page 94.

Migrating from IP Precedence to DSCPMigrating from an IP Precedence-based configuration to a DSCP-based configuration is accomplished through changes to the Service Activator capabilities files. When this change is made, Service Activator is not able to replace the Precedence entries with the DSCP entries within IP extended access-lists. This is because once the capabilities of the device driver have been changed to support DSCP, the device driver no longer parses or removes existing IP Precedence values. In this case, both IP Precedence and DSCP entries remain in the access-lists.

Once the new DSCP based configuration is verified to be correct, the remaining IP Precedence entries must be manually removed. If they are not manually removed Service Activator will continually attempt to remove the IP Precedence values on every device configuration.

ImplementationWhen access rules are implemented, as well as the specific permit or deny lines, additional lines are added to explicitly permit SNMP and Telnet traffic both inbound and outbound between the device and the device driver. These rules are always added at the end of the list, and minimize the chance of locking out network control traffic inadvertently.

Named access lists are set up on IOS 11.2 and above.



On the Service Activator user interface, access rules are set up on the Access Rule property pages:

Example configurationThis example shows an access rule that has been applied to an interface with the following configuration:

Action: Deny

Direction: In and Out

Traffic Type: http-d (TCP, destination port 80)

Source: Subnet 10.8.8.8

Destination: Subnet 10.9.9.9

The resulting configuration of the router is shown below.

interface Ethernet0

ip address 10.6.2.3 255.255.255.0

!

router eigrp 1

network 10.0.0.0

ip access-group NamedAcl_0 in

ip access-group NamedAcl_0 out



!

ip classless

Packet marking using classification rulesClassification rules both classify the traffic and specify the marking to apply. The following types of marking are supported:

DiffServ codepoint values in the IP packet header (in the range 0-63)

IP Precedence values in the IP packet header (in the range 0-7)

MPLS Experimental bits in the MPLS header (in the range 0-7)

MPLS Topmost Experimental bits in the MPLS header (in the range 0-7)

The MPLS Topmost packet marking is used to mark the MPLS Experimental bits in only the topmost MPLS label of a packet. Classifications using this Packet Marking are applicable only in MQC PHBs and only to perform policing and marking actions. Other actions will trigger the device to return errors which are then displayed in the Faults pane.

Classes of service using MPLS Experimental bits are supported by Service Activator for inbound traffic only. When you select both an inbound and out-bound MQC PHB phb using MPLS Experimental, the error states that there is a problem with the default class of service.

The Cisco device driver can mark IP packets using three different techniques:

Policy-based routing, using route maps. This is the default method used by classification rules for marking IP packets with IP Precedence/DiffServ codepoint values. It is automatically configured on devices that do not support NBAR. Route maps only permit marking on inbound interfaces, which means you may need to mark on multiple inbound interfaces rather than one outbound interface. Packets can be marked with the full range of DiffServ codepoints.

CAR (Committed Access Rate) marking. CAR can be configured to mark on inbound and outbound interfaces. On outbound interfaces, CAR marking is

ip access-list extended NamedAcl_0

permit tcp any eq telnet host 192.168.0.195

permit tcp host 192.168.0.195 any eq telnet

permit udp any eq snmp host 192.168.0.195

permit udp host 192.168.0.195 any eq snmp

deny tcp host 10.8.8.8 host 10.9.9.9 eq 80

permit ip any any



performed after queuing, and a queuing strategy is applied once the rate-limiting value set is exceeded. Depending on the device and IOS version, CAR can be used to mark with IP Precedence values and the full range of DiffServ codepoints or MPLS Experimental bits. At present, in order to implement CAR you need to specify a command-line parameter.

Using policy maps. This marking method is used automatically for classification rules on routers that support NBAR; you do not need to request it. Policy maps support the full range of DiffServ codepoints, MPLS Experimental bits, FR DE bits and ATM CLP bits. Classification rules use policy maps to mark MPLS Experimental bits unless CAR marking has been explicitly specified.

Note that the device driver has a limit of 255 classification rules per interface.

Note that classification rules cannot be used to perform any bandwidth management.

Marking using route maps

How marking using route-maps works

By default, route maps are used by the Cisco device driver to implement packet marking; IP packets identified by an access list are marked by setting the IP Precedence and/or Type of Service (ToS) bits.

Using route maps, packets can only be marked on inbound interfaces.

A route map defines where packets are output, and associated match and set commands define the conditions for policy routing. The match commands specify the conditions under which policy routing occurs, and the set commands specify the actions to perform when a match occurs.

The route map then has to be associated with the appropriate interfaces.

Cisco commands

The Cisco IOS commands to set up a route map are as follows:

(config)#route-map route-map-name permit sequence-no

Defines a route map to control where packets are output.

(config-route-map)#match ip address {ACLnumber | ACLname}

On devices where it is supported, MQC can also be used to mark packets. See Marking using MQC on page 178.



Defines the criteria by which packets are examined to see if they will be policy-routed. Matches IP addresses defined by one or more access lists to the route map.

(config-route-map)#set ip precedence

Sets the IP precedence value in the IP header.

(config-route-map)#set ip tos

Sets the TOS value in the IP header.

(config-if)#ip policy route-map route-map-name

Associates a route map with the interface.

Implementation

Marking using route maps is set up by configuring classification rules.

Example configuration – route maps

This example shows three classification rules that have been set from the user interface with the following configuration:

If no command-line directives are applied, and NBAR is not supported, the resulting configuration of the router is as follows:

interface Ethernet0

ip address 10.6.2.3 255.255.255.0

!

interface Serial0

ip address 10.6.2.4 255.255.255.0

!

Rule Source Destination Traffic Type Marking

Rule 1 10.8.8.8/32 10.9.9.9/32 ftp-data (dest. port 20)

IP precedence 3

Rule 2 10.8.8.8/32 10.9.9.9/32 http (dest port 80) IP precedence 0

Rule 3 10.8.8.8/32 10.9.9.9/32 user-defined traffic type (dest. port 5123)

IP precedence 5

ip policy route-map RouteMap_1



router eigrp 1

network 10.0.0.0

!

ip classless

!

Marking using CARAs an alternative to the default method, packets can be marked using CAR on either the inbound or outbound interface.


permit tcp host 10.8.8.8 host 10.9.9.9 eq ftp-data


permit tcp host 10.8.8.8 host 10.9.9.9 eq www


permit tcp host 10.8.8.8 eq 5123 host 10.9.9.9

route-map RouteMap_1 permit 0

match ip address NamedAcl_0

set ip tos normal

set ip precedence flash

!



set ip tos normal

set ip precedence routine

!



set ip tos normal

set ip precedence critical



How CAR marking works

CAR can be used to set a bandwidth limit for identified traffic, and allows different actions to be defined for traffic conforming to the defined bandwidth limit and traffic exceeding the agreed limit. When used for packet marking, default bandwidth values are set and the actions are set up to always mark packets with the specified values.

CAR can re-mark packets with IP Precedence values, the full range of DiffServ codepoints or MPLS experimental bits. However, not all devices and versions of IOS support DiffServ compliant CAR or MPLS experimental bits.

In Service Activator 5.2.4, CAR marking cannot be specified from the user interface, but must be implemented as a command line directive to the Cisco device driver.

If the appropriate command line directive is specified, classification rules will result in CAR being configured on the appropriate interface. IP packets identified by an access list are marked by IP Precedence values or the full range of DiffServ codepoints.

Note the following:

For IP Precedence/DiffServ codepoint marking, if CAR is specified and the device/IOS does not support it, the driver will try to use route maps instead. The default behavior of the Cisco device driver is to use route maps.

For MPLS Experimental marking, if CAR is not supported, the driver will use policy maps.

CAR can mark with either IP Precedence or the full range of DiffServ codepoints. However, not all devices and versions of IOS support DiffServ compliant CAR (see Driver support for Cisco features on page 5). The Cisco device driver will set DiffServ codepoints if they are supported, otherwise it will set IP Precedence values.

In order to implement CAR marking on a device you need to shut down and restart the component manager on the host system running the Cisco device driver. You also need to delete and rediscover the device.

Cisco commands

The Cisco command to implement CAR is as follows:

(config-if)rate-limit {input | output} access-group ACLnum rate bc be conform-action action exceed-action action

input applies CAR policy to packets received on this interface.

output applies CAR policy to packets sent on this interface.

ACLnum applies CAR policy to the specified access list.



Implementation

CAR marking cannot be specified from the user interface, but must be implemented as a command-line directive to the Cisco device driver.

On Solaris platforms, you need to edit the Cisco Device Driver entry in the configuration file cman.cfg in /opt/OracleCommunications.

On Windows platforms, you need to edit the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\OracleCommunications\DPE\2.0\ ComponentManager\ Cisco_Driver

In either case, add the following command within the section enclosed by quotation marks:

-MarkingStrategy { RouteMap | CarIn | CarOut }

rate average rate in bits per second. The value must be in increments of 8 Kbits/s. When used to implement CAR marking, this is always set to 8000.

bc normal burst size in bytes. When used to implement CAR marking, this is always set to 8000.

be excess burst size in bytes. When used to implement CAR marking, this is always set to 8000.

action action to take for packets that conform to the rate limit or exceed it. For CAR marking, one of:

set-prec-transmit IPprec where IPprec is the IP Precedence value (0-7)

set-dscp-transmit dscp where dscp is the DiffServ codepoint (0-63)

set-mpls-exp-transmit mpls where mpls is the MPLS Experimental bit (0-7)

Note that when used for marking, the rate, bc and be values are set to fixed values and the conform-action and exceed-action are the same. Note that CAR is also used to implement policing. See Policing using CAR on page 114.



where:

Example configuration – CAR inbound marking

If the Cisco device driver is run with the -MarkingStrategy CarIn command-line directive, CAR is configured to mark inbound traffic on the appropriate interface.

The following example shows the configuration of an interface resulting from three classification rules setting DiffServ codepoints.

Note that the conform action and exceed action both set the DiffServ codepoints to the specified value. The rate, bc and be values are all set to 8000.

interface Ethernet1/0/3

ip address 10.50.0.1 255.255.255.0

no ip directed-broadcast

ip route-cache distributed

!

interface Serial1/1/0

ip address 10.2.1.1 255.255.255.252



!

RouteMap Specifies that the device driver is to use route maps to mark packets (the default behavior).

CarIn Specifies that the device driver is to use CAR to mark inbound packets.

CarOut Specifies that the device driver is to use CAR to mark outbound packets.

rate-limit input access-group 100 8000 8000 8000 conform-action set-dscp-transmit 0 exceed-action set-dscp-transmit 0



access-list 100 permit tcp host 10.8.8.8 host 10.9.9.9 eq ftp-data

access-list 101 permit tcp host 10.8.8.8 host 10.9.9.9 eq www

access-list 102 permit tcp host 10.8.8.8 eq 5123 host 10.9.9.9



Example configuration – CAR outbound marking

If the Cisco device driver is run with the –MarkingStrategy CarOut command-line directive, classification rules are configured to mark outbound packets on the appropriate interface.

The following example shows the configuration of an interface resulting from three classification rules setting IP Precedence values of 0, 3 and 5.

Note that the conform action and exceed action both set the IP precedence to the specified value. The rate, bc and be values are all set to 8000. The rate-limit commands are implemented on the outbound interface.


ip address 10.2.1.1 255.255.255.252



!

router eigrp 1

network 10.0.0.0

ip classless!

Marking using policy maps

How marking using policy maps works

Classification rules use policy maps to perform marking in the following cases:

To mark DiffServ codepoint/IP Precedence values, if NBAR is supported on a device, and traffic is identified by URL, MIME-type or named protocol (as long as the device/IOS supports NBAR)

rate-limit output access-group 100 8000 8000 8000 conform-action set-prec-transmit 0 exceed-action set-prec-transmit 0





access-list 102 permit tcp host 10.8.8.8 eq 5123 host 10.9.9.9



To mark the MPLS Experimental bits in the MPLS header (used by default unless CAR marking is specified)

For more information about NBAR, see Class maps on page 96.

Cisco commands

Setting up a policy map to perform marking requires three stages:

Setting up a class map that identifies the traffic to be marked

Configuring a policy map that performs the marking

Associating the policy map with the appropriate interface

The IOS command to configure a class map is as follows:

(config)class-map class-map-name

Sets up the named class map.

(config-cmap)match criteria

Specifies the packet characteristics that will be matched to the class. For example, to match a protocol, the match protocol command is used.

The IOS command to set up a policy map is as follows:

(config)policy-map policy-map-name

Creates a policy map that can be attached to one or more interfaces to specify a service policy.

(config-pmap)class class-name

Associates the policy map with a previously-defined class map.

The following commands are configured in a policy map to implement marking:

(config-pmap-c)set ip precedence value

On devices where it is supported, MQC can also be used to mark packets. See Marking using MQC on page 178.

Traffic with FR DE or ATM CLP bits set to 0 are matched using the not keyword. For example not match fr-de



Specifies the value to which the IP Precedence bits are set if the packets match the specified class map (in the range 0-7). This command applies to pre-12.2(13)T IOSs.

(config-pmap-c)set precedence value

Specifies the value to which the IP Precedence bits are set if the packets match the specified class map (in the range 0-7). This command applies to IOS 12.2(13)T and later.

(config-pmap-c)set ip dscp value

Specifies the value to which the DiffServ codepoint bits are set if the packets match the specified class map (in the range 0-63). This command applies to pre-12.2(13)T IOSs.

(config-pmap-c)set dscp value

Specifies the value to which the DiffServ codepoint bits are set if the packets match the specified class map (in the range 0-63). Codepoints identifying known behaviors are shown by name rather than by value. This command applies to IOS 12.2(13)T and later.

(config-pmap-c)set mpls experimental value

Specifies the value to which the MPLS Experimental bits are set if the packets match the specified class map (in the range 0-7). This command applies to pre-12.2(13)T IOSs.

(config-pmap-c)set mpls experimental imposition value

Specifies the value to which the MPLS Experimental bits are set if the packets match the specified class map (in the range 0-7). This command applies to IOS 12.2(13)T and later.

(config-pmap-c)set fr-de

Sets the Frame Relay DE bit to 1.

The DE bit is used to indicate that a frame has lower importance than other frames. When the network becomes congested, frames with the DE bit set to 1 will be discarded before frames with the DE bit set to 0.

(config-pmap-c)set atm-clp

Sets the ATM Cell Loss Priority bit to 1.

The CLP bit is used to indicate that a cell has lower importance than other cells. When the network becomes congested, cells with the CLP bit set to 1 will be discarded before cells with the CLP bit set to 0.

The IOS command to attach a policy map to the input interface is as follows:

(config-if)service-policy input policy-map-name



For a classification rule, the type of marking is specified on the Marking property page of the Classification Rule dialog box.

The traffic to which the marking applies is defined on the Classification page of the Classification dialog box.

Example configuration – NBAR marking

The following example shows the configuration of a router after implementing a single classification rule with the following characteristics:

Traffic type: URL traffic type “www.Oracle.com”

Marking: DiffServ codepoint 0

The following example shows configuration pre-IOS 12.2(13)T.

!

!

class-map match-all ClassMap_0

match protocol http url www.Oracle.com

match access-group name NamedAcl_0



!

!

ip subnet-zero

ip cef

ip name-server 192.168.0.6

!

interface Loopback0

ip address 10.0.7.1 255.255.255.0


!

interface Serial1/0.1

ip address 1.1.1.1 255.255.255.0


!

interface POS2/0

no ip address


encapsulation frame-relay

clock source internal

!

router eigrp 1


network 10.0.0.0

!


permit ip 10.2.2.0 0.0.0.255 host 10.4.4.4

Example configuration – MPLS Experimental bits

The following example shows the configuration of a router after implementing a single classification rule which identifies traffic marked with MPLS Experimental 0 and resets it to MPLS Experimental 7.

policy-map PolicyMap_0

class ClassMap_0

set ip dscp 0

service-policy input PolicyMap_0



The following configuration is taken from a pre-12.2(13)T IOS.

ip subnet-zero

ip cef distributed

!

clns routing

!

!

interface Loopback0

ip address 10.0.0.4 255.255.255.255

!


ip address 10.2.0.4 255.255.255.0

!

For IOS 12.2(13)T and later, the following commands are configured:

ip subnet-zero

ip cef distributed

!

clns routing

!


match mpls experimental 0


class ClassMap_0

set mpls experimental 7





class ClassMap_0

set mpls experimental imposition 7



!

interface Loopback0

ip address 10.0.0.4 255.255.255.255

!


ip address 10.2.0.4 255.255.255.0

!

Policing using CARPolicing involves restricting traffic in specific classes of service to an agreed bandwidth. Service Activator configures policing by means of policing rules. Specific bandwidth restrictions can be set for committed rate, normal and excess burst sizes, and actions can be set for traffic that conforms to or exceeds the agreed limits.

How CAR policing worksPolicing rules use Committed Access Rate (CAR) to implement policing. CAR enables a bandwidth limit to be set on traffic within certain classes of service, and allows different actions to be defined for traffic conforming to the defined bandwidth limit and traffic exceeding the agreed limit.

Policing rules can classify traffic by any combination of the following parameters:

Packet markings

Source and/or destination IP address

Source and/or destination port number and/or IP protocol

Application name

URL or MIME type

For details, see Traffic classification on page 94.

CAR can re-mark packets with IP Precedence values, the full range of DiffServ codepoints or MPLS Experimental bits. However, not all devices and versions of IOS


On devices where it is supported, MQC can also be used to configure policing. See Marking using MQC on page 178.



support DiffServ compliant CAR or MPLS Experimental bits (for details, consult Cisco documentation).

Cisco commandsThe Cisco command to implement CAR policing is as follows:

(config-if)rate-limit {input | output} access-group ACLnumber rate bc be conform-action action exceed-action action

input applies CAR policy to packets received on this interface.

output applies CAR policy to packets sent on this interface.

ACLnumber applies CAR policy to the specified access list.

rate average rate in bits per second. The value must be in increments of 8 Kbits/s.

bc conform burst size in bytes.

be excess burst size in bytes.

action action to take for packets that conform to the rate limit or exceed it. One of:

continue evaluate next rate-limit command.

drop drop the packet.

set-prec-continue new-prec set the new IP precedence (0-7) and evaluate next rate-limit command.

set-prec-transmit new-prec set the new IP precedence (0-7) and transmit the packet.

set-dscp-continue new-dscp set the new DiffServ codepoint (0-63) and evaluate next rate-limit command.

set-dscp-transmit new-dscp set the new DiffServ codepoint (0-63) and transmit the packet.

set-mpls-exp-continue new-mpls

set the new MPLS Experimental setting (0-7) and evaluate next rate-limit command.

set-mpls-exp-transmit new-dscp

set the new MPLS Experimental setting (0-7) and transmit the packet.

transmit transmit the packet.



CAR can also be used to implement packet marking. See Marking using CAR on page 104.



Implementation Bandwidth requirements are set up on the Policing Rule page of the Policing Rule PHB group dialog box:

The Committed Rate, Normal Burst Size and Excess Burst Size can be set for each policing rule. Testing of TCP traffic suggests that the conform and excess burst values should be of the order of several seconds worth of traffic at the configured average rate. For example, if the average rate is 8 Mbits/s then the normal burst size should be 10-20 Mbits/s and the excess burst rate should be 20-40 Mbits.

The following are suggested guidelines for calculating the normal and extended burst parameters, but note that these values are dependent on the application and the QoS requirements.

Normal burst size: (committed rate / 8) * 1.5 seconds

Extended burst size: 2 * normal burst size

It is also possible to specify an ACL number (in the range 100-199 or 2000-2699) rather than accept the Service Activator default.



Conform and Exceed actions are set up on the Policing Action page of the properties:

The action to be taken can be one of: Drop, Transmit, Continue, and Re-mark and transmit.

The Cisco device driver will remark with DiffServ codepoints if they are supported, otherwise it will use IP Precedence values.

The device driver optimizes the commands placed on a device, therefore if you create two or more identical policing rules, they appear on a router as a single line of configuration. If one of the rules is removed, the driver will not remove the associated configuration: it will only be removed when the last of the identical rules is removed.



Example configuration

This policing example shows the implementation of three policing rules, as follows:


interface Ethernet0/0

description CONNECTION TO A2504-1

ip address 10.6.2.2 255.255.255.0


!

interface Serial1/0

ip address 10.6.1.2 255.255.255.252


clockrate 2015232

!

router eigrp 1

network 10.0.0.0

!

ip classless

Rule Committed Rate

(bits/s)

Normal Burst Size

(bytes)

Excess Burst Size

(bytes)

Conform Action

Exceed Action

Rule 1 96000 18000 36000 Transmit Transmit

Rule 2 24000 4500 9000 Transmit Remark as DiffServ codepoint 40 and transmit

Rule 3 8000 1500 3000 Transmit Drop

rate-limit input access-group 100 96000 18000 36000 conform-action transmit exceed-action transmit

rate-limit input access-group 101 24000 4500 9000 conform-action transmit exceed-action set-dscp-transmit 40

rate-limit input access-group 102 8000 1500 3000 conform-action transmit exceed-action drop



!

router eigrp 1

network 10.0.0.0

!

dialer-list 1 protocol ip permit

dialer-list 1 protocol ipx permit

snmp-server community public RO

Priority QueuingPriority Queuing is a mechanism for prioritizing traffic into queues. It ensures that important traffic gets the fastest handling. Cisco’s Priority Queuing is implemented within Service Activator by applying a standard PHB group specifying the Priority Queuing mechanism.

How Priority Queuing worksPackets are placed into one of the four output queue levels, High, Medium, Normal or Low, based on a previously-assigned priority. The higher priority queues have absolute precedence over the lower priority queues. Packets that are not classified by priority are allocated to the Normal queue. Note that starvation of low priority traffic is a significant risk with Priority Queuing



access-list 102 permit tcp host 10.8.8.8 host 10.9.9.9 eq 5123 host 10.9.9.9

alias exec Acl0 [ 100-102 ]

alias exec Orchestream Last configured on: Thu May 31 11:45:08 2001 UTC

When implementing Priority Queuing on Frame Relay interfaces, it is possible to specify that Service Activator bases the name of the generated map class on the PHB group name, rather than auto-generating a name. For more information, see Class map naming on Frame Relay interfaces on page 197.



Cisco commandsThe Cisco IOS commands that implement Priority Queuing are as follows:

(config)#priority list number protocol ip level list ACLnumber

This command associates a priority queue and a level to traffic identified by a particular ACL. The parameters are as follows:

(config)#priority-list number default level

This command is configured if default traffic is to be allocated to any queue other than Normal. By default, traffic not otherwise identified is allocated to the Normal queue.

(config-if)#priority-group number

Assigns the specified priority list to an interface.

On a Frame Relay interface, the device driver configures a frame-relay map-class using the frame-relay priority-group command. The commands are:

(config)map-class frame-relay mapclassname

Sets up a named Frame Relay map class.

Incoming packets Outgoing packets

Incoming packetsare classified and

placed in a specificqueue

Packets are only sentfrom lower priority

queues if nothing iswaiting on higherpriority queues

High

Low

Medium

Normal

number Identifies the list number

level High, Medium, Normal, Low

ACLnumber Access list number



(config-map-class)frame-relay priority-group n

Assigns the priority list n to the map class.

ImplementationPriority Queuing is set up using a standard PHB group which assigns a queue to each class of service:

Note that the command:

priority-list 1 default priority

is included if default traffic (that is, the default Class of Service) is allocated to any queue other than Normal.

Note that on a Frame Relay interface, Priority Queuing will be applied to the parent interface. The PHB group must be applied to the interface, but not to the sub-interface(s).



Example configuration This example shows a PHB group that has been configured from the user interface with the following configuration:

!

interface Ethernet0

ip address 10.6.2.3 255.255.255.0

!

router eigrp 1

network 10.0.0.0

!

ip classless

Note that if Frame Relay Traffic Shaping parameters are already configured on the device the -ReverseEngineerFRTS command-line option (see Command-line parameters on page 12) can be used to instruct the device driver to extract any FRTS parameters from the existing map-class and include them in the new map-class, ensuring that existing FRTS configuration is not overwritten. However users are strongly recommended to reconfigure FRTS using the FRTS PHB group. See Frame Relay Traffic Shaping on page 155.

Class of service Weight

Gold High

Silver Medium

Bronze Low

Default CoS Low

priority-group 1

access-list 100 permit ip any any precedence routine tos normal

access-list 101 permit ip any any precedence flash tos normal

access-list 102 permit ip any any precedence critical tos normal




Example configuration on Frame Relay interface

!

interface Serial0

no ip address


no ip mroute-cache

shutdown

no fair-queue

clockrate 4000000

frame-relay interface-dlci 123

vofr data 4

!

priority-list 1 protocol ip high list 102

priority-list 1 protocol ip medium list 101

priority-list 1 protocol ip low list 100

priority-list 1 default low

frame-relay class MapClass_0

frame-relay traffic-shaping

map-class frame-relay MapClass_0

no frame-relay adaptive-shaping

frame-relay priority-group 1



access-list 102 permit ip any any precedence priority tos normal



priority-list 1 protocol ip high list 104

priority-list 1 protocol ip medium list 103

priority-list 1 protocol ip normal list 102

priority-list 1 protocol ip low list 101



Weighted Round Robin (Custom Queuing)Cisco’s Custom Queuing is implemented within Service Activator by applying a PHB group specifying the WRR mechanism.

How Custom Queuing worksCustom Queuing is a mechanism for allocating bandwidth to queues so that higher priority applications have more bandwidth than lower priority applications when the network is congested. This guarantees some level of service to all traffic because you can allocate a percentage of bandwidth to each traffic type. Associated with each output queue is a configurable byte count, which specifies how many bytes of data should be delivered from the current queue by the system before the system moves on to the next queue. When a particular queue is being processed, packets are sent until the number of bytes sent exceeds the queue byte count or until the queue is empty.

Cisco commandsThe Cisco IOS commands to set up custom queuing are as follows:

(config)#queue-list number protocol ip queue-number list ACLnum

Sets up a queue for the identified traffic. The parameters are as follows:

(config)#queue-list number queue queue-number byte-count byte-count limit packet-limit

Specifies how many bytes are delivered from a given queue during a particular cycle (default value 1500) and the depth of the queue (default value 20).

(config-if)#custom-queue-list n

Note that tuning the byte count is very important when configuring Custom Queuing. See Calculating the byte count on page 126.

When implemented WRR on Frame Relay interfaces, it is possible to specify that Service Activator bases the name of the generated map class on the PHB group name, rather than auto-generating a name. For more information, see Class map naming on Frame Relay interfaces on page 197.

number identifies the custom queuing list

queue-number number of the queue

ACLnum access list number



Assigns the specified custom queue list to an interface.

On Frame Relay interfaces/PVCs the commands to set up a map class are:



(config-map-class)frame-relay custom-queue-list n

Assigns the custom queue list to the map class.

ImplementationCustom Queuing is implemented in Service Activator by means of a WRR PHB group.

For each class of service, a weighting can be specified, which is converted to a percentage of the available bandwidth.

Calculating the byte count

To use custom queuing effectively and to ensure that the actual bandwidth allocation is as close as possible to the required bandwidth allocation, you need to determine the byte count based on each protocol's packet size.

1. For each queue, divide the percentage of bandwidth you want to allocate to the queue by the packet size in bytes. For example, assume that the packet size for



protocol A is 1086 bytes, protocol B is 291 bytes and protocol C is 831 bytes. To allocate 20% of the bandwidth to A, 60% to B and 20% to C, the ratios would be 20/1086, 60/291 and 20/831.

2. Normalize the numbers by dividing by the lowest number, giving 1, 11.2, 1.3. This is the ratio of packets that must be sent so that the percentage of bandwidth that each protocol uses is approximately 20, 60, 20.

3. Round up numbers to get the actual packet count: 1, 12, 2.

4. Convert the packet number ratio into byte counts by multiplying each packet count by the packet size. In the example above, this gives 1086, 3492, 1662.

5. To determine the actual bandwidth that this ratio represents, first determine the total number of bytes sent after all these queues are serviced. 1086 + 3492 + 1662 = 6240.

6. Then determine the percentage of the total number of bytes sent from each queue: 1086/6240, 3492/6240, 1662/6240 = 17.4%, 56%, 26.6%.

If this is not close enough to the desired bandwidth, try multiplying the original ratio to try and obtain integer values. In the example above, if you multiply the original ratio 1 : 11.2 : 1.3 by two, you will get 2 : 22.4 : 2.6. This would result in (2 x 1086) + (23 x 291) + (3 x 831) or 2172/6693/2493 for a total of 11,358 bytes. This results in a ratio of 19% : 59% : 22%, which is close to the original requirement.

Implementation on normal interfaces

On normal interfaces, the device driver uses the queue-list command to set queuing parameters for traffic identified by means of access lists.

Implementation on Frame Relay interfaces/PVCs

On a Frame Relay interface, the device driver configures a frame-relay map-class using the frame-relay custom-queue list command.

Note that if Frame Relay Traffic Shaping parameters are already configured on the device the -ReverseEngineerFRTS command-line option (see Command-line parameters on page 12) can be used to instruct the device driver to extract any FRTS parameters from the existing map-class and include them in the new map-class, ensuring that existing FRTS configuration is not overwritten. However users are strongly recommended to reconfigure FRTS using the FRTS PHB group. See Frame Relay Traffic Shaping on page 155.



Example configuration The following configuration of a router shows the result of setting up a WRR PHB group with the parameters shown in Implementation on page 126.

Note that the packet limit defaults to 20, and the limit parameter will only be configured if a different value is specified.

interface Ethernet0

ip address 10.6.2.3 255.255.255.0

!

router eigrp 1

network 10.0.0.0

!

ip classless

Example configuration on a Frame Relay interface

The following configuration shows the same PHB group applied to a Frame Relay interface:

interface Serial1/1

no ip address


no fair-queue

custom-queue-list 1


queue-list 1 protocol ip 2 list 100



queue-list 1 queue 2 byte-count 150 limit 10

queue-list 1 queue 3 byte-count 350





class MapClass_0



!

Flow-based Weighted Fair QueuingThere are two types of WFQ: flow-based and class-based. Flow-based WFQ allocates an equal share of the available bandwidth to each flow, where a flow is identified as all packets with the same source IP address, destination IP address and source or destination TCP or UDP port.

For details of class-based WFQ, see Class-based Weighted Fair Queuing and Low Latency Queuing on page 132 and WFQ and LLQ using MQC on page 189

Flow-based Weighted Fair Queuing is implemented within Service Activator by PHB groups which are implemented on specific interfaces.

Note the following:

Flow-based WFQ is used by default on all serial interfaces less than 2.048 Mbits/s. Service Activator will not affect this configuration.

Flow-based WFQ is not recommended on high-bandwidth interfaces because of the processing involved in identifying each separate flow.

The capabilities reported do not distinguish between flow-based and class-based WFQ.



frame-relay custom-queue-list 1








queue-list 1 queue 3 byte-count 350




How flow-based WFQ worksFlow-based WFQ allocates an equal share of the available bandwidth to each flow, where a flow is identified as all packets with the same source IP address, destination IP address and source or destination TCP or UDP port. It is not specific to classes of service. Flow-based WFQ is used by default on all serial interfaces less than 2 Mbits/s; it can be applied to other interfaces but should be used with caution as on fast interfaces the processing overheads can result in poor performance.

Cisco commandsThe Cisco command that implements flow-based WFQ is as follows:

(config-if)fair-queue discard-threshold dynamic-queues reservable-queues

where:

Service Activator sets the default values only.

When configuring flow-based WFQ on Frame Relay interfaces, it is possible to specify that Service Activator bases the name of the generated map class on the PHB group name, rather than auto-generating a name. For more information, see Class map naming on Frame Relay interfaces on page 197.

discard-threshold number of packets allowed in each queue (default=64)

dynamic-queues Number of dynamic queues used for best-effort flow (default=256)

reservable-queues Number of reservable queues used for reserved flows (default=0)



ImplementationFlow-based WFQ is configured by creating a WFQ PHB group and deselecting the Class Based checkbox. The fair-queue command with default values is automatically configured.

Example configurationThe following configuration of an interface on a core router shows the result of setting up flow-based WFQ. (Default values are used for the discard threshold and numbers of queues.)

!


bandwidth 10000

ip address 10.200.3.2 255.255.255.252



fair-queue



Class-based Weighted Fair Queuing and Low Latency Queuing

Class-based WFQ (CB-WFQ) enables the available bandwidth on an interface to be allocated to traffic within identified classes of service.

Note that the capabilities reported on an interface do not distinguish between flow-based and class-based WFQ. Errors will be returned if you attempt to configure CB-WFQ on an interface that does not support it.

How class-based WFQ worksCB-WFQ allows you to allocate a particular bandwidth to particular classes of service. Each class is allocated to a particular queue.

CB-WFQ can be implemented either using a standard PHB group or as an MQC PHB group. The same configuration results in either case.

Both groups allow the following options to be to be specified for individual classes of service:

LLQ – allocates a guaranteed bandwidth to a CoS and assigns it to a strict priority queue

Queue size (Queue limit) – the maximum number of packets allowed in a queue

Drop strategy – the method used for dropping packets

Set the Frame Relay Discard Eligibility (DE) bit, in order to designate identified frames as low priority).

Low Latency Queuing

CB-WFQ can be configured in conjunction with Low Latency Queuing (LLQ). This enables strict priority queuing to be configured for particular classes, that is, traffic in the priority queue will always be sent first. LLQ is particularly useful for delay-sensitive data, such as voice traffic, where it can reduce jitter.

When configuring class-based WFQ on Frame Relay interfaces, it is possible to specify that Service Activator bases the name of the generated map class on the PHB group name, rather than auto-generating a name. For more information, see Class map naming on Frame Relay interfaces on page 197.

For devices that support MQC, you are recommended to use an MQC PHB group to configure CB-WFQ. See WFQ and LLQ using MQC on page 189.



Allocation of bandwidth

It is possible to specify bandwidth values as exact values in kbits/s or as percentage values.

MQC PHB groups allow bandwidth to be specified as a percentage of the bandwidth not allocated to other classes of service in the MQC PHB group.

By default, only 75% of the bandwidth available on an interface may be allocated in kbits/s for CB-WFQ and LLQ. If you want to allocate more than this percentage, configure the max-reserved-bandwidth command on the interface manually:

(config-if)max-reserved-bandwidth %

where % is the maximum percentage of bandwidth to be reserved.

Drop strategy

It is possible to configure the drop strategy that applies to each CB-WFQ/low priority queue. This can be:

Tail drop/Queue limit – The maximum number of packets allowed in a CB-WFQ queue. Packets above this value will be dropped.

WRED – WRED is configured for the queue. Default drop thresholds can be applied, or specific parameters set.

Frame Relay Discard Eligibility bit

For Frame Relay traffic, you can set the Frame Relay Discard Eligibility (DE) bit for specific classes of service considered to be of lower priority. The DE bit in the address field of a Frame Relay frame allows users to prioritize the discarding of frames in cases of congestion. The default DE bit setting is 0; frames with the DE bit set to 1 are discarded before frames with the DE bit set to 0.

Cisco commandsThe Cisco driver configures CB-WFQ by identifying traffic by means of access lists, then setting up class maps that define the traffic to be classified, by protocol. The QoS policy to be applied to the identified traffic is set up by means of a policy map, which is then associated with a particular interface.

LLQ on Frame Relay VCs can be configured by the combination of Frame Relay Traffic Shaping (or DTS on distributed platforms) with Class-based WFQ with LLQ. For details, see Low Latency Queuing for Frame Relay on page 170.



On Frame Relay interfaces, a Frame Relay map class is created, the service-policy commands are applied to it and the map class is applied to the interface/PVC.

Class map definition

The IOS commands to configure a class map are as follows:

(config)class-map classmap-name


(config-cmap)#match access-group name aclname

Specifies the name of the access list used to identify the traffic.

Policy map definition

The IOS commands to configure a policy map are as follows:

(config)policy-map policymap-name

Sets up the named policy map.

(config-pmap)#class classmap-name

Associates the policy map with a previously defined class map.

(config-pmap-c)#bandwidth { bandwidth-value | remaining percent value | percent value }

Specifies the bandwidth to be allocated to the class, where:

bandwidth-value is the absolute bandwidth (kbits/s)

remaining percent value is the bandwidth as a percentage of bandwidth not allocated to other classes of service

percent value is the percentage bandwidth (%)

(config-pmap-c)#queue-limit packets

Specifies the maximum number of packets that can be queued for the class.

LLQ configuration

The IOS command to configure LLQ with CB-WFQ is:

(config-pmap-c)#priority bandwidth { bandwidth-value | remaining percent value | percent value }

Specifies the bandwidth to be allocated to the class, where:

bandwidth-value is the absolute bandwidth (kbits/s)

remaining percent value is the bandwidth as a percentage of bandwidth not allocated to other classes of service



percent value is the percentage bandwidth (%)

Frame Relay DE bit

The IOS command to set the Frame Relay DE bit is:


Sets the DE bit for identified traffic, increasing the likelihood of it being dropped in the case of congestion.

WRED

Tail drop (Queue limit)

The IOS command to configure tail drop is:

(config-pmap-c)queue-limit 100

Specifies the tail drop queue limit.

Application to an interface

The IOS command to attach a policy map to an interface is as follows:

(config-if)#service-policy output policymap-name

Associates the named policy map with the output interface.

For details of the WRED commands that are configured if WRED is selected, see Cisco commands on page 143.



Implementation To configure class-based WFQ using a standard PHB group, create a WFQ PHB group and select the Class Based checkbox. Appropriate bandwidth values can then be set for the selected classes of service.

For information about configuring CB-WFQ using MQC PHB groups, see WFQ and LLQ using MQC on page 189.


Frame Relay DE bit

To set the DE bit for a particular class, select the Set DE checkbox. The DE bit can be set for more than one class.

Some versions of IOS support priority queuing using an exact bandwidth value but not a percentage value. You are advised to check the capabilities of an interface before configuration. These capabilities are reported as “High priority as %” and “Low priority as %”.



Drop strategy

For Low priority queues, the Drop Strategy can be set to one of the following:

Default – No drop strategy. The device defaults are used.

Tail Drop – The maximum queue size can be set, in packets.

Default WRED – WRED will be configured, with the device default settings. (Any parameters entered on the WRED property page are ignored.)

WRED – Specific parameters must be set on the WRED page. The Min Threshold, Max Threshold and Drop Probability parameters can be set per codepoint; for example if there are two codepoints in a class of service, two queues are configured, each of which can have independent WRED settings. The Weight Factor can be set per class of service.

For full details of WRED, see WRED on page 142.




Example showing CB-WFQ applied to three classes of service

This example shows a standard PHB group that has been configured from the user interface to apply CB-WFQ to three classes of service.

Class maps are configured to identify the three classes of traffic (classified by access lists). The specific bandwidth is set by means of a policy map, which is associated with the relevant interface.

!

!

!

!

ip subnet-zero

no ip domain-lookup

!

interface Loopback0

ip address 192.168.65.12 255.255.255.255

!

interface Vlan1

bandwidth 10000








class ClassMap_0

bandwidth 7500

class ClassMap_1

bandwidth 500

class ClassMap_2

bandwidth 150



ip address 192.168.64.103 255.255.255.0

!

interface Vlan2

ip address 192.168.1.74 255.255.255.252

!

interface Vlan3

ip address 192.168.1.78 255.255.255.252

!

router eigrp 1

passive-interface Vlan99

network 172.16.0.0

network 192.168.64.0

network 192.168.65.0

distribute-list 1 out

no auto-summary

Example showing LLQ configuration

!

service-policy output PolicyMap_0


permit ip any any precedence critical tos normal


permit ip any any precedence flash tos normal


permit ip any any precedence routine tos normal






class ClassMap_0

bandwidth 30



!

ip subnet-zero

!


ip address 10.4.7.3 255.255.255.0 !

interface Serial0/0

no ip address



!

interface Serial0/0.1 point-to-point

ip address 10.4.2.3 255.255.255.0


!


ip address 10.4.3.3 255.255.255.0


!

router eigrp 1

network 10.0.0.0

no eigrp log-neighbor-changes

!

ip classless

no ip http server

!

class ClassMap_1

priority 20



permit ip any any precedence flash tos normal


permit ip any any precedence critical tos normal



Example showing tail drop (queue limit)


!

!

interface Serial1/0

!

Example showing WRED drop strategy


!

!

interface Serial1/0

!

For an example configuration showing CB-WFQ in conjunction with FRTS, see Example of FRTS/CB-WFQ configuration on page 172. For an example configuration


match ip dscp 0


class ClassMap_0

bandwidth 32

queue-limit 100



match ip dscp 0


class ClassMap_0

bandwidth 32

random-detect

random-detect precedence 0 1 50 10

random-detect exponential-weighting-constant 15




showing CB-WFQ in conjunction with DTS, see Example of DTS/CB-WFQ configuration on page 173.

WREDWeighted Random Early Detection (WRED) is a congestion-avoidance mechanism, generally used in core networks to selectively discard lower-priority traffic when an interface begins to get congested.

How WRED worksWeighted Random Early Detection (WRED) is a variant of the standard RED mechanism, which drops packets randomly in times of congestion. WRED drops packets selectively, based on their priority (IP Precedence or DiffServ codepoint). The weighting is calculated so that higher priority traffic is allowed to use more queue space before it begins to be selectively dropped, compared to lower priority traffic, which is dropped more aggressively.

The IP Precedence or DiffServ codepoint of a packet corresponds to threshold levels specified within WRED. A minimum threshold level defines the queue size at which packets start to be dropped and a maximum threshold level defines the queue size at which a specified number of packets are dropped.

WRED can be configured to use IP Precedence values or the full range of DiffServ codepoints. However, not all devices and versions of IOS support DiffServ compliant WRED (see Driver support for Cisco features on page 5).

WRED is generally used to manage traffic throughout the core network and is implemented in Service Activator by PHB groups which associate WRED behavior with specific classes of service, defined by packet markings.

When WRED is implemented on an interface, it works as follows:

When a packet arrives, the average queue size is calculated.

If the average queue size is less than a specified minimum threshold value for this packet’s IP Precedence/DiffServ codepoint, the packet is queued.

When the average queue size is above the minimum threshold, WRED begins to drop packets. The rate of packet drop increases linearly as the average queue

For MPLS packets, WRED is able to use MPLS Experimental bit settings. Values are translated directly into IP Precedence or DiffServ codepoint values; this is transparent to the user.



size increases, until the average queue size reaches the maximum threshold for the packet’s IP Precedence/DiffServ codepoint.

If the average queue size is greater than the specified maximum threshold value for this packet’s IP Precedence/DiffServ codepoint, or MPLS Experimental value, the packet is dropped automatically.

Cisco commands

IP Precedence compliant WRED

The Cisco commands to implement WRED on devices that support IP Precedence only are as follows:

(config-if)random-detect

Specifies that WRED is to be configured based on IP Precedence values and configures WRED using default values based on the buffering capacity and speed of the interface.

(config-if)random-detect precedence precedence min-threshold max-threshold mark-prob-denominator

This configures IP Precedence compliant WRED using user-defined values. The parameters are:

Packetdiscard

probability

Average queuesize

(packets)Min 1 Max 1

Below theminimum

threshold, allpackets arequeued for

transmission

Between the min andmax thresholds,

packets are droppedaccording to a preset

probability value

Min 2 Max 2

Above the maxthreshold, the

maximum numberof packets are

dropped

Diagram shows twodifferent IP Precedence

levels - up to 8 canbe defined

Low priority -dropped earlier

High priority -dropped later

precedence IP Precedence number (0 to 7).



(config-if)random-detect exponential-weighting-constant n

Sets the exponential weight factor, where n specifies an exponent weight factor used in calculating the average queue size. It can be a value between 1 and 16. If this command is not present, the default value of 9 is used.

DiffServ compliant WRED

For DiffServ compliant WRED, the Cisco commands are as follows:

(config-if)random-detect dscp-based

Specifies that WRED is to be configured based on the DiffServ codepoint values.

(config-if)dscp dscp min-threshold max-threshold mark-prob-denominator

Specifies the minimum and maximum packet thresholds, where dscp indicates the DiffServ codepoint, in the range 0-63. Other parameters are as above.

min-threshold Minimum threshold (number of packets), in the range 1 to 4096. When the calculated average queue size reaches this value, WRED starts to drop packets with the specified IP Precedence. The number of packets that are dropped is determined by the number of packets between the Min and Max threshold values and the drop probability value.

max-threshold Maximum threshold in number of packets. The value range of this argument is the value of the min-threshold argument to 4096. When the calculated average queue size exceeds this value, WRED drops all arriving packets.

mark-prob-denominator

Denominator for the fraction of packets dropped when the calculated average queue size increases to a size that is between the min and max thresholds. The number of packets dropped is a fraction of the number of packets between the Min and Max thresholds multiplied by the drop probability value. For example, if the Min threshold is 10, the max threshold is 20, and the drop probability is 20, if the calculated average queue size increases by 3 packets, then 6 packets will be dropped (3/10 x 20 = 6). The value range is 1 to 65536. The default is 10.



ATM

The Cisco commands to implement WRED on an ATM PVC are as follows.

(config-if-atm-vc)random-detect

This will configure WRED using default values based on the buffering capacity and speed of the interface.

(config)random-detect-group group-name [dscp-based]

Defines a parameter group for WRED. The dscp-based parameter indicates that DiffServ codepoints are supported. This command is not applied if you are using the default values.

(cfg-red-group)precedence precedence min-threshold max-threshold mark-prob-denominator

Configures a WRED group for a particular IP Precedence. The parameters are as described above.

(cfg-red-group)dscp dscp min-threshold max-threshold mark-prob-denominator

Configures a WRED group for a particular DiffServ codepoint

(config-if-atm-vc)random-detect attach group-name

This command, run on the ATM VC, associates the VC with the WRED parameter group.

ImplementationWRED is implemented in Service Activator by standard PHB groups. WRED can also be configured with CB-WFQ and LLQ, to define the drop strategy used in the case of congestion.

If a WRED PHB group is configured on an interface that supports DiffServ compliant WRED, the DiffServ commands are configured; if not, the IP Precedence commands are configured.

If a WRED PHB group is configured on an interface handling MPLS packets, Service Activator automatically translates packet markings specified as MPLS Experimental bit values to the equivalent DiffServ codepoint or IP Precedence values, and configures the appropriate commands.

Note that an error is raised if a class of service is defined by both DiffServ codepoint and MPLS Experimental marking objects.

When configuring WRED, you are strongly advised to select the As default checkbox on the PHB group property dialog box. When this checkbox is selected, it



has the effect of enabling WRED on the interface using calculated default parameters.

Defaults for IP Precedence

When WRED is applied to interfaces on devices supporting IP Precedence, the following defaults apply:

The maximum threshold is based on the buffering capacity and speed of the interface.

The minimum threshold depends on the IP Precedence. The minimum threshold for IP Precedence 0 is set to half the maximum threshold. The values for other IP Precedences fall between half the maximum threshold and the entire maximum threshold at evenly spaced intervals.

Because it is so interface-specific, you are strongly advised to use the default settings. However, it is possible to set up specific values if required.

Defaults for DiffServ

When WRED is applied to interfaces on devices supporting DiffServ, the following defaults apply:

DiffServ codepoint

IP Precedence

Minimum threshold

Maximum threshold

Drop probability

0 0 20 40 1/10

1 22 40 1/10

2 24 40 1/10

3 26 40 1/10

4 28 40 1/10

5 30 40 1/10

6 32 40 1/10

7 34 40 1/10

8 1 22 40 1/10

9 22 40 1/10



10 24 40 1/10

11 26 40 1/10

12 28 40 1/10

13 30 40 1/10

14 32 40 1/10

15 34 40 1/10

16 2 24 40 1/10

17 22 40 1/10

18 24 40 1/10

19 26 40 1/10

20 28 40 1/10

21 30 40 1/10

22 32 40 1/10

23 34 40 1/10

24 3 26 40 1/10

25 22 40 1/10

26 24 40 1/10

27 26 40 1/10

28 28 40 1/10

29 30 40 1/10

30 32 40 1/10

31 34 40 1/10

32 4 28 40 1/10

DiffServ codepoint

IP Precedence

Minimum threshold

Maximum threshold

Drop probability



33 22 40 1/10

34 24 40 1/10

35 26 40 1/10

36 28 40 1/10

37 30 40 1/10

38 32 40 1/10

39 34 40 1/10

40 5 30 40 1/10

41 22 40 1/10

42 24 40 1/10

43 26 40 1/10

44 28 40 1/10

45 30 40 1/10

46 36 40 1/10

47 34 40 1/10

48 6 32 40 1/10

49 22 40 1/10

50 24 40 1/10

51 26 40 1/10

52 28 40 1/10

53 30 40 1/10

54 32 40 1/10

55 34 40 1/10

DiffServ codepoint

IP Precedence

Minimum threshold

Maximum threshold

Drop probability



If you do not choose the default, specific values can be set per selected class of service:

56 7 34 40 1/10

57 22 40 1/10

58 24 40 1/10

59 26 40 1/10

60 28 40 1/10

61 30 40 1/10

62 32 40 1/10

63 34 40 1/10

DiffServ codepoint

IP Precedence

Minimum threshold

Maximum threshold

Drop probability



Example configuration – using defaultsThe following configuration of a core router shows the result of setting up WRED with the As default checkbox selected on the user interface.


ip address 10.6.1.1 255.255.255.252



Example configuration – setting specific valuesThis example shows a PHB group that has been configured from the user interface with the following parameters:

Min threshold The average queue size at which the system begins to drop packets (expressed as a number of packets).

Max threshold The average queue size above which the system drops all arriving packets (expressed as a number of packets).

Drop probability Denominator for the fraction of packets dropped when the calculated average queue size increases to a size that is between the min and max thresholds. The number of packets dropped is a fraction of the number of packets between the Min and Max thresholds multiplied by the drop probability value. For example, if the min threshold is 10, the max threshold is 20, and the drop probability is 20, if the calculated average queue size increases by 3 packets, then 6 packets will be dropped (3/10 x 20 = 6). The value range is 1 to 65536. The default is 10.

Weight factor An exponent weight factor used in calculating the average queue size. This defaults to 9.

random-detect

Class of service

IP precedence

Min Threshold

Max Threshold

Drop Probability

Bronze 0 100 200 10



In this example, the Weight Factor parameter is set to 10. Note that if it is left as the default, the exponential-weighting-constant parameter is not set.

The following configuration will be applied to the appropriate interfaces:


ip address 10.6.1.1 255.255.255.252



Example configuration - DiffServ compliant WREDThe following is an example of configuration on a device that supports the full range of DiffServ codepoints:

interface Serial1/1

no ip address



Silver 3 200 400 20

Gold 5 300 500 50

random-detect

random-detect exponential-weighting-constant 10




Class of service

IP precedence

Min Threshold

Max Threshold

Drop Probability

random-detect dscp-based

random-detect dscp 0 1 10 5







WRED on ATM PVCsWRED is supported on ATM PVCs. It is only implemented on PA-A3 adapters, which are available on 7200s and 7500s only.


The following configuration of a core router shows the result of setting up WRED with the example parameters as given in Example configuration – setting specific values on page 150.

ip subnet-zero

ip cef distributed

ip domain-name orchestream.com

ip name-server 192.168.0.6

!

interface ATM0/0/0

ip address 10.20.1.2 255.255.255.0



no atm ilmi-keepalive

pvc 2/32

protocol ip 10.20.1.1 broadcast

Generic Traffic ShapingGeneric Traffic Shaping (GTS) is used to control access to the core network by constraining specific outbound traffic to a particular bandwidth.

Cisco’s GTS is applied to traffic classified using access lists and is implemented within Service Activator by applying a PHB group specifying the Rate Limiting mechanism. Note that it is unrelated to the Cisco rate limit command.

random-detect-group Rdg_0

exponential-weighting-constant 10

precedence 0 100 200 10



random-detect attach Rdg_0



For class-based shaping configured by an MQC PHB group, see Class-Based Shaping using MQC on page 190.

How GTS worksGeneric Traffic Shaping allows you to control access to the core network by constraining specific outbound traffic to a particular bandwidth. Excess traffic is delayed using a buffer, or queuing mechanism, to hold packets and shape the traffic when the data rate of the source is higher than expected. Traffic is classified using access lists.

Note that GTS is implemented on Frame Relay interfaces by applying a PHB group specifying the FRTS mechanism. See Frame Relay Traffic Shaping on page 155.

GTS is implemented in the form of a “token bucket” mechanism. The average bit rate defines the rate at which tokens are placed into a bucket of fixed capacity. Each token permits a number of bits to be transmitted. To send a packet, an appropriate number of tokens must be removed from the bucket. If there are not enough tokens in the bucket to send a packet, the packet is queued (or dropped if the queue is full). Therefore, the largest burst that can be transmitted is proportional to the size of the bucket.

Cisco commandsThe Cisco command to implement GTS is as follows:

(config)traffic-shape group ACLnum rate bc be packet-limit

ImplementationGTS is implemented in Service Activator by means of a standard PHB group configuring Rate Limiting.

Traffic within a particular class of service is identified by means of access lists. Traffic shaping is then enabled on a particular interface and associated with the access list.

ACLnum Access list number.

rate Bit rate that traffic is shaped to in bits per second.

bc Burst size: sustained number of bits that can be transmitted per interval.

be Excess burst size: Maximum number of bits that can exceed the burst size in the first interval in a congestion event.

packet-limit Maximum number of packets that can be queued at any time.




Values input to the user interface include:

Average

Burst Rate

Burst Interval

Values for the traffic-shape command are calculated from the input values as follows:

rate value is the input average rate * 1000 to give bits/s

bc value is calculated as input average rate * measurement_interval

be value is calculated as input burst rate * input interval * 1000 giving bits/s

The measurement_interval is determined as follows:

If rate >= 1 Mbps, measurement_interval = 32 ms

If rate <= 64 kbps, measurement_interval = 128 ms

If rate is within 64 kbps-1Mbps, measurement_interval = 64 ms

packet-limit is set to 1000 and cannot be changed from the user interface.



Note that values are input to the user interface in Kbits/s, but configured on the Cisco device in bits/s.

Example configurationThis example shows the configuration resulting from the PHB group above:

interface Ethernet0

ip address 10.6.2.3 255.255.255.0

!

interface Serial0

no ip address

no fair-queue

!

router eigrp 1

network 10.0.0.0

!

ip classless

Frame Relay Traffic ShapingFrame Relay Traffic Shaping (FRTS) delays excess traffic using a queuing mechanism to hold packets and shape the flow when the data rate of the source is higher than expected. It is implemented in Service Activator by a PHB group which sets Committed Information Rate (CIR) and/or an excess burst rate at the VC level.

traffic-shape group 100 100000 6400 1500000 1000






FRTS is applied to all traffic on the interface, sub-interface or VC endpoint, not to selected classes of service.



Service Activator supports the options to override inbound FRTS parameters "CIR in" and "Bc in" and to suppress the “frame relay bc out” command when FRTS is applied.

The FRTS PHB group also allows you to set Frame Relay Fragmentation (FRF.12), which can be configured in conjunction with traffic shaping or independently.

Not all devices and versions of IOS support FRTS or FRF.12. For details, consult Cisco documentation.

FRTS can be combined with PQ, WRR or class-based WFQ applied at the VC or sub-interface. This allows for finer control over traffic prioritization and queuing.

How Frame Relay Traffic Shaping works

Committed rate and burst rates

FRTS is based on setting a bit rate, known as the Committed Information Rate (CIR) which sets a guaranteed rate for data transfer. A minimum bit rate can also be set; this will control the rate at which traffic is transmitted if a frame is received that has the BECN (Backward Explicit Congestion Notification) bit set.

A committed burst rate (Bc – the maximum number of bits the network commits to transfer) and an excess burst rate (Be – the maximum number of uncommitted bits the interface attempts to transfer beyond the CIR) can also be set.

Note that these settings are all applied to a period of time known as the “CIR interval”, which is calculated as follows:

CIR interval = Bc / CIR

The CIR value and min CIR are averaged over the interval, while the committed and excess burst rates apply to the interval.

On Frame Relay interfaces on distributed platforms, i.e. VIP-based devices, Distributed Traffic Shaping is implemented to configure traffic shaping. For details, see Example showing FRF.12 without traffic shaping on page 162.

By default, Service Activator generates a default name for the installed map class. However, it is possible to specify that the PHB group name is used as the map class name, see Class map naming on Frame Relay interfaces on page 197.



BECN and FECN

FRTS can be configured to use information contained in the BECN and FECN-tagged frames received from the network to throttle traffic dynamically when congestion occurs:

If a frame’s BECN bit is set, it indicates that the frame passed frames traveling in the opposite direction that encountered a congested path.

If a frame’s FECN bit is set, it indicates that a frame encountered congestion in the path from source to destination.

When traffic is throttled, packets are held in the device’s buffer and the transmission rate is adjusted based on the number of BECN or FECN-tagged packets received.

FRF.12 fragmentation

FRF.12 fragmentation allows long data frames to be fragmented into smaller pieces and interleaved with real-time frames. This means that real-time voice and non real-time data frames can be carried together on lower speed networks without causing excessive delay to the real-time traffic. FRF.12 fragmentation is recommended for interleaving delay-sensitive voice traffic on one VC with fragments of a long frame on another VC using the same interface.

Cisco commandsFRTS is configured using Frame Relay map classes, which can then be associated with a specific interface, sub-interface or VC.

The global commands to set up a Frame Relay map class are as follows:



(config-map-class)frame-relay adaptive-shaping becn

Configures the router to respond to BECN.

(config-map-class)frame-relay fecn-adapt

Configures the router to respond to FECN.

(config-map-class)no frame-relay adaptive-shaping

Configured if neither BECN or FECN are required.

(config-map-class)frame-relay cir cir

Specifies the committed information rate (CIR) in bits per second.

(config-map-class)frame-relay bc

Specifies the committed burst size (Bc) in bits.



(config-map-class)frame-relay be

Sets the excess burst size (Be) in bits.

(config-map-class)frame-relay mincir mincir

Specifies the minimum acceptable committed information rate (min CIR) in bits per second.

(config-map-class)frame-relay fragment fragment-size

Enables fragmentation of Frame Relay frames (FRF.12) and specifies the number of bytes from the original Frame Relay frame that will go into each fragment. Valid values are from 16 to 1600 bytes.

The commands to apply FRTS to an interface are as follows:

(config-if)frame-relay traffic shaping

Configures FRTS on the interface. If FRF.12 is configured and traffic-shaping is not required, the command no frame-relay traffic shaping is configured.

(config-if)frame-relay class mapclassname

Associates the named map class with the interface.

The commands to apply FRTS to a sub-interface are as follows:

(config-subif)frame-relay class mapclassname

Associates the named map class with the sub-interface.

ImplementationFRTS is implemented in Service Activator by a PHB group which sets the FRF.12 and traffic shaping parameters.




If traffic shaping is required, select the Shaping checkbox and set the relevant parameters.

FRTS can be combined with Priority Queuing, WRR or CB-WFQ. Additionally, LLQ on a Frame Relay interface can be configured by selecting FRTS in combination with Priority Queuing for CB-WFQ. FRF.12 cannot be used in combination with WRR or Priority Queuing.

Inbound/Outbound frame relay traffic shaping

Service Activator supports two new options on certain Cisco devices:

OverrideInboundFRTSDefaults

SuppressFRTSBcOut

OverrideInboundFRTSDefaults

This capability file-based option can override inbound FRTS parameters "CIR in" and "Bc in" when FRTS is applied. This feature is supported on non-VIP Cisco platforms. It is not supported on Cisco 7500 series and any devices that use PolicyMap to provision traffic shaping.



OverrideInboundFRTSDefaults option overrides the inbound values for CIR and BC by issuing the following commands:

frame-relay cir in 45000000

frame-relay bc in 4500000

If this option is not active, commands will apply the same parameters inbound as outbound.

If the option is active, discrete in/out variants of the commands to set CIR and Bc in a frame-relay map-class are provisioned. Inbound CIR will be set to 45 000 000 and inbound Bc will be set to 450 000. The values of MinCIR and Be are not affected by this option.

SuppressFRTSBcOut

This capability file-based option can suppress the "frame-relay bc out" command in a frame-relay map class.

SuppressFRTSBcOut option suppresses provisioning of the following command:

frame-relay bc out bc_value

If enabled, this option suppresses as appropriate either the default "frame-relay bc" command (in/out not specified) or the "frame-relay bc out" command (created when the OverrideInboundFRTSDefaults option is applied.)

If not enabled, existing capabilities do not suppress the command.

Enabling the options

By default, both options are not enabled in capabilities files. To enable them, modify one of the following two files:

cisco.os.device_information.cfg cisco.device.device_information.cfg

with the following lines:

<DeviceName> FRTS for VOIP </DeviceName>

# Added support for FRTS for VOIP

<Regex> .* </Regex>

<Description> </Description>

<MechanismsDefinition>

</MechanismsDefinition>

<OptionsDefinition>

( SuppressFRTSBcOut, SUPPORTED )

( OverrideInboundFRTSDefaults, SUPPORTED )



</OptionsDefinition>

</DeviceDefinition>


Example showing FRTS with BECN

The following shows a sample configuration with FRF.12 turned off and traffic shaping turned on with the following parameters set:

CIR: 56000

Min CIR: 2800

Bc: 56000

Be: 0

BECN: on

FECN: off

!

interface Serial1/0

Example showing FRTS with FRF.12

The following shows a sample configuration with both FRF.12 and shaping turned on, with the following parameters set:

CIR: 56000

Min CIR: 2800

Bc: 56000


frame-relay adaptive-shaping becn

frame-relay cir 56000

frame-relay bc 56000

frame-relay be 0

frame-relay mincir 28000





Be: 0

BECN: off

FECN: off

FRF1.2: on

Fragment size: 100

!

interface Serial1/0

Example showing FRF.12 without traffic shaping

The following shows a sample configuration with shaping turned off and FRF.2 turned on with a fragment size of 100:

!

interface Serial1/0





frame-relay be 0


frame-relay fragment 100






no frame-relay traffic-shaping




Distributed Traffic ShapingDistributed Traffic Shaping (DTS) provides traffic shaping on distributed platforms. Like other traffic shaping mechanisms, it buffers excess traffic and regulates the rate at which packets are sent into the network, setting a Committed Information Rate (CIR), a Committed Burst (Bc) and an Excess Burst rate (Be).

How DTS worksDTS is automatically configured if a user selects FRTS on a Frame Relay interface on a distributed platform; no additional configuration is required. It is also configured if MQC class-based shaping is applied to a Frame Relay interface on a distributed platform (see Class-Based Shaping using MQC on page 190).

Committed rate and burst rates

The CIR sets a guaranteed rate for data transfer. A minimum bit rate can also be set; this will control the rate at which traffic is transmitted if a frame is received that has the BECN bit set.

For DTS, the CIR and minCIR values must be multiples of 8000. (If the value of CIR entered is not a multiple of 8000, the value is automatically rounded down to the nearest multiple of 8000.)

Note that these settings are all applied to a period of time known as the “CIR interval”, which is calculated as Bc / CIR

Bc and Be values are optional. If they are not set, default values are used. A measurement interval of 4 ms is used, so Bc will be CIR *4/1000.

If a value for Be is not set, the default value is equal to Bc.

Parameter ranges

For DTS, the available ranges for input parameters are as follows:

Parameter Range

CIR 8000-154 400 000

MinCIR 8000-154 400 000

Bc 32-154 400 000

Be 0-154 400 000



Cisco commandsDTS is configured using Frame Relay map classes and policy maps.



(config-map-class)no frame-relay adaptive-shaping

Adaptive shaping is always turned off because BECN and FECN adaption is set in the class map.

(config)policy-map policy-name


(config-pmap)#class class-default

Associates the policy map with the default class map.

(config-pmap-c)#shape peak cir bc be

Sets the CIR, Bc and Be values

(config-pmap-c)#shape adaptive mincir

Configures the router to respond to BECN and specifies the minimum acceptable committed information rate (minCIR) in bits per second.

(config-pmap-c)#shape fecn-adaptive

Configures the router to respond to FECN.


Example showing BECN

The following shows a sample configuration with the following parameters set:

CIR: 56000

Min CIR: 2800

Bc: 56000

Be: 0

BECN: on

FECN: off

FRF12: off



!

!

Example showing FRF.12

The following example shows a sample configuration with settings for CIR, MinCIR, Be and Bc as above, and FRF.12 switched on with a fragment size of 100.

!

!





class class-default

shape peak 56000 56000 0

interface Serial1/0







class class-default

shape peak 56000 56000 0

interface Serial1/0




ATM Traffic ShapingATM traffic shaping is a means of applying bandwidth restrictions to traffic in specific service classes on a particular VC.

Not all devices and versions of IOS support ATM traffic shaping. For details, consult Cisco documentation.

How ATM Traffic Shaping worksThe ATM Forum has defined five service classes to implement QoS within ATM networks:

Constant Bit Rate (CBR) - designed for ATM VCs that need an amount of bandwidth to be continuously available for the duration of the active connection. A VC configured as CBR can send cells at peak cell rate (PCR) at any time and for any duration. CBR is typically used for real-time applications such as interactive or distributed voice and video.

rt-VBR (real-time Variable Bit Rate) - intended for real-time applications that are sensitive to delay and delay variation, such as multimedia applications.

nrt-VBR (non-real-time Variable Bit Rate) - for transmission of critical data that is not as delay-sensitive as voice or video, such as banking transactions.

Available Bit Rate (ABR) - intended for traffic that can reduce or increase transmission rate - generally non-real-time applications.

Unspecified Bit Rate (UBR) - provides a best-effort service for traffic that is less sensitive to delay and loss, such as file transfers.

Each of these service classes has specific requirements for bandwidth allocation, delay, variance and cell loss rates. ATM traffic shaping is only concerned with the setting of specific parameters that control normal and burst bits rates that can be used to limit surges and apply restrictions to traffic in each of the service classes.

The following traffic parameters can be set:

Peak Cell Rate (PCR) – set for all service classes

ATM traffic shaping is applied to all traffic on the interface, sub-interface or VC endpoint, not to selected classes of service.

Note that CBR and rt-VBR are not supported by Service Activator at present.



Sustained Cell Rate (SCR) – the long-term average cell rate that can be transmitted. Set for rt-VBR and nrt-VBR

Maximum Burst Size (MBS) – set for rt-VBR and nrt-VBR

Minimum Cell Rate (MCR) – set for ABR only

Cisco commandsvc-class atm name

Creates a VC class for an ATM VC or ATM interface.

Subsequent commands are configured in VC class mode.

abr pcr mcr

Sets the PCR and MCR values for traffic in the ABR traffic class, where pcr is the output peak cell rate in kbits per second and mcr is the output minimum cell rate in kbits per second

ubr pcr

Sets the PCR value for traffic in the UBR traffic class, where pcr is the output peak cell rate in kbits per second

vbr-nrt pcr scr mbs

Sets the PCR, SCR and MBS value for traffic in the nrt-VBR traffic class, where pcr is the output peak cell rate in kbits per second, scr is the sustained cell rate in kbits per second and mbs is the maximum burst size expressed as a number of cells

(config-if)class-int vc-class name

Configures the defined vc-class on all VCs on that interface.

(config-if-atm-vc)class-int vc-class name

Configures the defined vc-class on the specified VC.

ImplementationATM traffic shaping is implemented in Service Activator by a PHB group which sets ATM normal and burst rates for service classes on a VC.



Each PHB group sets parameters for a specific service category. Default values apply.


UBR

When configuring UBR, only the PCR value can be set. This provides an indication of a physical bandwidth limitation within a VC.

Note that CBR and rt-VBR are not supported by Service Activator at present.



Example configurationThe following configuration of a router shows the result of applying three PHB groups as follows:

!

!

!

!

interface Loopback0

ip address 10.0.0.4 255.255.255.255

!

interface ATM0/0/0

ip address 10.1.1.4 255.255.255.0

ip ospf network point-to-multipoint

no ip mroute-cache

no atm ilmi-keepalive

pvc 1/32


PHB group Parameters

ABR PCR = 45000 kbps

MCR = 40000 kbps

UBR PCR = 42000 kbps

nrt-VBR PCR = 41000 kbps

SCR = 39000 kbps

MBS = 100 cells

vc-class atm VcClass_0

abr 45000 40000


ubr 42000


vbr-nrt 41000 39000 100



!

pvc 2/32


!

pvc 3/32


!

pvc 50/52

!

pvc 50/53

!

pvc 50/54

!

Low Latency Queuing for Frame Relay Low Latency Queuing on Frame Relay VCs can be configured by the combination of Frame Relay Traffic Shaping (or DTS on distributed platforms) with Class-based WFQ with Priority Queuing.

In Service Activator, this is implemented by creating a PHB group which combines FRTS (to set FRTS/DTS parameters) and WFQ (to configure Class-based WFQ with Priority Queuing).

Alternatively, LLQ on Frame Relay VCs can be implemented by creating an MQC PHB group configured with LLQ and a standard PHB group configured with FRTS and applying both to the Frame Relay VC endpoint.

class-vc VcClass_0

class-vc VcClass_1

class-vc VcClass_2



Not all devices and versions of IOS support FRTS/DTS. For details, consult Cisco documentation.

ImplementationWhen FRTS/DTS and CB-WFQ are combined, Low Latency Queuing for Frame Relay is configured using a combination of class-map, policy-map and Frame Relay map-class commands.

The class-map command defines traffic classes according to packet markings, protocol, interface, or access list.

The policy-map command defines how each class is treated in the queueing system according to bandwidth or priority, queue limit, or WRED. The map-class command attaches a policy-map to a Frame Relay VC endpoint.

Example configurationThe following shows a sample configuration with the following parameters set:

PQ CBWFQ parameters

FRTS parameters

CIR: 56000

Min CIR: 28000

On most Frame Relay interfaces, FRTS is configured (see Frame Relay Traffic Shaping on page 155). On Frame Relay interfaces on distributed platforms, i.e. VIP-based devices, Distributed Traffic Shaping is implemented to configure traffic shaping. For details, see Example showing FRF.12 without traffic shaping on page 162.

Codepoint Bandwidth Priority

0 32 Kbit/s Yes

1 64 kbit/s No

2 128 kbit/s No

3 256 kbit/s No



Bc: 56000

Be: 0

BECN: off

FECN: off

FRF12: off

Example of FRTS/CB-WFQ configuration


On a normal frame relay interface:

!

!

!

!


match ip dscp 0


match ip dscp 10


match ip dscp 20


match ip dscp 28


class ClassMap_0

priority 32000

class ClassMap_1

bandwidth 64000

class ClassMap_2

bandwidth 128000

class ClassMap_3

bandwidth 256000



!

interface Serial1/0

Example of DTS/CB-WFQ configuration

The following example shows configuration installed on IOS 12.2(13)T.

On a frame relay interface on a distributed platform:

!

!

!

!





frame-relay be 0






match dscp default


match dscp af11


match dscp af22


match dscp af32


class ClassMap_0

priority 32000



!

interface Serial1/0

Configuration of MQCMQC (Modular QoS CLI) PHB groups allow you to implement Cisco’s simplified configuration of policy mechanisms and actions for traffic queuing, shaping, policing, congestion avoidance and re-marking on the interfaces of Cisco routers and switches. You can specify several different QoS mechanisms for different classes of service associated with the same MQC PHB group.

An MQC PHB group defines the QoS policy that may be used at various points in the network. For example, an MQC PHB group might be used to manage the traffic going into the core network or to maintain the prioritization set up at the network edge throughout the core network.

MQC PHB groups allow you to define a CoS using classifications such as source and/ or destination IP address or account and traffic type.

MQC PHB groups allow you to specify the matching strategy for deciding if a packet belongs to a class of service. You can nest an MQC PHB group within another MQC

class ClassMap_1

bandwidth 64000

class ClassMap_2

bandwidth 128000

class ClassMap_3

bandwidth 256000


class class-default

shape peak 56000 56000 0

service-policy PolicyMap_0

!








PHB group. This allows you to apply a broad QoS policy to a number of classes of service and a more specific policy to a subset of those classes of service.

An MQC PHB group is configured as a policy map and implemented at an interface as a service policy. An MQC PHB group is defined by:

Class of Service (CoS) – defines the parameters for classifying traffic to which QoS is to be applied, such as packet marking, traffic type, source/destination, protocol and input interface

Quality of Service (QoS) actions – defines QoS actions such as policing, queuing, shaping and packet marking

You associate a CoS with an MQC PHB group and associate QoS actions with that CoS. An MQC PHB group can have several classes of service associated with it, and each CoS can have a different set of QoS actions.

When applying MQC PHB groups to Frame Relay interfaces, it is possible to specify that Service Activator bases the name of the generated map class on the PHB group name, rather than auto-generating a name. For more information, see Class map naming on Frame Relay interfaces on page 197.

Re-ordering classes within Service Activator policies sends the correct configuration to the router, but some Cisco IOSs do not show the correct order on subsequent 'show run' commands. The router does not return any errors. There is no indication that the configuration has not been accepted by the router.

For problematic IOSs, the best work-around is to unlink the entire policy map, re-order the classes and then re-link the policy map. This will ensure that the correct ordering is applied to the router.

The following IOSs have been tested:

IOS Version Class re-order successful on router

12.3(3) Yes

12.2(19c) No

12.2(15)T10 Yes

12.2(12i) No

12.2(8)T No



Classification of MQC trafficMQC uses class maps to configure QoS policy. Traffic can be classified according to the following methods:

Source/destination address

Source/destination port number (Service Activator Port traffic type)

IP Protocol (Service Activator Port traffic type)

Packet Marking – IP Precedence/DiffServ codepoint, MPLS Experimental, Frame Relay DE bit and ATM CLP bit (Service Activator Packet Marking traffic type)

Application protocol name (Service Activator Application traffic types)

URL (Service Activator URL traffic type)

MIME type (Service Activator MIME traffic type)

Cisco commands


class-map {match-all | match-any} class-name

Sets up the named class map. The match-all option specifies that all match criteria in the class-map must be matched. If match-any is specified, any criteria can match. When configuring MQC, the class-map is given the same name as the Class of Service.

The class map consists of a number of match statements, for example:

match access-group access-list

Matches an access-list.

match protocol protocol-name

Matches a named protocol.

match protocol http mime mime-type

Matches a specified MIME type.

match protocol http url url-string

Matches the specified URL.

match ip dscp

match mpls experimental

match fr-de

match atm-clp



Matches the specific packet marking (pre-IOS 12.2(13)T).

match dscp

match mpls experimental topmost

match fr-de

match atm-clp

Matches the specific packet marking (IOS 12.2(13)T and later).

The IOS command to configure a policy map is as follows:

(config)policy-map policy-name


(config-pmap)#class class-name


The IOS command to attach a policy map to an interface is as follows:

(config-if)#service-policy [output | input] policy-name

Associates the named policy map with the interface in the input or output direction. The same policy map can be associated with both the input and output direction of an interface.


Source/Destination port classifications are mapped to access-list entries. Access lists are then matched using the match access-group class-map statement.

Named access lists are used if supported by the device. The name of the access list is taken from the name of the classification object. Any spaces are automatically converted to underscores. Numbered lists are used if named access lists are not supported by the device.

Assuming a Class of Service is set up with the following characteristics:

CoS: COS1

Classification Group: HTTP Traffic

Classification: HTTP Out

Port Traffic Type: HTTP Out

Destination Port: 80

Classification: HTTP In

Source Port: 80

An access list and a class-map is configured as follows:



ip access-list extended HTTP_Traffic

permit ip any any eq 80

permit ip any eq 80 any

class-map COS1

match access-group HTTP_Traffic

Note that where classifications can be configured entirely by access list entries, nested class maps are not required.

Marking using MQCMQC PHB groups use policy maps to implement the following types of marking:

DiffServ codepoints/IP Precedence bits

MPLS Experimental bits

MPLS Topmost Experimental bits

Frame Relay Discard Eligibility bit – the DE bit is part of the Address field in the Frame Relay frame header

ATM Cell Loss Priority (CLP) bit

Cisco commands

Setting up a policy map to perform marking requires three stages:

Setting up a class map that identifies the traffic to be marked

Configuring a policy map that performs the marking

Associating the policy map with the appropriate interface


(config)class-map class-map-name


(config-cmap)match criteria

Specifies the packet characteristics that will be matched to the class. For example, to match a protocol, the match protocol command is used.

Traffic with FR DE or ATM CLP bits set to 0 are matched using the not keyword. For example not match fr-de



The IOS command to set up a policy map is as follows:

(config)policy-map policy-map-name

Creates a policy map that can be attached to one or more interfaces to specify a service policy.

(config-pmap)class class-name


The following commands are configured in a policy map to implement marking:

(config-pmap-c)set ip precedence value

Specifies the value to which the IP Precedence bits are set if the packets match the specified class map (in the range 0-7). This command applies to pre-12.2(13)T IOSs.

(config-pmap-c)set precedence value

Specifies the value to which the IP Precedence bits are set if the packets match the specified class map (in the range 0-7). This command applies to IOS 12.2(13)T and later.

(config-pmap-c)set ip dscp value

Specifies the value to which the DiffServ codepoint bits are set if the packets match the specified class map (in the range 0-63). This command applies to pre-12.2(13)T IOSs.

(config-pmap-c)set dscp value

Specifies the value to which the DiffServ codepoint bits are set if the packets match the specified class map (in the range 0-63). Codepoints identifying known behaviors are shown by name rather than by value. This command applies to IOS 12.2(13)T and later.

(config-pmap-c)set mpls experimental value

Specifies the value to which the MPLS Experimental bits are set if the packets match the specified class map (in the range 0-7). This command applies to pre-12.2(13)T IOSs.

(config-pmap-c)set mpls experimental imposition value

Specifies the value to which the MPLS Experimental bits are set if the packets match the specified class map (in the range 0-7). This command applies to IOS 12.2(13)T and later.

(config-pmap-c)set mpls experimental topmost value

Specifies the value to which the MPLS Experimental bits in the topmost label are set if the packets match the specified class map (in the range 0-7). This command applies to IOS 12.2(13)T and later.




Sets the Frame Relay DE bit to 1.

The DE bit is used to indicate that a frame has lower importance than other frames. When the network becomes congested, frames with the DE bit set to 1 will be discarded before frames with the DE bit set to 0.

(config-pmap-c)set atm-clp

Sets the ATM Cell Loss Priority bit to 1.

The CLP bit is used to indicate that a cell has lower importance than other cells. When the network becomes congested, cells with the CLP bit set to 1 will be discarded before cells with the CLP bit set to 0.

The IOS command to attach a policy map to the input interface is as follows:

(config-if)#service-policy input policy-map-name

Implementation

For an MQC PHB group, the type of marking is specified on the Mark page of the MQC PHB Group dialog box:



Example configuration – MPLS Experimental bits

The following example shows the configuration of a router resulting from implementing a single classification rule which identifies traffic marked with MPLS Experimental 0 and resets it to MPLS Experimental 7.

The following configuration is taken from a pre-12.2(13)T IOS.

ip subnet-zero

ip cef distributed

!

clns routing

!

!

interface Loopback0

ip address 10.0.0.4 255.255.255.255

!


ip address 10.2.0.4 255.255.255.0

!

router ospf 1

log-adjacency-changes

network 10.0.0.0 0.255.255.255 area 0

!

ip classless

no ip http server

For IOS 12.2(13)T and later, the following commands are configured:

ip subnet-zero

ip cef distributed




class ClassMap_0

set mpls experimental 7




!

clns routing

!

!

interface Loopback0

ip address 10.0.0.4 255.255.255.255

!


ip address 10.2.0.4 255.255.255.0

!

router ospf 1


network 10.0.0.0 0.255.255.255 area 0

!

ip classless

no ip http server

Example configuration – set ATM CLP bit

The following example shows the configuration of an MQC PHB group which specifies ATM cells with CLP bit set to 0 in a CoS called Silver will be remarked to 1:

class-map Silver

not match atm-clp


class Silver

set atm-clp


match mpls experimental topmost 0


class ClassMap_0

set mpls experimental imposition 7




Policing using MQCMQC PHB groups can be used to implement single-rate or two-rate class-based policing.

Single rate (SR) policing specifies limits for:

Committed information rate (CIR)

Conform burst size

Excess burst size

Two rate (TR) policing specifies limits for:

CIR

Conform burst size

Peak burst size

Peak information rate

PHB Policing Actions specify one or several actions to take for traffic that conforms to or exceeds the specified rates, or violates the specified burst sizes.

How class-based policing works

Single rate and two rate policing use a token bucket algorithm for measuring the burst conformance of packets. Single rate policing uses an algorithm based on the single rate three-color marker system, as described in RFC 2697, A Single Rate Three Color Marker. Two rate policing uses an algorithm based on the two rate three-color marker system, as described in RFC 2698, A Two Rate Three Color Marker.

Single rate policing uses a single token bucket if a violate action is not specified, and two token buckets if a violate action is specified. Two rate policing always uses two token buckets.

Note that Service Activator cannot remark ATM CLP bits or FR DE bits from 1 to 0.

Note that not all versions of IOS support all actions.

The Service Activator violate action is not supported in IOS 12.0(22)S2 for the Cisco 10000 router.



Cisco commands - single rate policing

The Cisco command to implement single rate policing is as follows:

(config-pmap-c)police bps-value burst-normal-value [burst-max-value] conform-action action exceed-action action [violate-action action]

Cisco commands – two rate policing

The Cisco command to implement two rate policing is as follows:

(config-pmap-c)police cir cir-value [bc bc-value] pir pir-value [be peak-burst-value] [conform-action action] [exceed-action action] [violate-action action]

bps-value Committed information rate in bits/s at which the conform token bucket and, if used, the excess token bucket is updated.

burst-normal-value Conform burst size in bytes represented as tokens in the conform token bucket.

burst-max-value Excess burst size in bytes represented as tokens in the excess token bucket.

action Action for conform, exceed or violate can be any one of the following:

drop Drop the packet.

set-clp-transmit Set ATM CLP bit to 1.

set-dscp-transmit Set DiffServ codepoint value (0-63)

set-frde-transmit Set Frame Relay DE bit to 1

set-mpls-exp-transmit Set MPLS Experimental bits value (0-7).

set-mpls-topmost-transmit

Set MPLS Topmost Experimental bits value (0-7).

set-prec-transmit Set IP Precedence value (0-7).

transmit Transmit the packet.

cir-value Committed information rate (CIR) in bits per second at which the conform token bucket is updated.

bc-value Conform burst size in bytes represented as tokens in the conform token bucket.

pir-value Peak information rate in bits per second at which the peak token bucket is updated.



MQC policing implementation

Bandwidth limits for single rate policing and two rate policing are specified on the Police page of the MQC PHB group properties. Appropriate parameters can be set, depending on whether Single Rate or Two Rate policing has been selected

peak-burst-value Peak burst size in bytes represented as tokens in the peak token bucket.

action Action for conform, exceed or violate can be any one of the following:

drop Drop the packet.

set-clp-transmit Set ATM CLP bit to 1.

set-dscp-transmit Set IP DiffServ codepoint value (0-63).

set-frde-transmit Set Frame Relay DE bit to 1.

set-mpls-exp-transmit

Set MPLS Experimental bits value (0-7).

set-mpls-topmost-transmit

Set MPLS Topmost Experimental bits value (0-7).

set-prec-transmit Set IP Precedence value.

transmit Transmit the packet.



.

Guidelines for calculating the conform burst size and excess burst size are the same as those suggested for Policing rule normal and excess burst sizes. See Implementation on page 117.

Suitable actions for conform, exceed and violate must be defined as Policing Actions, and then selected on the Police Action page of the MQC PHB Group dialog box.

Valid actions are Drop and Transmit. In addition, transmitted packets can be re-marked with one or more of the following:

DiffServ codepoint (0-63)

MPLS Experimental (0-7)

ATM Cell Loss Priority bit set to 1

Frame Relay Discard Eligibility bit set to 1




Single rate policing

The following example shows settings for three PHB Policing Actions:

The following example gives the single rate policing bandwidth settings for a CoS called CoS1 and an MQC PHB group called PE1-CE1:


policy-map PE1-CE1

class CoS1

police 8000 1000 1000 conform-action transmit exceed-action set-dscp-transmit 0 violate-action drop

Two rate policing

The following example shows settings for three PHB Policing Actions:

PHB Policing Action Name Action Marking

Default Conform Transmit None

Exceed Action 1 Transmit Re-mark to DiffServ codepoint 0

Default Violate Drop N/A

CoS Name CIR CBS EBS

Conform Action

Exceed Action

Violate Action

CoS1 8000 1000 1000 Default Conform Action

Exceed Action 1

Default Violate Action


Default Conform Action Transmit None



The following example gives the two rate policing bandwidth settings for a CoS called CoS2 and an MQC PHB group called PE1-CE2:


policy-map PE1-CE2

class CoS 2

police 8000 1000 16000 8000 conform-action transmit exceed-action set-dscp-transmit 0 violate-action set-dscp-transmit 3 set-frde-transmit

Exceed Action 2 Transmit Re-mark to DSCP 0

Violate Action 1 Transmit Re-mark to DSCP 3 and set FR DE

CoS Name CIR CBS PIR PBS

Conform Action

Exceed Action

Violate Action

CoS2 8000 1000 16000 8000 Default Conform Action

Exceed Action 2

Violate Action 1




WFQ and LLQ using MQCTo configure class-based WFQ or LLQ using an MQC PHB group, set parameters on the Queue page of an MQC PHB group:

Bandwidth allocation

For all classes in the MQC PHB group, bandwidth can be specified by one of the options in the Interpret LLQ Weight as or Interpret CBWFQ Weight as drop-down lists.




You can also configure fair queuing by selecting the Fair-queue checkbox. Select Default to use the routers default flow queueing value or select Value and supply a value in the edit box.

Congestion avoidance (drop strategy)

Congestion avoidance is configured on the Congestion page of the MQC PHB group. The strategy can be either:

Queue limit (the device default or a selected value up to 8 192 000)

WRED (default or selected WRED PHB group)

A queue limit can be applied to the default class of service for devices that support this. However, at least one class in the policy-map must have a queuing feature,

when a queue-limit is applied to the default class of service.For full details of WRED, see WRED on page 142.

Class-Based Shaping using MQCCisco’s Class-Based Shaping applies traffic shaping based on average rate or peak rate to a traffic class. It is configured by commands within a policy map. It is implemented within Service Activator by applying an MQC PHB group specifying shaping.

Class-based shaping can also apply adaptive shaping to Frame Relay interfaces.

If the queue type is LLQ for a Class of Service, the Queue Weight checkbox is always checked and you must specify a non-zero queue weight. Fair-queuing is not allowed in combination with a queue type of LLQ so the Fair-queue checkbox is disabled with a queue type of LLQ.

If the queue type is CBWFQ for a Class of service, then the Queue Weight checkbox is enabled. You can specify either a queue weight, or fair-queuing or both. If you want neither, then CBWFQ should be de-selected for the Class of Service.

Note that if a WRED PHB group is selected, it must only have WRED set up and must only be linked to classes of service defined only by packet marking(s).



How class-based shaping works

Class-Based Shaping allows you to control access to the core network by constraining specific outbound traffic to a particular bandwidth. Excess traffic is delayed using a buffer, or queuing mechanism, to hold packets and shape the traffic when the data rate of the source is higher than expected. Traffic can be specified using access lists and class maps allowing a choice of up to 64 different traffic classes.

Shape type

You can select average rate shaping, peak rate shaping or default shaping.

Average rate shaping limits the transmission rate to the committed information rate (CIR) and ensures that the average amount of traffic sent conforms to the rate expected by the network.

Peak rate shaping allows traffic bursts above the average rate to occur if extra bandwidth is available in the network. However, packets may be dropped if network congestion occurs. A router calculates the peak rate of traffic using the formula:

Peak rate = CIR(1+Be/Bc)

where Be is the excess burst size and Bc is the normal burst size.

Default shaping allows only the CIR value to be set, and applies default values for Bc and Be.

Adaptive shaping

Adaptive shaping allows Frame Relay interfaces and sub-interfaces to react to Backward and/or Forward Explicit Congestion Notification (BECN/FECN) bits.

A BECN bit is set in a frame to indicate that a frame traveling in the opposite direction to the frame encountered congestion. The device responds by limiting the

On Frame Relay interfaces on distributed platforms, i.e. VIP-based devices, Distributed Traffic Shaping is implemented to configure traffic shaping. For details, see Example showing FRF.12 without traffic shaping on page 162.

When configuring shaping on Cisco 10000 devices, Default Shaping must be selected. On these devices, only the CIR can be specified; default values are always applied for Bc and Be.



bit rate of frames that it transmits in the opposite direction to a value that corresponds to the number of BECN bits received but not less than the specified minimum CIR value.

A FECN bit is set in a frame to indicate that it encountered congestion in its path from source to destination. The device responds by setting the BECN bit in frames that it transmits in the opposite direction. The number of frames sent with the BECN bit set matches the number of frames received with the FECN bit set.

Class-based shaping and CB-WFQ

Class-based shaping can be used in conjunction with CB-WFQ. This allows a packet that exceeds the shape parameters to be placed in a queue whose priority and allocated bandwidth is defined by the CoS to which the packet belongs.

Cisco commands

The Cisco command to implement average or peak rate shaping is as follows:

(config-pmap-c)shape {average | peak} cir [bc] [be]

The command to implement BECN adaptive shaping is as follows:

(config-pmap-c)shape adaptive mean-rate-lower-bound

The command to implement FECN adaptive shaping is as follows:

(config-pmap-c)fecn-adapt

Implementation

Class-based shaping is defined in Service Activator using the Shape page in an MQC PHB group.

Traffic within a particular class of service is identified by means of class maps and access lists depending on the level of classification granularity. The resultant traffic shaping policy map is then applied to a particular interface as a service policy.

The following values are specified per CoS on the Shape page of the MQC PHB group: CIR, Bc, Be, Minimum CIR.

cir Committed information rate (CIR) in bits per second

bc Normal burst size in bits

be Peak burst size in bits

mean-rate-lower-bound The minimum transmission bit rate that will be used in response to frames that have their BECN bits set




To implement class-based shaping in conjunction with CB-WFQ, appropriate CB-WFQ values need to be set up on the Queue page.


Average rate traffic shaping

The settings for this example are as follows:

MQC PHB Group: MQC1

CoS name: Silver

MQC Action: Shape

MQC Shaping parameters:

— Shape Type: Shape Average

— CIR: 56000

— Bc: 28000

— Be: 0

— FR Extension: Off




policy-map MQC1

class Silver

shape average 56000 28000 0

Peak rate traffic shaping

The settings for this example are shown below:

MQC PHB Group: MQC2

CoS name: Bronze

MQC Action: Shape

MQC Shaping parameters

— Shape Type: Shape Peak

— CIR:56000

— Bc: 28000

— Be:50

— FR Extension: Off


policy-map MQC2

class Bronze

shape peak 56000 28000 50

Adaptive shaping

The settings for this example are shown below:

MQC PHB Group: MQC3

CoS name: Bronze

MQC Action: Shape

MQC Shaping parameters

— CIR: 56000

— Bc: 28000

— Be: 0

— Shape Type: Shape Average

— FR Extension: On



— BECN Adapt: Selected

— Min CIR: 8000

— FECN Adapt: On


policy-map MQC3

class Bronze


shape adaptive 8000

shape fecn-adapt

Nesting MQC PHB groupsA child MQC PHB group may be nested inside a parent MQC PHB group. This provides a method of applying a policy to a broad range of traffic, defined by the parent MQC PHB group, and another to a subset of that range, defined by the child MQC PHB group. For example, a single shaping policy may be applied to all traffic on an interface by a parent MQC PHB group, while the child applies a queuing policy to one or more classes of service. The resulting configuration is referred to by Cisco as a ‘hierarchical service policy’.

A child MQC PHB group may be nested for a CoS to which Policing, Shaping or CB- WFQ is applied.

Nesting is mapped to the service-policy command. It effectively places a policy map (a child MQC PHB group) within a class map (CoS) that is part of another policy map (a parent MQC PHB group).



ImplementationNested MQC PHB groups can be defined in Service Activator using the Nest page on the MQC PHB group property dialog box:

Child MQC PHB groups must be set up first and then linked to the parent. The child PHB group must configure Policing, Shaping or CB-WFQ. Multiple levels of nesting can be set up, up to a maximum of 20.

Example configurationsThe settings for this example are as follows:

Child PHB group

CoS name: COS1

— MQC Action: LLQ

— LLQ parameters:

Interpret Weight as: Percentage

Weight: 10

CoS name: COS2

— MQC Action: WFQ



— WFQ Shaping parameters:

Interpret Weight as: Percentage

Weight : 90

Parent PHB group

CoS name: Default Class of Service

— MQC Action: Shape

— Nest

— Shape parameters:

CIR: 56000

Bc: 28000

Be: 0

Shape Type: Shape Average

FR Extension: No

— Nest parameters:

PHB group: Child PHB group


policy-map Child PHB Group

class COS1

priority percentage 10

class COS2

bandwidth percentage 90

policy-map Parent PHB Group

class class-default


service-policy Child PHB Group

Class map naming on Frame Relay interfacesService Activator configures Frame Relay map classes to implement the following PHB groups on Frame Relay interfaces:

FRTS/FRF.12 PHB groups

WFQ (optionally plus WRED) PHB groups



MQC PHB groups

WRR PHB groups

PQ PHB groups

By default, the Cisco device driver automatically generates a name for each map class as follows:

MapClass_number

where number is generated by the driver and is unrelated to any user-defined data. However, it is possible to override the device driver’s default action and specify that Frame Relay map-classes used to configure PHB groups have unique, predictable names based on the PHB group name. For information on the device driver command-line option used to implement this feature, see Command-line parameters on page 12.

Having a predictable map class name can improve diagnostics and facilitate integration with third-party reporting tools. It can also prevent a brief loss of connection occurring when the device driver changes a map class name and reapplies configuration even though the configuration has not changed.

Where user-defined map-class names are used, the device driver creates the map-class name by concatenating the names of all PHB groups applied to the interface, both inbound and outbound. For example, if two PHB groups called “FRTS PHB group” and “MQC Out” are applied to an interface, the map-class command would be as follows:

map-class frame-relay FRTS PHB Group-MQC Out

Note that when applying user-defined map class names, relevant PHB group names configured in the Service Activator user interface or via the OIM must be checked for compatibility with the following map-class naming conventions:

A “ character must be preceded by a backslash character, that is: \”

A PHB group name cannot have leading or trailing whitespace

A PHB group name cannot include a ‘?’ character

There are some restrictions on the use of this feature and we therefore recommend you consult Contacting Oracle Global Customer Support (GCS) before implementing it.

Note that this feature does not apply to classification rules and cannot be used when map classes are used to configure classification rules on the same interface as PHB groups.


Cisco IOS Device Support Guide – Fourth Edition Configuration of Measurement Features

Chapter 8

Configuration of Measurement Features

This chapter describes how the Cisco device driver configures NetFlow and Service Assurance Agent (SAA) on devices. It includes the following:

Overviews of NetFlow and SAA

Cisco configuration commands for NetFlow

Cisco configuration commands for SAA


Configuration of Measurement Features Cisco IOS Device Support Guide – Fourth Edition

NetFlowNetFlow generates flow-based statistics per interface, producing highly granular information. Flow-based statistics are gathered on the router and stored in a cache. At intervals, the router sends its stored information in the form of NetFlow UDP datagrams to collector software. Service Activator currently supports Cisco’s NetFlow FlowCollector and InfoVista’s Vista Plug-in for NetFlow. If you are using the InfoVista plug-in, you can view reports based on NetFlow statistics through the Service Activator user interface. For more information, see the Network and SLA Monitoring Guide.

Data can be exported in a range of UDP formats. Later formats support aggregation of the data before export from the device. Aggregating data reduces the bandwidth required between the router and the collection software and the amount of flows sent to the collector software for processing. If aggregation is configured, additional aggregation caches are maintained on the device, one for each aggregation scheme. As flows expire in the main cache, relevant information is extracted from the expired flow and the relevant flow entry in an aggregation cache is updated.

Data may be exported from the main NetFlow cache in v1, v5 or v7 format. Data is exported from the aggregation cache in v8 format.

For more information see the Configuring SLA Monitoring.

Configuring NetFlowNetFlow is configured on the device and enabled on each interface.

Cisco commands

The Cisco commands to configure NetFlow on the device are as follows:

ip flow-cache entries number

Defines the number of entries maintained in the NetFlow cache.

ip flow-cache timeout inactive value

Defines the number of seconds after which an inactive flow is timed out from the NetFlow cache.

Service Activator supports export in v1, v5 or v8 format.

You cannot export data from the device to more than one collection system when configuring NetFlow with Service Activator and can therefore export data from the main cache or a single aggregation cache.



ip flow-cache timeout active value

Specifies the number of minutes after which the active timer expires.

ip flow-export source interface

Specifies the source interface IP address used in the NetFlow export datagram. Service Activator always configures the address of the loopback interface.

ip flow-export version number

Specifies the version format used by the NetFlow export packets.

ip flow-export destination ip-address UDP-port

Specifies the IP address and UDP protocol-specific port number to which to export packets.

An aggregation cache is configured using the following commands:

ip flow-aggregation cache {as | destination-prefix | prefix | protocol-port | source-prefix}

Enables aggregation cache configuration mode where:

cache {entries number | timeout [active minutes | inactive seconds]}

Configures aggregation cache operational parameters where:

as configures the autonomous system aggregation cache scheme.

destination-prefix configures the Destination Prefix aggregation cache scheme.

prefix configures the Prefix aggregation cache scheme.

protocol-port configures the Protocol Port aggregation cache scheme.

source-prefix configures the Source Prefix aggregation cache scheme.

entries specifies the number of cached entries allowed in the aggregation cache. The default is 4096; the number of entries can be in the range 1024 to 524288.

timeout specifies the number of minutes that an active entry is active. The default is 30 minutes; the range is between 1 and 60 minutes.

inactive specifies the number of seconds that an inactive entry will stay in the aggregation cache before it times out. The default is 15 seconds; the range is between 10 and 600 seconds.



enabled

Enables an aggregation cache.

NetFlow is enabled on an interface by the following command:

ip route-cache flow

Example configurationThis section provides example NetFlow configurations, with and without aggregation applied.

Data aggregated and exported in v8 format

In this example, NetFlow was configured with the following values in the user interface:

ip flow-export source Loopback0

ip flow-export destination 192.168.0.178 9991

ip flow-aggregation cache prefix

cache timeout inactive 50

cache timeout active 50



enabled

Data exported in v5 format

In this example, NetFlow was configured with the following values:

The following commands are configured on devices to which this configuration is applied:

ip flow-cache entries 2000

ip flow-cache timeout inactive 50

ip flow-cache timeout active 50

.

.

.

ip flow-export source Loopback0

Note that the destination for exported NetFlow data is defined by the external collector system that is assigned to the device in Service Activator. For information on external systems, see the Configuring SLA Monitoring.



ip flow-export version 5

ip flow-export destination 192.177.0.102 9991

The following command is configured on each interface to which NetFlow is applied:

ip route-cache flow

Service Assurance AgentService Assurance Agent (SAA) measures key SLA metrics such as response time, network resources, availability, jitter, connect time and packet loss between two devices. Service Activator supports SAA between two Cisco routers. SAA is also referred to as Response Time Reporter (RTR).

For more information see the Network and SLA Monitoring Guide.

Operation typesAn operation performs the point-to-point connection test provided by SAA. Operations use synthetic packets placed in a network to collect data about the network. The packets simulate other forms of network traffic, depending on which type of operation is configured.

Service Activator supports the following operation types:

ICMP Echo

UDP Echo

TCP Connect

Jitter

TCP Connect, UDP and Jitter operations probe non-native services and require SA Agent Responder to be configured on the target device. This is automatically configured by Service Activator. For more information on SA Agent Responder, see SA Agent Responder on page 205.

Configuring the operationSAA operations are configured in RTR configuration mode, using the rtr global configuration command and the ID number of the operation to be configured. Every operation has a type and each type may have a number of parameters associated with it.



How Service Activator allocates RTR numbers

Every operation that is configured on a device must have a unique RTR number. Service Activator automatically allocates an RTR number to an operation based on the following:

A number indicating the SAA operation type.

The ToS bits.

The ID of the device that the operation queries. Service Activator applies an ID number to each device in a VPN to which SAA measurement has been applied.

The VPN ID. Service Activator applies an internal ID number to each VPN.

Reaction thresholds

All operation types can be configured to send threshold notifications and perform an action, such as sending an SNMP trap, when a threshold has been reached. For information on configuring an SNMP trap, see Manual pre-configuration for SAA on page 37.

It is also possible to enable error checking, check for timeout conditions and for connection loss in connection-oriented protocols.

SA Agent Responder

SA Agent Responder is embedded in the operation’s target routing device and allows the device to anticipate and respond to SAA request packets. It is enabled on the target device for UDP Echo, Jitter and TCP Connect operations as these operations use non-native services to test the connection.

Cisco commands

The Cisco command to enter RTR configuration mode is:

rtr number

where number is a unique identifier for the operation being configured (see How Service Activator allocates RTR numbers on page 205).

The operation type is defined in RTR configuration mode.

type echo protocol ipIcmpEcho ip-address

The number of SAA operations that can be configured on a Cisco device is limited by the router’s IOS and the hardware specification. Devices running IOS 12.1 or later support a maximum of 500 operations.



Configures an ICMP Echo operation where:

type udpEcho dest-ipaddr ipaddr dest-port port-number [control {enable | disable} ]

Configures a UDP Echo operation where:

type tcpConnect dest-ipaddr ipaddr dest-port port-number [control {enable | disable} ]

Configures a TCP Connect operation. The parameters are as described for the UDP Echo operation.

type jitter dest-ipaddr ipaddr dest-port port-number [control {enable | disable}] [num-packets number-of-packets] [interval inter-packet-interval]

Configures a Jitter operation. The parameters are as described for the UDP Echo operation with the following additions:

The following commands are automatically configured by Service Activator.

owner text

Configures the SNMP owner of the operation. For operations configured with Service Activator, text is OracleCommunications.

tag text

ip-address Destination IP address.

dest-ipaddr ipaddr Destination of the udpEcho operation.

dest-port port-number Destination port number. The range of port numbers is from 1 to 65,535.

control (Optional) Specifies that the SAA RTR control protocol should be used when running this operation.

enable Enables the SAA collector to send a control message to the destination port prior to sending a packet.

disable Disables the SAA from sending a control message to the responder prior to sending a packet.

num-packets number (Optional) Number of packets, as specified by the number argument. The default value is 10.

interval inter-packet-interval (Optional) Interpacket interval in milliseconds. The default value of the inter-packet-interval argument is 20 ms.



Logically links operations in a group. Service Activator configures tag with the customer name as specified in the user interface.

The following commands may optionally be configured for an operation.

frequency seconds

Sets the frequency for an SAA operation.

request-data-size bytes

Sets the protocol data size in the payload of the operation's request packet. Applies to ICMP Echo (default 28), UDP Echo (default 16), Jitter (default 32), and TCP (default 4) operations.

rtr reaction-configuration operation [verify-error-enable][connection-loss-enable] [timeout-enable] [threshold-falling milliseconds] [threshold-type option] [action-type option]

Configures the actions that occur based on events under the control of SAA where:

operation Number of the SA Agent operation to configure

verify-error-enable Enables error checking.

connection-loss-enable Enables checking for connection loss in connection-oriented protocols. The default is disabled.

timeout-enable Enables checking for response time reporting operation timeouts. The default is disabled.

threshold-falling milliseconds Sets the falling threshold. When the falling threshold is met, generate a resolution reaction event. The default value is 3000 ms.



threshold-type option Specifies the algorithm used by SAA to calculate threshold violations which define when action-type is performed. option is one of the following:

never – do not calculate threshold violations (default)

immediate – perform action when the response time exceeds the rising threshold or drops below the falling threshold

consecutive [occurrences] – perform action when the response time exceeds the rising threshold consecutively five times or drops below the falling threshold consecutively five times

xofy [x-value y-value] – perform action when the response time exceeds the rising threshold five out of the last five times or drops below the falling threshold five out of the last five times

average [attempts] – perform action when the average of the last five response times exceeds the rising threshold or when the average of the last five response times drops below the falling threshold



rtr schedule operation-number life seconds start-time now

Schedules the operation by configuring the time parameters.

threshold milliseconds

Configures the rising threshold (hysteresis) that generates a reaction event and stores history information for the operation.

timeout milliseconds

Sets the amount of time the operation waits for a response from its request packet.

tos

Defines the IP ToS byte for request packets.

The following command configures an SA Agent responder on a target device:

rtr responder

action-type option Specifies the action performed when connection-loss-enable or timeout-enable is configured, or threshold events occur. option may be one of the following:

none – no action is taken.

trapOnly – send an SNMP trap on both over and falling threshold violations.

nmvtOnly – send an SNA NMVT Alert on over threshold violation and an SNA NMVT Resolution on falling threshold violation.

triggerOnly – have one or more target operation's operational state make the transition from “pending” to “active” on over (and falling) threshold violations.

trapAndNmvt – send a combination of trapOnly and nmvtOnly.

trapAndTrigger – send a combination of trapOnly and triggerOnly.

nmvtAndTrigger – send a combination of nmvtOnly and triggerOnly.

trapNmvtAndTrigger – send a combination of trapOnly, nmvtOnly, and triggerOnly.



Example SAA configurationsThis section provides example configurations of SAA applied to a hub and spoke and fully-meshed VPN.

Hub and spoke

In this example, a TCP Connect operation is applied to the following hub and spoke VPN.

Service Activator’s default operation values were specified in the user interface except for the following:

Control is disabled

ToS set to 55

The following sections show the configuration installed on the hub and each spoke devices.

Configuration on hub site (CE1)

rtr responder

P

Service ProviderCore

Hub

PPE

CE1 CE2

CE3

PE

CE4

PE

CE5

Spoke Spoke

Spoke

Spoke



Configuration on spoke sites (CE2, CE3, CE4, CE5)

rtr 1074791353

type tcpConnect dest-ipaddr 10.0.0.24 dest-port 23 control disable

tos 0xDC

owner Orchestream

tag Acme

threshold 0

timeout 5

request-data-size 0

rtr schedule 1074791353 life forever start-time now

rtr reaction-configuration 1074791353 threshold-falling 0 threshold-type immediate

Fully-meshed

In this example, a Jitter operation is applied to the following fully-meshed VPN.

The following values were specified in the user interface:

P

Service ProviderCore

PPE

CE1 CE2

CE3

PE

CE4

PE

CE5

10.0.0.26

10.0.0.24 10.0.0.22

10.0.0.20

10.0.0.28





The following sections show the configuration installed on the hub and each spoke device.

CE1

!

rtr responder

!

rtr 1074791123

type jitter dest-ipaddr 10.0.0.20 dest-port 8000 num-packets 5 interval 25

tos 0x68

owner Orchestream

tag Acme

threshold 10

timeout 5

request-data-size 50


rtr reaction-configuration 1074791123 timeout-enable threshold-falling 10 threshold-type average 8

rtr 1074791135


tos 0x68

owner Orchestream

tag Acme

threshold 10

timeout 5




rtr 1074791179


tos 0x68

owner Orchestream

tag Acme



threshold 10

timeout 5




rtr 1074791191


tos 0x68

owner Orchestream

tag Acme

threshold 10

timeout 5




CE2

!

rtr responder

!

rtr 1074791123


tos 0x68

owner Orchestream

tag Acme

threshold 10

timeout 5




rtr 1074791157




tos 0x68

owner Orchestream

tag Acme

threshold 10

timeout 5




rtr 1074791179


tos 0x68

owner Orchestream

tag Acme

threshold 10

timeout 5




rtr 1074791191


tos 0x68

owner Orchestream

tag Acme

threshold 10

timeout 5






CE3

!

rtr responder

!

rtr 1074791123


tos 0x68

owner Orchestream

tag Acme

threshold 10

timeout 5




rtr 1074791135


tos 0x68

owner Orchestream

tag Acme

threshold 10

timeout 5




rtr 1074791157


tos 0x68

owner Orchestream

tag Acme

threshold 10

timeout 5






rtr 1074791179


tos 0x68

owner Orchestream

tag Acme

threshold 10

timeout 5




CE4

!

rtr responder

!

rtr 1074791123


tos 0x68

owner Orchestream

tag Acme

threshold 10

timeout 5




rtr 1074791135




tos 0x68

owner Orchestream

tag Acme

threshold 10

timeout 5




rtr 1074791157


tos 0x68

owner Orchestream

tag Acme

threshold 10

timeout 5




rtr 1074791191


tos 0x68

owner Orchestream

tag Acme

threshold 10

timeout 5




CE5

!



rtr responder

!

rtr 1074791135


tos 0x68

owner Orchestream

tag Acme

threshold 10

timeout 5




rtr 1074791157


tos 0x68

owner Orchestream

tag Acme

threshold 10

timeout 5




rtr 1074791179


tos 0x68

owner Orchestream

tag Acme

threshold 10

timeout 5






rtr 1074791191


tos 0x68

owner Orchestream

tag Acme

threshold 10

timeout 5





Cisco IOS Device Support Guide – Fourth Edition Troubleshooting

Chapter 9

Troubleshooting

This chapter provides hints and tips for diagnosing and fixing problems occurring with the Cisco device driver. It includes the following:

Monitoring the Cisco device driver logs

Communication problems and how to fix them

Useful Cisco IOS commands for checking configuration


Troubleshooting Cisco IOS Device Support Guide – Fourth Edition

Checking the Cisco audit logsEach installed instance of the Cisco device driver records all device configuration changes that it makes in a specific device audit log file. You can check these log files to see if configuration is being successfully applied to a device.

A new log file is created each day, the first transaction after midnight resulting in a new log file being created. The same log file is used if a device driver is stopped and started within a 24-hour period.

Log files are created in the AuditTrails directory:

On Solaris systems, by default this is /opt/OracleCommunications/ServiceActivator/AuditTrails

On Windows systems, by default this is Program Files\Oracle Communications\ServiceActivator\AuditTrails

Each file is named <day>.cisco.audit.log, e.g. Tue.cisco.audit.log. After a week, the log files are automatically overwritten, so you should archive them within this period if you want to keep them.

Log files are text files, recording the date, time and details of each configuration change made to the devices controlled by the device driver.

The following example shows commands passed to a device to implement MPLS VPNs:

Thu 25/10/01 14:04:43 UTC|10.0.0.93|Start Configuring

Thu 25/10/01 14:04:43 UTC|10.0.0.93|ip vrf Orch_1:6070

Thu 25/10/01 14:04:43 UTC|10.0.0.93|rd 1:6070

Thu 25/10/01 14:04:43 UTC|10.0.0.93|route-target import 1:6273

Thu 25/10/01 14:04:43 UTC|10.0.0.93|route-target export 1:6272

Thu 25/10/01 14:04:43 UTC|10.0.0.93|exit

Thu 25/10/01 14:04:43 UTC|10.0.0.93|interface Ethernet0/1

Thu 25/10/01 14:04:43 UTC|10.0.0.93|no ip address 10.135.135.1 255.255.255.0

Thu 25/10/01 14:04:44 UTC|10.0.0.93|exit


Thu 25/10/01 14:04:44 UTC|10.0.0.93|ip vrf forwarding Orch_1:6070

Thu 25/10/01 14:04:44 UTC|10.0.0.93|exit


Thu 25/10/01 14:04:44 UTC|10.0.0.93|ip address 10.135.135.1 255.255.255.0

Thu 25/10/01 14:04:44 UTC|10.0.0.93|exit

Thu 25/10/01 14:04:44 UTC|10.0.0.93|router bgp 1



Thu 25/10/01 14:04:44 UTC|10.0.0.93|address-family ipv4 vrf Orch_1:6070

Thu 25/10/01 14:04:44 UTC|10.0.0.93|redistribute static

Thu 25/10/01 14:04:44 UTC|10.0.0.93|no auto-summary

Thu 25/10/01 14:04:44 UTC|10.0.0.93|no synchronization

Thu 25/10/01 14:04:45 UTC|10.0.0.93|neighbor 10.136.135.2 remote-as 60

Thu 25/10/01 14:04:45 UTC|10.0.0.93|neighbor 10.136.135.2 update-source Ethernet0/1

Thu 25/10/01 14:04:45 UTC|10.0.0.93|neighbor 10.136.135.2 activate

Thu 25/10/01 14:04:45 UTC|10.0.0.93|neighbor 10.136.135.2 description Management Hub

Thu 25/10/01 14:04:45 UTC|10.0.0.93|neighbor 10.136.135.2 send-community both

Thu 25/10/01 14:04:45 UTC|10.0.0.93|neighbor 10.136.135.2 as-override

Thu 25/10/01 14:04:45 UTC|10.0.0.93|exit-address-family

Thu 25/10/01 14:04:45 UTC|10.0.0.93|exit

Communication problemsIf you are unable to communicate with a router, check the following:

Check that you can ping the device and telnet to it.

Ensure that enable passwords are correctly set up, using the or enable secret commands.

Ensure a password for the router’s VTY line is set up (check for a password command following the line vty 0 4)

Ensure that an SNMP Read community is set up on the device, e.g. the following command is included:


If a community other than “public” is used, you need to amend the appropriate parameter within Service Activator.

Useful Cisco commandsThere are a number of Cisco commands that can be useful when checking device configuration. For full details of the command syntax and an explanation of the reported information, see the Cisco documentation.



General configurationThe following commands report general status and configuration:

(config)show processes cpus

Displays detailed CPU statistics, allowing you to monitor router performance.

(config)show memory

Lists the amount of memory utilization.

(config)#show running-config

Lists the current Cisco router configuration

(config)#show version

Indicates the current Cisco IOS version and general information about the router.

(config)show tech-support

Displays the equivalent of the following show commands:

show buffers

show controllers

show interfaces

show running-config

show processes cpu

show processes memory

show stacks

show version

This is useful when diagnosing or reporting problems.

VPN configurationThe following commands are useful for checking the configuration of MPLS VPNs.

bgp log-neighbor-changes

This command can be added to the BGP configuration to enable logging of BGP neighbor status changes (up or down) and resets. It can be useful for troubleshooting network connectivity problems and measuring network stability. Unexpected neighbor resets might indicate high error rates or high packet loss in the network and should be investigated. If the UNIX syslog option is enabled, messages are set to the UNIX host running the syslog daemon so that the messages can be stored and archived.



show ip bgp neighbor

This command shows information about the BGP neighbor of the device. On the PE and CE routers, look for lines starting:

BGP state =

Alternatively use modifiers such as :include BGP to show only those lines including BGP.

There will be one line for each peer device. A state of Established means the VPN is functioning correctly. If it is not established, this could indicate that the ASN or neighbor IP address has not been set correctly on the Site property pages. Alternatively, tag switching may not be running. An example is as follows:

D7500-3#s ip bgp nei

BGP neighbor is 172.16.1.3, remote AS 1, internal link

BGP version 4, remote router ID 172.16.1.3

Last read 00:00:04, hold time is 180, keepalive interval is 60 seconds

Neighbor capabilities:

Route refresh: advertised and received

Address family VPNv4 Unicast: advertised and received

Received 60 messages, 0 notifications, 0 in queue

Sent 60 messages, 0 notifications, 0 in queue

Route refresh request: received 0, sent 0

Minimum time between advertisement runs is 5 seconds

show ip route

This command shows the IP routes on the device. Lines starting with B indicate routes using BGP. An example is as follows:

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route, o - ODR

Gateway of last resort is not set

BGP state = Established, up for 00:56:03



172.16.0.0/16 is variably subnetted, 11 subnets, 3 masks

B 172.16.12.32/30 [20/0] via 172.16.12.30, 00:17:38

B 172.16.12.16/30 [20/0] via 172.16.12.30, 00:17:02

C 172.16.12.24/30 is directly connected, Serial0/0.1

D 172.16.13.24/29 [90/2195456] via 172.16.12.26, 02:28:45, Serial0/0.1

C 172.16.12.28/30 is directly connected, Serial0/0.2

C 172.16.11.3/32 is directly connected, Loopback0

D 172.16.11.2/32 [90/2323456] via 172.16.12.26, 02:28:43, Serial0/0.1

D 172.16.11.1/32 [90/2297856] via 172.16.12.26, 03:11:48, Serial0/0.1

B 172.16.12.8/30 [20/0] via 172.16.12.30, 00:17:02

C 172.16.13.8/29 is directly connected, Ethernet0/0

B 172.16.12.12/30 [20/0] via 172.16.12.30, 00:17:38

B 192.168.4.0/24 [20/0] via 172.16.12.30, 00:17:38

10.0.0.0/32 is subnetted, 5 subnets

B 10.0.0.2 [20/0] via 172.16.12.30, 00:17:02

B 10.0.0.3 [20/0] via 172.16.12.30, 00:17:38

B 10.0.0.1 [20/0] via 172.16.12.30, 00:17:38

B 10.0.0.4 [20/0] via 172.16.12.30, 00:17:38

B 10.0.0.5 [20/0] via 172.16.12.30, 00:17:38

B 192.168.1.0/24 [20/0] via 172.16.12.30, 00:17:38

B 192.168.2.0/24 [20/0] via 172.16.12.30, 00:17:38

B 192.168.3.0/24 [20/0] via 172.16.12.30, 00:17:38

show ip route vrf <vrf name>

Shows the routing tables specific to the named VRF, that is, the VPNv4 table rather than the global routing table.

show tag-switching interfaces

This command indicates the interfaces on a device on which tag switching is enabled. You can list all interfaces on a device or specify a particular interface.

show ip bgp

Displays a list of all BGP neighbors for the device.

show ip bgp vpnv4

Displays VPN address information from the BGP routing table.



show ip vrf

Shows the set of VRFs and associated route targets. For example:

D4500-1#show ip vrf

Name Default RDInterfaces

FRED 10:1

Orch_598 1:1012 Serial1

show cdp neighbor

This command shows the direct connections to neighboring devices.

D7500-3#s cdp nei

Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge

S - Switch, H - Host, I - IGMP, r - Repeater

Device IDLocal InterfaceHoldtmeCapability PlatformPort ID

D7500-1 Eth 0/0134 R RSP4Eth 0/1/0

D2500-3 Eth 0/1176 R 2500Eth 0

D7500-3#

show tag forwarding

This command shows whether tag switching is operational on a particular device.

clear ip bgp

This command can be run on a PE device to reset BGP routing. If the wildcard is specified (clear ip bgp *), all BGP routing will be reset; alternatively a particular device can be specified. The device should start to relearn routes immediately, so you can use this command to clear BGP routing and then run the show ip bgp command to check if the routes are present.

clear ip route

This command can be run on a CE device to delete routes from the IP routing table. If the wildcard is specified (clear ip route *) all IP routing will be reset; alternatively a particular device can be specified. If BGP is running correctly, this will leave just BGP routes. You can run the show ip route command to check the routes.

Problems have been encountered in early releases of tag switching. You are recommended to use the latest version of IOS.



QoS configurationThe following commands are useful for checking the QoS configuration:

show interfaces

Use the show interfaces command with appropriate parameters to display information about implemented queuing mechanisms:

(config)show interfaces [interface-type interface-number] fair-queue

Displays information and all statistics about WFQ for all interfaces or a specific interface.

(config)show interfaces [interface-type interface-number] random-detect

Displays information about WRED for all interfaces or a specific interface.

(config)show interfaces [interface-type interface-number] rate-limit

Displays information about CAR for all interfaces or a specific interface.

show policy-map

(config)show [policy-map] policy-map

Displays information about all policy maps or a specific policy map.

(config)show policy-map [policy-map] class [class-name]

Displays information about the specified class within the specified policy map.

(config)show policy-map interface interface-name

Displays information about policy maps on the specified interface.

show queue

(config)show queue interface-name interface-number

Displays the contents of packets inside a queue for a specified interface.

show queuing

Use the show queuing command to display details of queuing strategies in use

(config)show queueing [custom | fair | priority | random-detect]

Displays details of the statuses of all or selected queuing strategies for a specified interface.

(config)show queueing interface interface-number

Displays the queuing strategy and statistics of an interface or a VC.



show access-lists

(config)show access-lists <number> -

Displays all access lists or a selected access list. You can use this command to ensure that all access lists are in the correct order, with global deny or permit always appearing at the end of the list.

Measurement configurationThe following commands can be used to check SAA and NetFlow configuration.

SAA

show rtr conf

NetFlow

show ip cache flow aggregation

(monitor and maintain aggregation schemes).

show ip flow export

(monitor and maintain aggregation schemes data export).

Debugging commandsFor details of using Cisco debug commands to enable diagnostics and diagnose problems, see the debug command reference:

www.cisco.com/univercd/cc/td/doc/product/software/ios121/121sup/121debug/index.htm


http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121sup/121debug/index.htm



Cisco IOS Device Support Guide – Fourth Edition Useful References

Chapter 10

Useful References

This chapter provides links to useful pages on the Cisco website and suggestions for further reading.


Useful References Cisco IOS Device Support Guide – Fourth Edition

Cisco websiteFull information about Cisco routers, including comprehensive technical documentation, is available from the Cisco website. The following are particularly useful:

Index to all Cisco documentation

www.cisco.com/univercd/home/home.htm

QoS configuration guide for IOS 12.2, which provides explanations of QoS solutions and techniques:

www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/index.htm

QoS reference guide for IOS 12.2, which provides details of IOS commands for implementing QoS:

www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_r/index.htm

Release notes for IOS 12.2, which list caveats for different router platforms:

www.cisco.com/univercd/cc/td/doc/product/software/ios122/122relnt/index.htm

General feature support

The Feature Navigator allows you to find out what platforms, IOS versions and feature sets support particular features. Login as registered user required.

www.cisco.com/cgi-bin/Support/FeatureNav/FN.pl

Configuring MPLS VPNs

www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/vpn.htm#xtocid117432

Modular QoS CLI

www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120xe/120xe5/mqc/mcli.htm

Configuring SAA

www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/ffun_r/ffrprt3/frf017.htm

Configuring NetFlow

www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/netflsol/nfwhite.htm


http://www.cisco.com/univercd/home/home.htm

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/index.htm

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_r/index.htm



http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121relnt/index.htm



http://www.cisco.com/cgi-bin/Support/FeatureNav/FN.pl

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/vpn.htm#xtocid117432

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120xe/120xe5/mqc/mcli.htm



http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/ffun_r/ffrprt3/frf017.htm

http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/netflsol/nfwhite.htm

Cisco IOS Device Support Guide – Fourth Edition Useful References

IETF RFCsRFC 2474, Definition of the Differentiated Services Field in the IPv4 and IPv6 Headers, Nichols, Blake, Baker and Black, December 1998

RFC 2475, An Architecture for Differentiated Services, December 1998

RFC 3290, An Informal Management Model for Diffserv Routers, Bernet, Blake, Grossman and Smith, May 2002

RFC 2697, A Single Rate Three Color Marker, J. Heinanen, Telia Finland and R. Guerin, September 1999

RFC 2698, A Two Rate Three Color Marker, J. Heinanen, Telia Finland and R. Guerin, September 1999

RFC 2547bis, BGP/MPLS VPNs, Rosen and Rekhter, March 1999

RFC 1771, A Border Gateway Protocol 4 (BGP4) Rekhter and Li, March 1995

RFC 2858, Multiprotocol Extensions for BGP4, Bates, Chandra, Katz and Rekhter, June 2000

RFC 3036, LDP Specification, Andersson, Doolan, Feldman, Fredette and Thomas, January 2001

RFC 3031, Multiprotocol Label Switching Architecture, Rosen, Viswanathan and Callon, January 2001

For the initial IETF descriptions of Layer 2 Martini VPNs, refer to the following sources:

IETF Internet Draft, Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks, Martini, L. et al, draft-martini-l2circuit-encap-mpls-04.txt, work-in-progress.

IETF Internet Draft, Transport of Layer 2 Frames Over MPLS, Martini, L. et al, draft-martini-l2circuit-trans-mpls-08.txt, work-in-progress.


Useful References Cisco IOS Device Support Guide – Fourth Edition


Cisco IOS Device Support Guide – Fourth Edition MPLS VPN Device Configuration

Appendix A

MPLS VPN Device Configuration

This appendix provides example configurations of the routers involved in an MPLS VPN. The following examples are given:

The initial configuration of PE and CE devices before the VPN is set up, showing the necessary manual pre-configuration.

The configuration of PE devices after a management VPN has been set up.

The configuration of PE devices after both management and customer VPNs have been created.


MPLS VPN Device Configuration Cisco IOS Device Support Guide – Fourth Edition

Sample networkThe network associated with the sample configuration files is as follows:

A management VPN is set up comprising the Management site and all other sites. With Service Activator running at the management site, all CE routers can be managed.

Customer VPN 1 comprises sites 1, 2 and 4.

Customer VPN 2 comprises sites 1, 3 and 5.

Note that in order to configure the management VPN, two links are required between the management site and the core network, one to provide VPN connectivity and one to provide routes to the Service Provider backbone IGP:

AS 102EBGP

AS 100EBGP

3600_PE2

2600_CE3

CE

CE

CE

CE

CE

CE

PE PE

3600_PE1

mgmtCE

2600_CE2

2600_CE1

2600_CE5

2600_CE4

Service Provider CoreNetwork

Management Site runningService Activator

Site 1

Site 2

Site 3

Site 4

Site 5

AS 101EBGP

OSPF

RIP

Static

IGP (EIRGP) routingbetween PEs

AS 1



Note that the interfaces at both ends of the Serial 0.1 link between PE1 and MgmtCE, i.e. the link that is not to be used for the VPN connection, must be assigned a role of Disabled within Service Activator to prevent them being configured into a VPN.

Base configurationsThis section shows the configuration of the CE and PE devices before the VPN is set up and before any configuration is installed by Service Activator. Note that the CE devices must be configured manually.

Configuration of mgmtCEThe following shows the basic configuration of the CE device at the management site. Note that two sub-interfaces must be defined and BGP is configured. Note in particular the highlighted commands which you should ensure are applied before you configure the VPN.

Note that the interface or sub-interface that is in the Management VPN and thus provides routes to the CE are configured as passive. This is so that routes from the customer networks are not leaked into the Service Provider backbone, and vice versa.

For details of the steps required to set up management and customer VPNs, see the Configuring VPN Services guide.

3600_PE1

MgmtCE

Management Site runningService Activator

S0.2 172.16.12.29/30

S0.1 172.16.12.25/30

S1/0.2 172.16.12.30/30

S1/0.1 172.16.12.26/30

CE

PE



interface Loopback0

ip address 172.16.11.3 255.255.255.255

!


ip address 172.16.13.9 255.255.255.248

!

interface Serial0/0


!


ip address 172.16.12.25 255.255.255.252


!


ip address 172.16.12.29 255.255.255.252


!

router eigrp 1

network 172.16.0.0

!

!


!

line vty 0 4

password cisco

login

passive-interface Serial0/0.2

router bgp 100

no synchronization



no auto-summary



Configuration of customer site routers using EBGPThe following shows the basic configuration of device 2600_CE1 at Site 1, which uses EBGP. The configuration of 2600_CE2 is comparable.

!

hostname 2600_CE1

!

enable secret 5 $1$8KWK$jaS7W4RHC29BJzYyZo2/D1

!

interface Loopback0

ip address 10.0.0.1 255.255.255.255

!


ip address 192.168.1.1 255.255.255.0

!

interface Serial0/0

ip address 172.16.12.34 255.255.255.252


!

!


!

line vty 0 4

password cisco

login

router bgp 101

no synchronization



no auto-summary



Configuration of customer site routers using OSPFThe following shows the basic configuration of device 2600_CE3 at Site 3. Note the configuration of OSPF.

!

hostname 2600_CE4

!


!

interface Loopback0

ip address 10.0.0.4 255.255.255.255

!


ip address 192.168.4.1 255.255.255.0

!

interface Serial0/0

ip address 172.16.12.18 255.255.255.252


!

!


!

line vty 0 4

password cisco

login

router ospf 1


passive-interface Ethernet0/0

network 10.0.0.0 0.255.255.255 area 0



Configuration of customer site routers using RIPThe following shows the basic configuration of device 2600_CE4 at Site 4. Note the configuration of RIP.

!

hostname 2600_CE4

!


!

interface Loopback0

ip address 10.0.0.4 255.255.255.255

!


ip address 192.168.4.1 255.255.255.0

!

interface Serial0/0

ip address 172.16.12.18 255.255.255.252


!

!


!

line vty 0 4

password cisco

login

router rip

version 2


network 172.16.0.0

no auto-summary



Configuration of customer site routers using static routingThe following shows the basic configuration of device 2600_CE5 at Site 5. Note the configuration of static routing.

!

hostname 2600_CE5

!


!

interface Loopback0

ip address 10.0.0.5 255.255.255.255

!


ip address 192.168.5.1 255.255.255.0

!

interface Serial0/0

ip address 172.16.12.22 255.255.255.252


no ip route-cache

no ip mroute-cache

!


!

line vty 0 4

password cisco

login

Base configuration of 3600_PE1The following shows the configuration of this device before the VPN is set up and before any configuration is installed by Service Activator. Note in particular the highlighted commands which you should ensure are applied before you configure the VPN. For more information about these commands, see Mandatory manual configuration for MPLS VPNs on page 28.

!

hostname 3600_pe1

ip route 0.0.0.0 0.0.0.0 Serial0/0 172.16.12.21



!

frame-relay switching

!

!


ip address 172.16.13.25 255.255.255.248


!


no ip address


shutdown

!


no ip address


shutdown

!


no ip address


shutdown

!

interface Serial1/0

no ip address



ip cef

mpls label switching protocol

interface Loopback0

ip address 172.16.11.1 255.255.255.255


mpls ip



clockrate 2015232

frame-relay intf-type dce

!


ip address 172.16.12.26 255.255.255.252



!


ip address 172.16.12.30 255.255.255.252



!

interface Serial1/1

ip address 172.16.12.9 255.255.255.252


clockrate 63960

!

interface Serial1/2

ip address 172.16.12.33 255.255.255.252


clockrate 2015232

!

interface Serial1/3

no ip address


shutdown

!

!

router eigrp 1


network 172.16.0.0

router bgp 1

no synchronization



!

ip classless

no ip http server

!

!

snmp-server engineID local 00000009020000014219AFC0


!

line con 0

transport input none

line aux 0

line vty 0 4

password cisco

login

Base configuration of 3600_PE2The following shows the configuration of this device before the VPN is set up and before any configuration is installed by Service Activator. Note in particular the highlighted commands which need to be applied before you configure the VPN.

!

hostname 3600_pe2

!

ip subnet-zero

!

!


no bgp default ipv4-unicast

no auto-summary

ip cef


interface Loopback0

ip address 172.16.11.2 255.255.255.255



ip address 172.16.13.26 255.255.255.248


no ip address


shutdown

!


no ip address


shutdown

!


no ip address


shutdown

!

interface Serial1/0

ip address 172.16.12.13 255.255.255.252


clockrate 2015232

!

interface Serial1/1

ip address 172.16.12.17 255.255.255.252


clockrate 2015232

!

interface Serial1/2

ip address 172.16.12.21 255.255.255.252


clockrate 2015232

!

interface Serial1/3

no ip address


mpls ip



shutdown

!

!

!

snmp-server engineID local 00000009020000014219AAC0


!

line con 0


line aux 0

line vty 0 4

password cisco

login

!

end

Management VPNThis section shows the configuration of the PE devices after the management VPN has been configured.

Configuration of 3600_PE1The following shows the configuration of 3600_PE1 after the management VPN has been configured. Note in particular the highlighted commands, which show configuration added to the base configuration by Service Activator.

hostname 3600_pe1

!

router eigrp 1

network 172.16.0.0

router bgp 1

no synchronization


no auto-summary




!

!

ip subnet-zero

!

!

!

!


!

!

interface Loopback0

ip address 172.16.11.1 255.255.255.255


!

ip cef


ip vrf Orch_958

rd 1:958



ip vrf Orch_962

rd 1:962

maximum routes 55



ip vrf Orch_966

rd 1:966

export map my_export_map

maximum routes 55 warning-only






ip address 172.16.13.25 255.255.255.248


mpls ip

!


no ip address


shutdown

!


no ip address


shutdown

!


no ip address


shutdown

!

interface Serial1/0

no ip address



clockrate 2015478


!


ip address 172.16.12.26 255.255.255.252



!


ip address 172.16.12.30 255.255.255.252

ip vrf forwarding Orch_958





!

interface Serial1/1

ip address 172.16.12.9 255.255.255.252


clockrate 63960

!

interface Serial1/2

ip address 172.16.12.33 255.255.255.252


clockrate 2015232

!

interface Serial1/3

no ip address


shutdown

!

router eigrp 1


network 172.16.0.0

!

router bgp 1

no synchronization

no auto-summary

!





no neighbor 10.0.0.13 activate

address-family ipv4 vrf Orch_966




!

!

neighbor 172.16.12.34 description

neighbor 172.16.12.34 update-source Serial1/2


neighbor 172.16.12.34 send-community standard

neighbor 172.16.12.34 as-override

neighbor 172.16.12.34 allowas-in 4

neighbor 172.16.11.1 password v6lne0qkel33&

no auto-summary

no synchronization

exit-address-family







neighbor 172.16.12.14 prefix-list my_prefix_list_in in

neighbor 172.16.12.14 prefix-list my_prefix_list_out out

neighbor 172.16.12.14 route-map route_map

no auto-summary

no synchronization

exit-address-family



neighbor 172.16.12.29 update-source Serial1/0.2






!

!

ip classless

no ip http server

!



!

line con 0


line aux 0

line vty 0 4

password cisco

login

!

end

neighbor 172.16.12.29 maximum-prefix 10 warning-only

no auto-summary

no synchronization

exit-address-family

address-family vpnv4




no auto-summary

exit-address-family

alias ip-vrf Orch_rd_958 Management Site,

alias ip-vrf Orch_rd_962 Site 2,


alias ip-vrf Orch_rt_1100 Management VPN,


alias exec Orchestream Last configured on : Fri May 05 12:40:37 2000 UTC



Configuration of 3600_PE2The following shows the configuration of 3600_PE2 after the management VPN has been configured. Note in particular the highlighted commands, which show configuration added to the base configuration by the Cisco device driver. In this case, OSPF, RIP and static routes are configured.

hostname 3600_pe2

!

enable secret 5 $1$EnTd$eHLNWRT55GAMmkHl7hFHw.

!

ip subnet-zero

ip cef


!

!

!

!

interface Loopback0

ip address 172.16.11.2 255.255.255.255


ip vrf Orch_1012

rd 1:1012




ip vrf Orch_1016

rd 1:1016



ip vrf Orch_1020

rd 1:1020





!


ip address 172.16.13.26 255.255.255.248


mpls ip

!


no ip address


shutdown

!


no ip address


shutdown

!


no ip address


shutdown

!

interface Serial1/0

ip address 172.16.12.13 255.255.255.252


clockrate 2015232

!

interface Serial1/1

ip address 172.16.12.17 255.255.255.252


clockrate 2015232

!





interface Serial1/2

ip address 172.16.12.21 255.255.255.252


clockrate 2015232

!

interface Serial1/3

no ip address


shutdown

!

router eigrp 1

network 172.16.0.0

!

!


router ospf 1

passive-interface Ethernet 0/0

network 10.0.0.0 255.255.255.255 area 0

router ospf 249 vrf Orch_1012

router-id 10.0.0.4

log-adjacency changes

redistributed connected subnets

redistribute static subnets

redistribute bgp 1 metric 20 subnets

redistribute rip subnets

network 10.0.0.4 0.0.0.0 area 0

router rip

version 2



!

!

!

!

!


version 2

redistribute bgp 1 metric 2

network 172.16.0.0

no auto-summary

exit-address-family

router bgp 1

no synchronization




no auto-summary


redistribute static

no auto-summary

no synchronization

exit-address-family


redistribute rip

no auto-summary

no synchronization

exit-address-family


redistribute ospf 249 match internal external 1 external 1

no auto-summary



!

!

ip classless

no ip http server

!

!

line con 0


line aux 0

line vty 0 4

password cisco

login

!

end

no synchronization

exit-address-family




no auto-summary

exit-address-family

ip route vrf Orch_1020 10.0.0.5 255.255.255.255 Serial1/2 172.16.12.22












Management and customer VPN configuration

Configuration of 3600_PE1The following shows the configuration of 3600_PE1 after the management and customer VPNs have been configured. Note in particular the highlighted commands, which show additional route-target commands added to the previous configuration by Service Activator.

hostname 3600_pe1

!


!

!

ip subnet-zero

ip cef


!

!

ip vrf Orch_958

rd 1:958



!

ip vrf Orch_962

rd 1:962

maximum routes 55



!

ip vrf Orch_966

rd 1:966






maximum routes 55 warning-only




!

!

interface Loopback0

ip address 172.16.11.1 255.255.255.255


!


ip address 172.16.13.25 255.255.255.248


mpls ip

!


no ip address


shutdown

!


no ip address


shutdown

!


no ip address


shutdown

!







interface Serial1/0

no ip address



clockrate 2015478


!


ip address 172.16.12.26 255.255.255.252



!



ip address 172.16.12.30 255.255.255.252



!

interface Serial1/1


ip address 172.16.12.9 255.255.255.252


clockrate 63960

!

interface Serial1/2


ip address 172.16.12.33 255.255.255.252


clockrate 2015232

!

interface Serial1/3

no ip address


shutdown

!



router eigrp 1


network 172.16.0.0

!

router bgp 1

no synchronization




no auto-summary

!







neighbor 172.16.12.34 allowas-in 4

neighbor 172.16.11.1 password v6lne0qkel33&

no auto-summary

no synchronization

exit-address-family

!







neighbor 172.16.12.14 prefix-list my_prefix_list_in in

neighbor 172.16.12.14 prefix-list my_prefix_list_out out

neighbor 172.16.12.14 route-map route_map

no auto-summary

no synchronization

exit-address-family



!



neighbor 172.16.12.29 update-source Serial1/0.2




neighbor 172.16.12.29 maximum-prefix 10 warning-only

no auto-summary

no synchronization

exit-address-family

!




no auto-summary

exit-address-family

!

ip classless

no ip http server

!



alias ip-vrf Orch_rd_958 Management Site,






!

line con 0


alias ip-vrf Orch_rt_1084 Customer 1,




line aux 0

line vty 0 4

password cisco

login

!

end

Configuration of 3600_PE2The following shows the configuration of 3600_PE2 after the management and customer VPNs have been configured. Note in particular the highlighted commands, which show the additional route-target commands added to the previous configuration by Service Activator.

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname 3640_pe2

!

enable secret 5 $1$EnTd$eHLNWRT55GAMmkHl7hFHw.

!

ip subnet-zero

ip cef


!

!

ip vrf Orch_1012

rd 1:1012



!





ip vrf Orch_1016

rd 1:1016



!

ip vrf Orch_1020

rd 1:1020



!

interface Loopback0

ip address 172.16.11.2 255.255.255.255


!


ip address 172.16.13.26 255.255.255.248


mpls ip

!


no ip address


shutdown

!


no ip address


shutdown

!








no ip address


shutdown

!

interface Serial1/0


ip address 172.16.12.13 255.255.255.252


clockrate 2015232

!

interface Serial1/1


ip address 172.16.12.17 255.255.255.252


clockrate 2015232

!

interface Serial1/2


ip address 172.16.12.21 255.255.255.252


clockrate 2015232

!

interface Serial1/3

no ip address


shutdown

!

router eigrp 1

network 172.16.0.0

!

router rip

version 2

!




version 2

redistribute bgp 1 metric 2

network 172.16.0.0

no auto-summary

exit-address-family

!

router bgp 1

no synchronization




no auto-summary

!


redistribute static

no auto-summary

no synchronization

exit-address-family

!


redistribute rip

no auto-summary

no synchronization

exit-address-family

!






no auto-summary

no synchronization

exit-address-family

!






no auto-summary

exit-address-family

!

ip classless



no ip http server

!

!









!

line con 0


line aux 0

line vty 0 4

password cisco

login

!

end






Cisco IOS Device Support Guide – Fourth Edition Protocols Supported by NBAR

Appendix B

Protocols Supported by NBAR

This appendix lists the protocols supported by NBAR.


Protocols Supported by NBAR Cisco IOS Device Support Guide – Fourth Edition

NBAR can classify the following three types of protocols:

Non-UDP and non-TCP IP protocols

TCP and UDP protocols that use statically assigned port numbers

TCP and UDP protocols that dynamically assign port numbers

Table 1: IP protocol port numbers

Protocol Description Syntax

EGP Exterior Gateway Protocol egp

GRE Generic Routing Encapsulation gre

ICMP Internet Control Message Protocol icmp

IPINIP IP in IP ipinip

IPsec IP Encapsulating Security Payload/ Authentication Header

ipsec

EIGRP Enhanced Interior Gateway Routing Protocol

eigrp



Table 2: TCP and UDP application protocols that use statically assigned port numbers


BGP Border Gateway Protocol bgp

CU-SeeMe Desktop videoconferencing cuseeme

DHCP/BOOTP

Dynamic Host Configuration Protocol/ Bootstrap Protocol

dhcp

DNS Domain Name System dns

Finger Finger user information protocol finger

Gopher Internet Gopher Protocol gopher

HTTP Hypertext Transfer Protocol http

HTTPS Secured HTTP secure-http

IMAP Internet Message Access Protocol imap

IRC Internet Relay Chat irc

Kerberos Kerberos Network Authentication Service

kerberos

L2TP L2F/L2TP tunnel l2tp

LDAP Lightweight Directory Access Protocol ldap

MS-PPTP Microsoft Point-to-Point Tunneling Protocol for VPN

pptp

MS-SQLServer Microsoft SQL Server sqlserver

NetBIOS NetBIOS over IP (MS Windows) netbios

NFS Network File System nfs

NNTP Network News Transfer Protocol nntp

Notes Lotus Notes notes



Novadigm Novadigm Enterprise Desktop Manager (EDM)

novadigm

NTP Network Time Protocol ntp

PCAnywhere Symantec PCAnywhere pcanywhere

POP3 Post Office Protocol pop3

Printer Printer printer

RIP Routing Information Protocol rip

RSVP Resource Reservation Protocol rsvp

SFTP Secure FTP secure-ftp

SHTTP Secure HTTP secure-http

SIMAP Secure IMAP secure-imap

SIRC Secure IRC secure-irc

SLDAP Secure LDAP secure-ldap

SNNTP Secure NNTP secure-nntp

SMTP Simple Mail Transfer Protocol smtp

SNMP Simple Network Management Protocol snmp

SOCKS Firewall security protocol socks

SPOP3 Secure POP3 secure-pop3

SSH Secured Shell ssh

STELNET Secure Telnet secure-telnet

Syslog System Logging Utility syslog

Telnet Telnet Protocol telnet

X Windows X11, X Windows xwindows




Table 3: TCP and UDP protocols that dynamically assign port numbers


FTP File Transfer Protocol ftp

Exchange MS-RPC for Exchange exchange

HTTP HTTP with URL, MIME, or Host classification

http

Netshow Microsoft Netshow netshow

Realaudio RealAudio Streaming Protocol realaudio

r-commands rsh, rlogin, rexec rcmd

StreamWorks Xing Technology Stream Works audio and video

streamwork

SQL*NET SQL*NET for Oracle sqlnet

SunRPC Sun Remote Procedure Call sunrpc

TFTP Trivial File Transfer Protocol tftp

VDOLive VDOLive Streaming Video vdolive




Cisco IOS Device Support Guide – Fourth Edition Index

Index

AABR 166, 168Access lists 94, 99

extended 95named 94range 95

Access rulesexample configuration 100explanation 98implementation 99

ACLs 94Adaptive shaping 191ASN

override in AS_PATH 41ATM

interfaces 3service classes 166Traffic Shaping 166

ATM Cell Loss Priority bit 186ATM Traffic Shaping 166

commands 167example configuration 169implementation 167

Audit logs 222Authentication 21Average rate shaping 191

BBECN 157, 191BGP

autonomous systems 40communities 45domain-level parameters 40

Burst interval 154Burst rate 154Byte count for Custom Queuing 126

CCAR

marking 104, 106policing 114

CBR 166CB-WFQ

with class-based shaping 192CE routers

example configurations 237manual configuration 31

CEF 97for NBAR 37on P routers 30on PE routers 29

Check and force consistency 22Cisco commands

debugging 229general configuration 224QoS configuration 228

Cisco documentation 232cisco.device.device_information.cfg 2cisco.interface.device_information.cfg 2cisco.os.device_information.cfg 2cisco.postadd.device_information.cfg 2cisco.postremove.device_information.cfg 2Class map 134, 176

specifying class map names 197Class-based policing

example configuration 187implementation 185

Class-Based Shapingcommands 192example configurations 193, 196explanation 191

Class-based WFQ 132, 138Classification rules

example using route maps 103explanation 101


Index Cisco IOS Device Support Guide – Fourth Edition

Classification techniquesaccess lists 94class maps 96, 176HTTP 96MIME 96MQC 176NBAR 96route maps 176URL 96

clear ip bgp command 227clear ip route command 227Command-line interface 21Command-line options 105, 106Command-line parameters

details 12on Solaris 15on Windows 16

Committed Access Rate 104, 114Communication problems 223Configuration examples

base configurations 237customer VPNs 258hub and spoke VPNs 258management VPNs 247PE base configuration 242

Configuration files 2Configuration timeout period 14Conform action 118, 186Congestion-avoidance techniques 142Custom Queuing

calculating byte count 126commands 125example configuration 128explanation 125implementation 126on Frame Relay interfaces 128

customer support xii

DDE bit 133Debugging commands 229Denying traffic 94Device discovery 42Device logs 222Device roles 42DiffServ codepoints 101Discovery 42documentation

downloading xiiService Activator xiii

Drop strategy 133Drop strategy for CB-WFQ 133DTS

CIR 163commands 164example configuration 164explanation 163

Dynamically-assigned port numbers 96, 273

EeBGP

ASN in AS_PATH 57local preference 59prefix limits 59

Enable passwords 223Exceed action 118, 186Export maps

configuring 32, 33pre-defined 32, 33

FFeature sets 3FECN 157, 192Filtering 94Flow-based WFQ 129Frame Relay

adaptive shaping 191DE bit 133Discard Eligibility bit 186interfaces, specifying class map names 197Traffic Shaping 155

Frame Relay Traffic ShapingCIR 156commands 157example configuration 161explanation 155implementation 158with LLQ 170

FRF.12 fragmentation 157FRTS 123

GGeneric Traffic Shaping

commands 153example configuration 155



explanation 153implementation 153

GTScommands 153example configuration 155explanation 152implementation 153

HHub and spoke VPNs 44

IiBGP

MD5 authentication 41, 56, 71on PE routers 29peering 40

ICMP Echo 204IGP

on P routers 30on PE routers 29

InfoVista 202Interface capabilities 21Interface roles 42Interface types 3interface-less VRF 49IP Precedence 101

JJitter 6, 204

LLayer 2 Martini VPNs 79

creating a VPN 88deleting sub-interfaces 91encapsulation types 80modifying a VPN 89overview of creation 82provisioning endpoints (VC IDs) 87provisioning sub-interfaces 86supported features 8

LLQ 132, 170commands 134example configuration 139with class-based WFQ 134with FRTS 170

Local preference 57Log files 222Logs 222

Loopback interface 29, 41Low Latency Queuing 132, 170

MManagement VPNs 44Manual configuration for MPLS VPNs

VRF tables 22Marking

CAR 104explanation 101methods 101MPLS Experimental bits 109NBAR 109policy maps 108re-marking packets 115route maps 102

MarkingStrategy command line directive 107, 108

Maximum paths, in VPNs 41, 55, 60MBS 167MCR 167MD5 authentication

PE to PE 41, 56, 71Mesh VPNs 44MIME matching 96MPLS configuration

on PE routers 29MPLS experimental bits 101MPLS Topmost experimental bits 101MPLS VPN configuration

mandatory 28optional 31

MPLS VPNsconfiguring 39device roles 42discovery 42example configurations 235hub and spoke route targets 45PE-CE configuration 57, 62, 67, 71pre-requisites 40route distinguishers 43route targets 45VRF tables 42

MQCclass-based shaping 190classification methods 176marking 180

MQC PHB group



class-based shaping 190classification 96LLQ 189marking 102, 180policing 185WFQ 189

NNBAR 37, 96, 109, 178NBAR protocols supported 269NetFlow

aggregation 200configuring 200description 200example configurations 202

nrt-VBR 166, 168

PP routers pre-configuration 30Packet marking 101Passwords 223PCR 166PE routers pre-configuration 28Peak rate shaping 191PE-CE configuration

local preference 57static routes 73

PHB groupsATM Traffic Shaping 167Priority Queuing 121, 122Rate Limiting 152WFQ 129, 132WRED 142WRR 125

Policing rules 115example configuration 187

Policy maps 108, 176, 178Pre-defined

export maps 32, 33prefix list filters 34route targets 46VRF tables 31VRF tables, removing 31, 48

Prefix limits 59Prefix list filters

examples 36pre-defined 34

Prefix lists 35

Priority Queuingcommands 121example configuration 123explanation 120implementation 122

productsdownloading xii

QQoS features 5, 93

RRate limiting 152rate-limit command 115RD number

per VPN 44RD numbers 43Read community 28Re-marking packets 186Response Time Reporter 204RFCs 233Role assignment 42Route distinguishers 43Route maps 102Route reflectors 40Route targets 45

in hub and spoke VPNs 45user-defined 46

Router pre-configuration 27, 40RT numbers 45RTR 204RTR numbers 205rt-VBR 166

SSAA

configuring 204description 204example configurations 210manual pre-configuration 37

SCR 167Secure Shell 20, 21Securing TCP connections 41, 56, 71Security 21Service Application Point 49Shareable VRF tables 47show cdp neighbor command 227show interfaces command 228



show ip bgp command 226show ip bgp neighbor command 225show ip bgp vpnv4 command 226show ip route command 225show ip route vrf command 226show ip vrf command 227show policy-map command 228show processes cpus command 224show queue command 228show queuing command 228show rtr command 229show tag forwarding command 227show tag switching interfaces command 226Single Rate policing 183SNMP

configuring 28read community 223

SOO 59SSH 20, 21, 28Static routing 73Statically-assigned port numbers 96, 271support

customer xiiSupported Cisco interface types 3Supported Service Activator features 1

TTACACS+ server 20, 21Tag switching 29Tail drop 133TCP Connect 204Telnet 99Token bucket 153Traffic classification 94Traffic Shaping

ATM 166DTS 163Frame Relay 155GTS 152

Two Rate policing 183

UUBR 166, 168UDP Echo 204URL matching 96

VViolate action 186

Virtual device state 21VPN configuration 39VPN topologies 44VPNs

fully meshed 44hub and spoke 44management 44maximum paths 41, 55, 60

VPNs See MPLS VPNsVRF re-use 47VRF tables 42

pre-defined 31pre-defined, removing 48prefix limit 59route limit 46, 47, 56

VRF, interface-less 49

WWeighted Fair Queuing 129Weighted Random Early Detection 142Weighted Round Robin 126WFQ

class-based 132commands 130, 133example configuration 131explanation 129flow-based 129implementation 131implementation using MQC PHB group 189implementation using standard PHB group 136with LLQ 132

WREDdefault values 146DiffServ 144example configuration on ATM PVCs 152example configuration using defaults 150example configuration using specific values 150explanation 142implementation 145IP Precedence 143on ATM 145with WFQ 133

WRR 156example configuration 128explanation 125implementation 126



used with FRTS 156
