24.0.0 Application Guide

Nortel Application Switch Operating System

Application Guide

NN47220-104 (320507-D).

Document status: StandardDocument version: 01.01Document date: 28 January 2008

Copyright © 2008, Nortel NetworksAll Rights Reserved.

Sourced in Canada, India and the United States of America

Part Number: NN472000-104 (320507-D)

This document is protected by copyright and distributed under licenses restricting its use, copying, distribution,and decompilation. No part of this document may be reproduced in any form by any means without prior writtenauthorization of Nortel Networks, Inc. Documentation is provided "as is" without warranty of any kind, eitherexpress or implied, including any kind of implied or express warranty of non-infringement or the implied warrantiesof merchantability or fitness for a particular purpose.

U.S. Government End Users: This document is provided with a "commercial item" as defined by FAR 2.101 (Oct1995) and contains "commercial technical data" and "commercial software documentation" as those terms areused in FAR 12.211-12.212 (Oct 1995). Government End Users are authorized to use this documentation only inaccordance with those rights and restrictions set forth herein, consistent with FAR 12.211- 12.212 (Oct 1995), DFARS227.7202 (JUN 1995) and DFARS 252.227-7015 (Nov 1995).

Nortel Networks, Inc. reserves the right to change any products described herein at any time, and without notice.Nortel Networks, Inc. assumes no responsibility or liability arising from the use of products described herein, exceptas expressly agreed to in writing by Nortel Networks, Inc. The use and purchase of this product does not convey alicense under any patent rights, trademark rights, or any other intellectual property rights of Nortel Networks, Inc.

Nortel Application Switch Operating System, Nortel Application Switch 2424, Nortel Application Switch 2424-SSL,Nortel Application Switch 2224, 2216, 2208, 3408, Nortel Application Switch 180, Nortel Application Switch 180e,Nortel Application Switch 184, Nortel Application Switch AD3, Nortel Application Switch AD4, and ACEswitch aretrademarks of Nortel Networks, Inc. in the United States and certain other countries. Cisco® and EtherChannel®

are registered trademarks of Cisco Systems, Inc. in the United States and certain other countries. Check Point®

and FireWall-1® are trademarks or registered trademarks of Check Point Software Technologies Ltd. Any othertrademarks appearing in this manual are owned by their respective companies.

3

Contents

Preface 17Who should use this guide 17What you will find in this guide 17

Part 1: Basic Switching 17Part 2: IP Routing 18Part 3: Application Switching Fundamentals 18Part 4: Advanced Switching 19

Typographic Conventions 19Related Documentation 20How to get help 20

New in this release 23Features 23Other changes 23

Part 1: Basic Switching 25Accessing the Switch 26Using the CLI 26Using SNMP 27

SNMP v1.0 27SNMP v3.0 28

Using Nortel ASEM 35Using the Browser-Based Interface 36

Configuring BBI Access via HTTP 36Configuring BBI Access via HTTPS 37

Using the Management Port 37Setting Up the Management Port 38Limiting Management Access 40

Feature Description 40File Transfers 41Time Configuration 41

Time Zone Configuration 41Network Time Protocol 44

Securing the Switch 46Protecting Switch-Owned Addresses from Attacks 46

Nortel Application Switch Operating SystemApplication Guide

NN47220-104 (320507-D) 01.01 Standard24.0 28 January 2008

Copyright © 2008, Nortel Networks

.

4 Contents

How Different Protocols Attack the Switch 46Configuring Denial of Service Protection 47Viewing Dropped Packets 47

Setting Source IP Address Ranges for Switch Management 48RADIUS Authentication and Authorization 49

RADIUS Authentication Features 49How Radius Authentication Works 50Configuring RADIUS Authentication on the Switch 50Switch User Accounts 52RADIUS Attributes for User Privileges 53

TACACS+ Authentication 54How TACACS+ Authentication Works 54TACACS+ Authentication Features 55Authorization 55Accounting 56Configuring TACACS+ Authentication on the Switch 56

Secure Shell and Secure Copy 58Configuring SSH/SCP features on the switch 58Configuring the SCP Administrator Password 59SCP Services 60Using SSH and SCP Client Commands 60SSH and SCP Encryption of Management Messages 61Generating RSA Host and Server Keys for SSH Access 62SSH/SCP Integration with Radius Authentication 63SSH/SCP Integration with SecurID 63

End User Access Control 64Considerations for Configuring End User Accounts 64User Access Control Menu 65Setting up User IDs 65Defining User Names and Passwords 65Changing Passwords 65Defining User Access Level 66Assigning One or More Real Servers to the End User 66Validating User Configuration 66Listing Current Users 66Enabling or Disabling a User 67Logging into an End User Account 67

Deny Routes 67Configuring a Deny Route 68Viewing a Deny Route 68

VLANs 71VLAN ID Numbers 71VLAN Tagging 72




.

Contents 5

VLANs and the IP Interfaces 72VLAN Topologies and Design Issues 72

Example 1: Multiple VLANS with Tagging Adapters 73Example 2: Parallel Links with VLANs 74

VLANs and Default Gateways 75Segregating VLAN Traffic 75Configuring the Local Network 77Configuring Gateways per VLAN 77

VLANs and Jumbo Frames 80Limitations 80Isolating Jumbo Frame Traffic using VLANs 80Configuring VLANs for Jumbo and Non-Jumbo Frames 81

Port Trunking 83Overview 83

Statistical Load Distribution 84The Trunk Hash Algorithm 84Built-In Fault Tolerance 85

Static Port Trunking Example 85Link Aggregation Control Protocol Trunking 87

Configuring LACP 89Port Teaming 91Spanning Tree Protocol 93Overview 93Bridge Protocol Data Units (BPDUs) 94

Determining the Path for Forwarding BPDUs 94Spanning Tree Compatibility between BPDU Formats 95

Spanning Tree Group Configuration Guidelines 96Adding a VLAN to a Spanning Tree Group 96Creating a VLAN 96

Multiple Spanning Trees 97Why Do We Need Multiple Spanning Trees? 98Four-Switch Topology with a Single Spanning Tree 99Four-Switch Topology with Multiple Spanning Trees 100Switch-Centric Spanning Tree Protocol 101VLAN Participation in Spanning Tree Groups 101

Rapid Spanning Tree Protocol 102Port State Changes 102Port Type and Link Type 102RSTP Configuration Guidelines 103RSTP Configuration Example 103

Multiple Spanning Tree Protocol 104MSTP Region 105Common Internal Spanning Tree 105




.

6 Contents

MSTP Configuration Guidelines 105MSTP Configuration Example 105

Part 2: IP Routing 109Basic IP Routing 110IP Routing Benefits 110Routing Between IP Subnets 110Example of Subnet Routing 112Defining IP Address Ranges for the Local Route Cache 117Dynamic Host Configuration Protocol 118

DHCP Relay Agent 118DHCP Relay Agent Configuration 119

Gratuitous ARP (GARP) Command 120Static Routes 120

IPv4 Static Routes 121IPv6 Static Routes 121

IPv6 123IPv6 Address Format 123IPv6 Address Types 123

Unicast Address 123Multicast 124Anycast 124

Pinging IPv6 Addresses 124Verifying IPv6 Configuration 125Verifying IPv6 Statistics 125Routing Information Protocol 126Border Gateway Protocol 131Internal Routing Versus External Routing 131Forming BGP Peer Routers 133What is a Route Map? 133

Incoming and Outgoing Route Maps 134Precedence 134Configuration Overview 135

Aggregating Routes 137Redistributing Routes 137BGP Attributes 138

Local Preference Attribute 138Metric (Multi-Exit Discriminator) Attribute 138

Selecting Route Paths in BGP 139BGP Failover Configuration 139Default Redistribution and Route Aggregation Example 143Open Shortest Path First (OSPF) 146OSPF Overview 146

Equal Cost Multipath Routing Support 147




.

Contents 7

Types of OSPF Areas 147Types of OSPF Routing Devices 148Neighbors and Adjacencies 149The Link-State Database 150The Shortest Path First Tree 150Internal Versus External Routing 150

OSPF Implementation 151Configurable Parameters 151Defining Areas 152Interface Cost 154Electing the Designated Router and Backup 154Summarizing Routes 155Default Routes 155Virtual Links 156Router ID 157Authentication 158Host Routes for Load Balancing 160Redistributing Routes into OSPF 161OSPF Features Not Supported in This Release 164

OSPF Configuration Examples 164Example 1: Simple OSPF Domain 165Example 2: Virtual Links 167Example 3: Summarizing Routes 173Example 4: Host Routes 176Verifying OSPF Configuration 185

Part 3: Application Switching Fundamentals 187Server Load Balancing 188Understanding Server Load Balancing 188

Identifying Your Network Needs 189How Server Load Balancing Works 189

Implementing Basic Server Load Balancing 191Network Topology Requirements 192Configuring Server Load Balancing 194

Additional Server Load Balancing Options 199Supported Services and Applications 199Disabling and Enabling Real Servers 200IP Address Ranges Using imask 201Health Checks for Real Servers 201Configuring Multiple Services 202Metrics for Real Server Groups 202Weights for Real Servers 206Connection Time-outs for Real Servers 207Maximum Connections for Real Servers 207




.

8 Contents

Unlimited Connections to Real Servers 208Backup/Overflow Servers 208Backup Only Server 209Connection Pooling 210

Content Intelligent Server Load Balancing 210URL-Based Server Load Balancing 211Virtual Hosting 216Cookie-Based Preferential Load Balancing 219Browser-Smart Load Balancing 222URL Hashing for Server Load Balancing 223Header Hash Load Balancing 225Inserting the X-Forwarded-For Header in HTTP Requests 226

Extending SLB Topologies 227Virtual Matrix Architecture 227Proxy IP Address Configuration 229Port-based Proxy IP Addresses 229VLAN-based Proxy IP Addresses 230Selecting a Proxy IP Based on the Egress Port or VLAN 230Proxy IP Addresses in Filters 231Using a Virtual Server IP Address as the Proxy IP Address 231Configuring Proxy IP Addresses 232Proxy IP Limitation 234Mapping Ports 234Direct Server Return 238Direct Access Mode 239Assigning Multiple IP Addresses 240Delayed Binding 242

Session Timeout Per Service 245IPv6 and Server Load Balancing 246

IPv6 to IPv4 Server Load Balancing 247IPv6 to IPv6 Server Load Balancing 251IPv6 Layer 4 SLB Information 253IPv6 Real Server Health Checks 253

Load Balancing Special Services 254IP Server Load Balancing 254FTP Server Load Balancing 255

Active FTP Configuration 255FTP Network Topology Restrictions 256Configuring FTP Server Load Balancing 256

TFTP Server Load Balancing 256Requirements 257Configuring TFTP Server Load Balancing 257

Lightweight Directory Access Server SLB 257




.

Contents 9

LDAP Operations and Server Types 258How LDAP SLB Works 258Selectively Resetting a Real Server 258Configuring LDAP SLB 259

Domain Name Server (DNS) SLB 261Preconfiguration Tasks 262Configuring UDP-based DNS Load Balancing 263Configuring TCP-based DNS Load Balancing 264Layer 7 DNS Load Balancing 265

Real Time Streaming Protocol SLB 268How RTSP Server Load Balancing Works 268Supported RTSP Servers 269RTSP Port Configuration 269Configuring RTSP Load Balancing 270Content-Intelligent RTSP Load Balancing 273

Wireless Application Protocol SLB 279WAP SLB with RADIUS Static Session Entries 280WAP SLB with RADIUS Snooping 283WAP SLB with Radius/WAP Persistence 287

Intrusion Detection System SLB 290How Intrusion Detection Server Load Balancing Works 291Setting Up IDS Servers 292IDS Load Balancing Configurations 293

Session Initiation Protocol Server Load Balancing 310SIP Processing on the Switch 310TCP based SIP Servers 310Configuring SIP Server Load Balancing 310UDP based SIP servers 314Configuring SIP Server Load Balancing 314Enhancements to SIP Server Load Balancing 317

SoftGrid Load Balancing 319Workload Manager Support 322WAN Link Load Balancing 327Multi-homing 327

Benefits of WAN Link Load Balancing 328Identifying Your Network Needs 329What is Load Balancing? 329

How WAN Link Load Balancing Works 330Outbound Traffic 330Inbound Traffic 332

Configuring WAN Link Load Balancing 336Before You Begin 336Configuration Summary 336




.

10 Contents

Example 1: Simple WAN Link Load Balancing 338Example 2: WAN Link Load Balancing with Server Load Balancing 350Health Checking and Multi-homing 362

Filtering 364Overview 365

Filtering Benefits 365Filtering Criteria 365Filtering Actions 366Stacking Filters 367Overlapping Filters 367The Default Filter 368Optimizing Filter Performance 369IP Address Ranges 369Filter Logs 369Cached versus Non-cached Filters 371

MAC-Based Filters for Layer 2 Traffic 372VLAN-based Filtering 373

Configuring VLAN-based Filtering 373Filtering on 802.1p Priority Bit in a VLAN Header 376

802.1p Priorities 376Classifying Packets Based on 802.1p Priority Bits 376

Tunable Hash for Filter Redirection 377Filter-based Security 378Network Address Translation 385

Static NAT 386Dynamic NAT 388FTP Client NAT 389Overlapping NAT 391SIP NAT and Gleaning Support 392

Matching TCP Flags 394Matching ICMP Message Types 399Deny Filter Based on Layer 7 Content Lookup 400

Denying HTTP URL Requests 401Denying HTTP Headers 403

Multicast Filter Redirection 405IPv6 Filtering 406Application Redirection 409Overview 409

Cache Redirection Environment 410Additional Application Redirection Options 411Cache Redirection Configuration Example 411

RTSP Cache Redirection 417IP Proxy Addresses for NAT 421




.

Contents 11

Excluding Noncacheable Sites 423Content Intelligent Cache Redirection 423

URL-Based Cache Redirection 424HTTP Header-Based Cache Redirection 433Browser-Based Cache Redirection 434URL Hashing for Cache Redirection 436RTSP Streaming Cache Redirection 439

HTTP Redirection 444Configure SLB Strings for HTTP Redirection 444IP based HTTP redirection 447TCP Service Port Based HTTP Redirection 450MIME Type Header-Based Redirection 452URL-Based Redirection 454Source IP from HTTP header and Host Header-Based Redirection 456HTTP to HTTPS Redirection 458IPv6 Redirection Filter 459

Peer-to-Peer Cache Load Balancing 461Health Checking 463Real Server Health Checks 465

Advanced Group Health Check 465Disabling the Fast Link Health Check 467

DSR Health Checks 467Link Health Checks 468

Configuring Link Health Checks 469TCP Health Checks 469ICMP Health Checks 470Script-Based Health Checks 470

Configuring Script-Based Health Checks 470Script Formats 471Scripting Commands 473Scripting Guidelines 474Script Configuration Examples 474

Application-Specific Health Checks 478HTTP Health Checks 479UDP-Based DNS Health Checks 481TFTP Health Check 482SNMP Health Check 483FTP Server Health Checks 485POP3 Server Health Checks 486SMTP Server Health Checks 487IMAP Server Health Checks 488NNTP Server Health Checks 488RADIUS Server Health Checks 489




.

12 Contents

HTTPS/SSL Server Health Checks 492WAP Gateway Health Checks 492LDAP Health Checks 499Windows Terminal Server Health Checks 501ARP Health Checks 501Buddy Server Health Checks 503DHCP Health Checks 505

Failure Types 506Service Failure 506Server Failure 507

High Availability 508VRRP Overview 509

Standard VRRP Components 509IPv6 VRRP Support 521

IPv6 VRRP packets 522IPv6 VRRP configuration 523IPv6 VRRP information 523

Failover Methods and Configurations 524Active-Standby Redundancy 525Active-Active Redundancy 529Hot-Standby Redundancy 539Tracking Virtual Routers 548Service-Based Virtual Router Groups 550

IPv6 VRRP Configuration Examples 555Hot Standby Configuration Example 555Active-Standby Configuration Example 562Active-Active Configuration Example 569

Virtual Router Deployment Considerations 576Mixing Active-Standby and Active-Active Virtual Routers 577Eliminating Loops with STP and VLANs 577Assigning VRRP Virtual Router ID 578Configuring VRRP Peers for Synchronization 578Synchronizing Active/Active Failover 580

Stateful Failover of Persistent Sessions 580What Happens When a Switch Fails 581Viewing Statistics on Persistent Port Sessions 583

Service-based Session Failover 584Peer Synchronization 586

Part 4: Advanced Switching 587Persistence 588Overview of Persistence 588

Using Source IP Address 589Using Cookies 589




.

Contents 13

Using SSL Session ID 590HTTP and HTTPS Persistence Based on Client IP 590Cookie-Based Persistence 591

Permanent and Temporary Cookies 592Cookie Formats 593Cookie Properties 593Client Browsers that Do Not Accept Cookies 594Cookie Modes of Operation 594Configuring Cookie-Based Persistence 598Server-Side Multi-Response Cookie Search 604Proxy Support for Insert Cookie 604

SSL Session ID-Based Persistence 605How SSL Session ID-Based Persistence Works 605Configuring SSL Session ID-Based Persistence 607

Windows Terminal Server Load Balancing and Persistence 607Advanced Denial of Service Protection 611Background 611

Security Inspection Workflow 612Other Types of Security Inspection 612

IP Address Access Control Lists 612Configuring Blocking with IP Access Control Lists 613Viewing IP ACL statistics 614Bogon List 614

Protection Against Common Denial of Service Attacks 615Configuring Ports with DoS Protection 615Viewing DOS statistics 616Viewing DOS statistics per port 617Understanding the types of DOS attacks 618DoS Attack Prevention Configuration 627Preventing other types of DOS attack 627

Protocol-BasedRate Limiting 628Time Windows and Rate Limits 628Hold Down Periods 629UDP and ICMP Rate Limiting 629TCP Rate Limiting 629Configuring Protocol-Based Rate Limiting Filters 630

Protection Against UDP Blast Attacks 635Configuring UDP Blast Protection 635

TCP or UDP Pattern Matching 636Pattern Criteria 637Matching Groups of Patterns 639

Nortel Threat Protection System 4.1 Enforcement Point 647Remediation Subsystem 647




.

14 Contents

Operations IP Access Control List 648Session Deletion 649

Symantec Intelligent Network Protection 651Overview 652Intelligent Network Protection Components 653Installing Software Keys 653Configuration Tasks 654

CLI Command Analogs 655Tunable Resources 656Monitoring Symantec Functionality 657General Symantec Information 657Signature Names 658Configuration Example 659Troubleshooting 665

Configuration Synchronization - Different Memory Profiles 665Configuration Synchronization - Similar Memory Profiles 665

Firewall Load Balancing 667Firewall Overview 667Basic FWLB 669

Basic FWLB Implementation 670Configuring Basic FWLB 672

Four-Subnet FWLB 682Four-Subnet FWLB Implementation 683Configuring Four-Subnet FWLB 684

Advanced FWLB Concepts 701Free-Metric FWLB 701Adding a Demilitarized Zone (DMZ) 704Firewall Health Checks 706

Virtual Private Network Load Balancing 708Overview 708

How VPN Load Balancing Works 708VPN Load Balancing Persistence 710

VPN Load-Balancing Configuration 711Configure the First Clean-Side Application Switch-CA 712Configure the Second Clean-Side Application Switch-CB 716Configure the First Dirty-Side Application Switch-DA 718Configure the Second Dirty-Side Application Switch-DB 721Test Configurations and General Topology 723Test the VPN 724

Global Server Load Balancing 727Enabling GSLB on the Switch 727DSSP version 1 vs. version 2 728Migrating Previous GSLB Configurations 728




.

Contents 15

GSLB License Key 728GSLB Overview 728

Benefits 728How GSLB Works 729GSLB Metrics 731Metric preferences 733Rules 734GSLB Availability Persistence 734

Configuring Basic GSLB 735Basic GSLB Requirements 736Example GSLB Topology 736

Configuring a Standalone GSLB Domain 752GSLB Topology with a Standalone GSLB Site 753A Standalone DNS Server Configuration 757

Configuring GSLB with Rules 759Configuring Time-Based Rules 760Using the Availability Metric in a Rule 761

Configuring GSLB Network Preference 762Configuring GSLB with Proxy IP for Non-HTTP Redirects 764

How Proxy IP Works 765Configuring Proxy IP Addresses 766

Using Border Gateway Protocol for GSLB 767Verifying GSLB Operation 768Bandwidth Management 769Enabling Bandwidth Management 769Contracts 770

Classification Rules 771Grouped Bandwidth Contracts 773IP User Level Contracts for Individual Sessions 774

Policies 776Bandwidth Policy Index 776Time Policy 776Enforcing Policies 776

Rate Limiting 777Application Session Capping 779Rate Limiting Timeslots 779

Traffic Shaping 780Bandwidth Management Information 781

Viewing BWM Statistics 781Configuring BWM History 782Sending BWM History 782Statistics and Management Information Bases 783Synchronizing BWM Configurations in VRRP 783




.

16 Contents

Packet Coloring (TOS bits) for Burst Limit 783Contract-Based Packet Mirroring 784Configuring Bandwidth Management 784Additional BWM Configuration Examples 788

Configuring User/Application Fairness 788ConfiguringGrouped Contracts for Bandwidth Sharing 791Configuring a IP User-Level Rate Limiting Contract 794Configuring BWMPreferential Services 796Configuring Content Intelligent Bandwidth Management 799Configuring Cookie-Based Bandwidth Management 803ConfiguringSecurity Management 807Configuring Time and Day Policies 809Egress Bandwidth Tuning for Lower Speed Networks 811Overwriting the TCP Window Size 812Configuring Intelligent Traffic Management 812

XML Switch Configuration API 814Software Components 814XML Configuration File 815XML File Transmission 815Feature Configuration 816

Additional Feature Commands 817Port Mirroring 819

Mirroring Individual Ports 819Mirroring VLANs on a Port 821

Filtering the Session Dump 822Exclusionary String Matching for Real Servers 825

Configuring Exclusionary URL String Matching 826Regular Expression Matching 827

Standard Regular Expression Characters 827Configuring Regular Expressions 828

Content Precedence Lookup 829Requirements 830Assigning Multiple Strings 831

String Case Insensitivity 832Configurable HTTP Methods 833

Index 839




.

17

Preface

This Application Guide describes how to configure and use the NortelApplication Switch Operating System software on the Nortel ApplicationSwitches. For documentation on installing the switches physically, see theHardware Installation Guide for your particular switch model.

Who should use this guideThis Application Guide is intended for network installers and systemadministrators engaged in configuring and maintaining a network. Theadministrator should be familiar with Ethernet concepts, IP addressing,Spanning Tree Protocol, and SNMP configuration parameters.

What you will find in this guideThis guide helps you to plan, implement, and administer Nortel ApplicationSwitch Operating System software. Where possible, each section providesfeature overviews, usage examples, and configuration instructions.

Part 1: Basic Switching

• "Accessing the Switch" (page 26), describes how to access the NortelApplication Switch to configure, view information and run statistics onthe switch using the CLI, Nortel ASEM, the Browser-Based Interface,SNMP, and the Management port.

• "Securing the Switch" (page 46), describes how to protect the switchfrom attacks, unauthorized access, and also discusses differentmethods to manage the switch for remote administrators using specificIP addresses, RADIUS authentication, Secure Shell (SSH), and SecureCopy (SCP).

• "VLANs" (page 71), describes how to configure Virtual Local AreaNetworks (VLANs) for creating separate network segments, includinghow to use VLAN tagging for devices that use multiple VLANs. Thischapter also describes how Jumbo frames can be used to ease serverprocessing overhead.




.

18 Preface

• "Port Trunking" (page 83), describes how to group multiple physicalports together to aggregate the bandwidth between large-scale networkdevices.

• "Port Teaming" (page 91), describes how to configure port teaming.

• "Spanning Tree Protocol" (page 93), discusses how Spanning Treesconfigure the network so that the switch uses the most efficient pathwhen multiple paths exist.

Part 2: IP Routing

• "Basic IP Routing" (page 110), describes how to configure the NortelApplication Switch for IP routing using IP subnets, and DHCP Relay.

• "IPv6" (page 123), describes how to configure the IP version 6 featuresof the Nortel Application Switch.

• "Routing Information Protocol" (page 126), describes how the NortelApplication Switch Operating System software implements standard RIPfor exchanging TCP/IP route information with other routers

• "Border Gateway Protocol" (page 131), describes BGP concepts andBGP features supported in Nortel Application Switch Operating System.

• "Open Shortest Path First (OSPF)" (page 146), describes OSPFconcepts, how OSPF is implemented in Nortel Application SwitchOperating System, and four examples of how to configure your switchfor OSPF support.

Part 3: Application Switching Fundamentals

• "Server Load Balancing" (page 188), describes how to configure theNortel Application Switch to balance network traffic among a poolof available servers for more efficient, robust, and scalable networkservices.

• "Load Balancing Special Services" (page 254), describes how to extendserver load balancing configurations to load balance services includingsource IP addresses, FTP, RTSP, DNS, WAP, IDS, and Session InitiationProtocol (SIP).

• " WAN Link Load Balancing" (page 327), describes how to configurethe Nortel Application Switch to balance user session traffic among apool of available WAN Links.

• "Filtering" (page 364), describes how to configure and optimize networktraffic filters for security and Network Address Translation.

• "Application Redirection" (page 409), describes how to use filters forredirecting traffic to such network streamlining devices as caches.




.

Typographic Conventions 19

• "Health Checking" (page 463), describes how to configure the NortelApplication Switch to recognize the availability of the various networkresources used with the various load-balancing and applicationredirection features.

• "High Availability" (page 508), describes how to use the Virtual RouterRedundancy Protocol (VRRP) to ensure that network resources remainavailable if one Nortel Application Switch is removed for service.

Part 4: Advanced Switching

• "Persistence" (page 588), describes how to ensure that all connectionsfrom a specific client session reach the same server. Persistence canbe based on cookies or SSL session ID.

• "Advanced Denial of Service Protection" (page 611), describes theadvanced Denial of Service protection features in Nortel ApplicationSwitch Operating System that can be used to prevent a wide rangeof network attacks.

• "Symantec Intelligent Network Protection" (page 651), describes theSymantec Intelligent Network Protection features that can be used toguard against malicious attacks and intrusions on a network.

• "Firewall Load Balancing" (page 667), describes how to combinefeatures to provide a scalable solution for load balancing multiplefirewalls.

• "Virtual Private Network Load Balancing" (page 708), describes usingyour Nortel Application Switch to load balance secure point-to-pointlinks.

• "Global Server Load Balancing" (page 727), describes configuringServer Load Balancing across multiple geographic sites. This chapteralso describes new GSLB features added in this release.

• "Bandwidth Management" (page 769), describes how to configure theNortel Application Switch for allocating specific portions of the availablebandwidth for specific users or applications.

• "XML Switch Configuration API" (page 814), describes how to use andconfigure the XML Configuration API.

• "Troubleshooting" (page 819), discusses two tools for troubleshootingyour application switch—monitoring ports and filtering session dumps.

• "Layer 7 String Handling" (page 825), describes how to perform loadbalancing and application redirection based on Layer 7 packet contentinformation (such as URL, HTTP Header, browser type, and cookies).

Typographic ConventionsThe following table describes the typographic styles used in this book.




.

20 Preface

Typographic Conventions

Typeface orSymbol

Meaning Example

This type is used for names ofcommands, files, and directoriesused within the text.

View the readme.txtfile.

AaBbCc123

It also depicts on-screen computeroutput and prompts.

Main#

AaBbCc123 This bold type appears in commandexamples. It shows text that mustbe typed in exactly as shown.

Main# sys

This italicized type appearsin command examples as aparameter placeholder. Replacethe indicated text with theappropriate real name or valuewhen using the command. Do nottype the brackets.

To establish a Telnetsession, enter:host# telnet <IPaddress>

<AaBbCc123>

This also shows book titles, specialterms, or words to be emphasized.

Read your User’s Guidethoroughly.

[* ] Command items shown insidebrackets are optional and can beused or excluded as the situationdemands. Do not type the brackets.

host# ls [-a]

Related Documentation• Nortel Application Switch Operating System 24.0 Release Notes

(NN47220-401).

Provides up-to-date information about Nortel Application SwitchOperating System 24.0 installation, upgrade, and known issues.

• Nortel Application Switch Operating System 24.0 Command Reference(NN47220-105)

Provides a command and usage reference for all switch CLI commands.

• Nortel Application Switch Operating System Browser-Based Interface(BBI) Quick Guide (NN47220-103)

Provides a description of the switch BBI and how to configure andaccess it.

How to get helpIf you purchased a service contract for your Nortel Networks product from adistributor or authorized reseller, contact the technical support staff for thatdistributor or reseller for assistance.




.

How to get help 21

If you purchased a Nortel Networks service program, contact one of thefollowing Nortel Networks Technical Solutions Centers:

Technical Solutions Center Telephone

Europe, Middle East, and Africa 00800 8008 9009 or +44 (0) 870 907 9009

North America (800) 4NORTEL or (800) 466-7835

Asia Pacific (61) (2) 8870-8800

China (800) 810-5000

Additional information about the Nortel Networks Technical Solutions Centersis available at the following URL: http://www.nortel.com/help/contact/global

An Express Routing Code (ERC) is available for many Nortel Networksproducts and services. When you use an ERC, your call is routed to atechnical support person who specializes in supporting that product orservice. To locate an ERC for your product or service, refer to the followingURL: http://www.nortel.com/help/contact/erc/index.html




.

http://www.nortel.com/help/contact/global

http://www.nortel.com/help/contact/erc/index.html

22 Preface




.

23

New in this release

This section details what’s new in Nortel Application Switch OperatingSystem 24.0 Application Guide (NN47220-104) for release 24.0.

FeaturesSee the following sections for information about feature changes:

• "New Configuration options" (page 601)

• "Cookie Insert Mode Enhancement " (page 595)

• "Proxy support for Passive Cookie" (page 597)

• "A Standalone DNS Server Configuration" (page 757)

• "Accounting" (page 56)

• "Session Initiation Protocol Server Load Balancing" (page 310)

Other changesSee the following sections for information about changes that are notfeature-related:

• "Limiting Management Access" (page 40)

• "Hot-Standby Configuration" (page 541)

• "Virtual Matrix Architecture" (page 227)




.

24 New in this release




.

25

Part 1: Basic Switching

This part describes how to access and manage the switch, and how toconfigure basic Layer 1–2 switching functions.

• "Accessing the Switch" (page 26)

• "Securing the Switch" (page 46)

• "VLANs" (page 71)

• "Port Trunking" (page 83)

• "Port Teaming" (page 91)

• "Spanning Tree Protocol" (page 93)




.

26 Part 1: Basic Switching

Accessing the Switch

The Nortel Application Switch Operating System software provides meansfor accessing, configuring, and viewing information and statistics aboutthe Nortel Application Switch. The following topics are addressed in thischapter:

• "Using the CLI" (page 26)

• "Using SNMP" (page 27)

• "Using Nortel ASEM" (page 35)

• "Using the Browser-Based Interface" (page 36)

• "Using the Management Port" (page 37)

• "File Transfers" (page 41)

Using the CLIThe Command Line Interface (CLI) is a built-in, text-based menu systemfor access via local terminal or remote Telnet or SSH session. The CLI isthe most direct method for collecting switch information and performingswitch configuration. The Main Menu of the CLI with administrator privilegesis displayed in the following table:

[Main Menu]info - Information Menustats - Statistics Menucfg - Configuration Menuoper - Operations Command Menuboot - Boot Options Menumaint - Maintenance Menudiff - Show pending config changes [global command]apply - Apply pending config changes [global command]save - Save updated config to FLASH [global command]revert - Revert pending or applied changes

[global command]exit - Exit [global command, always available]

You can access the built-in, text-based CLI in the following ways:

• Using a serial connection via the console port

You can access and configure the application switch by using a computerrunning terminal emulation software.

• Using the management port

The management port is a Fast Ethernet port on the Nortel ApplicationSwitch that is used exclusively for managing the switch.




.

Accessing the Switch 27

For more information on the management port, see "Using theManagement Port" (page 37).

• Using a Telnet connection over the network

A Telnet connection offers the convenience of accessing the switch fromany workstation connected to the network. Telnet access provides thesame options for user and administrator access as those availablethrough the console port.

To establish a Telnet connection with the switch, run the Telnet programon your workstation and issue the Telnet command, followed by theswitch IP address:

telnet <switch IP address>

• Using a SSH connection to securely log into another computer overa network.

The SSH (Secure Shell) protocol enables you to securely log intoanother computer over a network to execute commands remotely. As asecure alternative to using Telnet to manage switch configuration, SSHensures that all data sent over the network is encrypted and secure. Formore information, see "Secure Shell and Secure Copy" (page 58).

For more information on the CLI, see the Nortel Application SwitchOperating System Command Reference.

Using SNMPNortel Application Switch Operating System provides SNMP v1.0 andSNMP v3.0 support for access through any network management software,such as Nortel ASEM or HP-OpenView.

SNMP v1.0To access the SNMP agent on the Nortel Application Switch, the read andwrite community strings on the SNMP manager should be configured tomatch those on the switch. The default read community string on the switchis public and the default write community string is private.

Note: Leaving the default community strings enabled on the switchpresents a security risk. Use the commands noted below to changethese community strings.

The read and write community strings on the switch can be changed usingthe following commands on the CLI:

>> /cfg/sys/ssnmp/rcomm




.


and

>> /cfg/sys/ssnmp/wcomm

The SNMP manager should be able to reach the management interface(management port) or any one of the IP interfaces on the switch.

SNMP v3.0SNMPv3 is an enhanced version of the Simple Network ManagementProtocol, approved by the Internet Engineering Steering Group in March,2002. SNMP v3.0 contains additional security and authentication featuresthat provide data origin authentication, data integrity checks, timelinessindicators and encryption to protect against threats such as masquerade,modification of information, message stream modification and disclosure.

SNMP v3 ensures that the client can use SNMP v3 to query the MIBs,mainly for security purposes.

To access the SNMP v3.0 menu, enter the following command in the CLI:

>> # /cfg/sys/ssnmp/snmpv3

For more information on SNMP MIBs and the commands used to configureSNMP on the switch, see the Nortel Application Switch Operating SystemCommand Reference.

Default configurationThe Nortel Application Switch Operating System has two users by default.Both the users adminmd5 and adminsha have access to all the MIBssupported by the switch.

Step Action

1 username 1: adminmd5/password adminmd5. Authenticationused is MD5.

2 username adminsha/password adminsha. Authentication usedis SHA.

To configure an SNMP user name, enter the following commandfrom the CLI:

>> # /cfg/sys/ssnmp/snmpv3/usm <x>

—End—




.


User ConfigurationUsers can be configured to use the authentication and privacy options.Currently Nortel Application Switch Operating System supports twoauthentication algorithms: MD5 and SHA. Authentication and privacyoptions are specified using the following command:

>> # /cfg/sys/ssnmp/snmpv3/usm <x> /auth md5|sha

Step Action

1 To configure a user with name ’test’, authentication type MD5,and authentication password of ’test’, privacy option DES withprivacy password of ’test’, enter the following CLI commands.

>> # /cfg/sys/ssnmp/snmpv3/usm 5>> SNMPv3 usmUser 5 # name "test">> SNMPv3 usmUser 5 # auth md5>> SNMPv3 usmUser 5 # authpw test>> SNMPv3 usmUser 5 # priv des>> SNMPv3 usmUser 5 # privpw test

2 Once a user is configured, specify the access level for this useralong with the views to which the user is allowed access. Thisis specified in the access table.

>> # /cfg/sys/ssnmp/snmpv3/access 5>> SNMPv3 vacmAccess 5 # name "testgrp">> SNMPv3 vacmAccess 5 # level authPriv>> SNMPv3 vacmAccess 5 # rview "iso">> SNMPv3 vacmAccess 5 # wview "iso">> SNMPv3 vacmAccess 5 # nview "iso"

3 Link the user to a particular access group.

>> # /cfg/sys/ssnmp/snmpv3/group 5>> SNMPv3 vacmSecurityToGroup 5 # uname test>> SNMPv3 vacmSecurityToGroup 5 # gname testgrp

If you want to allow the user access only certain MIBs, see "Viewbased Configurations" (page 30).

—End—




.


View based ConfigurationsTo configure an SNMP user equivalent to the CLI access level for user, usethe following configuration:

/cfg/sys/ssnmp/snmpv3/usm 4name "usr"/cfg/sys/ssnmp/snmpv3/access 3name "usrgrp"rview "usr"wview "usr"nview "usr"/cfg/sys/ssnmp/snmpv3/group 4uname usrgname usrgrp/cfg/sys/ssnmp/snmpv3/view 6name "usr"tree "1.3.6.1.4.1.1872.2.5.1.2"/cfg/sys/ssnmp/snmpv3/view 7name "usr"tree "1.3.6.1.4.1.1872.2.5.1.3"/cfg/sys/ssnmp/snmpv3/view 8name "usr"tree "1.3.6.1.4.1.1872.2.5.2.2"/cfg/sys/ssnmp/snmpv3/view 9name "usr"tree "1.3.6.1.4.1.1872.2.5.2.3"/cfg/sys/ssnmp/snmpv3/view 10name "usr"tree "1.3.6.1.4.1.1872.2.5.3.2"/cfg/sys/ssnmp/snmpv3/view 11name "usr"tree "1.3.6.1.4.1.1872.2.5.3.3"/cfg/sys/ssnmp/snmpv3/view 12name "usr"tree "1.3.6.1.4.1.1872.2.5.4.2"/cfg/sys/ssnmp/snmpv3/view 13name "usr"tree "1.3.6.1.4.1.1872.2.5.4.3"/cfg/sys/ssnmp/snmpv3/view 14name "usr"tree "1.3.6.1.4.1.1872.2.5.5.2"/cfg/sys/ssnmp/snmpv3/view 15name "usr"tree "1.3.6.1.4.1.1872.2.5.5.3"/cfg/sys/ssnmp/snmpv3/view 16name "usr"tree "1.3.6.1.4.1.1872.2.5.6.2"

To configure an SNMP user equivalent to the CLI access level for oper, usethe following configuration:




.


/cfg/sys/ssnmp/snmpv3/usm 5name "slboper"/cfg/sys/ssnmp/snmpv3/access 4name "slbopergrp"rview "slboper"wview "slboper"nview "slboper"/cfg/sys/ssnmp/snmpv3/group 4uname slbopergname slbopergrp/cfg/sys/ssnmp/snmpv3/view 20name "slboper"tree "1.3.6.1.4.1.1872.2.5.1.2"/cfg/sys/ssnmp/snmpv3/view 21name "slboper"tree "1.3.6.1.4.1.1872.2.5.1.3"/cfg/sys/ssnmp/snmpv3/view 22name "slboper"tree "1.3.6.1.4.1.1872.2.5.2.2"/cfg/sys/ssnmp/snmpv3/view 23name "slboper"tree "1.3.6.1.4.1.1872.2.5.2.3"/cfg/sys/ssnmp/snmpv3/view 24name "slboper"tree "1.3.6.1.4.1.1872.2.5.3.2"/cfg/sys/ssnmp/snmpv3/view 25name "slboper"tree "1.3.6.1.4.1.1872.2.5.3.3"/cfg/sys/ssnmp/snmpv3/view 26name "slboper"tree "1.3.6.1.4.1.1872.2.5.4"/cfg/sys/ssnmp/snmpv3/view 27name "slboper"tree "1.3.6.1.4.1.1872.2.5.4.1"type excluded/cfg/sys/ssnmp/snmpv3/view 28name "slboper"tree "1.3.6.1.4.1.1872.2.5.5.2"/cfg/sys/ssnmp/snmpv3/view 29name "slboper"tree "1.3.6.1.4.1.1872.2.5.5.3"/cfg/sys/ssnmp/snmpv3/view 30name "slboper"tree "1.3.6.1.4.1.1872.2.5.6.2"

Configuring SNMP Trap HostsSNMPv1 trap host




.


Step Action

1 To configure a SNMPv1 trap host, first configure a user with noauthentication and password.

>> # /cfg/sys/ssnmp/snmpv3/usm 10name "v1trap"

2 Configure an access group and group table entries for theuser. The nview command is used to specify whichtraps can be received by the user. In the examplebelow, the user will receive the traps send by theswitch.

>> # /cfg/sys/ssnmp/snmpv3/access 10>> SNMPv3 vacmAccess 10 # name "v1trap">> SNMPv3 vacmAccess 10 # model snmpv1>> SNMPv3 vacmAccess 10 # nview "iso"

>> # /cfg/sys/ssnmp/snmpv3/group 10>> SNMPv3 vacmSecurityToGroup 10 # model snmpv1>> SNMPv3 vacmSecurityToGroup 10 # uname v1trap>> SNMPv3 vacmSecurityToGroup 10 # gname v1trap

3 Configure an entry in the notify table.

>> # /cfg/sys/ssnmp/snmpv3/notify 10>> SNMPv3 vacmSecurityToGroup 10 # name v1trap>> SNMPv3 vacmSecurityToGroup 10 # tag v1trap

4 Specify the IP address and other trap parameters in thetargetAddr and targetParam tables. The uname command isused to specify the user name used with this targetParamtable.

>> # /cfg/sys/ssnmp/snmpv3/taddr10

(Access the targetAddrTable Menu)

>> SNMPv3 snmpTargetAddrTable 10 # name v1trap>> SNMPv3 snmpTargetAddrTable 10 # addr 50.80.23.245>> SNMPv3 snmpTargetAddrTable 10 # taglist v1trap>> SNMPv3 snmpTargetAddrTable 10 # pname v1param




.


>> # /cfg/sys/ssnmp/snmpv3/tparam10

(Access thetargetParams tablemenu)

>> SNMPv3 snmpTargetParamsTable 10 # name v1param>> SNMPv3 snmpTargetParamsTable 10 # mpmodel snmpv1>> SNMPv3 snmpTargetParamsTable 10 # uname v1trap>> SNMPv3 snmpTargetParamsTable 10 # model snmpv1

5 Specify the community string used in the traps using thecommunity table.

>> # /cfg/sys/ssnmp/snmpv3/comm 10 (Select the CommunityTable)

>> SNMPv3 snmpCommunityTable 10 # index v1trap>> SNMPv3 snmpCommunityTable 10 # name public>> SNMPv3 snmpCommunityTable 10 # uname v1trap

—End—

SNMPv2 trap host configuration The v2 trap host configuration is similarto the SNMPv1 trap host configuration. Wherever you specify the modelmake sure to specify snmpv2 instead of snmpv1.

/cfg/sys/ssnmp/snmpv3/usm 10name "v2trap"/cfg/sys/ssnmp/snmpv3/access 10

name "v2trap"model snmpv2nview "iso"

/cfg/sys/ssnmp/snmpv3/group 10model snmpv2uname v2trapgname v2trap

/cfg/sys/ssnmp/snmpv3/taddr 10name v2trapaddr 50.81.25.66taglist v2trappname v2param

/cfg/sys/ssnmp/snmpv3/tparam 10name v2parammpmodel snmpv2cuname v2trapmodel snmpv2

/cfg/sys/ssnmp/snmpv3/notify 10name v2traptag v2trap




.


/cfg/sys/ssnmp/snmpv3/comm 10index v2trapname publicuname v2trap

SNMPv3 trap host configuration To configure a user for SNMPv3 traps,you can choose to send the traps with both privacy and authentication, withauthentication only, or with neither.

An SNMPv3 trap host is configured in the access table using the followingcommands:

>> # /cfg/sys/ssnmp/snmpv3/access <x> /levelEnter new access level [noAuthNoPriv|authNoPriv|authPriv]:<access-level>

>> # /cfg/sys/ssnmp/snmpv3/tparam <snmpTargetParams number:(1-16)>

The user in the user table should also be configured accordingly from theSNMPv3 usmUser 1 Menu, which is accessed from the following command:

>> /cfg/sys/ssnmp/snmpv3/usm <usmUser number: (1-16)>

It is not necessary to configure the community table for SNMPv3 trapsbecause the community string is not used by SNMPv3.

The following example shows how to configure an SNMPv3 user ’v3trap’with authentication only:

/cfg/sys/ssnmp/snmpv3/usm 11name "v3trap"auth md5authpw v3trap

/cfg/sys/ssnmp/snmpv3/access 11name "v3trap"level authNoPrivnview "iso"

/cfg/sys/ssnmp/snmpv3/group 11uname v3trapgname v3trap

/cfg/sys/ssnmp/snmpv3/taddr 11name v3trapaddr 50.81.25.66taglist v3trappname v3param

/cfg/sys/ssnmp/snmpv3/tparam 11




.


name v3paramuname v3traplevel authNoPriv

/cfg/sys/ssnmp/snmpv3/notify 11name v3traptag v3trap

Using Nortel ASEMThe Nortel Application Switch Element Manager is a Java GUI applicationthat runs on many platforms used for configuring and monitoring NortelApplication Switches. The application communicates with the switches viathe SNMP protocol. Nortel ASEM can be integrated into larger NetworkManagement platforms such as HP OpenView.

Nortel ASEM requires SNMP to be enabled in the switch CLI.

The menu hierarchy is similar to but not identical to the CLI on the switch.Some of the functions that Nortel ASEM allows you to perform are thefollowing:

• Manage multiple switches simultaneously

Nortel ASEM has a tree control and a view panel similar to WindowsExplorer. View panels can be "torn off" and docked back into the view.Nortel ASEM allows you to view multiple aspects of a single switch, orcompare the same view of two different switches.

• Configure the switch

Nortel ASEM allows you to configure all the features on the switch,except security.

• View switch summary

Nortel ASEM provides an overall summary of the switch, such as portlevel statistics, layer 3 statistics, server load balancing health, Syslogviewer, MP statistics, and sessions.

• View server load balancing summary

Nortel ASEM allows you see the hierarchical association of serverload balancing components and at the same time view their state andstatistics. Color is used to give visual clues as to the health of the realserver.

• Enable/disable real servers

• Configure filters

Nortel ASEM allows you to insert a new filter, move a block of filters, orassign filters to ports.

• Monitor the switch




.


Nortel ASEM monitors data in tables and graphs. You must first select afew items in the table before the graph icons are enabled. Nortel ASEMgenerates line, bar, or pie charts.

• Export data to a file such as an Excel spreadsheet

"Nortel ASEM Screen Example" (page 36)illustrates an example of a NortelASEM screen.

Nortel ASEM Screen Example

Using the Browser-Based InterfaceNortel Application Switch Operating System Browser-based Interface (BBI)is a Web-based management interface for interactive switch access throughyour Web browser.

Configuring BBI Access via HTTPTo enable BBI access on the switch via HTTP, use the following command:

/cfg/sys/access/http ena

To change the HTTP web server port from the default port 80, use thefollowing command:

/cfg/sys/access/wport <x>




.


To access your switch via the Browser-Based Interface, open a Webbrowser window and type in the URL using the IP interface address of theswitch, such as http://10.10.10.1.

Configuring BBI Access via HTTPSThe BBI can also be accessed via a secure HTTPS connection overmanagement and data ports.

To enable BBI Access on the switch via HTTPS, use the following command:

/cfg/sys/access/https/https ena

To change the HTTPS Web server port number from the default port 443,use the following command:

/cfg/sys/access/https/port <x>

Accessing the BBI via HTTPS requires that you generate a certificate tobe used during the key exchange. A default certificate is created the firsttime HTTPS is enabled, but you can create a new certificate defining theinformation you want to be used in the various fields.

>> /cfg/sys/access/https/generateCountry Name (2 letter code) [ ]: <country code>State or Province Name (full name) []: <state>Locality Name (eg, city) []: <city>Organization Name (eg, company) []: <company>Organizational Unit Name (eg, section) []: <org. unit>Common Name (eg, YOUR name) []: <name>Email (eg, email address) []: <email address>Confirm generating certificate? [y/n]: yGenerating certificate. Please wait (approx 30 seconds)restarting SSL agent

The certificate can be saved to flash for use if the switch is rebooted byusing the apply and save commands.

When a client (e.g. web browser) connects to the switch, they will be askedif they accept the certificate and can verify that the fields are what expected.Once BBI access is granted to the client, the BBI can be used as describedin the BBI Quick Guide.

Using the Management PortThe management port is a Fast Ethernet port on the Nortel ApplicationSwitch that is used exclusively for managing the switch. While the switchcan be managed from any network port, the management port conserves a




.


data port that could otherwise be used for processing requests. You can usethe management port to access the switch using Telnet (CLI), SSH, SNMP(ASEM), or HTTP (Nortel Application Switch Operating System BBI).

The management port does not participate in the switching and routingprotocols that run on the data ports, but it can be used to performmanagement functions such as,

• accessing the NTP server

• sending out SNMP traps

• sending out Syslog messages

• accessing the Radius server

• accessing the TACACS+ server

• accessing the DNS server

• performing TFTP or FTP functions (ptimg, gtimg, ptcfg, gtcfg,ptdmp)

• accessing the SMTP server

• running ping, Telnet and traceroute commands

Note: BOOTP is not supported over the management port.

For more information on using the commands to perform these functions,see the Nortel Application Switch Operating System Command Reference.

Setting Up the Management Port

Step Action

1 Configure a default gateway address.

>> Main# /cfg/sys/mmgmt/gw10.10.10.1

(Configure a defaultgateway)

2 Configure a static IP address.

>> Management Port# addr10.10.10.5

(Configure a static IPaddress)

>> Management Port# mask255.255.255.0

(Configure a network mask)

3 Enable the management port.




.


When the management port is enabled, you can use it to accessthe switch via Telnet, SSH, BBI, and SNMP (ASEM), provided thecommands are enabled on the switch. These commands can occursimultaneously on both the management port and the data ports.

>> Management Port# ena (Enable the managementport)

Note: There is a maximum of four concurrent Telnet sessionson the Nortel Application Switch over the management and dataports combined.

4 Configure the default port type for each management function.

Select the management port or the default data port for eachmanagement function. For example, select the management port forNTP, Radius, and Syslog functions only. SMTP, TFTP, and SNMPtraps are configured to use the default data ports.

>> Management Port# ntp mgmt (Select the managementport for NTP)

>> Management Port# radius mgmt (Select the managementport for radius)

>> Management Port# syslog mgmt (Select the managementport for syslog)

Note: The default for TFTP can be overridden by using the–data or –mgmt option after a gtimg, ptimg, gtcfg, ptcfg,or ptdmp command.

5 Apply, verify your configuration, and save the changes.

>> Management Port # apply (Make your changes active)

>> Management Port # cur (View current settings)

>> Management Port # save (Save for restore afterreboot)

—End—




.


Limiting Management AccessIn previous versions of the Nortel Application Switch Operating System,when a management service such as Telnet, SSH, or SNMP was enabledon the switch, the service was accessible from the management and dataports. The switch administrator now has the capability to disable access toa management service from a data port.

"Management Access Commands" (page 40)outlines commands that canbe used to limit management services from data ports.

Management Access Commands

Action Command

Enable port for managementaccess.

/cfg/sys/access/port/add <port number>

Disable port frommanagement access.

/cfg/sys/access/port/rem <port number>

Disable all ports frommanagement access.

/cfg/sys/access/port/arem

Current listing of data portswith management access.

/cfg/sys/access/port/cur

Feature DescriptionTo support configuring 128 management IP addresses and mask pairs,support need to be added to provide more restriction if needed by enablingonly a particular type of access for a given network like Telnet, SSH, SNMP,or BBI.

Action Command

Now accepts 128 networks /cfg/sys/access/mgmt/add <1-128>

addr: IP Addressmask: Network maskacctype: all | telnet | ssh | snmp | bbi

Note: By default access type is all

/cfg/sys/access/mgmt/add <1-128><addr> <mask> <acctype>

Removes a defined network, whichconsists of a management networkaddress and management networkmask address.

/cfg/sys/access/mgmt/rem




.


Action Command

When a user enters a specific accesstype, only that protocol access isremoved. Network can accessthrough other access protocols.When all (default feature) is entered,network is removed.addr: IP Addressmask: Network maskacctype: all | telnet | ssh | snmp | bbi

Note: By default access type is all

/cfg/sys/access/mgmt/rem <addr><mask> <acctype>

When a user enters this commandall the entries are removed giving alltype of access to all the users as if norestrictions are configured.

/cfg/sys/access/mgmt/arem

It displays Network address, maskand access protocol for all thenetworks configured upto 128.

/cfg/sys/access/mgmt/cur

File TransfersThe Nortel Application Switch Operating System supports the usage of theFile Transfer Protocol (FTP) as a file transfer alternative to the Trivial FileTransfer Protocol (TFTP). FTP is supported over data and managementports for the upload and download of the following file types:

• Software Images

• Configuration Files

• TSDumps

• Panic Dumps

A FTP host name, file name, user name, and password is requested whenusing FTP.

The initiation of boot image uploads and downloads is also supportedthrough SNMP and the Browser-Based Interface.

Time ConfigurationThis section describes the time configuration options available in the NortelApplication Switch Operating System.

Time Zone ConfigurationUpon set up, the switch should be configured with the appropriate time zoneconfiguration. This enables the switch to provide proper time offsets and tobe able to adjust for Daylight Savings Time.




.


The following example sets the time zone to Atlantic Time for a switch that isphysically located in Atlantic Canada.

Step Action

1 Access time zone configuration.

>> Main# /cfg/sys/timezone

2 Select the general geographic zone in which the switch islocated.

Please identify a location so that time zonerules can beset correctly.Please select a continent or ocean.1) Africa2) Americas3) Antarctica4) Arctic Ocean5) Asia6) Atlantic Ocean7) Australia8) Europe9) Indian Ocean10) Pacific Ocean11) None - disable timezone settingEnter the number of your choice: 2

Note: The time zone setting can be disabled in this menu byselecting 11.

3 Select the country inside the geographic zone previouslyselected.

Please select a country.1) Anguilla 18) Ecuador 35) Paraguay2) Antigua & Barbuda 19) El Salvador 36) Peru3) Argentina 20) French Guiana37) Puerto Rico4) Aruba 21) Greenland 38)St Kitts & Nevis5) Bahamas 22) Grenada 39) St Lucia6) Barbados 23) Guadeloupe 40)St Pierre & Miquelon7) Belize 24) Guatemala 41) St Vincent8) Bolivia 25) Guyana 42) Suriname




.


9) Brazil 26) Haiti 43)Trinidad & Tobago10) Canada 27) Honduras 44)Turks & Caicos Is11) Cayman Islands 28) Jamaica 45)United States12) Chile 29) Martinique 46) Uruguay13) Colombia 30) Mexico 47) Venezuela14) Costa Rica 31) Montserrat 48)Virgin Islands (UK)15) Cuba 32) Netherlands Antilles49) Virgin Islands(US)16) Dominica 33) Nicaragua17) Dominican Republic 34) PanamaEnter the number of your choice: 10

4 Select the time zone appropriate to the specific geographiclocation of the switch.

Please select one of the following time zone regions.1) Newfoundland Island2) Atlantic Time - Nova Scotia (most places),NB, W Labrador, E Que-bec & PEI3) Atlantic Time - E Labrador4) Eastern Time - Ontario & Quebec - most locations5) Eastern Time - Thunder Bay, Ontario6) Eastern Standard Time - Pangnirtung, Nunavut7) Eastern Standard Time - east Nunavut8) Eastern Standard Time - central Nunavut9) Central Time - Manitoba & west Ontario10) Central Time - Rainy River & FortFrances, Ontario11) Central Time - west Nunavut12) Central Standard Time - Saskatchewan -most locations13) Central Standard Time - Saskatchewan - midwest14) Mountain Time - Alberta, east BritishColumbia & westSaskatchewan15) Mountain Time - central Northwest Territories16) Mountain Time - west Northwest Territories17) Mountain Standard Time - Dawson Creek &Fort Saint John, BritishColumbia18) Pacific Time - west British Columbia19) Pacific Time - south Yukon20) Pacific Time - north Yukon




.


Enter the number of your choice: 2

5 Apply and save the configuration change.

—End—

Network Time ProtocolThe network time protocol (NTP) is used to provide a switch with an accuratetime by synchronizing with a time server on either an internal or externalnetwork. Using NTP ensures that the switch always has an accurate timefor the various functions that integrate and use time.

To view the current NTP settings on the switch using the following command:

>> Main# /cfg/sys/ntp/curCurrent NTP state: disabledCurrent primary NTP server: 0.0.0.0Current resync interval: 1440 minutesCurrent GMT timezone offset: -8:00

The following example configures NTP for a switch:

Step Action

1 Access the NTP menu.

>> Main# /cfg/sys/ntp

2 Set the IP address of the primary NTP server.

This would be the NTP server that the switch would regularlysynchronize with to adjust its time.

>> NTP Server# prisrvCurrent NTP server address: 0.0.0.0Enter new NTP server address: 192.168.249.13

3 Set the IP address of the secondary NTP server.

This would be the NTP server that the switch would synchronize within instances where the primary server is not available.

>> NTP Server# secsrvCurrent NTP server address: 0.0.0.0Enter new NTP server address: 192.168.249.45




.


4 Set the resynchronisation interval.

The resynchronisation interval is the amount of time the switch waitsbetween queries to the NTP server.

>> NTP Server# intrvalCurrent resync interval (minutes): 1440Enter new resync interval (minutes) [1-44640]: 2000

5 (Optional) Set the NTP time zone offset.

The NTP time zone offset from Greenwich Mean Time defaults tothe setting configured with the switch time zone was set up. If thishas not been done, or you wish to override the current value, dothe following:

>> NTP Server# tzoneCurrent GMT timezone offset: -8:00Enter new GMT timezone offset in hours [-12:00,+12:00]: +4:00

6 Enable NTP functionality.

After NTP functionality has been configured, it must be enabled.

>> NTP Server# onCurrent status: OFFNew status: ON

Note: To disable NTP functionality use the off command.

—End—




.


Securing the Switch

Secure switch management is necessary for environments in whichsignificant management functions are performed across the Internet. Thefollowing topics are addressed in this section:

• "Protecting Switch-Owned Addresses from Attacks" (page 46)

• "Setting Source IP Address Ranges for Switch Management" (page 48)

• "RADIUS Authentication and Authorization" (page 49)

• "TACACS+ Authentication" (page 54) "TACACS+ Authentication" (page54)

• "Secure Shell and Secure Copy" (page 58)

• "End User Access Control" (page 64)

• "Deny Routes" (page 67)

Protecting Switch-Owned Addresses from AttacksDenial of Service (DOS) attacks can be targeted not only at real servers, butat any IP address that is owned by an Nortel Application Switch. A DOSattack can potentially overwhelm switch resources. The system-wide ratelimiting command can be used to prevent DOS attacks over ARP, ICMP,TCP and UDP protocols by setting the maximum rate at which packetscan enter the switch. After the configured limit has been reached, packetsare dropped. The maximum rate (packets per second) can be configureddifferently for each of the supported protocols.

How Different Protocols Attack the SwitchWithout the system-wide rate limiting commands enabled, the followingprotocol packets destined to a switch-owned management interface couldpotentially overwhelm its management processor’s CPU capacity:

• Address Resolution Protocol (ARP) requests to the switch managementinterface IP address.

• ICMP pings to the switch management interface IP address.

• TCP SYN packets sent the switch management interface IPaddress—including Telnet sessions, HTTP requests via theBrowser-Based Interface, and BGP peer connections to the switch."TCP Rate Limiting" (page 629) should also be configured to limit TCPpackets destined to a switch virtual server IP (vip) address.

• UDP packets sent to a switch interface address—including routinginformation protocol (RIP) and simple network management protocol(SNMP) packets.




.

Securing the Switch 47

Configuring Denial of Service Protection

Step Action

1 Set the rate limit for the desired protocol.

>> /cfg/sys/access/rlimitEnter protocol [arp|icmp|tcp|udp]: arpCurrent max rate: 0

Enter new max rate: 1000 (Set rate to 1000 packetsper second)

2 Repeat step 1 to configure rate limits on any other of thesupported protocols.

3 Apply and save the configuration.

—End—

Viewing Dropped PacketsThe /stats/sp/maint command is used to view the number of droppedpackets for each protocol which is configured for system-wide rate limiting.The information is available on a per-switch processor (SP) basis:

>> Main# /stats/sp/maintEnter SP number: (1-4) 22------------------------------------------------------------Maintenance statistics for SP 2:Receive Letter success from MP: 6487510Receive Letter success from SP 1: 0Receive Letter success from SP 3: 0Receive Letter success from SP 4: 0Receive Letter errors from MP: 0Receive Letter errors from SP 1: 0Receive Letter errors from SP 3: 0Receive Letter errors from SP 4: 0Send Letter success to MP: 13808935Send Letter success to SP 1: 0Send Letter success to SP 3: 0Send Letter success to SP 4: 8Send Letter failures to MP: 13Send Letter failures to SP 1: 0Send Letter failures to SP 3: 0Send Letter failures to SP 4: 0learnErrNoddw: 0 resolveErrNoddw: 0ageMPNoddw: 0 deleteMiss: 0




.


pfdbFreeEmpty: 0arpDiscards: 0 icmpDiscards: 0tcpDiscards: 0 udpDiscards: 0

Dynamic Memory statistics--------------------------------------------------Total memory in bytes 36699136Current memory in bytes 5580064allocs 28frees 2alloc failures 0bytes hiwait 5580064

Setting Source IP Address Ranges for Switch ManagementTo limit access to the switch without having to configure filters for eachswitch port, you can set a source IP address (or range) that allows toconnect to the switch IP interface through Telnet, SSH, SNMP, or the NortelApplication Switch Operating System Browser-Based Interface (BBI). Thisalso helps to prevent spoofing or attacks on the switch’s TCP/IP stack.

When an IP packet reaches the application switch, the source IP address ischecked against range of addresses defined by the management networkand mask. If the source IP address of the host or hosts are within this range,they are allowed to attempt to log in. Any packet addressed to a switch IPinterface with a source IP address outside this range is discarded.

Up to five management IP address and mask pairs can be configured onthe switch. For example, to define a range of allowed source IP addressesbetween 192.192.192.1 to 192.192.192.127, enter the following:

>> Main# /cfg/sys/access/mgmt addEnter Management Network Address:192.192.192.0Enter Management Network Mask: 255.255.255.128

The following source IP addresses are granted or not granted access tothe switch:

• A host with a source IP address of 192.192.192.21 falls within thedefined range and would be allowed to access the switch.

• A host with a source IP address of 192.192.192.192 falls outside thedefined range and is not granted access. To make this source IPaddress valid, you would need to shift the host to an IP address withinthe valid range specified by the addr and mask or modify the addr tobe 192.192.192.128 and the mask to be 255.255.255.128. This wouldput the 192.192.192.192 host within the valid range allowed by the addrand mask (192.192.192.128-255).




.


RADIUS Authentication and AuthorizationNortel Application Switch Operating System supports the RADIUS (RemoteAuthentication Dial-in User Service) method to authenticate and authorizeremote administrators for managing the switch. This method is based ona client/server model. The Remote Access Server (RAS)—the switch—isa client to the back-end database server. A remote user (the remoteadministrator) interacts only with the RAS, not the back-end server anddatabase.

RADIUS authentication consists of the following components:

• A protocol with a frame format that utilizes UDP over IP (based on RFC2138 and 2866)

• A centralized server that stores all the user authorization information

• A client, in this case, the switch

RADIUS Authentication FeaturesNortel Application Switch Operating System supports the following Radiusauthentication features:

• Supports Radius client on the switch, based on the protocol definitionsin RFC 2138 and RFC 2866.

• Allows RADIUS secret password up to 32 bytes and less than 16 octets.

• Supports secondary authentication server so that when the primaryauthentication server is unreachable, the switch can send clientauthentication requests to the secondary authentication server. Usethe /cfg/sys/radius/cur command to show the currently activeRADIUS authentication server.

• Supports user-configurable RADIUS server retry and time-out values:

— Time-out value = 1-10 seconds

— Retries = 1-3

The switch times out if it does not receive a response from the RADIUSserver in 1-3 retries. The switch also automatically retries connecting tothe RADIUS server before it declares the server down.

• Supports user-configurable RADIUS application port.

The default is 1812/UDP-based on RFC 2138.

• Allows network administrator to define privileges for one or more specificusers to access the switch at the RADIUS user database.

• Supports SecurID if the RADIUS server can do an ACE/Server clientproxy. The password is the PIN number, plus the token code of theSecurID card.




.


How Radius Authentication WorksIn "RADIUS Authentication and Authorization: How It Works" (page 50), theNortel Application Switch—acting as the RADIUS client—communicates tothe RADIUS server to authenticate and authorize a remote administratorusing the protocol definitions specified in RFC 2138 and 2866. Transactionsbetween the client and the RADIUS server are authenticated using a sharedkey that is not sent over the network. In addition, the remote administratorpasswords are sent encrypted between the RADIUS client (the switch) andthe back-end RADIUS server.

RADIUS Authentication and Authorization: How It Works

Step Action

1 Remote administrator connects to the switch and provides username and password.

2 Using Authentication/Authorization protocol, the switch sendsrequest to authentication server.

3 Authentication server checks the request against the user IDdatabase.

4 Using RADIUS protocol, the authentication server instructs theswitch to grant or deny administrative access.

—End—

Configuring RADIUS Authentication on the Switch

Step Action

1 Turn RADIUS authentication on, then configure the Primary andSecondary RADIUS servers.




.


>> Main# /cfg/sys/radius (Select the RADIUSServer menu)

>> RADIUS Server# on (Turn RADIUS on)

Current status: OFFNew status: ON

>> RADIUS Server# prisrv 10.10.1.1 (Enter primary serverIP)

Current primary RADIUS server: 0.0.0.0New pending primary RADIUS server: 10.10.1.1

>> RADIUS Server# secsrv 10.10.1.2 (Enter secondary serverIP)

Current secondary RADIUS server: 0.0.0.0New pending secondary RADIUS server: 10.10.1.2

2 Configure the RADIUS secret.

>> RADIUS Server# secretEnter new RADIUS secret: <1-32 character secret>

CAUTIONIf you configure the RADIUS secret using any methodother than a direct console connection, the secret may betransmitted over the network as clear text.

3 If desired, you may change the default TCP port number usedto listen to RADIUS.

The well-known port for RADIUS is 1812.

>> RADIUS Server# portCurrent RADIUS port: 1812Enter new RADIUS port [1500-3000]: <port number>

4 Configure the number retry attempts for contacting the RADIUSserver, and the timeout period.

>> RADIUS Server# retriesCurrent RADIUS server retries: 3

Enter new RADIUS server retries[1-3]:

< server retries>




.


>> RADIUS Server# timeCurrent RADIUS server timeout: 3

Enter new RADIUS server timeout[1-10]: 10

(Enter the timeoutperiod in minutes)


—End—

Switch User AccountsThe user accounts listed in "Nortel Application Switch Operating SystemUser Accounts and Access Levels" (page 52) are provided as a referencehere for understanding user levels that can be defined in the RADIUS serverdictionary file (see "RADIUS Attributes for User Privileges" (page 53)), or fordefining Class of Service for the End User Access Control feature (see "EndUser Access Control" (page 64)).

Nortel Application Switch Operating System User Accounts and AccessLevels

User Account Description and Tasks Performed Password

User The User has no direct responsibility forswitch management. He/she can view allswitch status information and statistics butcannot make any configuration changes tothe switch.

user

SLB Operator The SLB Operator manages content serversand other Internet services and their loads.In addition to being able to view all switchinformation and statistics, the SLB Operatorcan enable/disable servers using the SLBoperation menu.

slboper

Layer 4 Operator The Layer 4 Operator manages traffic on thelines leading to the shared Internet services.This user currently has the same accesslevel as the SLB operator. This level isreserved for future use, to provide accessto operational commands for operatorsmanaging traffic on the line leading to theshared Internet services.

l4oper

Operator The Operator manages all functions of theswitch. In addition to SLB Operator functions,the Operator can reset ports or the entireswitch.

oper




.


User Account Description and Tasks Performed Password

SLB Administrator The SLB Administrator configures andmanages content servers and other Internetservices and their loads. In addition to SLBOperator functions, the SLB Administratorcan configure parameters on the SLB menus,with the exception of not being able toconfigure filters or bandwidth management.

slbadmin

Layer 4 Administrator

The Layer 4 Administrator configures andmanages traffic on the lines leading to theshared Internet services. In addition toSLB Administrator functions, the Layer 4Administrator can configure all parameterson the SLB menus, including filters andbandwidth management.

l4admin

Administrator The super-user Administrator has completeaccess to all menus, information, andconfiguration commands on the switch,including the ability to change both the userand administrator passwords.

admin

RADIUS Attributes for User PrivilegesWhen the user logs in, the switch authenticates his/her level of accessby sending the RADIUS access request, that is, the client authenticationrequest, to the RADIUS authentication server.

If the remote user is successfully authenticated by the authentication server,the switch verifies the privileges of the remote user and authorize theappropriate access. When both the primary and secondary authenticationservers are not reachable, the administrator has an option to allow backdooraccess via the console only or console and Telnet access. The default isdisable for Telnet access and enable for console access.

All user privileges, other than those assigned to the Administrator, have tobe defined in the RADIUS dictionary. Radius attribute 6 which is built into allRadius servers defines the administrator. The file name of the dictionary isRADIUS vendor-dependent. The following Radius attributes are defined forNortel Application Switch Operating System user privileges levels:

Nortel Application Switch Operating System-Proprietary Attributes for Radius

User Name/Access User-Service-Type Value

user Vendor-supplied 255

slboper Vendor-supplied 254

l4oper Vendor-supplied 253




.


User Name/Access User-Service-Type Value

oper Vendor-supplied 252

slbadmin Vendor-supplied 251

l4admin Vendor-supplied 250

admin Vendor-supplied 6 (pre-defined)

TACACS+ AuthenticationNortel Application Switch Operating System supports authentication andauthorization with networks using the Cisco Systems TACACS+ protocol.The Nortel Application Switch functions as the Network Access Server(NAS) by interacting with the remote client and initiating authenticationand authorization sessions with the TACACS+ access server. The remoteuser is defined as someone requiring management access to the NortelApplication Switch either through a data or management port.

TACACS+ offers the following advantages over RADIUS:

• TACACS+ uses TCP-based connection-oriented transport; whereasRADIUS is UDP-based. TCP offers a connection-oriented transport,while UDP offers best-effort delivery. RADIUS requires additionalprogrammable variables such as re-transmit attempts and time-outsto compensate for best-effort transport, but it lacks the level of built-insupport that a TCP transport offers.

• TACACS+ offers full packet encryption whereas RADIUS offerspassword-only encryption in authentication requests.

• TACACS+ separates authentication, authorization and accounting.

• TACACS+ offers privilege level mapping. By enabling cmap, the privilegelevel can be increased from default 0-6 to 0-15.

• Nortel Application Switch sends command log messages to TACACS+server when clog is enabled.

How TACACS+ Authentication WorksTACACS+ works much in the same way as RADIUS authentication asdescribed on "How Radius Authentication Works" (page 50).

Step Action

1 Remote administrator connects to the switch and provides username and password.

2 Using Authentication/Authorization protocol, the switch sendsrequest to authentication server.




.


3 Authentication server checks the request against the user IDdatabase.

4 Using TACACS+ protocol, the authentication server instructsthe switch to grant or deny administrative access.

—End—

TACACS+ uses the AAA architecture, which separates authentication,authorization, and accounting. This allows separate authenticationsolutions that can still use TACACS+ for authorization and accounting.For example, with TACACS+, it is possible to use Kerberos authenticationand TACACS+ authorization and accounting. After the Nortel ApplicationSwitch authenticates on a Kerberos server, it requests authorizationinformation from a TACACS+ server without requiring re-authentication.The Nortel Application Switch informs the TACACS+ server that it hassuccessfully authenticated on a Kerberos server, and the server thenprovides authorization information.

During a session, if additional authorization checking is needed, the NortelApplication Switch checks with a TACACS+ server to determine if the useris granted permission to use a particular command.

TACACS+ Authentication FeaturesAuthentication is the action of determining the identity of a user, andis generally done when the user first attempts to log in to a device orgain access to its services. Nortel Application Switch Operating Systemsupports ASCII inbound login to the device. PAP, CHAP and ARAP loginmethods, TACACS+ change password requests, and one-time passwordauthentication are not supported.

AuthorizationAuthorization is the action of determining a user’s privileges on the device,and usually takes place after authentication.

The mapping between TACACS+ authorization levels and Nortel ApplicationSwitch Operating System management access levels is shown in "NortelApplication Switch Operating System-Proprietary Attributes for TACACS+"(page 55).

Nortel Application Switch Operating System-Proprietary Attributes forTACACS+

Nortel Application Switch Operating SystemUser Access Level

TACACS+ level

user 0




.


Nortel Application Switch Operating SystemUser Access Level

TACACS+ level

slboper 1

l4oper 2

oper 3

slbadmin 4

l4admin 5

admin 6

AccountingAccounting is the action of recording a user’s activities on the devicefor the purposes of billing and/or security. It follows the authenticationand authorization actions. If the authentication and authorization is notperformed through TACACS+, there will be no TACACS+ accountingmessages sent out.

The approach is simple. Whenever there is successful command executionon CLI an accounting message is created by NAS and sent to the TACACS+server.

The attributes provided for the TACACS+ accounting are:

• protocol (console/telnet/ssh/http)

• start_time (in seconds, since 12am 1-1-1970)

• stop_time (in seconds, since 12am 1-1-1970)

• elapsed_time (in seconds)

• disc-cause (a string)

Note: Other than these, cmd and cmd-arg accounting attributes is alsosupported for command logging.

Configuring TACACS+ Authentication on the Switch

Step Action

1 Turn TACACS+ authentication on, then configure the Primaryand Secondary TACACS+ servers.

>> Main# /cfg/sys/tacacs (Select the TACACS+Server menu)

>> TACACS+ Server# on (Turn TACACS+ on)





.


>> TACACS+ Server# prisrv10.10.1.1

(Enter primary server IP)

Current primary TACACS+ server: 0.0.0.0New pending primary TACACS+ server: 10.10.1.1

>> TACACS+ Server# secsrv10.10.1.2

(Enter secondary server IP)

Current secondary TACACS+ server: 0.0.0.0New pending secondary TACACS+ server: 10.10.1.2

2 Configure the TACACS+ secret.

>> TACACS+ Server# secretEnter new TACACS+ secret: <1-32 character secret>

CAUTIONIf you configure the TACACS+ secret using any methodother than a direct console connection, the secret may betransmitted over the network as clear text.

3 If desired, you may change the default TCP port number usedto listen to TACACS+.

The well-known port for TACACS+ is 49.

>> TACACS+ Server# portCurrent TACACS+ port: 49Enter new TACACS+ port [1-65000]: <port number>

4 Configure the number retry attempts for contacting theTACACS+ server, and the timeout period.

>>TACACS+ Server# retriesCurrent TACACS+ server retries: 3

Enter new TACACS+ serverretries [1-3]:

<server retries>

>> TACACS+ Server# timeCurrent TACACS+ server timeout: 4

Enter new TACACS+ servertimeout [1-15]: 10

(Enter the timeout period inminutes)





.


—End—

Secure Shell and Secure CopyThe Telnet method of managing an Nortel Application Switch does notprovide a secure connection. Secure Shell (SSH) and Secure Copy(SCP) however, use secure tunnels so that messages between a remoteadministrator and the switch is encrypted and secured.

SSH is a protocol that enables remote administrators to log securely intoanother computer over a network to execute management commands.

SCP is typically used to copy files securely from one machine to another.SCP uses SSH for encryption of data on the network. On a NortelApplication Switch, SCP is used to download and upload the switchconfiguration via secure channels.

The Nortel Application Switch Operating System implementation of SSHsupports both versions 1.5 and 2.0. and supports SSH clients version1.5—2.x. The following SSH clients have been tested:

• SSH 1.2.23 and SSH 1.2.27 for Linux (freeware)

• SecureCRT 3.0.2 and SecureCRT 3.0.3 for Windows NT (Van DykeTechnologies, Inc.)

• F-Secure SSH 1.1 for Windows (Data Fellows)

• Putty SSH

• Cygwin OpenSSH

• Mac X OpenSSH

• Solaris 8 OpenSSH

• AxeSSH SSHPro

• SSH Communications Vandyke SSH A

• F-Secure

Note: There can be a maximum number of foursimultaneous Telnet/SSH/SCP connections at one time. The/cfg/sys/radius/telnet command also applies to SSH/SCPconnections.

Configuring SSH/SCP features on the switchSSH/SCP parameters can be configured via the console port only, usingthe CLI. However, SCP putcfg and TFTP getcfg can also change theSSH/SCP configuration. When SSH is enabled, SCP is also enabled. Theswitch SSH daemon uses TCP port 22 only and is not configurable.




.


Before you can use SSH commands, use the following commands to turnon SSH/SCP.

Enabling or disabling SSHConnect to the switch CLI and enter the following commands:

>> Main# /cfg/sys/access/sshd/on (Turn SSH on)


>> Main# /cfg/sys/access/sshd/off (Turn SSH off)

Current status: ONNew status: OFF

Enabling or disabling SCP apply and saveEnter the following commands from the switch CLI to enable the SCPputcfg_apply and putcfg_apply_save commands:

>> # /cfg/sys/access/sshd/ena (Enable SCP apply and save)

SSH Server# apply (Apply the changes to startgenerating RSA host andserver keys)

RSA host key generation starts..................................................................................................................RSA host key generation completes (lasts 212549 ms)RSA host key is being saved to Flash ROM, please don’trebootthe box immediately.RSA server key generation starts............................................................RSA server key generation completes (lasts 75503 ms)RSA server key is being saved to Flash ROM, please don’trebootthe box immediately.------------------------------------------------------------------Apply complete; don’t forget to "save" updatedconfiguration.

>> Main# /cfg/sys/access/sshd/dis (Disable SSH/SCP apply andsave)

Configuring the SCP Administrator PasswordTo configure the scpadmin (SCP Administrator) password, first connect tothe switch via the RS-232 management console. For security reasons,the scpadmim password may only be configured when connected directlyto the switch console.




.


To configure the password, enter the following command via the CLI. Atfactory default settings, the current SCP administrator password is admin.

>> /cfg/sys/access/sshd/scpadminChanging SCP-only Administrator password; validationrequired...Enter current administrator password: <password>Enter new SCP-only administrator password: <new password>Re-enter new SCP-only administrator password: <new password>New SCP-only administrator password accepted.

SCP ServicesTo perform SCP commands, you need the SCP admin password withadministrator privileges (this password must be different from the adminpassword).

The following SCP commands are supported in this service. Thesecommands are entered using the CLI on the client that is running the SCPapplication:

• getcfg is used to download the switch’s configuration to the remotehost via SCP.

• putcfg is used to upload the switch’s configuration from a remote hostto the switch; the diff command is automatically executed at the endof putcfg to notify the remote client of the difference between the newand the current configurations.

• putcfg_apply runs the apply command after the putcfg is done.

• putcfg_apply_save saves the new configuration to the flash afterputcfg_apply is done.

The putcfg_apply and putcfg_apply_save commands are providedbecause extra apply and save commands are usually required after aputcfg; however, an SCP session is not in an interactive mode at all.

Using SSH and SCP Client CommandsThis section shows the format for using some client commands. Theexamples below uses 192.168.249.13 as the IP address of a sample switch.

Logging into the switch:Syntax:

ssh <switch IP address> or ssh -l <login-name> <switch IPaddress>

Example:




.


>> # ssh 192.168.249.13

>> # ssh -l <login-name> 192.168.249.13 (Login to the switch)

Downloading the switch configuration using SCP:Syntax:

scp <switch IP address> :getcfg <local filename>

Example:

>> # scp 192.168.249.13:getcfg applSwitch.cfg

Uploading the configuration to the switch:Syntax:

scp <local filename> <switch IP address> :putcfg

Example:

>> # scp applSwitch.cfg 192.168.249.13:putcfg

Applying and saving the configurationThe apply and save commands are still needed after the last command(scp applSwitch.cfg 192.168.249.13:putcfg). Or, instead, youcan use the following commands:

>> # scp applSwitch.cfg 192.168.249.13:putcfg_apply>> # scp applSwitch.cfg 192.168.249.13:putcfg_apply_save

• The diff command is automatically executed at the end of putcfgto notify the remote client of the difference between the new and thecurrent configurations.

• putcfg_apply runs the apply command after the putcfg is done.

• putcfg_apply_save saves the new configuration to the flash afterputcfg_apply is done.

• The putcfg_apply and putcfg_apply_save commands areprovided because extra apply and save commands are usuallyrequired after a putcfg; however, an SCP session is not in aninteractive mode at all.

SSH and SCP Encryption of Management MessagesThe following encryption and authentication methods are supported forSSH and SCP:




.


Server Host Authentication: Client RSA authenticates the switch at thebeginning of every connection

Key Exchange: RSA

Encryption: 3DES-CBC, DES

User Authentication: Local password authentication, RADIUS,SecurID (via RADIUS, for SSH only—does notapply to SCP)

Generating RSA Host and Server Keys for SSH AccessTo support the SSH server feature, two sets of RSA keys (host and serverkeys) are required. The host key is 1024 bits and is used to identify theNortel Application Switch. The server key is 768 bits and is used to makeit impossible to decipher a captured session by breaking into the NortelApplication Switch at a later time.

When the SSH server is first enabled and applied, the switch automaticallygenerates the RSA host and server keys and is stored in the FLASHmemory.

To configure RSA host and server keys, first connect to the switch via theconsole port (these commands are not available via Telnet connection), andenter the following commands to generate the keys manually

>> # /cfg/sys/access/sshd/hkeygen (Generates the host key)

>> # /cfg/sys/access/sshd/skeygen (Generates the server key)

These two commands take effect immediately without the need of an applycommand.

When the switch reboots, it retrieves the host and server keys from theFLASH memory. If these two keys are not available in the flash and ifthe SSH server feature is enabled, the switch automatically generatesthem during the system reboot. This process may take several minutesto complete.

The switch can also automatically regenerate the RSA server key. To setthe interval of RSA server key autogeneration, use this command:

>> # /cfg/sys/access/sshd/interval <number of hours (0-24)>

Note: The /cfg/sys/access/sshd/interval is only availablewhen connected through the console port.




.


The number of hours must range between 0–24. A value of 0 denotes thatRSA server key autogeneration is disabled. When greater than 0, the switchautogenerates the RSA server key every specified interval; however, RSAserver key generation is skipped if the switch is busy doing other key orcipher generation when the timer expires.

Note: The Nortel Application Switch performs only one session ofkey/cipher generation at a time. Thus, an SSH/SCP client is not beable to log in if the switch is performing key generation at that time, or ifanother client has logged in immediately prior. Also, key generation failsif an SSH/SCP client is logging in at that time.

SSH/SCP Integration with Radius AuthenticationSSH/SCP is integrated with RADIUS authentication. After the RADIUSserver is enabled on the switch, all subsequent SSH authentication requestsis redirected to the specified RADIUS servers for authentication. Theredirection is transparent to the SSH clients.

SSH/SCP Integration with SecurIDSSH/SCP can also work with SecurID, a token card-based authenticationmethod. The use of SecurID requires the interactive mode during login,which is not provided by the SSH connection.

Note: There is no SNMP or Browser-Based Interface (BBI) support forSecurID because the SecurID server, ACE, is a one-time passwordauthentication and requires an interactive session.

Using SecurID with SSHUsing SecurID with SSH involves the following tasks.

• To log in using SSH, use a special username, "ace," to bypass the SSHauthentication.

• After an SSH connection is established, you are prompted to enter theusername and password (the SecurID authentication is being performednow).

• Provide your username and the token in your SecurID card as a regularTelnet user.

Using SecurID with SCPUsing SecurID with SCP can be accomplished in two ways:

• Using a RADIUS server to store an administrator password.

You can configure a regular administrator with a fixed password in theRADIUS server if it can be supported. A regular administrator with afixed password in the RADIUS server can perform both SSH and SCPwith no additional authentication required.




.


• Using an SCP-only administrator password.

Use the command, /cfg/sys/access/sshd/scpadmin to bypassthe checking of SecurID.

Note: The /cfg/sys/access/sshd/scpadmin command is onlyavailable when connected through the console port.

An SCP-only administrator’s password is typically used when SecurID isused. For example, it can be used in an automation program (in whichthe tokens of SecurID are not available) to back up (download) the switchconfigurations each day.

Note: The SCP-only administrator’s password must be different fromthe regular administrator’s password. If the two passwords are the same,the administrator using that password is not allowed to log in as a SSHuser because the switch recognizes him as the SCP-only administratorand only allow the administrator access to SCP commands.

Alternately, you can configure a regular administrator with a fixed passwordin the RADIUS server if it can be supported. A regular administrator with afixed password in the RADIUS server can perform both SSH and SCP withno additional authentication required.

End User Access ControlNortel Application Switch Operating System allows an administrator todefine end user accounts that permit end users to operationally act on theirown real servers via the switch CLI commands. Once end user accountsare configured and enabled, the switch requires the username/passwordauthentication.

For example, an administrator can assign a user to manage real servers 1and 2 only. The user can then log into the switch and perform operationalcommands (effective only until the next switch reboot), to enable or disablethe real servers, or change passwords on the real servers.

Considerations for Configuring End User Accounts

• Only one user ID can be assigned to a real server resource to enable ordisable a real server. Consequently, a single end user may be assignedthe maximum number of real servers that can be configured on theswitch, to the exclusion of any other users.

• A maximum of 10 user IDs are supported on the switch.

• The administrator must ensure that all real and backup servers orgroups belonging to a virtual service are owned by the same end userID. The switch does not automatically validate configurations. The




.


criterion for displaying virtual service information for end users is basedon the validation of ownership of the first real server in the group fora given virtual server port.

• The Nortel Application Switch Operating System has end user supportfor Console and Telnet access to the switch. As a result, only very limitedaccess is granted to the Primary Administrator under the BBI/SSH1mode of access.

• If RADIUS authentication is used, the user password on the Radiusserver will override the user password on the Nortel ApplicationSwitch. Also note that the password change command on the switchONLY modifies the use switch password and has no effect on theuser password on the Radius server. Radius authentication and userpassword cannot be used concurrently to access the switch.

• Passwords can be up to 128 characters in length for TACACS, RADIUS,Telnet, SSH, Console, and Web access.

User Access Control MenuThe end user access control menu is located in the System access menu.

>> # /cfg/sys/access/user

Setting up User IDsUp to 10 user IDs can be configured.

/cfg/sys/access/user/uid 1

Defining User Names and Passwords

>> User ID 1 # name jane (Assign name "jane" to user ID1)

Current user name:New user name: jane

Changing Passwords

>> User ID 1 # passwdChanging user password; validation required:Enter current admin password: <current administratorpassword>Enter new user password: <new user password>Re-enter new user password: <new user password>New user password accepted.




.


Defining User Access LevelThe end user is by default assigned to the user access level (also known asclass of service, or CoS). CoS for all user accounts have global access to allresources except for User CoS, which has access to view resources thatthe user owns only. For more information, see "Nortel Application SwitchOperating System User Accounts and Access Levels" (page 52).

To change the user’s level, enter the class of service cos command, andselect one of the following options:

>> User ID 1 # cos <user|slboper|l4oper|oper|slbadmin|l4admin|admin>

Assigning One or More Real Servers to the End UserA single end user may be assigned up to 1023 real servers. Once assigned,the real server cannot be assigned to any other user.

>> User ID 1 # addEnter real server number: (1-1023) 23

Validating User Configuration

User ID 2 # curname jane , dis, cos user , password valid, offlinereal servers:23: 0.0.0.0, disabled, name , weight 1,

timeout 20 mins, max-con 200000

24: 0.0.0.0, disabled, name , weight 1,timeout 20 mins, max-con 200000

Listing Current UsersThe cur command displays defined user accounts and whether or not eachuser is currently logged into the switch.

# /cfg/sys/access/user/cur

Usernames:user - Enabledslboper - Disabledl4oper - Disabledoper - Disabledslbadmin - Disabledl4admin - Disabledadmin - Always Enabled




.


Current User ID table:1: name jane , ena, cos user , passwordvalid, online

real servers:1: 10.10.10.211, disabled, name , weight

1, timeout 10 mins,maxcon 200000

2: 10.10.10.212, enabled, name , weight 1,timeout 10 mins,maxcon 2000002: name john , ena, cos user , passwordvalid, online

real servers:3: 10.10.10.213, enabled, name , weight 1,

timeout 10 mins,maxcon 200000

Enabling or Disabling a UserAn end user account must be enabled before the switch recognizes andpermits login under the account. Once enabled, the switch requires anyuser to enter both username and password.

>> # /cfg/sys/access/user/uid <#> /ena>> # /cfg/sys/access/user/uid <#> /dis

Logging into an End User AccountOnce an end user account is configured and enabled, the user can login tothe switch username/password combination. The level of switch access isdetermined by the CoS established for the end user account.

Deny RoutesA deny route, or black hole route, can be configured to deny Layer 3routable packets to destinations covered by a static route. A deny route iscreated by setting the gateway address in a static route to 0. If the longestprefix match route (which is obtained via route lookup) is deny route, thepacket is dropped.

A deny route may be configured when an administrator finds a specific useror network that is under attack. For example, IP addresses in the 62.62.x.xnetwork are under attack from an unknown source. The Nortel ApplicationSwitch can be configured temporarily with a deny route so that any trafficdestined to this network is dropped. In the meantime the attack patternand source can be detected.




.


This feature is similar to a deny filter, except that it works only on routableLayer 3 traffic; it does not deny Layer 2 traffic.

Configuring a Deny RouteTo deny traffic to the destination network 62.62.0.0, enter the followingcommands.

>> # /cfg/l3/route (Select the IP Static Routemenu)

>> IP Static Route# add (Add a static route)

Enter destination IP address:62.62.0.0

(Of this IP network address)

Enter destination subnet mask: 255.255.0.0(And this maskaddress)Enter gateway IP address (for martian/deny route use 0):0

(Enter 0 to create a deny route)

Enter interface number: (1-256) (A deny route will ignore an Interface number, so don’t enter onehere.)

CAUTIONDo not configure a deny route that covers the destination/maskpair of an existing IP interface’s IP address/mask pair. Forexample, if you have an IP interface of 50.0.0.1/255.0.0.0, and adeny route of 50.0.0.0/255.0.0, then traffic to the interface as wellas the subnet is denied—which is not the desired result.

Viewing a Deny RouteTo view a deny route, enter the /info/l3/dump command. A deny routeappears in the routing table in bold.

Status code: * - bestDestination Mask Gateway

Type Tag Metr If--------------- --------------- ------------------------ --------- ---- --* 0.0.0.0 0.0.0.0 47.80.16.1indirect static 47* 52.80.16.0 255.255.254.0 47.80.16.59direct fixed 47* 52.80.16.59 255.255.255.255 47.80.16.59local addr 47* 52.80.17.255 255.255.255.255 47.80.17.255broadcast broadcast 47




.


* 62.62.0.0 255.255.0.0 0.0.0.0deny static




.





.

71

VLANs

This chapter describes network design and topology considerations forusing Virtual Local Area Networks (VLANs). VLANs are commonly used tosplit up groups of network users into manageable broadcast domains, tocreate logical segmentation of workgroups, and to enforce security policiesamong logical segments.

The following topics are addressed in this chapter:

• "VLAN ID Numbers" (page 71)

• "VLAN Tagging" (page 72)

• "VLANs and the IP Interfaces" (page 72) This section briefly describeshow management functions can only be accomplished from stations onVLANs that include an IP interface to the switch.

• "VLAN Topologies and Design Issues" (page 72) This section discusseshow you can logically connect users and segments to a host thatsupports many logical segments or subnets by using the flexibility ofthe multiple VLAN system.

• "VLANs and Default Gateways" (page 75)

Note: Basic VLANs can be configured during initial switch configuration(see "Using the Setup Utility" in the Nortel Application SwitchOperating System Command Reference). More comprehensive VLANconfiguration can be done from the Command Line Interface (see "VLANConfiguration" as well as "Port Configuration" in the Nortel ApplicationSwitch Operating System Command Reference).

VLAN ID NumbersNortel Application Switch Operating System supports up to 2048 VLANs perswitch. Even though the maximum number of VLANs supported at any giventime is 2048, each can be identified with any number between 1 and 4090.

VLANs are defined on a per-port basis. Each port on the switch can belongto one or more VLANs, and each VLAN can have any number of switchports in its membership. Any port that belongs to multiple VLANs, however,must have VLAN tagging enabled (see "VLAN Tagging" (page 72)).




.

72 VLANs

Each port in the switch has a configurable default VLAN number, known asits PVID. The factory default value for all PVIDs is 1. This places all ports onthe same VLAN initially, although each port’s PVID is configurable to anyVLAN number between 1 and 4090.

Any untagged frames (those with no VLAN specified) are classified with thesending port’s PVID.

VLAN TaggingNortel Application Switch Operating System software supports 802.1QVLAN tagging, providing standards-based VLAN support for Ethernetsystems.

Tagging places the VLAN identifier in the frame header, allowing multipleVLANs per port. When you configure multiple VLANs on a port, you mustalso enable tagging on that port.

Since tagging fundamentally changes the format of frames transmitted ona tagged port, you must carefully plan network designs to prevent taggedframes from being transmitted to devices that do not support 802.1Q VLANtags.

VLANs and the IP InterfacesCarefully consider how you create VLANs within the switch, so thatcommunication with the switch remains possible.

You can access the switch for remote configuration, trap messages, andother management functions only from stations on VLANs that include anIP interface to the switch (see "IP Interface Menu" section in the NortelApplication Switch Operating System Command Reference). Likewise, youcan cut off access to management functions to any VLAN by excluding IPinterfaces from the VLAN’s membership.

For example, if all IP interfaces are left on VLAN 1 (the default), and all portsare configured for VLANs other than VLAN 1, then switch managementfeatures are effectively cut off. If an IP interface is added to one of the otherVLANs, the stations in that VLAN will all have access to switch managementfeatures.

VLAN Topologies and Design IssuesBy default, the Nortel Application Switch Operating System software has asingle VLAN configured on every port. This configuration groups all portsinto the same broadcast domain. The VLAN has an 802.1Q VLAN PVIDof 1. VLAN tagging is turned off, because by default only a single VLAN isconfigured per port.




.

VLAN Topologies and Design Issues 73

Since VLANs are most commonly used to create individual broadcastdomains and/or separate IP subnets, host systems should be present onmore than one VLAN simultaneously. Nortel Application Switches andVLAN-tagging server adapters support multiple VLANS on a per-port orper-interface basis, allowing very flexible configurations.

You can configure multiple VLANs on a single VLAN-tagging server adapter,with each VLAN being configured through a logical interface and logical IPaddress on the host system. Each VLAN configured on the server adaptermust also be configured on the switch port to which it is connected. Ifmultiple VLANs are configured on the port, tagging must be turned on.

Using this flexible multiple VLAN system, you can logically connect usersand segments to a host with a single VLAN-tagging adapter that supportsmany logical segments or subnets.

Note: If a 802.1Q tagged frame is sent to a port that has vlan-taggingdisabled, then the frames are dropped at the ingress port.

Example 1: Multiple VLANS with Tagging AdaptersExample 1: Multiple VLANs with VLAN-Tagged Gigabit Adapters

The features of this VLAN are described below:




.

74 VLANs

Component Description

Application Switch This switch is configured for three VLANs that representthree different IP subnets. Two servers and five clients areattached to the switch.

Server #1 This server is part of VLAN 3 and only has presence inone IP subnet. The port that the VLAN is attached to isconfigured only for VLAN 3, so VLAN tagging is off.

Server #2 This high-use server needs to be accessed from all VLANsand IP subnets. The server has a VLAN-tagging adapterinstalled with VLAN tagging turned on. The adapter isattached to one of the application switch’s Gigabit Ethernetports, that is configured for VLANs 1, 2, and 3. Taggingis turned on. Because of the VLAN tagging capabilitiesof both the adapter and the switch, the server is ableto communicate on all three IP subnets in this network.Broadcast separation between all three VLANs and subnets,however, is maintained.

PCs #1 and #2 These PCs are attached to a shared media hub that isthen connected to the switch. They belong to VLAN 2 andare logically in the same IP subnet as Server 2 and PC 5.Tagging is not enabled on their switch port.

PC #3 A member of VLAN 1, this PC can minimize its broadcastdomain to Server 2 and PC 5.

PC #4 A member of VLAN 3, this PC can minimize its broadcastdomain to Server 1 and Server 2.

PC #5 A member of both VLAN 1 and VLAN 2, this PC hasVLAN-tagging Gigabit Ethernet adapter installed. It canminimize its broadcast domain to Server #2 via VLAN 1, andto PC #1 and PC #2 via VLAN 2. The switch port to which itis connected is configured for both VLAN 1 and VLAN 2 andhas tagging enabled.

Note: VLAN tagging is required only on ports that are connected toother Nortel Application Switches or on ports that connect to tag-capableend-stations, such as servers with VLAN- tagging adapters.

Example 2: Parallel Links with VLANsExample 2 shows how it is possible, through the use of VLANs, to createconfigurations where there are multiple links between two switches, withoutcreating broadcast loops.

In "Example 2: Parallel Links with VLANs" (page 75), two Nortel ApplicationSwitches are connected with two different Gigabit Ethernet links. WithoutVLANs, this configuration would create a broadcast loop. To prevent




.

VLANs and Default Gateways 75

broadcast loops, port 25 is on VLAN 10, port 26 is on VLAN 109. Bothswitch-to-switch links are on different VLANs and, thus, are separated intotheir own broadcast domains.

Example 2: Parallel Links with VLANs

In this example the Gig ports are on different VLANs and Spanning TreeProtocol is disabled. For information on Spanning Tree Protocol, see"Spanning Tree Protocol" (page 93)."

VLANs and Default GatewaysNortel Application Switch Operating System allows you to assign differentgateways for each VLAN. You can effectively map multiple customers tospecific gateways on a single switch. The benefits of segregating customersto different default gateways are:

• Resource optimization

• Enhanced customer segmentation

• Improved service differentiation

Segregating VLAN TrafficDeploy this feature in an environment where you want to segregate VLANtraffic to a configured default gateway. In "Default Gateways per VLAN"(page 76), VLANs 2 and 3 have different routing requirements. VLAN 2 isrequired to route traffic through default gateway 5 and VLAN 3 is required toroute traffic through default gateway 6.




.

76 VLANs

Default Gateways per VLAN

You can configure up to 255 gateways with one gateway per VLAN withvalues starting from 5 through 259. If the gateways per VLAN fail, thentraffic is directed to default gateways 1 through 4. Default gateways 1through 4 are used for load balancing session requests and as backup whena specific gateway that has been assigned to a VLAN is down.

In the example shown in "Default Gateways per VLAN" (page 76), ifgateways 5 or 6 fail, then traffic is directed to default gateway 1, which isconfigured with IP address 10.10.4.1. If default gateways 1 through 4 arenot configured on the switch, then packets from VLAN 2 and VLAN 3 arediscarded.

The route cache table on the switch records each session request bymapping the destination IP address with the MAC address of the defaultgateway. The command /info/l3/arp/dump on the switch commandline displays the entries in the route cache similar to those shown in "RouteCache Example" (page 76). The destination IP addresses (see the last tworows) are associated with the MAC addresses of the gateways.

Route Cache Example

Destination IPaddress

Flags MAC address VLAN Port ReferencedSPs

10.10.1.1 P 00:60:cf:46:48:60 4 1-4

10.10.1.20 00:60:cf:44:cd:a0 4 25(Gig)

empty




.


Destination IPaddress

Flags MAC address VLAN Port ReferencedSPs

10.10.1.30 00:60:cf:42:3b:40 4 26(Gig)

empty

10.10.4.1 00:60:cf:42:77:e0 1 27(Gig)

empty

10.10.4.40 P 00:60:cf:46:48:60 1 1-4

172.21.2.27 00:50:da:17:c8:05 2 7 1

172.21.2.200 P 00:60:cf:46:48:60 2 1-4

172.21.3.14 00:c0:4f:09:3e:56 3 8 2

172.21.2.200 P 00:60:cf:46:48:60 3 1-4

192.168.20.200 R 00:60:cf:44:cd:a0 4 1 7

200.1.2.200 R 00:60:cf:42:3b:40 4 2 8

As shown in "Route Cache Example" (page 76), traffic from VLAN 2 usesGateway 5 to access destination IP address 192.168.20.200. If traffic fromVLAN 3 requests the same destination address, then traffic is routed viaGateway 5 instead of Gateway 6, because 192.168.20.200 in the routecache is mapped to Gateway 5. If the requested route is not in the routecache, then the switch reads the routing table. If the requested route is notin the routing table, then the switch looks at the configured default Gateway.

Configuring the Local NetworkTo completely segregate VLAN traffic to its own default gateway, you canconfigure the local network addresses of the VLAN. This ensures that alltraffic from VLAN 2 is forwarded to Gateway 5 and all traffic from VLAN 3is forwarded to Gateway 6.

Typically, the switch routes traffic based on the routes in the routing table.The routing table contains an entry of the configured local network withthe default gateway. The route cache will not contain the route entry. Thisconfiguration provides a more secure environment, but affects performanceif the routing table is close to its maximum capacity.

Configuring Gateways per VLANFollow this procedure to configure the example shown in "Default Gatewaysper VLAN" (page 76):

Step Action

1 Assign an IP address for each router and client workstation.

2 Assign an IP interface for each subnet attached to the switch.




.

78 VLANs

>> /cfg/l3/if 1 (Select IP interface 1 forgateway 5 & 6 subnet)

>> IP Interface 1# addr10.10.1.1

(Assign IP address forinterface 1)

>> IP Interface 1# mask255.255.255.0

(Assign mask for IF 1)

>> IP Interface 1# vlan 4 (Assign VLAN 4 to IF 1)

>> IP Interface 1# /cfg/l3/if2

(Select IP interface 2 forgateway 1)







(Select IP interface 3 forVLAN 2 subnet)







(Select IP interface 4 forVLAN 3) subnet)






3 Configure the default gateways .

Configuring gateways 5 and 6 for VLANs 2 and 3 respectively.Configure default gateway 1 for load balancing session requests andas backup when gateways 5 and 6 fail.

>> /cfg/l3/gw 5 (Select gateway 5)

>> Default gateway 5# addr10.10.1.20

( Assign IP address forgateway 5)

>> Default gateway 5#/cfg/l3/gw 6

(Select default gateway 6)


(Assign IP address forgateway 6)




.





(Assign IP address forgateway 1)

Note: The IP address for default gateways 1 to 4 must beunique. IP addresses for default gateways 5 to 259 can be setto the same IP address as the other gateways (including defaultgateway 1 to 4). For example, you can configure two defaultgateways with the same IP address for two different VLANs.

4 Add the VLANs to the gateways and enable them.

>> /cfg/l3/gw 5 (Select gateway 5)

>> Default gateway 5# vlan 2 (Add VLAN 2 for defaultgateway 5)

>> Default gateway 5# ena (Enable gateway 5)


(Select gateway 6)

>> Default gateway 6# vlan 3 (Add VLAN 3 for defaultgateway 6)

>> Default gateway 6# ena (Enable gateway 6)



>> Default gateway 1# ena (Enable gateway 1 for allVLAN s)

5 Apply and verify your configuration.

>> Default gateway 1#/cfg/l3/cur

(View current L3 settings)

6 (Optional) Configure the local networks using address andmask pairs to ensure that the VLANs use the configured defaultgateways.

>> Default gateway 1#/cfg/l3/frwd/local

(Select the local networkMenu)

>> IP Forwarding# add10.10.0.0 255.255.0.0

(Specify the network forrouters 1, 2, & 3)




.

80 VLANs


(Specify the network forVLAN 2)


(Specify the network forVLAN 3)

7 Apply and save your new configuration changes.

>> IP Forwarding# apply>> IP Forwarding# save

—End—

VLANs and Jumbo FramesTo reduce host frame processing overhead, Gigabit network adapters thatcan handle frame sizes of 9014 bytes (such as the 3COM PCI-X/PCIGigabit adapters) and Nortel Application Switches running operating NortelApplication Switch Operating System version 21.0 or later, can receive andtransmit frames that are far larger than the maximum normal Ethernetframe. By sending one jumbo frame instead of myriad smaller frames, thesame task is accomplished with less processing.

The switches and the adapter should support jumbo frame sizes up to 9018octets. jumbo frames can be transmitted and received between Gigabitadapter-enabled hosts through the switch across any VLAN that has jumboframes enabled.

Limitations

• Jumbo frames are supported on the switch uplink ports and notsupported on switch downlink ports. For information on uplink vs.downlink ports on your particular switch model, refer Nortel ApplicationSwitch Hardware Installation Guide.

• Jumbo frames are not supported if Bandwidth Management is enabledon the switch.

• Jumbo Frames are supported only for ROHS/E model ApplicationSwitches in NAS 23.2.X and 24.X.

Isolating Jumbo Frame Traffic using VLANsJumbo frame traffic must not be used on a VLAN where there is any devicethat cannot process frame sizes larger than Ethernet maximum frame size.On Nortel Application Switch 2000 and 3000 series switches, additionalVLANs can be configured on the adapters and switches to supportnon-jumbo frame VLANs for servers and workstations that do not support




.

VLANs and Jumbo Frames 81

extended frame sizes. End-stations installed with jumbo frames-capableGigabit adapters, and attached to application switches can communicateacross both the jumbo frame VLANs and regular frame VLANs at the sametime.

In the example illustrated in "Jumbo Frame VLANs" (page 81), the twoservers can handle jumbo frames but the two clients cannot; thereforejumbo frames should only be enabled and used on the VLAN representedby the solid lines but not for the VLAN with the dashed lines. Jumbo framesare not supported on ports that are configured for half-duplex mode.

Jumbo Frame VLANs

Configuring VLANs for Jumbo and Non-Jumbo FramesTo configure a Nortel Application Switch 2424 for jumbo and non-jumboframe traffic, configure two VLANs:

Step Action

1 Add the switch uplink ports 25 and 26 to VLAN 2.

>> Main# /cfg/l2/vlan 2

VLAN number 2 with name "VLAN 2" created.------------------------------------------------------[VLAN 2 Menu]

name - Set VLAN namestg - Assign VLAN to a Spanning Tree Groupcont - Set BW contractadd - Add port to VLANrem - Remove port from VLAN




.

82 VLANs

def - Define VLAN as list of portsjumbo - Enable/disable Jumbo Frame supportlearn - Enable/disable smac learningena - Enable VLANdis - Disable VLANdel - Delete VLANcur - Display current VLAN configuration

>> VLAN 2# add 25Port 25 is an UNTAGGED port and itscurrent PVID is 1.Confirm changing PVID from 1 to 2 [y/n]: yCurrent ports for VLAN 2: emptyPending new ports for VLAN 2: 25

>> VLAN 2# add 26Port 26 is an UNTAGGED port and itscurrent PVID is 1.Confirm changing PVID from 1 to 2 [y/n]: yCurrent ports for VLAN 2: emptyPending new ports for VLAN 2: 25 26

>> VLAN 2#

2 Enable jumbo frame processing on VLAN 2, then apply andsave the changes.

>> VLAN 2# jumbo enableCurrent jumbo frame support: disabledNew jumbo frame support: enabled>> apply>> save

—End—




.

Port Trunking 83

Port Trunking

Trunk groups can provide super-bandwidth, multi-link connections betweenNortel Application Switches or other trunk-capable devices. A trunk groupis a group of ports that act together, combining their bandwidth to create asingle, larger virtual link. This chapter provides configuration backgroundand examples for trunking multiple ports together either in a static (manuallyconfigured) trunk group, or dynamic trunk group using Link AggregationControl Protocol.


• " "Overview" (page 83) " on this page

• "Static Port Trunking Example" (page 85)

• "Link Aggregation Control Protocol Trunking" (page 87)

OverviewWhen using port trunk groups between two Nortel Application Switchesas shown in "Port Trunk Group" (page 83), you can create a virtual linkbetween the switches operating up to 4 Gigabits per second, depending onhow many physical ports are combined. The switch supports up to 12 statictrunk groups per switch, each with two to eight ports per group.

Port Trunk Group

Trunk groups are also useful for connecting a Nortel Application Switch tothird-party devices that support link aggregation, such as Cisco routers andswitches with EtherChannel technology (not ISL trunking technology) andSun’s Quad Fast Ethernet Adapter. Nortel Networks trunk group technologyis compatible with these devices when they are configured manually.




.

84 VLANs

Statistical Load DistributionNetwork traffic is statistically load balanced between the ports in a trunkgroup. The Nortel Application Switch Operating System-powered switchuses both the Layer 2 MAC address and Layer 3 IP address informationpresent in each transmitted frame for determining load distribution.

The addition of Layer 3 IP address examination is an important advancefor traffic distribution in trunk groups. In some port trunking systems, onlyLayer 2 MAC addresses are considered in the distribution algorithm. Eachpacket’s particular combination of source and destination MAC addressesresults in selecting one line in the trunk group for data transmission. If thereare enough Layer 2 devices feeding the trunk lines, then traffic distributionbecomes relatively even. In some topologies, however, only a limitednumber of Layer 2 devices (such as a handful of routers and servers) feedthe trunk lines. When this occurs, the limited number of MAC addresscombinations encountered results in a lopsided traffic distribution, which canreduce the effective combined bandwidth of the trunked ports.

By adding Layer 3 IP address information to the distribution algorithm, a farwider variety of address combinations is seen. Even with just a few routersfeeding the trunk, the normal source/destination IP address combinations(even within a single LAN) can be widely varied. This results in a widerstatistical load distribution and maximizes the use of the combinedbandwidth available to trunked ports.

The Trunk Hash AlgorithmIn order to distribute the load across all active ports in a trunk group, thefollowing algorithm is used to determine which port within the trunk groupto use for frame forwarding:

hash_idx = (A xor B)

port = (lower 6 bits of hash_idx) mod x

where x is the number of active ports within the trunk group. The parametersA and B are given below for different types of forwarding and frames. Thesetwo parameters are XOR’ed together to give the hash index. The modulusx of the lower 6 bits of the hash index is then taken to give the port of thetrunk group.

Note: The same algorithm is used across all Nortel ApplicationSwitches including Nortel Application Switch 180 and AD series, NortelSwitched Firewall Accelerator, and Nortel Application Switches.

• For Layer 2 forwarding of non-IP frames:

A = lower 16 bits of destination MAC address

B = lower 32 bits of source MAC address




.

Port Trunking 85

• For L2 forwarding of IP frames:

A = lower 16 bits of source IP address

B = lower 32 bits of source MAC address

• For L3 forwarding (enabled in WSM platform and Cheetah 20.1):

A = lower 32 bits of destination IP

B = lower 16 bits of source MAC

• For L4 trunking (traffic towards the real servers in SLB and WCR):

A = lower 32 bits of source IP

B = lower 16 bits of destination MAC

Note: L4 trunk hashing is currently supported only in Nortel ApplicationSwitch Operating System 21.0 and higher.

Built-In Fault ToleranceSince each trunk group is comprised of multiple physical links, the trunkgroup is inherently fault tolerant. As long as one connection between theswitches is available, the trunk remains active.

Statistical load balancing is maintained whenever a port in a trunk group islost or returned to service.

Static Port Trunking ExampleIn the example below, three ports will be trunked between two NortelApplication Switches.

Port Trunk Group Configuration Example

Prior to configuring each switch in the above example, you must connect tothe appropriate switch’s Command Line Interface (CLI) as the administrator.




.

86 VLANs

Note: For details about accessing and using any of the menucommands described in this example, see the Nortel Application SwitchOperating System Command Reference.

In this example, two Nortel Application Switches are used. If a third-partydevice supporting link aggregation is used (such as Cisco routers andswitches with EtherChannel technology or Sun’s Quad Fast EthernetAdapter), trunk groups on the third-party device should be configuredmanually. Connection problems could arise when using automatic trunkgroup negotiation on the third-party device.

CAUTIONTo prevent spanning tree instability, do not change the spanningtree parameters on individual ports belonging to any trunk group.

Step Action

1 Connect the switch ports that is involved in the trunk group.

2 On application switch 1, define a trunk group.

>> # /cfg/l2/trunk 1 (Select trunk group 1)

>> Trunk group 1# add 2 (Add port 2 to trunk group 1)



>> Trunk group 1# ena (Enable trunk group 1)

3 Apply and verify the configuration.

>> Trunk group 1# apply (Make your changes active)

>> Trunk group 1# cur (View current trunkingconfiguration)

Examine the resulting information. If any settings are incorrect,make appropriate changes.

4 Save your new configuration changes.

>> Trunk group 1# save (Save for restore after reboot)

5 Repeat the process on application switch 2.




.

Port Trunking 87

>> # /cfg/l2/trunk 3 (Select trunk group 3)




>> Trunk group 3# ena (Enable trunk group 3)

>> Trunk group 3# apply (Make your changes active)

>> Trunk group 3# cur (View current trunkingconfiguration)

>> Trunk group 3# save (Save for restore after reboot)

Trunk group 1 (on application switch 1) is now connected to trunkgroup 3 (on application switch 2).

6 Examine the trunking information on each switch.

>> /info/l2/trunk (View trunking information)

Information about each port in each configured trunk group isdisplayed. Make sure that trunk groups consist of the expected portsand that each port is in the expected state.

The following restrictions apply:

• Any physical switch port can belong to only one trunk group.

• Up to eight ports can belong to the same trunk group.

• Best performance is achieved when all ports in any given trunkgroup are configured for the same speed.

• Trunking from non-Nortel devices must comply with Cisco®

EtherChannel® technology.

—End—

Link Aggregation Control Protocol TrunkingLink Aggregation Control Protocol (LACP) is an IEEE 802.3ad standard forgrouping several physical ports into one logical port (known as trunk groupor Link Aggregation group) with any device that supports the standard. If alink in a LACP trunk group fails, traffic is reassigned dynamically to any ofthe remaining links of the LACP trunk group. Link aggregation is a methodof grouping physical link segments of the same media type and speed infull duplex, and treating them as if they were part of a single, logical linksegment. Refer to IEEE 802.3ad-2002 for full description of the standard.




.

88 VLANs

When using LACP, any trunk groups you may have already configuredaccording to the manual procedure described in "Static Port TrunkingExample" (page 85) "Static Port Trunking Example" (page 85) are "statictrunks." Any trunk groups using LACP are "dynamic trunks." With LACP, themaximum number of trunk groups has increased to 40; static trunks continueto be limited to trunk IDs 1–12, and LACP trunks use IDs 13 through 40.

The Nortel Application Switch Operating System implementation of LACPallows you to group a maximum of eight physical ports into one logicalport (LACP trunk group). Standby ports in LACP are created only whenthere are more than eight LACP ports configured in a trunk. The switchautomatically assigns any non-trunked LACP-configured ports as standbyports for the LACP trunk. If any of the eight primary LACP ports fails, theswitch dynamically replaces it with the standby port.

The Nortel Application Switch can form trunk groups with any device whichsupports the IEEE 802.3ad standard.

Each LACP port in the switch has a parameter called ’admin key’. An LACPtrunk group is formed with the ports with the same admin key. The value ofadmin key can be any integer between 1 and 65535.

For example, consider two switches as shown in "Actor vs. Partner LACPconfiguration" (page 88).

Actor vs. Partner LACP configuration

Actor Switch Partner Switch 1

Port 1 (admin key = 100) Port 1 (admin key = 50)




In the configuration shown in "Actor vs. Partner LACP configuration" (page88), Actor switch ports 1-4 can aggregate to form an LACP trunk groupwith the Partner switch ports 1-4. Note that the port admin key value haslocal significance only —the admin key value for the partner switch portscan be any integer value but it should be same for all ports 1-4. In thisexample it is 50.

Each port in the Nortel Application Switch can have one of the followingLACP modes.

• off (default)

The user can configure this port into a regular static trunk group.

• active




.

Port Trunking 89

The port is capable of forming an LACP trunk. This port sends LACPDUpackets to partner system ports.

• passive

The port is capable of forming an LACP trunk. This port only respondsto the LACPDU packets sent from an LACP active port.

Each active LACP port transmits LACP data units (LACPDUs), while eachpassive LACP port listens for LACPDUs. During LACP negotiation, theadmin key value is exchanged. The LACP trunk group is enabled as longas the information matches at both ends of the link. If the admin key valuechanges for a port at either end of the link, that port’s association with theLACP trunk group is lost.

When the system is initialized, all ports by default are in LACP off modeand are assigned unique admin keys. To make a group of ports eligible foraggregation, you assign them all the same admin key. You must set theport’s LACP mode to active to activate LACP negotiation. You can set otherport’s LACP mode to passive, to reduce the amount of LACPDU traffic, atthe initial trunk-forming stage.

Note: LACP implementation in Nortel Application Switch OperatingSystem 22.0 does not support the Churn machine, an option used fordetecting the port is operable within a bounded time period between theactor and the partner. Only the Marker responder is implemented, andthere is no marker protocol generator. Refer to 802.3ad-2002 for details.

Configuring LACPUse the following procedure to configure LACP for port 1 through port 4 forthe actor switch to participate in link aggregation.

Perform a similar configuration on the partner switch with adminkey 50.

Step Action

1 Set the LACP mode on port 1.

>> # /cfg/l2/lacp/port 1/mode (Select port 1 for LACPmode of operation)

>> LACP port 1# active (Set port 1 to LACP active)

Current Port 1 LACP mode setting: offNew Port 1 LACP mode setting: active

2 Define the admin key on port 1. Only ports with the same adminkey can form a LACP trunk group.




.

90 VLANs

>> # /cfg/l2/lacp/port1/adminkey 100

(Set port 1 adminkey to100)

Current LACP port adminkey: 1New pending LACP port adminkey: 100

3 Set the LACP mode on ports 2 to 4.

>> # /cfg/l2/lacp/port 2/modeactive

(Select port 2 mode ofoperation)





4 Define the admin key on ports 2 to 4.


(Select port 2 adminkey to100)






>> LACP port 4# apply (Make your changes active)

>> LACP port 4# cur (View current trunkingconfiguration)


>> LACP port 4# save (Save for restore afterreboot)

—End—




.

Port Teaming 91

Port Teaming

Port teaming is a feature deployed in scenarios where VRRP is not usedto detect link failures. If an uplink connection fails, then the switch notifiesuplink routers and switches of the failure instead of waiting for the routersand switches to time out.

This feature is also used to team ports or trunks so that when one port ortrunk in the team is down, all others in the team are operationally disabled.

The following examples create two simple port teams. The first examplecreates a simple, two port team and the second creates a simple two trunkteam.

The following example creates a simple two port team:

Step Action

1 Create a new port team.

>> Main# /cfg/l2/team 1

2 Add ports to the new team.

>> Port Team 1# addport 1>> Port Team 1# addport 2

3 Enable port team.

>> Port Team 1# ena

—End—

The following example creates a simple two trunk team:

Step Action

1 Create a new port team.

>> Main# /cfg/l2/team 2

2 Add trunks to the new team.




.

92 VLANs

>> Port Team 2# addtrunk 1>> Port Team 2# addtrunk 2

3 Enable port team.

>> Port Team 2# ena

In both examples above, the teams are placed in passive mode witheither the ports or trunks operational. The team is in passive modeis when all ports or trunks are operational and the team is waiting forany one of the ports or trunks to become disabled. When one of theports or trunks is disabled, the team goes to active mode and theother ports or trunks in the team are operationally disabled. The portor trunk that triggered this becomes the master port.

When the master port or trunk becomes operational once more, theother ports or trunks in the team are operationally enabled. When allthe ports or trunks are operational, the team goes back to passivemode.

There are scenarios when, after operationally enabled, some of theother ports or trunks in the team are not operational due to a linkbeing down or operational or configuration disabling. When thishappens the team goes into off mode. In this mode, the team waitsuntil all ports or trunks are operational before going back to passivemode to repeat the cycle.

The Nortel Application Switch Operating System supports amaximum of 8 port teams.

—End—




.

Spanning Tree Protocol 93

Spanning Tree Protocol

When multiple paths exist on a network, Spanning Tree Protocol (STP)configures the network so that a switch uses only the most efficient path.


• "Overview" (page 93)

• "Bridge Protocol Data Units (BPDUs)" (page 94)

• "Spanning Tree Group Configuration Guidelines" (page 96)

• "Multiple Spanning Trees" (page 97)

• "Rapid Spanning Tree Protocol" (page 102)

• "Multiple Spanning Tree Protocol" (page 104)

OverviewSpanning Tree Protocol (STP) detects and eliminates logical loops ina bridged or switched network. STP forces redundant data paths intoa standby (blocked) state. When multiple paths exist, Spanning Treeconfigures the network so that a switch uses only the most efficient path. Ifthat path fails, Spanning Tree automatically sets up another active path onthe network to sustain network operations.

The relationship between port, trunk groups, VLANs, and Spanning Trees isshown in "Ports, Trunk Groups, and VLANs" (page 93).

Ports, Trunk Groups, and VLANs

Switch Element Belongs to

Port Trunk grouporOne or more VLANs

Trunk group One or more VLANs

VLAN One Spanning Tree group

Note: Due to Spanning Tree’s sequence of listening, learning, andforwarding or blocking, lengthy delays may occur. For more informationon using STP in cross-redundant topologies, see "Eliminating Loopswith STP and VLANs" (page 577).




.

94 VLANs

Bridge Protocol Data Units (BPDUs)To create a Spanning Tree, the application switch generates a configurationBridge Protocol Data Unit (BPDU), which it then forwards out of its ports. Allswitches in the Layer 2 network participating in the Spanning Tree gatherinformation about other switches in the network through an exchange ofBPDUs.

A BPDU is a 64-byte packet that is sent out at a configurable interval, whichis typically set for two seconds. The BPDU is used to establish a path,much like a "hello" packet in IP routing. BPDUs contain information aboutthe transmitting bridge and its ports, including bridge and MAC addresses,bridge priority, port priority, and path cost. If the ports are tagged, each portsends out a special BPDU containing the tagged information.

The generic action of a switch on receiving a BPDU is to compare thereceived BPDU to its own BPDU that it transmits. If the received BPDU isbetter than its own BPDU, it will replace its BPDU with the received BPDU.Then, the application switch adds its own bridge ID number and incrementsthe path cost of the BPDU. The application switch uses this information toblock any necessary ports.

Determining the Path for Forwarding BPDUsWhen determining which port to use for forwarding and which port to block,application switches use information in the BPDU, including each bridgepriority ID. A technique based on the "lowest root cost" is then computed todetermine the most efficient path for forwarding.

For more information on bridge priority, port priority, and port cost,refer to the Nortel Application Switch Operating System CommandReference. Much like least-cost routing, root cost assigns lower values tohigh-bandwidth ports, such as Gigabit Ethernet, to encourage their use. Forexample, a 10-Mbps link has a "cost" of 100, a 100-Mbps (Fast Ethernet)link carries a cost of 10, and a 1000-Mbps (or Gigabit Ethernet) link has acost of 1. The objective is to use the fastest links so that the route withthe lowest cost is chosen.

Bridge PriorityThe bridge priority parameter controls which bridge on the network is theSTP root bridge. To make one switch the root bridge, configure the bridgepriority lower than all other switches and bridges on your network. The lowerthe value, the higher the bridge priority. The bridge priority is configuredusing the /cfg/l2/stg/brg/prior command in the CLI.




.


Port PriorityThe port priority helps determine which bridge port becomes the designatedport. In a network topology that has multiple bridge ports connectedto a single segment, the port with the lowest port priority becomes thedesignated port for the segment. The port priority is configured using the/cfg/l2/stg/port/prior command in the CLI.

Port Path CostThe port path cost assigns lower values to high-bandwidth ports, such asGigabit Ethernet, to encourage their use. The cost of a port also dependson whether the port operates at full-duplex (lower cost) or half-duplex(higher cost). For example, if a 100-Mbps (Fast Ethernet) link has a "cost"of 10 in half-duplex mode, it will have a cost of 5 in full-duplex mode. Theobjective is to use the fastest links so that the route with the lowest cost ischosen. A value of 0 indicates that the default cost will be computed for anauto-negotiated link speed.

Spanning Tree Compatibility between BPDU FormatsWhen a tagged port belongs to more than one spanning tree group, thespanning tree bridge protocol data units (BPDUs) are tagged to distinguishthe BPDUs of one spanning tree group from those of another. BPDUs fromthe default spanning tree group STG 1 are not tagged.

However, because tagged BPDUs are not part of the IEEE 802.1D standard,not all devices can interpret tagged BPDUs in the same way.

Nortel Networks routers such as the Passport 8600 or switches suchas the Baystack 470 handle the transmission of spanning tree BPDUsdifferently than equipment vendors such as Cisco Systems. In the Ciscoimplementation, only ONE of the ports in the trunk transmits a BPDU. In theNortel implementation, all of the ports in the trunk each transmit an identicalcopy of the BPDU, and the tagged BPDUs are transmitted using a multicastMAC address as tagged frames with a VLAN ID.

An Nortel Application Switch by default uses the Cisco-type BPDUtransmission format, and can also be enabled for compatibility with theNortel-type BPDU format.

The Nortel tagged BPDU format should be enabled on an Nortel ApplicationSwitch when it is connected it to a Nortel product that uses tagging. Use thefollowing commands to enable Nortel tagged BPDU format:

Main # /cfg/l2/ntmstg ena (Enable Nortel tagged BPDUformat)

Main # /boot/reset (Reset the switch to enable)




.

96 VLANs

Spanning Tree Group Configuration GuidelinesThis section provides important information on configuring Spanning TreeGroups (STGs):

Adding a VLAN to a Spanning Tree Group

• If no VLANs exist beyond the default VLAN 1, see "Creating a VLAN"(page 96) for information on adding ports to VLANs.

• Add the VLAN to the STG using the /cfg/l2/stg <stg-#> /add<vlan-number> command.

Creating a VLAN

• When you create a VLAN, that VLAN automatically belongs to STG 1,the default STG. If you want the VLAN in another STG, you must movethe VLAN by assigning it to another STG.

Move a newly created VLAN to an existing STG by following this order:

— Create the VLAN

— Add the VLAN to an existing STG

• If ports are tagged, all trunked ports can belong to multiple STGs.

• A port that is not a member of any VLAN cannot be added to any STG.The port must be added to a VLAN, and that VLAN added to the desiredSTG.

Rules for VLAN Tagged ports

• Tagged ports can belong to more than one STG, but untagged ports canbelong to only one STG.

• When a tagged port belongs to more than one STG, the egress BPDUsare tagged to distinguish the BPDUs of one STG from those of anotherSTG.

• An untagged port cannot span multiple STGs.

Adding and removing ports from STGs

• When you add a port to a VLAN that belongs to an STG, the port is alsoadded to the STG. However, if the port you are adding is an untaggedport and is already a member of an STG, that port is not added to anadditional STG because an untagged port cannot belong to more thatone STG.

For example, assume that VLAN1 belongs to STG1. You add anuntagged port, port 1, that does not belong to any STG to VLAN1, andport 1 becomes part of STG1.




.


If you add untagged port 5 (which is a member to STG2) to STG1, theswitch prompts you to change the PVID from 2 to 1:

"Port 5 is an UNTAGGED port and its current PVID is 2.Confirm changing PVID from 2 to 1 [y/n]:" y

• When you remove a port from VLAN that belongs to an STG, that portwill also be removed from the STG. However, if that port belongs toanother VLAN in the same STG, the port remains in the STG.

As an example, assume that port 1 belongs to VLAN1, and VLAN1belongs to STG1. When you remove port 1 from VLAN1, port 1 is alsoremoved from STG1.

However, if port 1 belongs to both VLAN1 and VLAN2 and both VLANsbelong to STG1, removing port 1 from VLAN1 does not remove port 1from STG1 because VLAN2 is still a member of STG1.

• An STG cannot be deleted, only disabled. If you disable the STG whileit still contains VLAN members, Spanning Tree will be off on all portsbelonging to that VLAN.

Spanning Tree Implementations in Trunk Groups

• In both Cisco and Nortel spanning tree implementation as describedin "Spanning Tree Compatibility between BPDU Formats" (page 95),the trunking methodology applies for both the default and non-defaultspanning tree groups. Make sure that all members of the trunk groupare configured to the correct spanning tree group parameters, anddetermine whether or not to enable use of the Nortel multiple spanningtree group mode.

CAUTIONAll ports that are within a trunk group should be configured to havethe same Spanning Tree and VLAN parameters. Spanning Treeparameters should not be changed on individual ports that belongto a trunk group. To change spanning tree on one or more portsbelonging to a trunk group, first remove individual members fromthe trunk group before changing their spanning tree parameters.

Multiple Spanning TreesThe Nortel Application Switch Operating System supports Multiple SpanningTree Protocol (MSTP) and Rapid Spanning Tree Protocol (RSTP) as definedin the IEEE 802.1S (MSTP) and 802.1W (RSTP) standards. This is animprovement over previous spanning tree implementations in that it is astandards-based approach to implementing this functionality.




.

98 VLANs

Before the 802.1S standard, MSTP was implemented through a varietyof proprietary protocols such as Nortel MSTP and Cisco PVST+. Eachone of these proprietary protocols had advantages and disadvantages butthey were never interoperable. The 801.S standard solves this by creatingstandards-based MSTP. The 802.1W standard takes the same approachin creating standards-based RSTP.

In this implementation of MSTP, up to 2048 VLANs can be mapped to anyof the 16 spanning tree instances. Each spanning tree instance handlesmultiple VLANs that have the same Layer 2 topology but each spanningtree instance can have a topology independent of other instances. As well,MSTP provides multiple forwarding paths for data traffic, enables loadbalancing, and improves overall network fault tolerance.

This implementation of RSTP improves upon previous implementations byaddressing slow convergence times.

Note: By default, all newly created VLANs are members of SpanningTree Group 1.

For specific information on Multiple and Rapid Spanning Tree Protocol,refer to the following topics:

• "Rapid Spanning Tree Protocol" (page 102)

• "Multiple Spanning Tree Protocol" (page 104)

Why Do We Need Multiple Spanning Trees?"Multiple Instances of Spanning Tree Protocol" (page 98) shows a simpleexample of why we need multiple Spanning Trees. Two VLANs, VLAN 1 andVLAN 100 exist between Nortel Application Switch A and Nortel ApplicationSwitch B. If you have a single Spanning Tree group, the switches see anapparent loop, and one VLAN may become blocked, affecting connectivity,even though no actual loop exists.

If VLAN 1 and VLAN 100 belong to different Spanning Tree Groups, thenthe two instances of Spanning Tree separate the topology without forming aloop. Both VLANs can forward packets between the application switcheswithout losing connectivity.

Multiple Instances of Spanning Tree Protocol




.


Four-Switch Topology with a Single Spanning TreeIn the four-switch topology example shown in "VLAN 3 Isolated in a SingleSpanning Tree Group" (page 99), and assuming Nortel Application Switch Ahas a higher priority, you can have at least three loops on the network:

• Data flowing from application switches A to B to C and back toapplication switch A.

• Data flowing from application switches A to C to D and back toapplication switch A

• Data flowing from application switches A to B to C to D and back toapplication switch A.

With a single Spanning Tree environment, as shown in "VLAN 3 Isolated ina Single Spanning Tree Group" (page 99), you will have two links blocked toprevent loops on the network. It is possible that the blocks may be betweenapplication switches C and D and between application switches B andC, depending on the bridge priority, port priority, and port cost. The twoblocks would prevent looping on the network, but the blocked link betweenapplication switches B and C will inadvertently isolate VLAN 3 altogether.

Note: For more information on bridge priority, port priority, and portcost see the Nortel Application Switch Operating System CommandReference.

VLAN 3 Isolated in a Single Spanning Tree Group




.

100 VLANs

Four-Switch Topology with Multiple Spanning TreesIf multiple Spanning Trees are implemented and each VLAN is on a differentSpanning Tree, elimination of logical loops will not isolate any VLAN.

"Implementing Multiple Spanning Tree Groups" (page 100) shows the samefour-switch topology as in "VLAN 3 Isolated in a Single Spanning TreeGroup" (page 99), but with multiple Spanning Trees enabled. The VLANsare identified on each of the three shaded areas connecting the switches.The port numbers are shown next to each switch. The Spanning Tree Group(STG) number for each VLAN is shown at the switch.

Implementing Multiple Spanning Tree Groups

Three instances of Spanning Tree are configured in the example shownin "Implementing Multiple Spanning Tree Groups" (page 100). Refer to"Multiple Spanning Tree Groups per VLAN" (page 100) to identify theSpanning Tree group a VLAN is participating in for each switch.

Multiple Spanning Tree Groups per VLAN

VLAN 1 VLAN 2 VLAN 3

Nortel ApplicationSwitch A

Spanning TreeGroup1Ports 1 and 2

Spanning TreeGroup2Port 8

Nortel ApplicationSwitch B






.


VLAN 1 VLAN 2 VLAN 3

Nortel ApplicationSwitch C


Spanning TreeGroup2 Port 8

Nortel ApplicationSwitch D


Switch-Centric Spanning Tree ProtocolIn "Implementing Multiple Spanning Tree Groups" (page 100), VLAN 2 isshared by application switch A and B on ports 8 and 1 respectively. NortelApplication Switch A identifies VLAN 2 in Spanning Tree group 2 andapplication switch B identifies VLAN 2 in Spanning Tree group 1. SpanningTree group is switch-centric—it is used to identify the VLANs participating inthe Spanning Tree groups. The Spanning Tree group ID is not transmitted inthe BPDU. Each Spanning Tree decision is based on the configuration ofthat switch.

VLAN Participation in Spanning Tree GroupsThe VLAN participation for each Spanning Tree group in "ImplementingMultiple Spanning Tree Groups" (page 100) is discussed in the followingsections:

• VLAN 1 Participation

If application switch A is the root bridge, then application switch Atransmits the BPDU for VLAN 1 on ports 1 and 2. Nortel ApplicationSwitch C receives the BPDU on its port 2 and application switch Dreceives the BPDU on its port 1. Nortel Application Switch D blocks port8 or application switch C blocks port 1 depending on the informationprovided in the BPDU.


Nortel Application Switch A, the root bridge generates another BPDUfor Spanning Tree Group 2 and forwards it out from port 8. NortelApplication Switch B receives this BPDU on its port 1. Port 1 onapplication switch B is on VLAN 2, Spanning Tree group 1. Becauseapplication switch B has no additional ports participating in SpanningTree group 1, this BPDU is not be forwarded to any additional ports andapplication switch A remains the designated root.


For VLAN 3 you can have application switch B or C to be the root bridge.If application switch B is the root bridge for VLAN 3, Spanning Treegroup 2, then application switch B transmits the BPDU out from port




.

102 VLANs

8. Nortel Application Switch C receives this BPDU on port 8 and isidentified as participating in VLAN 3, Spanning Tree group 2. Sinceapplication switch C has no additional ports participating in SpanningTree group 2, this BPDU is not forwarded to any additional ports andapplication switch B remains the designated root.

Rapid Spanning Tree ProtocolRapid Spanning Tree Protocol (RSTP) provides rapid convergence of thespanning tree and provides for the fast reconfiguration critical for networkscarrying delay-sensitive traffic such as voice and video. RSTP significantlyreduces the time to reconfigure the active topology of the network whenchanges occur to the physical topology or its configuration parameters.RSTP reduces the bridged-LAN topology to a single Spanning Tree.

RSTP parameters are configured in Spanning Tree Group 1. STP Groups2-32 do not apply to RSTP, and must be cleared. There are new STPparameters to support RSTP, and some values to existing parameters aredifferent.

RSTP is compatible with devices that run 802.1d Spanning Tree Protocol. Ifthe switch detects 802.1d BPDUs, it responds with 802.1d-compatible dataunits. RSTP is not compatible with the Per VLAN Spanning Tree (PVST+)protocol.

Port State ChangesThe port state controls the forwarding and learning processes of SpanningTree. In RSTP, the port state has been consolidated to the following:discarding, learning, and forwarding. "RSTP vs. STP Port states" (page102) compares the port states between 802.1d Spanning Tree and 802.1wRapid Spanning Trees.

RSTP vs. STP Port states

Operational status STP Port State RSTP Port State

Enabled Blocking Discarding

Enabled Listening Discarding

Enabled Learning Learning

Enabled Forwarding Forwarding

Disabled Disabled Discarding

Port Type and Link TypeSpanning Tree configuration includes the edge port and link type parametersto support RSTP and MSTP. Although these parameters are configuredfor Spanning Tree Groups 1-32, they only take effect when RSTP/MSTPis turned on.




.


Edge PortA port that does not connect to a bridge is called an edge port. Edge portsare generally connected to a server. Edge ports can start forwarding assoon as the link is up.

Edge ports do not take part in Spanning Tree, and should not receiveBPDUs. If a port with edge enabled does receive a BPDU, it begins STPprocessing only if it is connected to a spanning tree bridge. If it is connectedto a host, the edge port ignores BPDUs.

Link TypeThe link type determines how the port behaves in regard to Rapid SpanningTree. The link type corresponds to the duplex mode of the port. A full-duplexlink is point-to-point (p2p), while a half-duplex link should be configured asshared. If you select auto as the link type, the port dynamically configuresthe link type.

RSTP Configuration GuidelinesThese guidelines should be followed when configuring Rapid SpanningTree Groups:

• When RSTP is turned on, STP parameters apply only to STP Group 1.

• When RSTP is turned on, all VLANs (including the management VLAN4095) are moved to Spanning Tree Group 1.

RSTP Configuration ExampleThis section provides steps to configure Rapid Spanning Tree using the CLI.

Configure Rapid Spanning Tree

Step Action

1 Create VLAN and add ports.

Once ports have been readied for VLAN membership, VLAN 3 canbe created and the ports added to the VLAN.

>> Main# /cfg/l2/vlan 2<If the VLAN was not already created, it would becreated with this command.>

>> VLAN 2# add 2>> VLAN 2# add 3>> VLAN 2# add 4

2 Disable and clear STP groups 2 through 32.




.

104 VLANs

>> Main# /cfg/l2/stg 2 (Select Spanning TreeGroup 2)

>> Spanning Tree Group 2# clear (Clear STP Group 2parameters)

>> Spanning Tree Group 2# off (Turn off STP Group 2)

3 Set the Spanning Tree mode to Rapid Spanning Tree.

>> Main# /cfg/l2/mrst (Select Multiple SpanningTree menu)

>> Multiple Spanning Tree# moderstp

(Set mode to RapidSpanning Tree)

>> Multiple Spanning Tree# on (Turn Rapid Spanning Treeon)

4 Configure STP Group 1 parameters.

>> /cfg/l2/stg 1 (Select Spanning TreeProtocol menu)

>> Spanning Tree Group 1# add 2 (Add VLAN 2 to STP Group1)

>> Spanning Tree Group 1# apply (Apply the configurations)

>> Spanning Tree Group 1# save (Save the configuration)

—End—

Multiple Spanning Tree ProtocolIEEE 802.1s Multiple Spanning Tree extends the IEEE 802.1w RapidSpanning Tree Protocol through multiple Spanning Tree Groups. MSTPmaintains up to 16 spanning-tree instances, that correspond to STP Groups1-16.

In Multiple Spanning Tree Protocol (MSTP), several VLANs can bemapped to each Spanning-Tree instance. Each Spanning-Tree instance isindependent of other instances. MSTP allows frames assigned to differentVLANs to follow separate paths, each path based on an independentSpanning-Tree instance. This approach provides multiple forwardingpaths for data traffic, enabling load-balancing, and reducing the number ofSpanning-Tree instances required to support a large number of VLANs.




.


By default, the spanning tree on the management ports is turned off in bothSTP/PVST+ mode and in MSTP/RSTP mode.

MSTP RegionA group of interconnected bridges that share the same attributes is calledan Multiple Spanning Tree (MST) region. Each bridge within the regionmust share the following attributes:

• Alphanumeric name

• Version number

• VLAN-to STG mapping scheme

MSTP provides rapid reconfiguration, scalability and control due to thesupport of regions, and multiple Spanning-Tree instances support withineach region.

Common Internal Spanning TreeThe Common Internal Spanning Tree (CIST) provides a common form ofSpanning Tree Protocol, with one Spanning-Tree instance that can be usedthroughout the MSTP region. CIST allows the switch to interoperate withlegacy equipment, including devices that run IEEE 802.1d (STP).

CIST allows the MSTP region to act as a virtual bridge to other bridgesoutside of the region, and provides a single Spanning-Tree instance tointeract with them.

CIST port configuration includes Hello time, Edge port enable/disable, andLink Type. These parameters do not affect Spanning Tree Groups 1-32.They apply only when the CIST is used.

MSTP Configuration GuidelinesAdhere to these guidelines when configuring MSTP:

• When MSTP is turned on, the switch automatically moves managementVLAN 4095 to the CIST. When MSTP is turned off, the switch movesVLAN 4095 from the CIST to Spanning Tree Group 32.

• For enabling MSTP, Region Name must be configured, and a defaultversion number of 1 is configured automatically. Each bridge in theregion must have the same name, version number, and VLAN mapping.

MSTP Configuration ExampleThis section provides steps to configure Multiple Spanning Tree Protocolusing the CLI.




.

106 VLANs

Configure Multiple Spanning Tree Protocol

Step Action

1 Ready ports for VLAN membership.

To create a VLAN, ports must first be readied for VLAN membership.To do this, the port PVID (Port VLAN ID) is changed from the defaultof 1 to 2, indicating that they are a part of VLAN 2.

>> Main# /cfg/port 2/pvid 2>> Main# /cfg/port 3/pvid 2>> Main# /cfg/port 4/pvid 2

2 Create VLAN and add ports.

Once ports have been readied for VLAN membership, VLAN 3 canbe created and the ports added to the VLAN.

>> Main# /cfg/l2/vlan 2<If the VLAN was not already created, it would becreated with this command.>

>> VLAN 2# add 2>> VLAN 2# add 3>> VLAN 2# add 4

3 Set the mode to Multiple Spanning Tree, and configure MSTPregion parameters.

>> Main# /cfg/l2/mrst (Select Multiple SpanningTree menu)

>> Multiple Spanning Tree# modemstp

(Set mode to MultipleSpanning Trees)

>> Multiple Spanning Tree# on (Turn Multiple SpanningTrees on)

>> Multiple Spanning Tree# namexxxxxx

(Define the Region name)

4 Assign VLANs to Spanning Tree Groups.

>> Main# /cfg/l2/stg 2 (Select Spanning TreeGroup 2)

>> Spanning Tree Group 2# add 2 (Add VLAN 2)

5 Turn off Layer 3 forwarding.




.


>> Main# /cfg/l3/frwd off (Turn Layer 3 forwardingoff)

>> IP Forwarding# apply (Apply the configuration)

>> IP Forwarding# save (Save the configuration)

—End—




.

108 VLANs




.

109

Part 2: IP Routing

This section discusses Layer 3 switching functions. In addition to switchingtraffic at near line rates, the application switch can perform multi-protocolrouting. This section discusses basic routing and advanced routingprotocols:

• "Basic IP Routing" (page 110) "

• "IPv6" (page 123) "

• "Routing Information Protocol" (page 126) "

• "Border Gateway Protocol" (page 131)

• "Open Shortest Path First (OSPF)" (page 146)




.

110 Part 2: IP Routing

Basic IP Routing

This chapter provides configuration background and examples for using theNortel Application Switch to perform IP routing functions.


• "IP Routing Benefits" (page 110)

• "Routing Between IP Subnets" (page 110)

• "Example of Subnet Routing" (page 112)

• "Defining IP Address Ranges for the Local Route Cache" (page 117)

• "Dynamic Host Configuration Protocol" (page 118)

• "Gratuitous ARP (GARP) Command" (page 120)

• "Static Routes" (page 120)

IP Routing BenefitsThe Nortel Application Switch uses a combination of configurable IP switchinterfaces and IP routing options. The switch IP routing capabilities providethe following benefits:

• Connects the server IP subnets to the rest of the backbone network.

• Performs server load balancing (using both Layer 3 and Layer 4switching in combination) to server subnets that are separate frombackbone subnets.

• Provides another means to invisibly introduce Jumbo frame technologyinto the server-switched network by automatically fragmenting UDPJumbo frames when routing to non-Jumbo frame VLANs or subnets.

• Provides the ability to route IP traffic between multiple Virtual Local AreaNetworks (VLANs) configured on the switch.

Routing Between IP SubnetsThe physical layout of most corporate networks has evolved over time.Classic hub/router topologies have given way to faster switched topologies,particularly now that switches are increasingly intelligent. Nortel ApplicationSwitches are intelligent and fast enough to perform routing functions on apar with wire speed Layer 2 switching.

The combination of faster routing and switching in a single device providesanother service—it allows you to build versatile topologies that account forlegacy configurations.

For example, consider the following topology migration:




.

Basic IP Routing 111

The Router Legacy Network

In this example, a corporate campus has migrated from a router-centrictopology to a faster, more powerful, switch-based topology. As is often thecase, the legacy of network growth and redesign has left the system with amix of illogically distributed subnets.

This is a situation that switching alone cannot cure. Instead, the router isflooded with cross-subnet communication. This compromises efficiencyin two ways:

• Routers can be slower than switches. The cross-subnet side trip fromthe switch to the router and back again adds two hops for the data,slowing throughput considerably.

• Traffic to the router increases, increasing congestion.

Even if every end-station could be moved to better logical subnets (adaunting task), competition for access to common server pools on differentsubnets still burdens the routers.

This problem is solved by using Nortel Application Switches with built-in IProuting capabilities. Cross-subnet LAN traffic can now be routed within theapplication switches with wire speed Layer 2 switching performance. Thisnot only eases the load on the router but saves the network administratorsfrom reconfiguring each and every end-station with new IP addresses.




.


Take a closer look at the Nortel Application Switch in the followingconfiguration example:

Switch-Based Routing Topology

The Nortel Application Switch connects the Gigabit Ethernet and FastEthernet trunks from various switched subnets throughout one building.Common servers are placed on another subnet attached to the switch. Aprimary and backup router are attached to the switch on yet another subnet.

Without Layer 3 IP routing on the switch, cross-subnet communication isrelayed to the default gateway (in this case, the router) for the next level ofrouting intelligence. The router fills in the necessary address informationand sends the data back to the switch, which then relays the packet to theproper destination subnet using Layer 2 switching.

With Layer 3 IP routing in place on the Nortel Application Switch, routingbetween different IP subnets can be accomplished entirely within the switch.This leaves the routers free to handle inbound and outbound traffic for thisgroup of subnets.

To make implementation even easier, UDP Jumbo frame traffic isautomatically fragmented to regular Ethernet frame sizes when routing tonon-Jumbo frame VLANS or subnets. This automatic frame conversionallows servers to communicate using Jumbo frames, all transparently tothe user.

Example of Subnet RoutingPrior to configuring, you must be connected to the switch Command LineInterface (CLI) as the administrator.




.


Note: For details about accessing and using any of the menucommands described in this example, see the Nortel Application SwitchOperating System Command Reference.

Step Action

1 Assign an IP address (or document the existing one) for eachreal server, router, and client workstation.

In the example topology in "Switch-Based Routing Topology" (page112), the following IP addresses are used:

Subnet Routing Example: IP Address Assignments

Subnet Devices IP Addresses

1 Primary and Secondary DefaultRouters

205.21.17.1 and205.21.17.2

2 First Floor Client Workstations 100.20.10.2-254

3 Second Floor ClientWorkstations

131.15.15.2-254

4 Common Servers 206.30.15.2-254

2 Assign an IP interface for each subnet attached to the switch.

Since there are four IP subnets connected to the switch, four IPinterfaces are needed:

Subnet Routing Example: IP Interface Assignments

Interface Devices IP Interface Address

IF 1 Primary and Secondary DefaultRouters

205.21.17.3

IF 2 First Floor Client Workstations 100.20.10.1

IF 3 Second Floor ClientWorkstations

131.15.15.1

IF 4 Common Servers 206.30.15.1

IP interfaces are configured using the following commands at theCLI:

>> # /cfg/l3/if 1 (Select IP interface 1)


(Assign IP address for theinterface)

>> IP Interface 1# ena (Enable IP interface 1)




.



(Select IP interface 2)














3 Set each server and workstation’s default gateway to theappropriate switch IP interface (the one in the same subnetas the server or workstation).

4 Configure the default gateways to the routers’ addresses.

Configuring the default gateways allows the switch to send outboundtraffic to the routers:

>> IP Interface 5# /cfg/l3/gw1

(Select primary defaultgateway)


( Assign IP address forprimary router)

>> Default gateway 1# ena (Enable primary defaultgateway)


(Select secondary defaultgateway)


(Assign address forsecondary router)

>> Default gateway 2# ena ( Enable secondary defaultgateway)

5 Enable, apply, and verify the configuration.

>> Default gateway 2#/cfg/l3/fwrd

(Select the IP ForwardingMenu)

>> IP Forwarding# on (Turn IP forwarding on)




.


>> IP Forwarding# apply (Make your changes active)

>> IP Forwarding# /cfg/l3/cur (View current IP settings)

Examine the resulting information. If any settings are incorrect,make the appropriate changes.


>> IP# save (Save for restore afterreboot)

—End—

Using VLANs to Segregate Broadcast DomainsIn the previous example, devices that share a common IP network are allin the same broadcast domain. If you want to limit the broadcasts on yournetwork, you could use VLANs to create distinct broadcast domains. Forexample, as shown in the following procedure, you could create one VLANfor the client trunks, one for the routers, and one for the servers.

In this example, you are adding to the previous configuration.

Step Action

1 Determine which switch ports and IP interfaces belong to whichVLANs.

The following table adds port and VLAN information:

Subnet Routing Example: Optional VLAN Ports

VLAN Devices IP Interface Switch Port VLAN #

1 First Floor ClientWorkstations

2 1 1

Second Floor ClientWorkstations

3 2 1

2 Primary DefaultRouter

1 3 2

Secondary DefaultRouter

1 4 2

3 Common Servers 1 4 5 3

Common Servers 2 4 6 3

2 Add the switch ports to their respective VLANs.




.


The VLANs shown in "Subnet Routing Example: Optional VLANPorts" (page 115) are configured as follows:

>> # /cfg/l2/vlan 1 (Select VLAN 1)

>> VLAN 1# add port 1 (Add port for 1st floor toVLAN 1)

>> VLAN 1# add port 2 (Add port for 2nd floor toVLAN 1)

>> VLAN 1# ena (Enable VLAN 1)

>> VLAN 1# /cfg/l2/vlan 2 (Select VLAN 2)

>> VLAN 2# add port 3 (Add port for default router1)

>> VLAN 2# add port 4 (Add port for default router2)


>> VLAN 2# /cfg/l2/vlan 3 (Add port for default router3)

>> VLAN 3# add port 5 (Select VLAN 3)

>> VLAN 3# add port 6 (Select port for commonserver 1)


Each time you add a port to a VLAN, you may get the followingprompt:

Port 4 is an untagged port and its current PVID is 1.Confirm changing PVID from 1 to 2 [y/n] ?

Enter y to set the default Port VLAN ID (PVID) for the port.

3 Add each IP interface to the appropriate VLAN.

Now that the ports are separated into three VLANs, the IP interfacefor each subnet must be placed in the appropriate VLAN. From"Subnet Routing Example: Optional VLAN Ports" (page 115), thesettings are made as follows:

>> VLAN 3# /cfg/l3/if 1 (Select IP interface 1 fordef. routers)

>> IP Interface 1# vlan 2 (Set to VLAN 2)


(Select IP interface 2 forfirst floor)





.



(Select IP interface 3 forsecond floor)



(Select IP interface 4 forservers)



>> IP Interface 5# apply (Make your changes active)

>> IP Interface 5#/info/l2/vlan

(View current VLANinformation)

>> Layer 2# /info/port (View current portinformation)



>> Information# save (Save for restore afterreboot)

—End—

Defining IP Address Ranges for the Local Route CacheA local route cache lets you use switch resources more efficiently. The localnetwork address and local network mask parameters (accessed via the/cfg/l3/frwd/local/add command) define a range of addresses thatare cached on the switch. The local network address is used to define thebase IP address in the range that will be cached. The local network mask isapplied to produce the range. To determine if a route should be added tothe memory cache, the destination address is masked (bit-wise AND) withthe local network mask and checked against the local network address.

By default, the local network address and local network mask are both setto 0.0.0.0. This produces a range that includes all Internet addresses forroute caching: 0.0.0.0 through 255.255.255.255.

To limit the route cache to your local hosts, you could configure theparameters as shown in the following example:




.


Local Routing Cache Address Ranges

Local Host Address Range Local Network Address Local Network Mask

0.0.0.0 - 127.255.255.255 0.0.0.0 128.0.0.0

128.0.0.0 - 128.255.255.255 128.0.0.0 128.0.0.0 or 255.0.0.0

205.32.0.0 - 205.32.255.255 205.32.0.0 255.255.0.0

Note: Static routes must be configured within the configured range. Allother addresses that fall outside the defined range are forwarded tothe default gateway.

Dynamic Host Configuration ProtocolDynamic Host Configuration Protocol (DHCP) is a transport protocolthat provides a framework for automatically assigning IP addresses andconfiguration information to other IP hosts or clients in a large TCP/IPnetwork. Without DHCP, the IP address must be entered manually foreach network device. DHCP allows a network administrator to distribute IPaddresses from a central point and automatically send a new IP addresswhen a device is connected to a different place in the network.

DHCP is an extension of another network IP management protocol,Bootstrap Protocol (BOOTP), with an additional capability of being ableto dynamically allocate reusable network addresses and configurationparameters for client operation.

Built on the client/server model, DHCP allows hosts or clients on anIP network to obtain their configurations from a DHCP server, therebyreducing network administration. The most significant configuration theclient receives from the server is its required IP address; (other optionalparameters include the "generic" file name to be booted, the address ofthe default gateway, and so forth).

Nortel Networks DHCP relay agent eliminates the need to haveDHCP/BOOTP servers on every subnet. It allows the administrator toreduce the number of DHCP servers deployed on the network and tocentralize them. Without the DHCP relay agent, there must be at least oneDHCP server deployed at each subnet that has hosts needing to performthe DHCP request.

DHCP Relay AgentDHCP is described in RFC 2131, and the DHCP relay agent supported onNortel Application Switches is described in RFC 1542. DHCP uses UDP asits transport protocol. The client sends messages to the server on port 67and the server sends messages to the client on port 68.




.


DHCP defines the methods through which clients can be assigned anIP address for a finite lease period and allowing reassignment of the IPaddress to another client later. Additionally, DHCP provides the mechanismfor a client to gather other IP configuration parameters it needs to operate inthe TCP/IP network.

In the DHCP environment, the Nortel Application Switch acts as a relayagent. The DHCP relay feature (/cfg/l3/bootp) enables the switch toforward a client request for an IP address to two BOOTP servers with IPaddresses that have been configured on the switch.

When a switch receives a UDP broadcast on port 67 from a DHCP clientrequesting an IP address, the switch acts as a proxy for the client, replacingthe client source IP (SIP) and destination IP (DIP) addresses. The requestis then forwarded as a UDP Unicast MAC layer message to two BOOTPservers whose IP addresses are configured on the switch. The serversrespond as a a UDP Unicast message back to the switch, with the defaultgateway and IP address for the client. The destination IP address inthe server response represents the interface address on the switch thatreceived the client request. This interface address tells the switch on whichVLAN to send the server response to the client.

DHCP Relay Agent ConfigurationTo enable the Nortel Application Switch to be the BOOTP forwarder, youneed to configure the DHCP/BOOTP server IP addresses on the switch.Generally, you should configure the command on the switch IP interfaceclosest to the client so that the DHCP server knows from which IP subnetthe newly allocated IP address should come.

The following figure shows a basic DHCP network example:

DHCP Relay Agent Configuration

In this Nortel Application Switch implementation, there is no need forprimary or secondary servers. The client request is forwarded to the BOOTPservers configured on the switch. The use of two servers provide failoverredundancy. However, no health checking is supported.

Use the following commands to configure the switch as a DHCP relay agent:




.


>> # /cfg/l3/bootp

>> Bootstrap Protocol Relay# addr (Set IP address of BOOTPserver)

>> Bootstrap Protocol Relay# addr2 (Set IP address of 2nd BOOTPserver)

>> Bootstrap Protocol Relay# on (Globally turn BOOTP relay on)

>> Bootstrap Protocol Relay# off (Globally turn BOOTP relay off)

>> Bootstrap Protocol Relay# cur (Display current configuration)

Additionally, DHCP Relay functionality can be assigned on a per interfacebasis. Use the following command to enable the Relay functionality:

>> #/cfg/l3/if <interface number> /relay ena

Gratuitous ARP (GARP) CommandGratuitous ARP packets are used to force a next-hop router to learn an IPand MAC pair. For security reasons, this command can only be used for anIP address belonging to a VIP, PIP, or Interface.

Use the GARP command as follows:

>> Main#/oper/ip/garp <IP Address> <VLAN Number>

Static RoutesA switch has two basic mechanisms for learning networking routes. Theprimary mechanism is through the use of routing protocols like the RoutingInformation Protocol (RIP) and Open Shortest Path First (OSPF)protocol. Routes learned in this manner are often referred to dynamic routesbecause they are updated periodically by the routing protocols to reflect thecurrent conditions in the network. For more information on these protocolsand their use, refer to "Routing Information Protocol" (page 126) and "OpenShortest Path First (OSPF)" (page 146).

Switches also learn networking routes through static routes. Static routesare manually entered into the switch by an administrator. Although wholenetworks could be built upon static routes, they do not have the capacity tochange without user intervention and therefore do not adequately representthe every changing reality of an enterprise network. It is because of this thatstatic routes have an important but limited role in the enterprise network.Typically static routes are used in situations when a protocol like RIP orOSPF cannot provide the information necessary to create connectivitybetween two nodes.




.


For example, a node in a network that is running OSPF may need to knowthe route to a node in a network that is not running OSPF. OSPF would notbe able to provide information about either network to its counterpart. In thissituation, a static route should be used to provide connectivity.

The Nortel Application Switch supports both IPv4 and IPv6 static routesthrough the Layer 3 configuration menu. Up to 128 IPv4 and 128 IPv6 staticroutes are supported.

IPv4 Static RoutesIPv4 static routes are used to support static connectivity to anIPv4 network. IPv4 static routes are added to the switch using the/cfg/l3/route/ip4/add command. This command has the followingsyntax:

>> Main#/cfg/l3/route/ip4/add <destination> <mask> <gateway>[interface number]

IPv4 static routes are removed from the switch using the/cfg/l3/route/ip4/rem command. This command has the followingsyntax:

>> Main#/cfg/l3/route/ip4/rem <destination> <mask>

The IPv4 static routes that are currently part of the switch configurationcan be displayed using the /cfg/l3/route/ip4/cur command. Thiscommand has no parameters.

IPv6 Static RoutesIPv6 static routes are used to support static connectivity to an IPv6 network.IPv6 static routes are conceptually identical to their IPv4 counterpartsand only differ in the addressing format used. For information about IPv6concepts and addressing formats refer to "IPv6" (page 123).

IPv6 static routes are added to the switch using the/cfg/l3/route/ip6/add command. This command has thefollowing syntax:

>> Main#/cfg/l3/route/ip6/add <destination> <prefix length><next hop>[interface number]

IPv6 static routes are removed from the switch using the/cfg/l3/route/ip6/rem command. This command has the followingsyntax:




.


>> Main#/cfg/l3/route/ip6/rem <destination> <prefix length><next hop>

The IPv6 static routes that are currently part of the switch configurationcan be displayed using the /cfg/l3/route/ip6/cur command. Thiscommand has no parameters.




.

IPv6 123

IPv6

IPv6, or Internet Protocol version 6, is a network layer protocol intended toexpand the network address spaces of IPv4. IPv6 will differ in a numberof ways from IPv4 that makes it more robust and expandable protocol asthe need for physical address space goes up. IPv6 was mainly conceivedas a protocol to help alleviate the shortage of available network addresses.Currently, IPv4 supports the creation and use of approximately 4 billionIP addresses. IPv6 expands the number of available addresses toapproximately 3.4 x 1038.

IPv6 is defined in RFC 2373, RFC 2460, and RFC 2461.

The Nortel Application Switch Operating System 24.0 supports IPv6 in anumber of different areas. Refer to the individual feature sections for detailson the level of support. This section describes the basic configuration andmanagement of IPv6 on the switch.

IPv6 Address FormatThe IPv6 address is 128 bits long and is represented as a sequence ofeight 16-bit hex values, separated by colons. The preferred format isxxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx. For example,

FEDC:BA98:7654:BA98:FEDC:1234:ABCD:5412

Some address can contain long sequences of zeros. A contiguoussequence of zeros can be compressed to :: (double colon). For example,the address of FE80:0:0:0:2AA:FF:FA:4CA2 can be compressed toFE80::2AA:FF:FA:4CA2. Unlike IPv4, a subnet mask is not used for IPv6addresses.

IPv6 uses prefix length for network identifier. For example,

21DA:D300:0000:2F3C::/64

where 64 is the network prefix.

IPv6 Address TypesThere are three types of IPv6 addresses: unicast, multicast, and anycast.

Unicast AddressThere are two types of unicast addresses:

• Global Unicast address: An address that can be reached and identifiedglobally.




.


Global Unicast addresses use the high-order bit range from 2000to 3FFF. If the last 64 bits of the address are not configured, NortelApplication Switch Operating System will default automatically to utilizethe EUI-64 (Extended Unique Identifier 64-bit) address format. RFC3513 defines the expanding of the Ethernet MAC address based on a48-bit format into a 64-bit EUI-64 format.

The interface ID must be unique within the same subnet.

• Link-local unicast address: An address used to communicate with aneighbor on the same link.

Link-local addresses use the high-order bit range from FE80 to FEBF.Link-local unicast addresses are automatically configured on theinterface by using the link-local prefix FE80::/10 and the interfaceidentifier in EUI-64 format for its low-order 64-bit. Link-local packetsare not routed between subnets.

MulticastA multicast address (FF00 - FFFF) is an identifier for a group interface. Themulticast address most often encountered is a solicited-mode multicastaddress using prefix FF02::1:FF00:0000/104 with the low-order 24 bits ofthe unicast or anycast address.

AnycastAnycast addresses can be global unicast, site-local or link-localaddresses used for a one-to-nearest node member of the anycast groupcommunication. Nortel Application Switch Operating System does notsupport anycast addresses.

Pinging IPv6 AddressesThe following two examples show how to ping IPv6 addresses:

• Enter the following command to ping an IPv6 address.

>> IP6 Neighbor Discovery Protocol# ping6 3000::1

3000:0:0:0:0:0:0:1 is alive

• Specify the interface number when pinging to a IPv6 link-local unicastaddress.

>> IP6 Neighbor Discovery Protocol# ping6 fe80::20d:56ff:fe22:df09Enter interface number: (1-256) 200

fe80:0:0:0:20d:56ff:fe22:df09 is alive




.

IPv6 125

Verifying IPv6 ConfigurationTo verify IPv6 configuration, enter the following commands:

• General IPv6 information

>> Main# /info/l3/ip

• IPv6 routing table

>> Main# /info/l3/route6>> IP6 Routing# dump

• IPv6 neighbor discovery protocol table

>> Main# /info/l3/nbrcache>> IP6 Neighbor Discovery Protocol# dump

Verifying IPv6 StatisticsTo display IPv6 statistics, enter the following command:

>> Main# /stats/l3/ip6




.


Routing Information Protocol

In a routed environment, routers communicate with one another to keep trackof available routes. Routers can learn about available routes dynamicallyusing the Routing Information Protocol (RIP). Nortel Application SwitchOperating System software supports RIP version 1 (RIPv1) and RIP version2 (RIPv2) for exchanging TCP/IP route information with other routers.

Distance Vector ProtocolRIP is known as a distance vector protocol. The vector is the networknumber and next hop, and the distance is the cost associated with thenetwork number. RIP identifies network reachability based on cost, andcost is defined as hop count. One hop is considered to be the distancefrom one switch to the next which is typically 1. This cost or hop count isknown as the metric.

When a switch receives a routing update that contains a new or changeddestination network entry, the switch adds 1 to the metric value indicated inthe update and enters the network in the routing table. The IP address ofthe sender is used as the next hop.

StabilityRIP includes a number of other stability features that are common to manyrouting protocols. For example, RIP implements the split horizon andhold-down mechanisms to prevent incorrect routing information from beingpropagated.

RIP prevents routing loops from continuing indefinitely by implementinga limit on the number of hops allowed in a path from the source to adestination. The maximum number of hops in a path is 15. The networkdestination network is considered unreachable if increasing the metric valueby 1 causes the metric to be 16 (that is infinity). This limits the maximumdiameter of a RIP network to less than 16 hops.

RIP is often used in stub networks and in small autonomous systems thatdo not have many redundant paths.

Routing UpdatesRIP sends routing-update messages at regular intervals and when thenetwork topology changes. Each router " advertises" routing informationby sending a routing information update every 30 seconds. If a routerdoesn’t receive an update from another router for 180 seconds, those routesprovided by that router are declared invalid. After another 120 secondswithout receiving an update for those routes, the routes are removed fromthe routing table and respective regular updates.




.

Routing Information Protocol 127

When a router receives a routing update that includes changes to an entry,it updates its routing table to reflect the new route. The metric value forthe path is increased by 1, and the sender is indicated as the next hop.RIP routers maintain only the best route (the route with the lowest metricvalue) to a destination.

For more information see the Configuration Menu, Routing InformationProtocol Configuration (/cfg/l3/rip) in the Nortel Application SwitchOperating System 24.0 Command Reference (NN47220-105).

RIPv1RIP version 1 uses broadcast User Datagram Protocol (UDP) data packetsfor the regular routing updates. The main disadvantage is that the routingupdates do not carry subnet mask information. Hence, the router cannotdetermine whether the route is a subnet route or a host route. It is of limitedusage after the introduction of RIPv2. For more information about RIPv1and RIPv2, refer to RFC 1058 and RFC 2453.

RIPv2RIPv2 is the most popular and preferred configuration for most networks.RIPv2 expands the amount of useful information carried in RIP messagesand provides a measure of security. For a detailed explanation of RIPv2,refer to RFC 1723 and RFC 2453.

RIPv2 improves efficiency by using multicast UDP (address 224.0.0.9) datapackets for regular routing updates. Subnet mask information is provided inthe routing updates. A security option is added for authenticating routingupdates, by using a shared password. Nortel Application Switch OperatingSystem 24.0 supports using clear text passwords for RIPv2.

RIP Version 2 EnhancementsRIP version 2 supports the following enhancements to version 1:

• Variable length subnet masks for classless inter-domain routing.

• RIP version 2 updates always include the next-hop router address.

• Routing updates can be sent to a multicast address.

• Routing updates can be authenticated using a simple password scheme.

For a detailed description of RIP version 2, refer to RFC 1723 and 2453.

RIPv2 in RIPv1 compatibility modeNortel Application Switch Operating System 24.0 allows for RIPv2configuration RIPv1compatibility mode to use both RIPv2 and RIPv1 routerswithin a network. In this mode, the regular routing updates use broadcastUDP data packet to allow RIPv1 routers to receive those packets. With




.


RIPv1 routers as recipients, the routing updates have to carry natural orhost mask. Hence, it is not a recommended configuration for most networktopologies.

Note: When using both RIPv1 and RIPv2 within a network, use a singlesubnet mask throughout the network.

RIP FeaturesNortel Application Switch Operating System 24.0 provides the followingfeatures to support RIPv1 and RIPv2:

PoisonSimple split horizon in the RIP scheme omits routes learned from oneneighbor in updates sent to that neighbor. That is the most commonconfiguration used in RIP network topology. Split horizon with poisonedreverse includes such routes in updates, but sets their metrics to 16. Thedisadvantage of using this feature is the increase of size in the routingupdates. So, it is recommended to disable split horizon with poisonedreverse.

Triggered updatesTriggered updates are an attempt to speed up convergence. WhenTriggered Updates is enabled, whenever a router changes the metric for aroute, it sends update messages almost immediately, without waiting for theregular update interval. It is recommended to enable Triggered Updates.

MulticastRIPv2 messages use IP multicast address (224.0.0.9) for periodicbroadcasts. Multicast RIPv2 announcements are not processed by RIPv1routers.

To configure RIPv2 in RIPv1 compatibility mode, set multicast to DISABLE.

DefaultThe RIP router can listen and supply a default route, usually representedas 0.0.0.0 in the routing table. When a router does not have an explicitroute to a destination network in its routing table, it uses the default route toforward those packets.

MetricThe metric field contains a configurable value between 1 and 15 whichspecifies the current metric for the interface. The metric value typicallyindicates the total number of hops to the destination. The metric value of 16represents an unreachable destination.




.

Routing Information Protocol 129

AuthenticationRIPv2 authentication uses clear text passwords for authentication. Ifconfigured using Authentication password, then it is necessary to enteran authentication key value.

The following method is used to authenticate a RIP message:

• If the router is not configured to authenticate RIPv2 messages,then RIPv1 and unauthenticated RIPv2 messages are accepted;authenticated RIPv2 messages are discarded.

• If the router is configured to authenticate RIPv2 messages, then RIPv1messages and RIPv2 messages which pass authentication testing areaccepted; unauthenticated and failed authentication RIPv2 messagesare discarded.

For maximum security, RIPv1 messages are ignored when authenticationis enabled. If not, the routing information from authenticated messages ispropagated by RIPv1 routers in an unauthenticated manner.

RIP Configuration Example

Note: A disabled RIP interface uses all the default values of the RIP,no matter how the RIP parameters are configured for that interface.RIP sends out RIP regular updates to include an UP interface, but nota DOWN interface.

Step Action

1 Add VLANs for routing interfaces.

>> Main# cfg/l2/vlan 2/ena (Enable VLAN 2)

>> VLAN 2# add 2 (Add port 2 to VLAN 2)

Port 2 is an UNTAGGED port and its current PVID is 1.Confirm changing PVID from 1 to 2 [y/n]: y

>> VLAN 2# /cfg/l2/vlan 3/ena (Enable VLAN 3)

>> VLAN 3# add 3 (Add port EXT3 to VLAN 3)

Port 3 is an UNTAGGED port and its current PVID is 1.Confirm changing PVID from 1 to 3 [y/n]: y

2 Add IP interfaces to VLANs.

>> Main# cfg/l3/if 2/ena (Enable interface 2)


(Define IP address forinterface 2)

>> IP Interface 2# vlan 2 (Add interface 2 to VLAN 2)




.


>> IP Interface 2# /cfg/l3/if3/ena

(Enable interface 3)


(Define IP address forinterface 3)

>> IP Interface 3# vlan 3 (Add interface 3 to VLAN 3)

3 Turn on RIP globally and enable RIP for each interface.

>> Main# cfg/l3/rip on (Turn on RIP globally)

>> Routing InformationProtocol# if 2/ena

(Enable RIP on IP interface2)

>> RIP Interface 2# ..

>> Routing InformationProtocol# if 3/ena

(Enable RIP on IP interface3)

>> RIP Interface 3# apply (Apply your changes)

>> RIP Interface 3# save (Save the configuration)

Use the /maint/route/dump command to check the current validroutes in the routing table of the switch.

For those RIP learnt routes within the garbage collection period,routes phasing out of the routing table with metric 16, use the/info/l3/routes/dump command. Locally configured staticroutes do not appear in the RIP Routes table.

—End—




.

Border Gateway Protocol 131

Border Gateway Protocol

Border Gateway Protocol (BGP) is an Internet protocol that enables routerson a network to share and advertise routing information with each otherabout the segments of the IP address space they can access withintheir network and with routers on external networks. BGP allows you todecide what is the "best" route for a packet to take from your network to adestination on another network rather than simply setting a default routefrom your border router(s) to your upstream provider(s). BGP is defined inRFC 1771.

Nortel Application Switches can advertise their IP interfaces and virtualserver IP addresses using BGP and take BGP feeds from as many as 16BGP router peers. This allows more resilience and flexibility in balancingtraffic from the Internet.


• "Internal Routing Versus External Routing" (page 131)

• "Forming BGP Peer Routers" (page 133)

• "What is a Route Map?" (page 133)

• "Aggregating Routes" (page 137)

• "Redistributing Routes" (page 137)

• "BGP Attributes" (page 138)

• "Selecting Route Paths in BGP" (page 139)

• "BGP Failover Configuration" (page 139)

• "Default Redistribution and Route Aggregation Example" (page 143)

BGP-based Global Server Load Balancing utilizes the Internet’s routingprotocols to localize content delivery to the most efficient and consistent site.For more information on BGP-based GSLB, see "Using Border GatewayProtocol for GSLB" (page 767).

Internal Routing Versus External RoutingTo ensure effective processing of network traffic, every router on yournetwork needs to know how to send a packet (directly or indirectly) to anyother location/destination in your network. This is referred to as internalrouting and can be done with static routes or using active, internal dynamicrouting protocols, such as RIP, RIPv2, and OSPF.




.


Static routes, should have a higher degree of precedence than dynamicrouting protocols. If the destination route is not in the route cache, then thepackets are forwarded to the default gateway which may be incorrect if adynamic routing protocol is enabled.

It is also useful to tell routers outside your network (upstream providers orpeers) about the routes you can access in your network. External networks(those outside your own) that are under the same administrative control arereferred to as autonomous systems (AS). Sharing of routing informationbetween autonomous systems is known as external routing.

External BGP (eBGP) is used to exchange routes between differentautonomous systems whereas internal BGP (iBGP) is used to exchangeroutes within the same autonomous system. An iBGP is a type of internalrouting protocol you can use to do active routing inside your network. Italso carries AS path information, which is important when you are an ISPor doing BGP transit.

Note: The iBGP peers must be part of a fully meshed network, asshown in "iBGP and eBGP" (page 132).

iBGP and eBGP

Typically, an AS has one or more border routers—peer routers that exchangeroutes with other ASs—and an internal routing scheme that enables routersin that AS to reach every other router and destination within that AS. Whenyou advertise routes to border routers on other autonomous systems, youare effectively committing to carry data to the IP space represented in theroute being advertised. For example, if you advertise 192.204.4.0/24, youare declaring that if another router sends you data destined for any addressin 192.204.4.0/24, you know how to carry that data to its destination.




.


Forming BGP Peer RoutersTwo BGP routers become peers or neighbors once you establish a TCPconnection between them. For each new route, if a peer is interested in thatroute (for example, if a peer would like to receive your static routes and thenew route is static), an update message is sent to that peer containing thenew route. For each route removed from the route table, if the route hasalready been sent to a peer, an update message containing the route towithdraw is sent to that peer.

For each Internet host, you must be able to send a packet to that host, andthat host has to have a path back to you. This means that whoever providesInternet connectivity to that host must have a path to you. Ultimately, thismeans that they must "hear a route" which covers the section of the IPspace you are using; otherwise, you will not have connectivity to the hostin question.

What is a Route Map?A route map is used to control and modify routing information. Routemaps define conditions for redistributing routes from one routing protocolto another or controlling routing information when injecting it in and out ofBGP. Route maps are used by OSPF only for redistributing routes. Forexample, a route map is used to set a preference value for a specific routefrom a peer router and another preference value for all other routes learnedvia the same peer router. For example, the following command is used todefine a route map:

>> # /cfg/l3/rmap 1 (Select a route map)

A route map allows you to match attributes, such as metric, networkaddress, and AS number. It also allows users to overwrite the localpreference metric and to append the AS number in the AS route. See "BGPFailover Configuration" (page 139).

The Nortel Application Switch Operating System allows you to configure 32route maps. Each route map can have up to eight access lists. Each accesslist consists of a network filter. A network filter defines an IP address andsubnet mask of the network that you want to include in the filter. "DistributingNetwork Filters in Access Lists and Route Maps" (page 134) illustrates therelationship between route maps, access lists and network filters.




.


Distributing Network Filters in Access Lists and Route Maps

Incoming and Outgoing Route MapsYou can have two types of route maps: incoming and outgoing. A BGP peerrouter can be configured to support up to eight route maps in the incomingroute map list and outgoing route map list.

If a route map is not configured in the incoming route map list, the routerimports all BGP updates. If a route map is configured in the incoming routemap list, the router ignores all unmatched incoming updates.

Route maps in an outgoing route map list behave similar to route maps inan incoming route map list. If a route map is not configured in the outgoingroute map list, all routes are advertised or permitted. If a route map isconfigured in the outgoing route map list, matched routes are advertisedand unmatched routes are ignored.

PrecedenceYou can set a priority to a route map by specifying a precedence valuewith the following command:

>> /cfg/l3/rmap <x> /pre (Specify a precedence)




.


The smaller the value the higher the precedence. If two route maps havethe same precedence value, the smaller number has higher precedence.

Configuration OverviewTo configure route maps, you need to do the following:

Step Action

1 Define network filter.

>> # /cfg/l3/nwf 1 (Specify a network filternumber)

>> IP Network Filter 1# addr <IPaddress>

(Specify network address)

>> IP Network Filter 1# mask <IPmask>

(Specify network mask)

>> IP Network Filter 1# ena (Enable network filter)

Enter a filter number from 1 to 256. Specify the IP address andsubnet mask of the network that you want to match. Enable thenetwork filter. You can distribute up to 256 network filters among 32route maps each containing eight access lists.

2 (Optional) Define the criteria for the access list and enable it.

Specify the access list and associate the network filter numberconfigured in Step 1.

>> # /cfg/l3/rmap 1 (Specify a route mapnumber)

>> IP Route Map 1# alist 1 (Specify the access listnumber)

>> IP Access List 1# nwf 1 (Specify the network filternumber)

>> IP Access List 1# metric (Define a metric)

>> IP Access List 1# actiondeny

(Specify action for theaccess list)

>> IP Access List 1# ena (Enable the access list)

Steps 2 and 3 are optional, depending on the criteria that you wantto match. In Step 2, the network filter number is used to match thesubnets defined in the network filter. In Step 3, the autonomoussystem number is used to match the subnets. Or, you can use both(Step 2 and Step 3) criteria: access list (network filter) and accesspath (AS filter) to configure the route maps.




.


3 (Optional) Configure the attributes in the AS filter menu.

>> # cfg/l3/rmap 1/aspath 1 (Specify the attributes in thefilter)

>> AS Filter 1# as 1 (Specify the AS number)

>> AS Filter 1# action deny (Specify the action for thefilter)

>> AS Filter 1# ena (Enable the AS filter)

4 Set up the BGP attributes.

If you want to overwrite the attributes that the peer router is sending,then define the following BGP attributes:

• Specify the AS numbers that you want to prepend to a matchedroute and the local preference for the matched route.

• Specify the metric [Multi Exit Discriminator (MED)] for thematched route.

>> # /cfg/l3/rmap 1 (Specify a route mapnumber)

>> IP Route Map 1# ap (Specify the AS numbers toprepend)

>> IP Route Map 1# lp (Specify the localpreference)

>> IP Route Map 1# med (Specify the metric)

5 Enable the route map.

>> # /cfg/l3/rmap 1/en (Enable the route map)

6 Assign the route map to a peer router.

Select the peer router and then add the route map to the incomingroute map list,

>> # /cfg/l3/bgp/peer 1/addi (Add to the incoming routemap)

or to the outgoing route map list.

>> # /cfg/l3/bgp/peer 1/addo (Add to the outgoing routemap)




.


—End—

Aggregating RoutesAggregation is the process of combining several different routes in sucha way that a single route can be advertised, which minimizes the size ofthe routing table. You can configure aggregate routes in BGP either byredistributing an aggregate route into BGP or by creating an aggregateentry in the BGP routing table.

When a subnet is redistributed from an Interior Gateway Protocol (IGP) intoBGP, only the network route is injected into the BGP table. By default, thisautomatic summarization is disabled. To define the route to aggregate,use the following commands:

>> # /cfg/l3/bgp (Specify BGP)

>> Border Gateway Protocol# aggr 1 (Specify aggregate list number)

>> BGP aggr 1 # addr (Enter aggregation networkaddress)

>> BGP aggr 1 # mask (Enter aggregation networkmask)

>> BGP aggr 1 # ena (Enable aggregation)

An example of creating a BGP aggregate route is shown in "DefaultRedistribution and Route Aggregation Example" (page 143).

Redistributing RoutesIn addition to running multiple routing protocols simultaneously, the NortelApplication Switch Operating System software can redistribute informationfrom one routing protocol to another. For example, you can instruct theswitch to use BGP to readvertise static routes. This applies to all of theIP-based routing protocols.

You can also conditionally control the redistribution of routes betweenrouting domains by defining a method known as route maps between thetwo domains. For more information on route maps, see "What is a RouteMap?" (page 133). Redistributing routes is another way of providing policycontrol over whether to export OSPF routes, fixed routes, static routes,and virtual IP address routes. For an example configuration, see "DefaultRedistribution and Route Aggregation Example" (page 143).

Default routes can be configured using the following methods:

• Import




.


• Originate—The router sends a default route to peers even though itdoes not have any default routes in its routing table.

• Redistribute—Default routes are either configured through the defaultgateway or learned via other protocols and redistributed to peer routers.If the default routes are from the default gateway, enable the staticroutes because default routes from the default gateway are static routes.Similarly, if the routes are learned from another routing protocol, makesure you enable that protocol for redistribution.

• None

BGP AttributesThe following two BGP attributes are discussed in this section: Localpreference and metric (Multi-Exit Discriminator).

Local Preference AttributeWhen there are multiple paths to the same destination, the local preferenceattribute indicates the preferred path. The path with the higher preference ispreferred (the default value of the local preference attribute is 100). Unlikethe weight attribute, which is only relevant to the local router, the localpreference attribute is part of the routing update and is exchanged amongrouters in the same AS.

The local preference attribute can be set in one of two ways:

• /cfg/l3/bgp/pref

This command uses the BGP default local preference method, affectingthe outbound direction only.

• /cfg/l3/rmap/lp

This command uses the route map local preference method, whichaffects both inbound and outbound directions.

Metric (Multi-Exit Discriminator) AttributeThis attribute is a hint to external neighbors about the preferred path into anAS when there are multiple entry points. A lower metric value is preferredover a higher metric value. The default value of the metric attribute is 0.

Unlike local preference, the metric attribute is exchanged between ASs;however, a metric attribute that comes into an AS does not leave the AS.

When an update enters the AS with a certain metric value, that value isused for decision making within the AS. When BGP sends that update toanother AS, the metric is reset to 0.

Unless otherwise specified, the router compares metric attributes for pathsfrom external neighbors that are in the same AS.




.


Selecting Route Paths in BGPBGP selects only one path as the best path. It does not rely on metricsattributes to determine the best path. When the same network is learnedvia more than one BGP peer, BGP uses its policy for selecting the bestroute to that network. The BGP implementation on the Nortel ApplicationSwitches uses the following criteria to select a path when the same route isreceived from multiple peers.

Step Action

1 Local fixed and static routes are preferred over learned routes.

2 With iBGP peers, routes with higher local preference valuesare selected.

3 In the case of multiple routes of equal preference, the route withlower AS path weight is selected.

AS path weight = 128 x AS path length (number of autonomoussystems transversed).

4 In the case of equal weight and routes learned from peers thatreside in the same AS, the lower metric is selected.

Note: A route with a metric is preferred over a route without ametric.

5 The lower cost to the next hop of routes is selected.

6 In the case of equal cost, the eBGP route is preferred over iBGP.

7 If all routes are from eBGP, the route with the lower router IDis selected.

When the path is selected, BGP puts the selected path in its routingtable and propagates the path to its neighbors.

—End—

BGP Failover ConfigurationUse the following example to create redundant default gateways for anNortel Application Switch at a Web Host/ISP site, eliminating the possibility,should one gateway go down, that requests is forwarded to an upstreamrouter unknown to the switch.




.


As shown in "BGP Failover Configuration Example" (page 140), the switchis connected to ISP 1 and ISP 2. The customer negotiates with both ISPs toallow the Application switch to use their peer routers as default gateways.The ISP peer routers will then need to announce themselves as defaultgateways to the Application switch.

BGP Failover Configuration Example

On the Application switch, one peer router (the secondary one) is configuredwith a longer AS path than the other, so that the peer with the shorter ASpath will be seen by the switch as the primary default gateway. ISP 2, thesecondary peer, is configured with a metric of "3," thereby appearing to theswitch to be three router hops away.

Step Action

1 Configure the switch as you normally would for Server LoadBalancing (SLB).

• Assign an IP address to each of the real servers in the serverpool.

• Define each real server.

• Define a real server group.

• Define a virtual server.

• Define the port configuration.




.


For more information about SLB configuration, refer to "Server LoadBalancing" (page 188)."

2 Define the VLANs.

For simplicity, both default gateways are configured in the sameVLAN in this example. The gateways could be in the same VLANor different VLANs.

>> # /cfg/l2/vlan 1 (Select VLAN 1)

>> vlan 1# add <port number> (Add a port to the VLANmembership)

3 Define the IP interfaces.

The switch needs an IP interface for each default gateway to which itis connected. Each interface needs to be placed in the appropriateVLAN. These interfaces is used as the primary and secondarydefault gateways for the switch.

>> /cfg/l3/arp/rearp 10 (Set re-ARP period forinterface to 10)

>> IP# /cfg/l3/metric strict (Set metric for defaultgateway)

>> IP# if 1 (Select default gatewayinterface 1)

>> IP Interface 1# ena (Enable switch interface 1)


(Configure IP address ofinterface 1)


(Configure IP subnetaddress mask)

>> IP Interface 1# /cfg/l3/if 2 (Select default gatewayinterface 2)

>> IP Interface 2# ena (Enable switch interface 2)


(Configure IP address ofinterface 2)


(Configure IP subnetaddress mask)

4 Enable IP forwarding.




.


IP forwarding is enabled by default and is used for VLAN-to-VLAN(non-BGP) routing. Make sure IP forwarding is enabled if the defaultgateways are on different subnets or if the switch is connected todifferent subnets and those subnets need to communicate throughthe switch (which they almost always do).

>> /cfg/l3/frwd/on (Enable IP forwarding)

Note: To help eliminate the possibility for a Denial of Service(DoS) attack, the forwarding of directed broadcasts is disabledby default.

5 Globally turn on BGP.

>> # /cfg/l3/bgp/on

6 Configure BGP peer router 1 and 2.

Peer 1 is the primary gateway router. Peer 2 is configured with ametric of 3. The metric option is key to ensuring gateway trafficis directed to Peer 1, as it makes Peer 2 appear to be three routerhops away from the switch. Thus, the switch should never use itunless Peer 1 goes down.

>> # /cfg/l3/bgp/peer 1 (Select BGP peer router 1)

>> BGP Peer 1# ena (Enable this peerconfiguration)

>> BGP Peer 1# addr 200.200.200.2

(Set IP address for peerrouter 1)

>> BGP Peer 1# if 200.200.200.1 (Set IP interface for peerrouter 1)

>> BGP Peer 1# ras 100 (Set remote AS number)

>> BGP Peer 1# /cfg/l3/bgp/peer2

(Select BGP peer router 2)


>> BGP Peer 2# addr 210.210.210.2

(Set IP address for peerrouter 2)

>> BGP Peer 2# if 210.210.210.1 (Set IP interface for peerrouter 2)


>> BGP Peer 2# metric 3 (Set AS path length to 3router hops)




.


The metric command in the peer menu tells the Nortel ApplicationSwitch to create an AS path of "3" when advertising via BGP.

7 On the switch, apply and save your configuration changes.

>> BGP Peer 2# apply (Make your changes active)

>> save (Save for restore after reboot)

—End—

Default Redistribution and Route Aggregation ExampleThis example shows you how to configure the switch to redistributeinformation from one routing protocol to another and create an aggregateroute entry in the BGP routing table to minimize the size of the routing table.

As illustrated in "Route Aggregation and Default Route Redistribution" (page143), you have two peer routers: an internal and an external peer router.Configure the Nortel Application Switch to redistribute the default routesfrom AS 200 to AS 135. At the same time, configure for route aggregationto allow you to condense the number of routes traversing from AS 135 toAS 200.

Route Aggregation and Default Route Redistribution

Step Action

1 Configure the IP interface.




.


2 Configure the AS number (AS 135) and router ID number(10.1.1.135).

The router ID number must be a unique number and does not haveto be an IP address. However, for convenience, this id is typicallyone of IP addresses assigned in IP interfaces.

>> # /cfg/l3/bgp (Select the BGP menu)

>> Border Gateway Protocol# as135

(Specify an AS number)

>> Border Gateway Protocol# /cfg/l3/rtrid 10.1.1.135

(Specify the router IDnumber)

3 Configure internal peer router 1 and external peer router 2.

>> # /cfg/l3/bgp/peer 1 (Select internal peer router1)


>> BGP Peer 1# addr 10.1.1.4 (Set IP address for peerrouter 1)


>> BGP Peer 1# /cfg/l3/bgp/peer2

(Select external peer router2)


>> BGP Peer 2# addr 20.20.20.2 (Set IP address for peerrouter 2)


4 Configure redistribution for Peer 1.

>> # /cfg/l3/bgp/peer 1/redist (Select redistribute)

>> BGP Peer 1# defaultredistribute

(Set default to redistribute)

>> BGP Peer 1# fixed ena (Enable fixed routes)

5 Configure aggregation policy control.

Configure the routes that you want aggregated.




.


>> # /cfg/l3/bgp/aggr 1 (Set aggregation number)

>> BGP Aggr 1# addr 135.0.0.0 (Add IP address toaggregate 1)

>> BGP Aggr 1# mask 255.0.0.0 (Add IP mask to aggregate1)

>> BGP Aggr 1# ena (Enable route aggregation)


>> # apply>> # save

—End—




.


Open Shortest Path First (OSPF)

Nortel Application Switch Operating System supports the Open ShortestPath First (OSPF) routing protocol. The Nortel Application Switch OperatingSystem implementation conforms to the OSPF version 2 specificationsdetailed in Internet RFC 1583.


• "OSPF Overview" (page 146). This section provides information onOSPF concepts, such as types of OSPF areas, types of routing devices,neighbors, adjacencies, link state database, authentication, and internalversus external routing.

• "OSPF Implementation" (page 151). This section describes how OSPFis implemented in Nortel Application Switch Operating System, such asconfiguration parameters, electing the designated router, summarizingroutes, defining route maps and so forth.

• "OSPF Configuration Examples" (page 164). This section providesstep-by-step instructions on configuring four different configurationexamples:

— Creating a simple OSPF domain

— Creating virtual links

— Summarizing routes

— Creating host routes

OSPF OverviewOSPF is designed for routing traffic within a single IP domain called anAutonomous System (AS). The AS can be divided into smaller logical unitsknown as areas.

All routing devices maintain link information in their own Link State Database(LSDB). The LSDB for all routing devices within an area is identical but is notexchanged between different areas. Only routing updates are exchangedbetween areas, thereby significantly reducing the overhead for maintainingrouting information on a large, dynamic network.

The following sections describe key OSPF concepts.




.

Open Shortest Path First (OSPF) 147

Equal Cost Multipath Routing SupportEqual-cost multipath (ECMP) is a routing technique for routing packetsalong multiple paths of equal cost. The routing table contains multiplenext-hops for any given destination. The router load balances packetsalong the multiple next-hops. Nortel Application Switch Operating Systemsupports ECMP, and there are no CLI additions or changes.

Types of OSPF AreasAn AS can be broken into logical units known as areas. In any AS withmultiple areas, one area must be designated as area 0, known as thebackbone. The backbone acts as the central OSPF area. All other areas inthe AS must be connected to the backbone. Areas inject summary routinginformation into the backbone, which then distributes it to other areas asneeded.

As shown in "OSPF Area Types" (page 148), OSPF defines the followingtypes of areas:

• Stub Area—an area that is connected to only one other area. Externalroute information is not distributed into stub areas.

• Not-So-Stubby-Area (NSSA)—similar to a stub area with additionalcapabilities. Routes originating from within the NSSA can be propagatedto adjacent transit and backbone areas. External routes from outsidethe AS can be advertised within the NSSA but are not distributed intoother areas.

• Transit Area—an area that allows area summary information to beexchanged between routing devices. The backbone (area 0), any areathat contains a virtual link to connect two areas, and any area that is nota stub area or an NSSA are considered transit areas.




.


OSPF Area Types

Types of OSPF Routing DevicesAs shown in "OSPF Domain and an Autonomous System" (page 149),OSPF uses the following types of routing devices:

• Internal Router (IR)—a router that has all of its interfaces within thesame area. IRs maintain LSDBs identical to those of other routingdevices within the local area.

• Area Border Router (ABR)—a router that has interfaces in multipleareas. ABRs maintain one LSDB for each connected area anddisseminate routing information between areas.

• Autonomous System Boundary Router (ASBR)—a router that acts as agateway between the OSPF domain and non-OSPF domains, such asRIP, BGP, and static routes.




.


OSPF Domain and an Autonomous System

Neighbors and AdjacenciesIn areas with two or more routing devices, neighbors and adjacencies areformed.

Neighbors are routing devices that maintain information about each others’health. To establish neighbor relationships, routing devices periodicallysend hello packets on each of their interfaces. All routing devices thatshare a common network segment, appear in the same area, and have thesame health parameters (hello and dead intervals) and authenticationparameters respond to each other’s hello packets and become neighbors.Neighbors continue to send periodic hello packets to advertise their healthto neighbors. In turn, they listen to hello packets to determine the health oftheir neighbors and to establish contact with new neighbors.

The hello process is used for electing one of the neighbors as the area’sDesignated Router (DR) and one as the area’s Backup Designated Router(BDR). The DR is adjacent to all other neighbors and acts as the centralcontact for database exchanges. Each neighbor sends its databaseinformation to the DR, which relays the information to the other neighbors.

The BDR is adjacent to all other neighbors (including the DR). Eachneighbor sends its database information to the BDR just as with the DR,but the BDR merely stores this data and does not distribute it. If the DRfails, the BDR takes over the task of distributing database information tothe other neighbors.




.


The Link-State DatabaseOSPF is a link-state routing protocol. A link represents an interface (orroutable path) from the routing device. By establishing an adjacency with theDR, each routing device in an OSPF area maintains an identical Link-StateDatabase (LSDB) describing the network topology for its area.

Each routing device transmits a Link-State Advertisement (LSA) on eachof its interfaces. LSAs are entered into the LSDB of each routing device.OSPF uses flooding to distribute LSAs between routing devices.

When LSAs result in changes to the routing device’s LSDB, the routingdevice forwards the changes to the adjacent neighbors (the DR and BDR)for distribution to the other neighbors.

OSPF routing updates occur only when changes occur, instead ofperiodically. For each new route, if an adjacency is interested in that route(for example, if configured to receive static routes and the new route isindeed static), an update message containing the new route is sent to theadjacency. For each route removed from the route table, if the route hasalready been sent to an adjacency, an update message containing the routeto withdraw is sent.

The Shortest Path First TreeThe routing devices use a link-state algorithm (Dijkstra’s algorithm)to calculate the shortest path to all known destinations, based on thecumulative cost required to reach the destination.

The cost of an individual interface in OSPF is an indication of the overheadrequired to send packets across it. The cost is inversely proportional to thebandwidth of the interface. A lower cost indicates a higher bandwidth.

Internal Versus External RoutingTo ensure effective processing of network traffic, every routing device onyour network needs to know how to send a packet (directly or indirectly) toany other location/destination in your network. This is referred to as internalrouting and can be done with static routes or using active internal routingprotocols, such as OSPF, RIP, or RIPv2.

It is also useful to tell routers outside your network (upstream providers orpeers) about the routes you have access to in your network. Sharing ofrouting information between autonomous systems is known as externalrouting.




.


Typically, an AS has one or more border routers (peer routers that exchangeroutes with other OSPF networks) as well as an internal routing systemenabling every router in that AS to reach every other router and destinationwithin that AS.

When a routing device advertises routes to boundary routers on otherautonomous systems, it is effectively committing to carry data to the IPspace represented in the route being advertised. For example, if the routingdevice advertises 192.204.4.0/24, it is declaring that if another router sendsdata destined for any address in the 192.204.4.0/24 range, it will carry thatdata to its destination.

OSPF ImplementationNortel Application Switch Operating System supports a single instance ofOSPF and up to 4 K routes on the network. The following sections describeOSPF implementation in Nortel Application Switch Operating System:

• "Configurable Parameters" (page 151)

• "Defining Areas" (page 152)

• "Interface Cost" (page 154)

• "Electing the Designated Router and Backup" (page 154)

• "Summarizing Routes" (page 155)

• "Default Routes" (page 155)

• "Virtual Links" (page 156)

• "Router ID" (page 157)

• "Authentication" (page 158) "Host Routes for Load Balancing" (page160)

Configurable Parameters

• In Nortel Application Switch Operating System, OSPF parameters canbe configured through the Command Line Interface (CLI)

The CLI supports the following parameters: interface output cost, interfacepriority, dead and hello intervals, retransmission interval, and interfacetransmit delay.

In addition to the above parameters, you can also specify the following:

• Shortest Path First (SPF) interval—Time interval between successivecalculations of the shortest path tree using the Dijkstra’s algorithm.

• Stub area metric—A stub area can be configured to send a numericmetric value such that all routes received via that stub area carry theconfigured metric to potentially influence routing decisions.




.


• Default routes—Default routes with weight metrics can be manuallyinjected into transit areas. This helps establish a preferred route whenmultiple routing devices exist between two areas. It also helps routetraffic to external networks.

Defining AreasIf you are configuring multiple areas in your OSPF domain, one of the areasmust be designated as area 0, known as the backbone. The backboneis the central OSPF area and is usually physically connected to all otherareas. The areas inject routing information into the backbone which, in turn,disseminates the information into other areas.

Since the backbone connects the areas in your network, it must be acontiguous area. If the backbone is partitioned (possibly as a result ofjoining separate OSPF networks), parts of the AS will be unreachable, andyou will need to configure virtual links to reconnect the partitioned areas(see "Virtual Links" (page 156)).

Up to three OSPF areas can be connected to the Nortel Application Switchwith Nortel Application Switch Operating System software. To configure anarea, the OSPF number must be defined and then attached to a networkinterface on the switch. The full process is explained in the followingsections.

An OSPF area is defined by assigning two pieces of information—an areaindex and an area ID. The command to define an OSPF area is as follows:

>> # /cfg/l3/ospf/aindex <area index> /areaid <n.n.n.n>

Note: The aindex option above is an arbitrary index used only on theswitch and does not represent the actual OSPF area number. The actualOSPF area number is defined in the areaid portion of the command asexplained in the following sections.

Assigning the Area IndexThe aindex <area index> option is actually just an arbitrary index (0-2)used only by the switch. This index does not necessarily represent theOSPF area number, though for configuration simplicity, it should wherepossible.

For example, both of the following sets of commands define OSPF area 0(the backbone) and area 1 because that information is held in the area IDportion of the command. However, the first set of commands is easier tomaintain because the arbitrary area indexes agree with the area IDs:

• Area index and area ID agree




.


/cfg/l3/ospf/aindex0/areaid 0.0.0.0

(Use index 0 to set area 0 in ID octetformat)



• Area index set to an arbitrary value





Using the Area ID to Assign the OSPF Area NumberThe OSPF area number is defined in the areaid <IP address> option.The octet format is used in order to be compatible with two different systemsof notation used by other OSPF network vendors. There are two valid waysto designate an area ID:

• Placing the area number in the last octet (0.0.0.n)

Most common OSPF vendors express the area ID number as a singlenumber. For example, the Cisco IOS-based router command "network1.1.1.0 0.0.0.255 area 1" defines the area number simply as"area 1." On the application switch, using the last octet in the area ID,"area 1" is equivalent to "areaid 0.0.0.1".

• Multi-octet (IP address)

Some OSPF vendors express the area ID number in multi-octet format.For example, "area 2.2.2.2" represents OSPF area 2 and canbe specified directly on the Nortel Application Switch as "areaid2.2.2.2".

Note: Although both types of area ID formats are supported, be surethat the area IDs are in the same format throughout an area.

Attaching an Area to a NetworkOnce an OSPF area has been defined, it must be associated with anetwork. To attach the area to a network, you must assign the OSPF areaindex to an IP interface that participates in the area. The format for thecommand is as follows:

>> # /cfg/l3/ospf/if <interface number> /aindex <area index>

For example, the following commands could be used to configure IPinterface 14 for a presence on the 10.10.10.1/24 network, to define OSPFarea 1, and to attach the area to the network:




.


>> # /cfg/l3/if 14 (Select menu for IP interface14)

>> IP Interface 14# addr 10.10.10.1 (Define IP address onbackbone network)

>> IP Interface 14# mask 255.255.255.0

(Define IP mask on backbone)


>> IP Interface 14# /cfg/l3/ospf/aindex 1

(Select menu for area index 1)

>> OSPF Area (index) 1 # areaid0.0.0.1

(Define area ID as OSPF area1)

>> OSPF Area (index) 1 # ena (Enable area index 1)

>> OSPF Area (index) 1 # /cfg/l3/ospf/if 14

(Select OSPF menu forinterface 14)

>> OSPF Interface 14# aindex 1 (Attach area to network oninterface 14)

>> OSPF Interface 14# enable (Enable interface 14 for areaindex 1)

Interface CostThe OSPF link-state algorithm (Dijkstra’s algorithm) places each routingdevice at the root of a tree and determines the cumulative cost required toreach each destination. Usually, the cost is inversely proportional to thebandwidth of the interface. Low cost indicates high bandwidth. You canmanually enter the cost for the output route with the following command:

>> # /cfg/l3/ospf/if <OSPF interface number> /cost <costvalue (1-65535)>

Electing the Designated Router and BackupIn any area with more than two routing devices, a Designated Router (DR)is elected as the central contact for database exchanges among neighbors,and a Backup Designated Router (BDR) is elected in case the DR fails.

DR and BDR elections are made through the hello process. The electioncan be influenced by assigning a priority value to the OSPF interfaces onthe Nortel Application Switch. The command is as follows:

>> # /cfg/l3/ospf/if <OSPF interface number> /prio <priorityvalue (0-255)>




.


A priority value of 255 is the highest, and 1 is the lowest. A priority value of0 specifies that the interface cannot be used as a DR or BDR. In case of atie, the routing device with the highest router ID wins.

Summarizing RoutesRoute summarization condenses routing information. Withoutsummarization, each routing device in an OSPF network would retain aroute to every subnet in the network. With summarization, routing devicescan reduce some sets of routes to a single advertisement, reducing both theload on the routing device and the perceived complexity of the network. Theimportance of route summarization increases with network size.

Summary routes can be defined for up to 16 IP address ranges using thefollowing command:

>> # /cfg/l3/ospf/range <range number> /addr <IP address>/mask <mask>

where <range number> is a number 1 to 16, <IP address> is thebase IP address for the range, and <mask> is the IP address mask for therange. For a detailed configuration example, see "Example 3: SummarizingRoutes" (page 173).

Default RoutesWhen an OSPF routing device encounters traffic for a destination address itdoes not recognize, it forwards that traffic along the default route. Typically,the default route leads upstream toward the backbone until it reaches theintended area or an external router.

Each Nortel Application Switch acting as an ABR automatically inserts adefault route into each attached area. In simple OSPF stub areas or NSSAswith only one ABR leading upstream (see Area 1 in "Injecting DefaultRoutes" (page 156)), any traffic for IP address destinations outside thearea is forwarded to the switch’s IP interface, and then into the connectedtransit area (usually the backbone). Since this is automatic, no furtherconfiguration is required for such areas.




.


Injecting Default Routes

In more complex OSPF areas with multiple ABRs or ASBRs (such asarea 0 and area 2 in "Injecting Default Routes" (page 156)), there aremultiple routes leading from the area. In such areas, traffic for unrecognizeddestinations cannot tell which route leads upstream without furtherconfiguration.

To resolve the situation and select one default route among multiple choicesin an area, you can manually configure a metric value on each ABR. Themetric assigns a priority to the ABR for its selection as the priority defaultroute in an area. The following command is used for setting the metric value:

>> # /cfg/l3/ospf/default <metric value> <metric type (1 or2)>

where <metric value> sets the priority for choosing this switch fordefault route. The value none sets no default and 1 sets the highest priorityfor default route. Metric type determines the method for influencing routingdecisions for external routes.

To clear a default route metric from the switch, use the following command:

>> # /cfg/l3/ospf/default none

Virtual LinksUsually, all areas in an OSPF AS are physically connected to the backbone.In some cases where this is not possible, you can use avirtual link. Virtuallinks are created to connect one area to the backbone through anothernon-backbone area (see "OSPF Area Types" (page 148)).




.


The area which contains a virtual link must be a transit area and have fullrouting information. Virtual links cannot be configured inside a stub areaor NSSA. The area type must be defined as transit using the followingcommand:

>> # /cfg/l3/ospf/aindex <area index> /type transit

The virtual link must be configured on the routing devices at each endpointof the virtual link, though they may traverse multiple routing devices. Toconfigure a Nortel Application Switch as one endpoint of a virtual link, usethe following command:

>> # /cfg/l3/ospf/virt <link number> /aindex <area index>/nbr <router ID>

where<link number> is a value between 1 and 3, <area index> is theOSPF area index of the transit area, and <router ID> is the IP address ofthe virtual neighbor (nbr), the routing device at the target endpoint. Anotherrouter ID is needed when configuring a virtual link in the other direction. Toprovide the Nortel Application Switch with a router ID, see the followingsection "Router ID" (page 157).

For a detailed configuration example on Virtual Links, see "Example 2:Virtual Links" (page 167).

Router IDRouting devices in OSPF areas are identified by a router ID. The router IDis expressed in IP address format. The IP address of the router ID is notrequired to be included in any IP interface range or in any OSPF area.

The router ID can be configured in one of the following two ways:

• Dynamically—OSPF protocol configures the lowest IP interface IPaddress as the router ID. This is the default.

• Statically—Use the following command to manually configure the routerID:

>> # /cfg/l3/rtrid <IP address>

• To modify the router ID from static to dynamic, set the router ID to0.0.0.0, save the configuration, and reboot the Nortel Application Switch.To view the router ID, enter:

>> # /info/l3/ospf/gen




.


AuthenticationOSPF protocol exchanges can be authenticated so that only trusted routingdevices can participate. This ensures less processing on routing devicesthat are not listening to OSPF packets.

OSPF allows packet authentication and uses IP multicast when sendingand receiving packets. Routers participate in routing domains basedon predefined passwords. Nortel Application Switch Operating Systemsupports simple password (type 1 plain text passwords) and MD5cryptographic authentication. This type of authentication allows a passwordto be configured per area.

"OSPF Authentication" (page 158) shows authentication configured for area0 with the password test. Simple authentication is also configured for thevirtual link between area 2 and area 0. Area 1 is not configured for OSPFauthentication.

OSPF Authentication

To configure simple plain text OSPF passwords on the Nortel ApplicationSwitches shown in "OSPF Authentication" (page 158) use the followingcommands:

Step Action

1 Enable OSPF authentication for Area 0 on Nortel ApplicationSwitches 1, 2, and 3.

>> # /cfg/l3/ospf/aindex 0/auth password

(Turn on OSPF passwordauthenti-cation)

2 Configure a simple text password up to eight characters foreach OSPF IP interface in Area 0 on Nortel Application Switches1, 2, and 3.




.


>> # /cfg/l3/ospf/if 1>> OSPF Interface 1 # key test>> OSPF Interface 1 # /cfg/l3/ospf/if 2>> OSPF Interface 2 # key test>> OSPF Interface 1 # /cfg/l3/ospf/if 3>> OSPF Interface 3 # key test

3 Enable OSPF authentication for Area 2 on Nortel ApplicationSwitch 4.

>> # /cfg/l3/ospf/aindex 2/auth password

(Turn on OSPF passwordauthenti-cation)

4 Configure a simple text password up to eight characters for thevirtual link between Area 2 and Area 0 on Nortel ApplicationSwitches 2 and 4.

>> # /cfg/l3/ospf/virt 1/key alteon

Use the following commands to configure MD5 authentication onthe Nortel Application Switches shown in "OSPF Authentication"(page 158):

—End—

Step Action

1 Enable OSPF MD5 authentication for Area 0 on NortelApplication Switches 1, 2, and 3.

>> # /cfg/l3/ospf/aindex 0/authmd5

(Turn on MD5authentication)

2 Configure MD5 key ID for Area 0 on Nortel Application Switches1, 2, and 3.

>> # /cfg/l3/ospf/md5key 1/key test

3 Assign MD5 key ID to OSPF interfaces on Nortel ApplicationSwitches 1, 2, and 3.




.


>> # /cfg/l3/ospf/if 1>> OSPF Interface 1 # mdkey 1>> OSPF Interface 1 # /cfg/l3/ospf/if 2>> OSPF Interface 2 # mdkey 1>> OSPF Interface 1 # /cfg/l3/ospf/if 3>> OSPF Interface 3 # mdkey 1

4 Enable OSPF MD5 authentication for Area 2 on NortelApplication Switch 4.

>> # /cfg/l3/ospf/aindex 2/auth md5

5 Configure MD5 key for the virtual link between Area 2 and Area0 on Nortel Application Switches 2 and 4.

>> # /cfg/l3/ospf/md5key 2/key alteon

6 Assign MD5 key ID to OSPF virtual link on Nortel ApplicationSwitches 2 and 4.

>> # /cfg/l3/ospf/virt 1/mdkey 2

—End—

Host Routes for Load BalancingNortel Application Switch Operating System implementation of OSPFincludeshost routes. Host routes are used for advertising network device IPaddresses to external networks, accomplishing the following goals:

• Server Load Balancing (SLB) within OSPF

Host routes advertise virtual server IP addresses to external networks.This allows standard SLB between the Nortel Application Switch and theserver pools in an OSPF environment. For more information on SLB,see "Server Load Balancing" (page 188) " and your Nortel ApplicationSwitch Operating System Command Reference.

• ABR Load Sharing

As a second form of load balancing, host routes can be used for dividingOSPF traffic among multiple ABRs. To accomplish this, each applicationswitch provides identical services but advertises a host route for adifferent virtual server IP address to the external network. If each virtualserver IP address serves a different and equal portion of the externalworld, incoming traffic from the upstream router should be split evenlyamong ABRs.




.


• ABR Failover

Complementing ABR load sharing, identical host routes can beconfigured on each ABR. These host routes can be given different costsso that a different ABR is selected as the preferred route for each virtualserver and the others are available as backups for failover purposes.

If redundant routes via multiple routing processes (such as OSPF, RIP,BGP, or static routes) exist on your network, the application switch defaultsto the OSPF-derived route.

For a configuration example, see "Example 4: Host Routes" (page 176).

Redistributing Routes into OSPFNortel Application Switch Operating System software allows your switch toemulate an ASBR by redistributing information from other routing protocols(static, RIP, iBGP, eBGP, and fixed routes) into OSPF. For information onASBR, see "Types of OSPF Routing Devices" (page 148). For example, youcan instruct OSPF to readvertise a RIP-derived route into OSPF as anAS-External LSA. Based on this LSA, other routers in the OSPF routingdomain installs an OSPF route.

Use the following command to redistribute a protocol into OSPF:

/cfg/l3/ospf/redist <protocol name>

where the protocol name is static, RIP, iBGP, eBGP, or fixed.

By default, these protocol routes are not redistributed into OSPF.

Use one of the following three methods to redistribute the routes of aparticular protocol into OSPF:

• Exporting all the routes of the protocol

• Using route maps

Route maps allow you to control the redistribution of routes betweenrouting domains. For conceptual information on route maps, see "Whatis a Route Map?" (page 133).

• Exporting all routes of the protocol except a few selected routes

Each of these methods is discussed in detail in the following sections.

Exporting All RoutesTo redistribute all routes of a protocol, use the following command:

/cfg/l3/ospf/redist <protocol name> /export <metric> <metrictype>




.


where metric sets the OSPF cost for the route and metric type (either 1 or 2)determines whether the route’s cost includes or excludes external costs ofthe route. If you want to remove a previous configuration to export all theroutes of a protocol, then use the parameter "none" to the export command.

/cfg/l3/ospf/redist <protocol name> /export none

Using Route Maps to Export Selected RoutesUse route maps to specify which routes of the protocol that you wantexported into OSPF. "Commands for Using Route MapsRoute Maps" (page162) shows the tasks that you can perform using route maps.

Route Maps

Task Command

Adding a route map for aparticular protocol

/cfg/l3/ospf/redist <protocol name>/add <route map numbers>

Adding all 32 route maps /cfg/l3/ospf/redist <protocol name>/add all

Removing a route map for aparticular protocol

/cfg/l3/ospf/redist <protocol name>/rem <route map numbers>

Removing all 32 route mapsfor a particular protocol

/cfg/l3/ospf/redist <protocol name>/rem all

OSPF does not require you to set all the fields in the route map menu.However, set the following parameters in the route maps and network filtermenu:

Step Action

1 Enable the route map.

/cfg/l3/rmap <route map number> /ena

2 Assign the metric value in the AS-External LSA.

/cfg/l3/rmap <route map number> /metric <metric value>

If a route map is added to a protocol for redistribution, and if theroutes of that protocol match any of the routes in the access lists,and if action is set to permit, then those routes are redistributed intoOSPF using the metric and metric type assigned for that route map.Metric sets the priority for choosing this switch for default route.




.


3 Enable the access list.

/cfg/l3/rmap <route map number> /alist <access listnumber> /ena

4 Set the action to permit for the access list.

/cfg/l3/rmap <route map number> /alist <access listnumber> /action permit

To redistribute routes matched by the route map, the action in thealist must be set to permit. If the action is set to deny the routesmatched by the route map is not be redistributed.

5 Link a network filter to the access list.

/cfg/l3/rmap <route map number> /alist <access listnumber> /nwf <network filter number>

6 Enable the network filter.

/cfg/l3/nwf <network filter number> /ena

7 Specify the IP address and mask for the network filter.

/cfg/l3/nwf 1/addr <IP address> /mask <IP mask>

—End—

Optional Parameters for Route MapsSet the following optional parameters (metric type and metric) for routeredistribution into OSPF:

Step Action

1 Assign the metric type in the AS-External LSA.

/cfg/l3/rmap <route map number> /type [1|2]

Metric type determines the method for influencing routing decisionsfor external routes.

2 Match the metric of the protocol route.




.


/cfg/l3/rmap <l> /alist <access list number> /metric<metric value>

Metric value sets the priority for choosing this switch for the route.The value none sets no default and 1 sets the highest priority forthe route.

—End—

Exporting All Routes Except a Few Selected RoutesThis method is a combination of the previous two methods. The basic stepsto configure this method are outlined below:

Step Action

1 Configure OSPF to export all routes of the protocol using theexport command as described in the first method ( "ExportingAll Routes" (page 161) ).

2 Use route maps to configure routes to be denied by setting theaction in the access list of the route map to deny.

The configuration of the route map is similar to that described in thesecond method except that the action is set to deny.

—End—

OSPF Features Not Supported in This ReleaseThe following OSPF features are not supported in this release:

• Summarizing external routes

• Filtering OSPF routes

• Using OSPF to forward multicast routes

• Configuring OSPF on non-broadcast multi-access networks (such asframe relay, X.25, and ATM)

OSPF Configuration ExamplesA summary of the basic steps for configuring OSPF on the Nortel ApplicationSwitch is listed here. Detailed instructions for each of the steps is covered inthe following sections:




.


Step Action

1 Configure IP interfaces.

One IP interface is required for each desired network (range ofIP addresses) being assigned to an OSPF area on the NortelApplication Switch.

2 (Optional) Configure the router ID.

The router ID is required only when configuring virtual links on theNortel Application Switch.

3 Enable OSPF on the switch.

4 Define the OSPF areas.

5 Configure OSPF interface parameters.

IP interfaces are used for attaching networks to the various areas.

6 (Optional) Configure route summarization between OSPF areas.

7 (Optional) Configure virtual links.

8 (Optional) Configure host routes.

—End—

Example 1: Simple OSPF DomainIn this example, two OSPF areas are defined—one area is the backboneand the other is a stub area. A stub area does not allow advertisements ofexternal routes, thus reducing the size of the database. Instead, a defaultsummary route of IP address 0.0.0.0 is automatically inserted into thestub area. Any traffic for IP address destinations outside the stub area isforwarded to the stub area’s IP interface, and then into the backbone.

A Simple OSPF Domain




.


Follow this procedure to configure OSPF support as shown in "A SimpleOSPF Domain" (page 165):

Step Action

1 Configure IP interfaces on each network that is attached toOSPF areas.

In this example, two IP interfaces are needed: one for the backbonenetwork on 10.10.7.0/24 and one for the stub area network on10.10.12.0/24.

>> # /cfg/l3/if 1 (Select menu for IPinterface 1)

>> IP Interface 1 # addr10.10.7.1

(Set IP address onbackbone network)

>> IP Interface 1 # mask255.255.255.0

(Set IP mask on backbonenetwork)

>> IP Interface 1 # enable (Enable IP interface 1)

>> IP Interface 1 # /cfg/l3/if2

(Select menu for IPinterface 2)


(Set IP address on stubarea network)


(Set IP mask on stub areanetwork)


2 Enable OSPF.

>> IP Interface 2 # /cfg/l3/ospf/on

(Enable OSPF on the NortelApplication Switch)

3 Define the backbone.

The backbone is always configured as a transit area using areaid0.0.0.0.

>> Open Shortest Path First #aindex 0

(Select menu for area index0)


(Set the ID for backbonearea 0)

>> OSPF Area (index) 0 # typetransit

(Define backbone as transittype)

>> OSPF Area (index) 0 # enable (Enable the area)




.


4 Define the stub area.

>> OSPF Area (index) 0 # /cfg/l3/ospf/aindex 1(Selectmenu for area index 1)


(Set the area ID for OSPFarea 1)

>> OSPF Area (index) 1 # typestub

(Define area as stub type)


5 Attach the network interface to the backbone.

>> OSPF Area 1 # /cfg/l3/ospf/if 1

(Select OSPF menu for IPinterface 1)

>> OSPF Interface 1 # aindex 0 (Attach network tobackbone index)

>> OSPF Interface 1 # enable (Enable the backboneinterface)

6 Attach the network interface to the stub area.

>> OSPF Interface 1 #/cfg/l3/ospf/if 2


>> OSPF Interface 2 # aindex 1 (Attach network to stubarea index)

>> OSPF Interface 2 # enable (Enable the stub areainterface)

7 Apply and save the configuration changes.

>> OSPF Interface 2 # apply (Global command to applyall changes)

>> OSPF Interface 2 # save (Global command to saveall changes)

—End—

Example 2: Virtual LinksIn the example shown in "Configuring a Virtual Link" (page 168), area 2 isnot physically connected to the backbone as is usually required. Instead,area 2 is connected to the backbone through a virtual link through area 1.The virtual link must be configured at each endpoint.




.


Configuring a Virtual Link

Configuring OSPF for a Virtual Link on Switch 1

Step Action

1 Configure IP interfaces on each network that is attached to theswitch.

In this example, two IP interfaces are needed on Switch #1: one forthe backbone network on 10.10.7.0/24 and one for the transit areanetwork on 10.10.12.0/24.










(Set IP address on transitarea network)


(Set IP mask on transit areanetwork)

>> IP Interface 2 # enable (Enable interface 2)

2 Configure the router ID.

A router ID is required when configuring virtual links. Later, whenconfiguring the other end of the virtual link on Nortel ApplicationSwitch 2, the router ID specified here is used as the target virtualneighbor (nbr) address.

>> IP Interface 2 # /cfg/l3/rtrid 10.10.10.1

(Set static router ID onNortel Application Switch 1)




.


3 Enable OSPF.

>> IP # /cfg/l3/ospf/on (Enable OSPF on NortelApplication Switch 1)





(Set the area ID forbackbone area 0)




5 Define the transit area.

The area that contains the virtual link must be configured as a transitarea.





(Define area as transit type)



>> OSPF Area (index) 1 #/cfg/l3/ospf/if 1




7 Attach the network interface to the transit area.




.




>> OSPF Interface 2 # aindex 1 (Attach network to transitarea index)

>> OSPF Interface 2 # enable (Enable the transit areainterface)

8 Configure the virtual link.

The nbr router ID configured in this step must be the same as therouter ID that is configured for Switch #2 in step 2.

>> OSPF Interface 2 #/cfg/l3/ospf/virt 1

(Specify a virtual linknumber)

>> OSPF Virtual Link 1 # aindex1

(Specify the transit area forthe virtual link)

>> OSPF Virtual Link 1 # nbr10.10.14.1

(Specify the router ID of therecipient)

>> OSPF Virtual Link 1 # enable (Enable the virtual link)




—End—

Configuring OSPF for a Virtual Link on Switch 2

Step Action

1 Configure IP interfaces on each network that is attached toOSPF areas.

Two IP interfaces are needed on Switch #2: one for the transitarea network on 10.10.12.0/24 and one for the stub area networkon 10.10.24.0/24.




.




(Set IP address on transitarea network)


(Set IP mask on transit areanetwork)









2 Configure the router ID.

A router ID is required when configuring virtual links. This router IDshould be the same one specified as the target virtual neighbor (nbr)on Nortel Application Switch 1 in Step 8.

>> IP Interface 2 # /cfg/l3/rtrid 10.10.14.1

(Set static router ID on NortelApplication Switch 2)

3 Enable OSPF.

>> IP# /cfg/l3/ospf/on (Enable OSPF on NortelApplication Switch 2)


This version of Nortel Application Switch Operating System requiresthat a backbone index be configured on the non-backbone end ofthe virtual link as follows:


(Select the menu for areaindex 0)




5 Define the transit area.




.






(Define area as transit type)












>> OSPF Interface 1 # aindex 1 (Attach network to transitarea index)

>> OSPF Interface 1 # enable (Enable the transit areainterface)

8 Attach the network interface to the transit area.





9 Configure the virtual link.

The nbr router ID configured in this step must be the same as therouter ID that was configured for Nortel Application Switch #1 inStep 2.




.


>> OSPF Interface 2 #/cfg/l3/ospf/virt 1

(Specify a virtual linknumber)

>> OSPF Virtual Link 1 # aindex1

(Specify the transit area forthe virtual link)

>> OSPF Virtual Link 1 # nbr10.10.10.1

(Specify the router ID of therecipient)

>> OSPF Virtual Link 1 # enable (Enable the virtual link)




—End—

Other Virtual Link Options

• You can use redundant paths by configuring multiple virtual links.

• Only the endpoints of the virtual link are configured. The virtual link pathmay traverse multiple routers in an area as long as there is a routablepath between the endpoints.

Example 3: Summarizing RoutesBy default, ABRs advertise all the network addresses from one areainto another area. Route summarization can be used for consolidatingadvertised addresses and reducing the perceived complexity of the network.

If the network IP addresses in an area are assigned to a contiguous subnetrange, you can configure the ABR to advertise a single summary route thatincludes all the individual IP addresses within the area.

The following example shows one summary route from area 1 (stub area)injected into area 0 (the backbone). The summary route consists of all IPaddresses from 36.128.192.0 through 36.128.254.255 except for the routesin the range 36.128.200.0 through 36.128.200.255.




.


Summarizing Routes

Note: You can specify a range of addresses to prevent advertising byusing the hide option. In this example, routes in the range 36.128.200.0through 36.128.200.255 are kept private.

Follow this procedure to configure OSPF support as shown in "SummarizingRoutes" (page 174):

Step Action

1 Configure IP interfaces for each network which is attached toOSPF areas.






>> IP Interface 1 # ena (Enable IP interface 1)








2 Enable OSPF.


(Enable OSPF on the NortelApplication Switch)




.


















>> OSPF Area (index) 1 # /cfg/l3/ospf/if 1(Select OSPFmenu for IP interface 1)








7 Configure route summarization by specifying the startingaddress and mask of the range of addresses to be summarized




.


>> OSPF Interface 2 #/cfg/l3/ospf/range 1

(Select menu for summaryrange)

>> OSPF Summary Range 1 # addr36.128.192.0

(Set base IP address ofsummary range)

>> OSPF Summary Range 1 # mask255.255.192.0

(Set mask address forsummary range)

>> OSPF Summary Range 1 #aindex 0

(Inject summary route intobackbone)

>> OSPF Summary Range 1 #enable

(Enable summary range)

8 Use the hide command to prevent a range of addresses fromadvertising to the backbone.

>> OSPF Interface 2 #/cfg/l3/ospf/range 2

(Select menu for summaryrange)

>> OSPF Summary Range 2 # addr36.128.200.0

(Set base IP address)

>> OSPF Summary Range 2 # mask255.255.255.0

(Set mask address)

>> OSPF Summary Range 2 # hideenable

(Hide the range ofaddresses)


>> OSPF Summary Range 2 # apply (Global command to applyall changes)

>> OSPF Summary Range 2 # save (Global command to saveall changes)

—End—

Example 4: Host RoutesThe Nortel Application Switch Operating System implementation of OSPFincludes host routes. Host routes are used for advertising network device IPaddresses to external networks and allows for Server Load Balancing (SLB)within OSPF. It also makes ABR load sharing and failover possible.

Consider the example network in "Configuring OSPF Host Routes" (page177). Both Nortel Application Switches have access to servers with identicalcontent and are configured with the same virtual server IP addresses:10.10.10.1 and 10.10.10.2. Nortel Application Switch #1 is given a host




.


route with a low cost for virtual server 10.10.10.1 and another host routewith a high cost for virtual server 10.10.10.2. Nortel Application Switch #2is configured with the same hosts but with the costs reversed; one hostroute has a high cost for virtual server 10.10.10.1 and another has a lowcost for virtual server 10.10.10.2.

All four host routes are injected into the upstream router and advertisedexternally. Traffic comes in for both virtual server IP addresses (10.10.10.1and 10.10.10.2). The upstream router sees that both addresses exist onboth Nortel Application Switches and uses the host route with the lowestcost for each. Traffic for 10.10.10.1 goes to Nortel Application Switch #1because its host route has the lowest cost for that address. Traffic for10.10.10.2 goes to Nortel Application Switch #2 because its host route hasthe lowest cost. This effectively shares the load among ABRs. Both NortelApplication Switches then use standard server load balancing to distributetraffic among available real servers.

In addition, if one of the Nortel Application Switches were to fail, theupstream routing device would forward the traffic to the ABR whose hostroute has the next lowest cost. In this example, the remaining NortelApplication Switch would assume the entire load for both virtual servers.

Configuring OSPF Host Routes

Configuring Host Routes on Nortel Application Switch 1

Step Action

1 Configure IP interfaces for each network that is attached toOSPF areas.




.


>> Virtual server 1 #/cfg/l3/if 1










2 Configure basic SLB parameters.

Nortel Application Switch 1 is connected to two real servers. Eachreal server is given an IP address and is placed in the same realserver group.

>> # /cfg/slb/real 1 (Select menu for real server1)

>> Real server 1 # rip100.100.100.25

(Set the IP address for realserver 1)

>> Real server 1 # ena (Enable the real server)

>> Real server 1 # /cfg/slb/real 2

(Select menu for real server2)

>> Real server 2 # rip100.100.100.26

(Set the IP address for realserver 2)

>> Real server 2 # ena (Enable the real server)

>> Real server 2 # /cfg/slb/group 1

(Select menu for real servergroup 1)

>> Real server group 1 # add 1 (Add real server 1 to group)

>> Real server group 1 # add 2 (Add real server 2 to group)

>> Real server group 1 # enable (Enable the group)

>> Real server group 1 #/cfg/slb/on

(Turn SLB on)

3 Configure client and server processing on specific ports.

>> Layer 4# /cfg/slb/port 4 (Select switch port 4)

>> SLB Port 4 # client ena (Enable client processingon Port 4)




.


>> SLB Port 4 # /cfg/slb/port 5 (Select switch Port 5)

>> SLB Port 5 # server ena (Enable server processingon Port 5)

4 Enable direct access mode.

>> Layer 4 Port 5# /cfg/slb/adv (Select the SLB advancemenu)

>> Layer 4 Advanced# direct ena (Enable DAM)

>> Layer 4 Advanced# .. (Return to the SLB menu)

5 Configure the primary virtual server.

Nortel Application Switch # 1 is preferred for virtual server10.10.10.1.

>> Layer 4 # /cfg/slb/virt 1 (Select menu for virtualserver 1)

>> Virtual server 1 # vip10.10.10.1

(Set the IP address forvirtual server 1)

>> Virtual server 1 # ena (Enable the virtual server)

>> Virtual server 1 # servicehttp

(Select menu for service onvirtual server)

>> Virtual server 1 httpservice # group 1

(Use real server group 1 forhttp service)

6 Configure the backup virtual server.

Nortel Application Switch # 1 acts as a backup for virtual server10.10.10.2. Both virtual servers in this example are configured withthe same real server group and provide identical services.

>> Virtual server 2 http service # /cfg/slb/virt2(Select menu for virtual server 2)



>> Virtual server 1 # ena (Enable the virtualserver)



>> Virtual server 1 # group 1 (Use real server group 1 forhttp service)




.


7 Enable OSPF on Nortel Application Switch 1.

>> IP Interface 2 # /cfg/l3/ospf/ospf/on

(Enable OSPF on NortelApplication Switch 1)












(Set the ID for stub area 1)










>> OSPF Interface 1 # /cfg/l3/ospf/if 2







.


12 Configure host routes.

One host route is needed for each virtual server on Nortel ApplicationSwitch 1. Since virtual server 10.10.10.1 is preferred for NortelApplication Switch 1, its host route has a low cost. Because virtualserver 10.10.10.2 is used as a backup in case Nortel ApplicationSwitch 2 fails, its host route has a high cost.

Note: You do not need to enable redistribution(/cfg/l3/ospf/redist) if you configure virtual server routesas host routes.

>> OSPF Interface 2 #/cfg/l3/ospf/host 1

(Select menu for host route1)

>> OSPF Host Entry 1 # addr10.10.10.1

(Set IP address same asvirtual server 1)

>> OSPF Host Entry 1 # aindex 0 (Inject host route intobackbone area)

>> OSPF Host Entry 1 # cost 1 (Set low cost for preferredpath)

>> OSPF Host Entry 1 # enable (Enable the host route)

>> OSPF Host Entry 1 #/cfg/l3/ospf/host 2





>> OSPF Host Entry 2 # cost 100 (Set high cost for use asbackup path)


Note: When a service goes down, the corresponding host routeis removed from advertising.


>> OSPF Host Entry 2 # apply (Global command to applyall changes)

>> OSPF Host Entry 2 # save (Global command to saveall changes)

—End—




.


Configuring Host Routes on Nortel Application Switch 2

Step Action

1 Configure basic SLB parameters.

Nortel Application Switch 2 is connected to two real servers. Eachreal server is given an IP address and is placed in the same realserver group.

>> # /cfg/slb/real 1 (Select menu for realserver 1)

>> Real server 1 # rip100.100.100.27

(Set the IP address forreal server 1)

>> Real server 1 # enable (Enable the real server)

>> Real server 1 # /cfg/slb/real2

(Select menu for realserver 2)

>> Real server 2 # rip100.100.100.28

(Set the IP address forreal server 2)

>> Real server 2 # enable (Enable the real server)


(Select menu for realserver group 1)

>> Real server group 1 # add 1 (Add real server 1 togroup)

>> Real server group 1 # add 2 (Add real server 2 togroup)

>> Real server group 1 # enable (Enable the group)

>> Real server group 1 #/cfg/slb/on

(Turn SLB on)

2 Configure the virtual server parameters.

The same virtual servers are configured as on Nortel ApplicationSwitch 1.

>> Layer 4 # /cfg/slb/virt 1 (Select menu for virtualserver 1)



>> Virtual server 1 # enable (Enable the virtual server)






.


>> Virtual server 1 httpservice # group 1

(Use real server group 1 forhttp service)

>> Virtual server 2 http service # /cfg/slb/virt 2(Select menu for virtual server 2)



>> Virtual server 1 # enable (Enable the virtual server)


(Select menu forservice on virtualserver)

>> Virtual server 1 # group 1 (Use real server group 1 forhttp service)

3 Configure IP interfaces for each network that will be attachedto OSPF areas.

>> Virtual server 1 # /cfg/l3/if1

(Select menu for IPInterface 1)




>> IP Interface 1 # /cfg/l3/if 2 (Select menu for IPInterface 2)




4 Enable OSPF on Nortel Application Switch #2.


(Enable OSPF on NortelApplication Switch #2)



(Select menu for areaindex 0)




(Define backbone astransit type)





.





(Set the ID for stub area 1)










>> OSPF Interface 1 # /cfg/l3/ospf/if 2




9 Configure host routes.

Host routes are configured just like those on Nortel ApplicationSwitch 1, except their costs are reversed. Since virtual server10.10.10.2 is preferred for Nortel Application Switch 2, its host routehas been given a low cost. Because virtual server 10.10.10.1 isused as a backup in case Nortel Application Switch 1 fails, its hostroute has been given a high cost.

>> OSPF Interface 2 #/cfg/l3/ospf/host 1








.


>> OSPF Host Entry 1 # cost 100 (Set high cost for use asbackup path)


>> OSPF Host Entry 1 #/cfg/l3/ospf/host 2





>> OSPF Host Entry 2 # cost 1 (Set low cost for primarypath)



>> OSPF Host Entry 2 # apply (Global command to applyall changes)

>> OSPF Host Entry 2 # save (Global command to saveall changes)

—End—

Verifying OSPF ConfigurationUse the following commands to verify the OSPF configuration on yourswitch:

• /info/l3/ospf/general

• /info/l3/ospf/nbr

• /info/l3/ospf/dbase/dbsum

• /info/l3/ospf/route

• /stats/l3/route

Refer to the Nortel Application Switch Operating System CommandReference for information on the above commands.




.





.

187

Part 3: Application SwitchingFundamentals

Internet traffic consists of myriad services and applications which use theInternet Protocol (IP) for data delivery. IP, however, is not optimized for allthe various applications. Application switching goes beyond IP and makesintelligent switching decisions based on the application and its data. Thissections details the following fundamental switching features:

• "Server Load Balancing" (page 188)

• "Load Balancing Special Services" (page 254)

• " WAN Link Load Balancing" (page 327)

• "Filtering" (page 364)

• "Application Redirection" (page 409)

• "Health Checking" (page 463)

• "High Availability" (page 508)




.

188 Part 3: Application Switching Fundamentals

Server Load Balancing

Server Load Balancing (SLB) allows you to configure the Nortel ApplicationSwitch to balance user session traffic among a pool of available serversthat provide shared services.


• "Understanding Server Load Balancing" (page 188). This sectiondiscusses the benefits of server load balancing and its operation.

• "Implementing Basic Server Load Balancing" (page 191). This sectiondiscusses how implementing SLB provides reliability, performance, andease of maintenance on the network.

• "Content Intelligent Server Load Balancing" (page 210). This sectiondiscusses the implementation of content-based SLB.

• "Extending SLB Topologies" (page 227). This section discusses proxyIP addresses, mapping real to virtual ports, monitoring real server ports,and delayed binding.

• "Session Timeout Per Service" (page 245). This section discusses theconfiguration of the session timeout per service feature.

• "IPv6 and Server Load Balancing" (page 246). This section discussesthe configuration and management of server load balancing and IPv6.

For additional information on SLB commands, Nortel Application SwitchOperating System Command Reference.

Understanding Server Load BalancingSLB benefits your network in a number of ways:

• Increased efficiency for server utilization and network bandwidth

With SLB, your Nortel Application Switch is aware of the shared servicesprovided by your server pool and can then balance user session trafficamong the available servers. Important session traffic gets throughmore easily, reducing user competition for connections on overutilizedservers. For even greater control, traffic is distributed according to avariety of user-selectable rules.

• Increased reliability of services to users

If any server in a server pool fails, the remaining servers continue toprovide access to vital applications and data. The failed server can bebrought back up without interrupting access to services.

• Increased scalability of services




.

Server Load Balancing 189

As users are added and the server pool’s capabilities are saturated, newservers can be added to the pool transparently.

Identifying Your Network NeedsSLB may be the right option for addressing these vital network concerns:

• A single server no longer meets the demand for its particular application.

• The connection from your LAN to your server overloads the server’scapacity.

• When servers hold critical application data and must remain availableeven in the event of a server failure.

• Your Web site is being used as a way to do business and for takingorders from customers. It must not become overloaded or unavailable.

• You want to use multiple servers or hot-standby servers for maximumserver uptime.

• You must be able to scale your applications to meet client and LANrequest capacity.

• You can’t afford to continue using an inferior load-balancing technique,such as DNS round robin or a software-only system.

How Server Load Balancing WorksIn an average network that employs multiple servers without server loadbalancing, each server usually specializes in providing one or two uniqueservices. If one of these servers provides access to applications or datathat is in high demand, it can become overutilized. Placing this kind ofstrain on a server can decrease the performance of the entire network asuser requests are rejected by the server and then resubmitted by the userstations. Ironically, over-utilization of key servers often happens in networkswhere other servers are actually available.

The solution to getting the most from your servers is SLB. With this softwarefeature, the switch is aware of the services provided by each server. Theswitch can direct user session traffic to an appropriate server, based on avariety of load-balancing algorithms.




.


Traditional Versus SLB Network Configurations

To provide load balancing for any particular type of service, each server inthe pool must have access to identical content, either directly (duplicatedon each server) or through a back-end network (mounting the same filesystem or database server).

The Nortel Application Switch, with SLB software, acts as a front-end to theservers, interpreting user session requests and distributing them among theavailable servers. Load balancing in Nortel Application Switch OperatingSystem can be done in the following ways:

• Virtual server-based load balancing

This is the traditional load balancing method. The switch is configured toact as a virtual server and is given a virtual server IP address (or rangeof addresses) for each collection of services it distributes. Depending onyour switch model, there can be as many as 1023 virtual servers on theswitch, each distributing up to eight different services.

Each virtual server is assigned a list of the IP addresses (or rangeof addresses) of the real servers in the pool where its servicesreside. When the user stations request connections to a service, theycommunicate with a virtual server on the switch. When the switchreceives the request, it binds the session to the IP address of the bestavailable real server and remaps the fields in each frame from virtualaddresses to real addresses.

HTTP, IP, FTP, RTSP, IDS, and static session WAP are examples ofsome of the services that use virtual servers for load balancing.

• Filtered-based load balancing

A filter allows you to control the types of traffic permitted through theswitch. Filters are configured to allow, deny, or redirect traffic according




.


to the IP address, protocol, or Layer 4 port criteria. In filtered-based loadbalancing, a filter is used to redirect traffic to a real server group. If thegroup is configured with more than one real server entry, redirectedtraffic is load balanced among the available real servers in the group.

Firewalls, WAP with RADIUS snooping, IDS, and WAN links useredirection filters to load balance traffic.

• Content-based load balancing

Content-based load balancing uses Layer 7 application data (such asURL, cookies, and Host Headers) to make intelligent load balancingdecisions.

URL-based load balancing, browser-smart load balancing, andcookie-based preferential load balancing are a few examples ofcontent-based load balancing.

Implementing Basic Server Load BalancingConsider a situation where customer Web sites are being hosted by apopular Web hosting company and/or Internet Service Provider (ISP).The Web content is relatively static and is kept on a single NFS serverfor easy administration. As the customer base increases, the number ofsimultaneous Web connection requests also increases.

Web Hosting Configuration Without SLB

Such a company has three primary needs:

• Increased server availability

• Server performance scalable to match new customer demands

• Easy administration of network and servers




.


Web Hosting with SLB Solutions

All the issues can be addressed by adding an Nortel Application Switchwith SLB software.

• Reliability is increased by providing multiple paths from the clientsto the Nortel Application Switch and by accessing a pool of serverswith identical content. If one server fails, the others can take up theadditional load.

• Performance is improved by balancing the Web request load acrossmultiple servers. More servers can be added at any time to increaseprocessing power.

• For ease of maintenance, servers can be added or removed dynamically,without interrupting shared services.

Network Topology RequirementsWhen deploying SLB, there are a few key aspects to consider:

• In standard SLB, all client requests to a virtual server IP address andall responses from the real servers must pass through the switch, asshown in "SLB Client/Server Traffic Routing" (page 193). If there is apath between the client and the real servers that does not pass throughthe switch, the Nortel Application Switch can be configured to proxyrequests in order to guarantee that responses use the correct path (see"Proxy IP Addresses" (page 228)).




.


SLB Client/Server Traffic Routing

• Identical content must be available to each server in the same pool.Either of these methods can be used:

— Static applications and data are duplicated on each real server inthe pool.

— Each real server in the pool has access to the same data throughuse of a shared file system or back-end database server.

• Some services require that a series of client requests go to the samereal server so that session-specific state data can be retained betweenconnections. Services of this nature include Web search results,multi-page forms that the user fills in, or custom Web-based applicationstypically created using cgi-bin scripts. Connections for these types ofservices must be configured as persistent (see "Persistence" (page588) ") or must use the minmisses, hash, phash metrics (see "Metricsfor Real Server Groups" (page 202)).

• Clients and servers can be connected through the same switch port.Each port in use on the switch can be configured to process clientrequests, server traffic, or both. You can enable or disable processingon a port independently for each type of Layer 4 traffic.

— Layer 4 client processing: Ports that are configured to process clientrequest traffic provide address translation from the virtual serverIP to the real server IP address.

— Layer 4 server processing: Ports that are configured to processserver responses to client requests provide address translation fromthe real server IP address to the virtual server IP address. These




.


ports require real servers to be connected to the Nortel ApplicationSwitch directly or through a hub, router, or another switch.

Note: Switch ports configured for Layer 4 client/server processingcan simultaneously provide Layer 2 switching and IP routingfunctions.

Consider the following network topology:

Example Network for Client/Server Port Configuration

In "Example Network for Client/Server Port Configuration" (page 194),the switch load balances traffic to a Web server pool and to a DomainName System (DNS) server pool. The switch port connected to theWeb server pool (port 11) is asked to perform both server and clientprocessing.

Configuring Server Load BalancingThis section describes the steps for configuring an SLB Web hostingsolution. In the following procedure, many of the SLB options are left totheir default values. See "Additional Server Load Balancing Options" (page199) for more options. Before you start configuring, you must be connectedto the switch CLI as the administrator.

Note: For details about any of the menu commands described in thisexample, refer Nortel Application Switch Operating System CommandReference.

Step Action

1 Assign an IP address to each of the real servers in the serverpool.




.


The real servers in any given real server group must have an IProute to the switch that performs the SLB functions. This IP routingis most easily accomplished by placing the switches and servers onthe same IP subnet, although advanced routing techniques can beused as long as they do not violate the topology rules outlined in"Network Topology Requirements" (page 192).

For this example, the three hosts (real servers) have been given thefollowing IP addresses on the same IP subnet:

Web Host Example: Real Server IP Addresses

Real Server IP address

Server A 200.200.200.2

Server B 200.200.200.3

Server C 200.200.200.4

Note: An imask option can be used to define a range of IPaddresses for real and virtual servers (see "IP Address RangesUsing imask" (page 201)).

2 Define an IP interface on the switch.

The switch must have an IP route to all of the real servers thatreceive switching services. For SLB, the switch uses this path todetermine the level of TCP/IP reach of the real servers.

To configure an IP interface for this example, enter these commandsfrom the CLI:





Note: The IP interface and the real servers must belong tothe same VLAN, if they are in the same subnet. This exampleassumes that all ports and IP interfaces use default VLAN 1,requiring no special VLAN configuration for the ports or IPinterface.

3 Define each real server.

For each real server, you must assign a real server number, specifyits actual IP address, and enable the real server. For example:




.


>> IP Interface 1#/cfg/slb/real 1

(Server A is real server 1)

>> Real server 1# rip200.200.200.2

(Assign Server A IP address)

>> Real server 1# ena (Enable real server 1)

>> Real server 1#/cfg/slb/real 2

(Server B is real server 2)

>> Real server 2# rip200.200.200.3

(Assign Server B IP address)



(Server C is real server 3)

>> Real server 3# rip200.200.200.4

(Assign Server C IP address)


4 Define a real server group and add the three real servers tothe service group.

>> Real server 3#/cfg/slb/group 1

(Select real server group 1)

>> Real server group 1# add1

(Add real server 1 to group 1)





5 Define a virtual server.

All client requests is addressed to a virtual server IP address on avirtual server defined on the switch. Clients acquire the virtual serverIP address through normal DNS resolution. In this example, HTTP isconfigured as the only service running on this virtual server, and thisservice is associated with the real server group. For example:

>> Real server group 1#/cfg/slb/virt 1

(Select virtual server 1)

>> Virtual server 1# vip200.200.200.1

(Assign a virtual server IPaddress)

>> Virtual server 1# ena (Enable the virtual server)




.


>> Virtual server 1# servicehttp

(Select the HTTP servicemenu)

>> Virtual server 1 httpService# group 1

(Associate virtual port toreal group)

Note: This configuration is not limited to HTTP Web service.Other TCP/IP services can be configured in a similar fashion. Fora list of other well-known services and ports, see "Well-KnownApplication Ports" (page 199). To configure multiple services,see "Configuring Multiple Services" (page 202).

6 Define the port settings.

In this example, the following ports are being used on the NortelApplication Switch:

Web Host Example: Port Usage

Port Host L4 Processing

1 Server A serves SLB requests. Server

2 Server B serves SLB requests. Server

3 Server C serves SLB requests. Server

4 Back-end NFS server provides centralizedcontent for all three real servers. This portdoes not require switching features.

None

5 Client router A connects the switch to theInternet where client requests originate.

Client

6 Client router B connects the switch to theInternet where client requests originate.

Client

The ports are configured as follows:

>> Virtual server 1#/cfg/slb/port 1

(Select physical switch port 1)

>> SLB port 1# server ena (Enable server processing onport 1)

>> SLB port 1# /cfg/slb/port2









.




>> SLB port 5# client ena (Enable client processing onport 5)





>> SLB port 6# /cfg/slb (Select the SLB Menu)

>> Layer 4# on (Turn Server Load Balancing on)

>> Layer 4# apply (Make your changes active)

>> Layer 4# cur (View current settings)



>> Layer 4# save (Save for restore after reboot)

Note: You must apply any changes in order for them to takeeffect, and you must save changes if you wish them to remain ineffect after switch reboot.

9 Check the SLB information.

>> Layer 4# /info/slb/dump (View SLB information)

Check that all SLB parameters are working according to expectation.If necessary, make any appropriate configuration changes and thencheck the information again.

—End—




.


Additional Server Load Balancing OptionsIn the previous section ("Configuring Server Load Balancing" (page 194)),many of the SLB options are left to their default values. The followingconfiguration options can be used to customize SLB on your NortelApplication Switch:

• "Supported Services and Applications" (page 199)

• "Disabling and Enabling Real Servers" (page 200)

• "IP Address Ranges Using imask" (page 201)

• "Health Checks for Real Servers" (page 201)

• "Configuring Multiple Services" (page 202)

• "Metrics for Real Server Groups" (page 202)

• "Weights for Real Servers" (page 206)

• "Connection Time-outs for Real Servers" (page 207)

• "Maximum Connections for Real Servers" (page 207)

• "Backup/Overflow Servers" (page 208)

• "Connection Pooling" (page 210)

Supported Services and ApplicationsEach virtual server can be configured to support up to eight services,limited to a total of 1023 services per switch. Using the /cfg/slb/virt<virtual server number> /service option, the following TCP/UDPapplications can be specified:

Note: The service number specified on the switch must match theservice specified on the server.

Well-Known Application Ports

Number TCP/UDPApplication



20 ftp-data 79 finger 179 bgp

21 ftp 80 http 194 irc

22 ssh 109 pop2 389 ldap

23 telnet 110 pop3 443 https

25 smtp 119 nntp 520 rip

37 time 123 ntp 554 rtsp

42 name 143 imap 1812 RADIUS

43 whois 144 news 1813 Radius Radius Accounting




.





53 domain 161 snmp 1985 hsrp

69 tftp 162 snmptrap

Note: Load balancing some applications (such as FTP and RTSP)require special configuration. See "Load Balancing Special Services"(page 254) for more information.

Disabling and Enabling Real ServersIf you need to reboot a server, make sure that new sessions are not sent tothe real server and that current sessions are not discarded before shuttingdown the server.

• Use the following command with the n (none) option to suspendconnection assignments to the real server:

>> # /oper/slb/dis <real server number> n

When the current session count on your server falls to zero, you canshut down your server.

• If you have configured persistence on the real server, use the followingcommand with the p (persistent) option to suspend connectionassignments (except for persistent http 1.0 sessions) to the real server:

>> # /oper/slb/dis <real server number> p

When the current session count on your server falls to zero and whenpersistent sessions for the real server have aged out (refer to thepersistence parameters you have set for this real server), you can shutdown your server. For more information (see "Persistence" (page 588) ").

• When maintenance is complete, use the following command to enablethe real server:

>> # /oper/slb/ena <real server number>

The switch resumes assignment of connections to this real serverimmediately.

• Following table is the behavior comparison of >> # /oper/slb/disand >> # /cfg/slb/dis.




.


Behavior >> # /oper/slb/dis >> # /cfg/slb/dis

Clearing all oldsessions immediatelyafter executingcommand

No Yes

Allowing persistentHTTP 1.0 sessions

Yes/No NA

The grace option is enabled only if the real server is in "failed" state andnot in "disabled" state (failed by health check).For example, consider HTTP service when grace option is enabled.After handling client requests for some time the real server is markedfailed by health check, but the remaining sessions to the real server arestill kept to maintain previous connections from client to the real server.

IP Address Ranges Using imaskThe imask option lets you define a range of IP addresses for the real andvirtual servers configured under SLB. By default, the imask setting is255.255.255.255, which means that each real and virtual server representsa single IP address. An imask setting of 255.255.255.0 would mean thateach real and virtual server represents 256 IP addresses. Consider thefollowing example:

• A virtual server is configured with an IP address of 172.16.10.1.

• Real servers 172.16.20.1 and 172.16.30.1 are assigned to service thevirtual server.

• The imask is set to 255.255.255.0.

If the client request was sent to virtual server IP address 172.16.10.45,the unmasked portion of the address (0.0.0.45) gets mapped directly towhichever real server IP address is selected by the SLB algorithm. Thus,the request would be sent to either 172.16.20.45 or 172.16.30.45.

Health Checks for Real ServersDetermining health for each real server is a necessary function for SLB.By default for TCP services, the switch checks health by opening a TCPconnection to each service port configured as part of each service. Formore information, see "Configuring Multiple Services" (page 202). For UDPservices, the switch pings servers to determine their status.

The switch checks each service on each real server every two seconds. Ifthe real server is busy processing connections, it may not respond to ahealth check. By default, if a service does not respond to four consecutivehealth checks, the switch declares the service unavailable. As shown below,the health check interval and the number of retries can be changed:




.


>> # /cfg/slb/real <realserver number>

(Select the real server)

>> Real server# inter 4 (Check real server every 4 seconds)

>> Real server# retry 6 (Declare down after 6 checks fail)

For more complex health-checking strategies, see "Health Checking" (page463)."

Configuring Multiple ServicesWhen you configure multiple services in the same group, their health checksare dependent on each other. If a real server fails a health check for aservice, then the status of the real server for the second service appearsas "blocked."

Independent Services. If you are configuring two independent servicessuch as FTP and SMTP—where the real server failure on one service doesnot affect other services that the real server supports, then configure twogroups with the same real servers, but with different services. If a realserver configured for both FTP and SMTP fails FTP, the real server is stillavailable for SMTP. This allows the services to act independently eventhough they are using the same real servers.

Dependent Services. If you are configuring two dependent services suchas HTTP and HTTPS—where the real server failure on one service blocksthe real server for other services, then configure a single group with multipleservices. If a real server configured for both HTTP and HTTPS fails forthe HTTP service, then the server is blocked from supporting any HTTPSrequests. The switch blocks HTTPS requests, (even though HTTPS hasnot failed) until the HTTP service becomes available again. This helps introubleshooting so you know which service has failed.

Metrics for Real Server GroupsMetrics are used for selecting which real server in a group receives the nextclient connection. The available metrics minmisses (minimum misses),hash, phash (persistent hash), leastconns (least connections), roundrobin,bandwidth, and response (response time) are explained in detail below. Thedefault metric is leastconns.

To change a real server group metric to minmisses, for example, enter:

>> # /cfg/slb/group <group number> (Select the real server group)

>> Real server group# metricminmisses

(Use minmisses metric)




.


Minimum MissesThe minmisses metric is optimized for application redirection. It uses IPaddress information in the client request to select a server. When selectinga server, the switch calculates a value for each available real server basedon the relevant IP address information. The server with highest value isassigned the connection. This metric attempts to minimize the disruption ofpersistency when servers are removed from service. This metric should beused only when persistence is a must.

By default the minmiss algorithm uses the upper 24-bits of the source IPaddress to calculate the real server that the traffic should be sent to whenthe minmiss metric is selected. The Nortel Application Switch OperatingSystem allows the selection of all 32-bits of the source IP address to hashto the real server.

The source or destination IP address information used depends on theapplication:

• For application redirection, the client destination IP address is used.All requests for a specific IP destination address is sent to the sameserver. This metric is particularly useful in caching applications, helpingto maximize successful cache hits. Best statistical load balancing isachieved when the IP address destinations of load-balanced frames arespread across a broad range of IP subnets.

• For SLB, the client source IP address and real server IP address areused. All requests from a specific client are sent to the same server.This metric is useful for applications where client information must beretained on the server between sessions. With this metric, server loadbecomes most evenly balanced as the number of active clients withdifferent source or destination addresses increases.

To select all 32-bits of the source IP address, use the command,/cfg/slb/group x/mhash 32. This 32-bit hash is most useful inthe wireless world.

The minmisses metric cannot be used for firewall load balancing, sincethe real server IP addresses used in calculating the score for this metric aredifferent on each side of the firewall.

HashThe hash metric uses IP address information in the client request toselect a server. The specific IP address information used depends on theapplication:

• For Application Redirection, the client destination IP address is used. Allrequests for a specific IP destination address is sent to the same server.This is particularly useful for maximizing successful cache hits.




.


• For SLB, the client source IP address is used. All requests froma specific client is sent to the same server. This option is usefulfor applications where client information must be retained betweensessions.

• For FWLB, both the source and destination IP addresses are used toensure that the two unidirectional flows of a given session are redirectedto the same firewall.

When selecting a server, a mathematical hash of the relevant IP addressinformation is used as an index into the list of currently available servers.Any given IP address information will always have the same hash result,providing natural persistence, as long as the server list is stable. However,if a server is added to or leaves the set, then a different server might beassigned to a subsequent session with the same IP address informationeven though the original server is still available. Open connections arenot cleared. The phash metric can be used to maintain stable serverassignment. For more information, see "Persistent Hash" (page 204).

Note: The hash metric provides more distributed load balancing thanminmisses at any given instant. It should be used if the statistical loadbalancing achieved using minmisses is not as optimal as desired. Ifthe load balancing statistics with minmisses indicate that one server isprocessing significantly more requests over time than other servers,consider using the hash metric.

Persistent Hash The phash metric provides the best features of hash andminmisses metrics together. This metric provides stable server assignmentslike the minmiss metric and even load distribution like the hash metric.

When you select the phash metric for a group, a baseline hash is assumedbased on the configured real servers that are enabled for the group. If theserver selected from this baseline hash is unavailable, then the old hashmetric is used to find an available server.

If all the servers are available, then phash operates exactly like hash. Whena configured server becomes unavailable, then clients bound to operationalservers will continue to be bound to the same servers for future sessionsand clients bound to unavailable servers are rehashed to an operationalserver using the old hash metric.

With phash however, when more servers go down, then you will not have aneven load distribution as you would with the standard hash metric.




.


Tunable Hash By default, the hash metric has used the client’s sourceIP address as the parameter for directing a client request to a real server.In environments where multiple users are sharing the same proxy, andthus the same source IP address, a load balancing hash on the source IPaddress would direct all users to the same real server.

Tunable hash allows the user to select the parameters (source IP, or sourceIP and source port) that are used when hashing is chosen as the loadbalancing metric.

Least ConnectionsWith the leastconns metric, the number of connections currently openon each real server is measured in real time. The server with the fewestcurrent connections is considered to be the best choice for the next clientconnection request.

This option is the most self-regulating, with the fastest servers typicallygetting the most connections over time.

Round RobinWith the roundrobin metric, new connections are issued to each server inturn; that is, the first real server in the group gets the first connection, thesecond real server gets the next connection, followed by the third real server,and so on. When all the real servers in this group have received at least oneconnection, the issuing process starts over with the first real server.

Response TimeThe response metric uses real server response time to assign sessions toservers. The response time between the servers and the switch is used asthe weighting factor. The switch monitors and records the amount of time ittakes for each real server to reply to a health check to adjust the real serverweights. The weights are adjusted so they are inversely proportional to amoving average of response time. In such a scenario, a server with half theresponse time as another server receives a weight twice as large.

Note: The effects of the response weighting apply directly to the realservers and are not necessarily confined to the real server group. Whenresponse time-metered real servers are also used in other real servergroups that use the leastconns or roundrobin metrics, the responseweights are applied on top of the leastconns or roundrobin calculationsfor the affected real servers. Since the response weight changesdynamically, this can produce fluctuations in traffic distribution for thereal server groups that use the leastconns or roundrobin metrics.




.


BandwidthThe bandwidth metric uses real server octet counts to assign sessions to aserver. The switch monitors the number of octets sent between the serverand the switch. Then, the real server weights are adjusted so they areinversely proportional to the number of octets that the real server processesduring the last interval.

Servers that process more octets are considered to have less availablebandwidth than servers that have processed fewer octets. For example, theserver that processes half the amount of octets over the last interval receivestwice the weight of the other servers. The higher the bandwidth used,the smaller the weight assigned to the server. Based on this weighting,the subsequent requests go to the server with the highest amount of freebandwidth. These weights are automatically assigned.

The bandwidth metric requires identical servers with identical connections.

Note: The effects of the bandwidth weighting apply directly to the realservers and are not necessarily confined to the real server group. Whenbandwidth-metered real servers are also used in other real servergroups that use the leastconns or roundrobin metrics, the bandwidthweights are applied on top of the leastconns or roundrobin calculationsfor the affected real servers. Since the bandwidth weight changesdynamically, this can produce fluctuations in traffic distribution for thereal server groups that use the leastconns or roundrobin metrics.

Weights for Real ServersWeights can be assigned to each real server. These weights can bias loadbalancing to give the fastest real servers a larger share of connections.Weight is specified as a number from 1 to 48. Each increment increases thenumber of connections the real server gets. By default, each real server isgiven a weight setting of 1. A setting of 10 would assign the server roughly10 times the number of connections as a server with a weight of 1. To setweights, enter the following commands:

>> # /cfg/slb/real <real servernumber>


>> Real server# weight 10 (10 times the number ofconnections)

Readjusting server weights based on SNMP health checkresponse Nortel Application Switch Operating System can be configuredto dynamically change weights of real servers based on a health checkresponse using the Simple Network Management Protocol (SNMP). Toenable dynamic assignment of weights based on the response to an SNMPhealth check, enter the following commands:




.


>> # /cfg/slb/adv/snmphc < SNMP health script number>

>> SNMP Health Check 1# weight e (Enable weighting via SNMPhealth check)

For more information on configuring SNMP health checks, see "SNMPHealth Check" (page 483).

Connection Time-outs for Real ServersIn some cases, open TCP/IP sessions might not be closed properly (forexample, the switch receives the SYN for the session, but no FIN is sent).If a session is inactive for 10 minutes (the default), it is removed fromthe session table in the switch. To change the time-out period, enter thefollowing:



>> Real server# tmout 4 (Specify an even numbered interval)

The example above would change the time-out period of all connections onthe designated real server to four minutes.

Maximum Connections for Real ServersYou can set the number of open connections each real server is allowed tohandle for SLB. To set the connection limit, enter the following:



>> Real server# maxcon 1600 (Allow 1600 connections maximum)

Values average from approximately 500 HTTP connections for slowerservers to 1500 for quicker, multiprocessor servers. The appropriate valuealso depends on the duration of each session and how much CPU capacityis occupied by processing each session. Connections that use a lot of Javaor CGI scripts for forms or searches require more server resources and thusa lower maxcon limit. You may wish to use a performance benchmark toolto determine how many connections your real servers can handle.

When a server reaches its maxcon limit, the switch no longer sends newconnections to the server. When the server drops back below the maxconlimit, new sessions are again allowed.




.


Unlimited Connections to Real ServersThis feature allows an unlimited number of connections to be allocatedto traffic accessing a real server. The CLI specifies a range of 0 to 200Kconnections per real server. A maxcon value of 0 allows the specified realserver to handle up to its maximum number of connections, or the switch’smaximum of 4 Million connections.

Step Action

1 To configure unlimited connections, set the real server maxconvalue to zero.

>> # Main# /cfg/slb/real <x> /maxconCurrent max connections: 200000Max connections 0 means unlimited connectionsEnter new max connections [0-200000]: 0Current max connections: 200000Pending max connections: 0


>> # apply>> # save

—End—

Backup/Overflow ServersA real server can backup other real servers and can handle overflow trafficwhen the maximum connection limit is reached. Each backup real servermust be assigned a real server number and real server IP address. It mustthen be enabled. Finally, the backup server must be assigned to eachreal server that it will back up. The following defines real server 4 as abackup/overflow for real servers 1 and 2:

>> # /cfg/slb/real 4 (Select real server 4 as backup)

>> Real server 4# rip 200.200.200.5 (Assign backup IP address)


>> Real server 4# /cfg/slb/real 1 (Select real server 1)

>> Real server 1# backup 4 (Real server 4 is backup for 1)



>> Real server 2# overflow enabled (Overflow enabled)




.


In a similar fashion, a backup/overflow server can be assigned to a realserver group. If all real servers in a real server group fail or overflow, thebackup comes online.

>> # /cfg/slb/group <real servergroup number>

(Select real server group)

>> Real server group# backup r4 (Assign real server 4 asbackup)

Real server groups can also use another real server group forbackup/overflow:



>> Real server group# backup g2 (Assign real server group 2 asbackup)

Backup Only ServerUnlike a Backup/Overflow server, a Backup Only server is used to backupreal servers only and not provide an overflow capability. This providesfor the enforcement of maximum session capacity while still providingresiliency. In this configuration, if the primary server reaches its maximumsession capacity, the backup server does not take over sessions from theprimary server. The backup server only comes into play if the primaryserver fails. The following defines real server 4 as a backup only server forreal servers 1 and 2

>> # /cfg/slb/real 4 (Select real server 4 as backup)

>> Real server 4# rip 200.200.200.5 (Assign backup IP address)






In a similar fashion, a backup/overflow server can be assigned to a realserver group. If all real servers in a real server group fail the backup comesonline.



>> Real server group# backup r4 (Assign real server 4 asbackup)




.


Real server groups can also use another real server group for backup:



>> Real server group# backup g2 (Assign real server group 2 asbackup)

Connection PoolingThe Nortel Application Switch Operating System supports connectionpooling to the Nortel Application Switch. This feature multiplexes client andserver connections and improves the throughput of server load balancing.It also helps the real server lower the needs of establishing and tearingdown TCP connections.

In a connection pooled environment, a pool of server connections inmaintained for servicing client connections. When a client requests aconnection, an unused connection is selected from the server pool andused to service the request. When the client request is complete, the serverconnection is returned to the pool and the client connection dropped.

This feature only supports the HTTP and HTTPS protocols over TCP withdelayed binding enabled.

The following example enable s connection pooling for the HTTP protocolon virtual server 1:

>> Main# /cfg/slb/virt 1/service http/http/pooling enabled

The following example enables connection pooling for the HTTPS protocolon virtual server 1:

>> Main# /cfg/slb/virt 1/service https/http/pooling enabled

Connection pooling statistics can be displayed by issuing the followingcommand:

>> Main# /stats/slb/layer7/pooling

Content Intelligent Server Load BalancingNortel Application Switch Operating System allows you to load balanceHTTP requests based on different HTTP header information, such as"Cookie:" header for persistent load balancing, "Host:" header for virtualhosting, or "User-Agent" for browser-smart load balancing.




.


Note: When Layer 7 load balancing is configured, a Nortel ApplicationSwitch does not support IP fragments. If IP fragments were supportedin this mode, the switch would have to buffer, re-assemble, and inspectpackets before making a forwarding decision.

• "URL-Based Server Load Balancing" (page 211)

• "Virtual Hosting" (page 216)

• "Cookie-Based Preferential Load Balancing" (page 219)

• "URL Hashing for Server Load Balancing" (page 223)

• "Header Hash Load Balancing" (page 225)

URL-Based Server Load BalancingURL-based SLB allows you to optimize resource access and serverperformance. Content dispersion can be optimized by makingload-balancing decisions on the entire path and filename of each URL.

Note: Both HTTP 1.0 and HTTP 1.1 requests are supported.

For URL matching you can configure up to 1024 strings comprised of 40bytes each. Each URL request is then examined against the URL stringsdefined for each real server. URL requests are load balanced amongmultiple servers matching the URL, according to the load balancing metricconfigured for the real server group (leastConns is the default).

In "URL-Based Server Load Balancing" (page 212), the following criteria arespecified for content load balancing:

• Requests with ".cgi" in the URL are forwarded to real servers 3 and 4.

• Requests with the string "images" in the URL are sent to real servers1 and 2.

• Requests with URLs starting with "/product:" are sent to real servers2, 3, and 5.

Requests containing URLs with anything else are sent to real servers 1, 2,3, and 4. These servers have been defined with the "any" string.




.


URL-Based Server Load Balancing

Configuring URL-Based Server Load BalancingTo configure URL-based SLB, perform the following steps:

Step Action

1 Before you can configure SLB string-based load balancing,ensure that the switch has already been configured for basicSLB with the following tasks:

Note: When URL-based SLB is used in an active/activeredundant setup, use a proxy IP address instead of DirectAccess Mode (DAM) to enable the URL parsing feature.


• Define an IP interface on the switch.


• Define a real server group and set up health checks for the group.

• Define a virtual server on virtual port 80 (HTTP), and assign thereal server group to service it.

• Enable SLB on the switch.

• Enable client processing on the port connected to the clients.

For information on how to configure your network for SLB, see"Server Load Balancing" (page 188).




.


2 Define the string(s) to be used for URL load balancing.

>> # /cfg/slb/layer7/slb/addstr|remstr <l7lkup|pattern>

• addstr: Add string or a pattern.

• remstr: Remove string or a pattern.

A default string any indicates that the particular server can handle allURL or cache requests. Refer to the following examples given below:

Example 1: String with the Forward Slash (/)

A string that starts with a forward slash ( / ), such as "/images,"indicates that the server processes requests that start out with the"/images" string only.

For example, with the "/images" string, the server handles theserequests:

/images/product/b.gif/images/company/a.gif/images/testing/c.jpg

The server does not handle these requests:

/company/images/b.gif/product/images/c.gif/testing/images/a.gif

Example 2: String without the Forward Slash (/)

A string that does not start out with a forward slash ( / ) indicatesthat the server will process any requests that contain the definedstring. For example, with the "images" string, the server will processthese requests:

/images/product/b.gif/images/company/a.gif/images/testing/c.jpg/company/images/b.gif/product/images/c.gif/testing/images/a.gif

Example 3: String with the Forward Slash (/) Only




.


If a server is configured with the load balance string ( / ) only, it willonly handle requests to the root directory. For example, the serverhandles any files in the root directory:

//index.htm/default.asp/index.shtm

3 Apply and save your configuration changes.

4 Identify the defined string IDs.

>> # /cfg/slb/layer7/slb/cur

For easy configuration and identification, each defined string isassigned an ID number, as shown in the following example:

ID SLB String

1 any

2 .gif

3 /sales

4 /xitami

5 /manual

6 .jpg

5 Configure one or more real servers to support URL-based loadbalancing.

6 Add the defined string(s) to the real server using the followingcommand:

>> # /cfg/slb/real 2/layer7/addlb <ID>

where

ID is the identification number of the defined string.

Note: If you don’t add a defined string (or add the defined stringany) the server will handle any request.

A server can have multiple defined strings. For example:

• "/images"

• "/sales"




.


• ".gif"

With these defined strings, this particular server can handle requeststhat start with "/images" or "/sales" and any requests that contain".gif".

7 Enable SLB on the switch.

>> # /cfg/slb/on (Turn SLB on)

8 Enable DAM on the switch or configure proxy IP addresses andenable proxy on the client port.

DAM and proxy IPs allow you to perform port mapping for URL loadbalancing.

• Enable DAM

>> # /cfg/slb/adv/direct ena

• Configure a proxy IP address and enable proxy on the client port

>> # /cfg/slb/direct dis>> # /cfg/slb/pip>> Proxy IP Address# add 12.12.12.12

>> Proxy IP Address# typeport

(Use port-based proxy IP)

>> # /cfg/slb/port 2/proxyena

(Enable proxy on clientport)

For more information on proxy IP addresses, see "Proxy IPAddresses" (page 228).

9 Enable URL-based SLB on the virtual server(s).

>> # /cfg/slb/virt <virtual server number> /service80/httpslb urlslb

—End—

Statistics for URL-Based Server Load BalancingTo show the number of hits to the SLB or cache server, use this command:

>> # /stats/slb/layer7/str




.


Sample Statistics:

ID SLB String Hits

1 any 73881

2 .gif 0

3 /sales 0

4 /xitami 162102

5 /manual 0

6 .jpg 0

Virtual HostingNortel Application Switch Operating System allows individuals andcompanies to have a presence on the Internet in the form of a dedicatedWeb site address. For example, you can have a "www.site-a.com"and "www.site-b.com" instead of "www.hostsite.com/site-a" and"www.hostsite.com/site-b."

Service providers, on the other hand, do not want to deplete the pool ofunique IP addresses by dedicating an individual IP address for each homepage they host. By supporting an extension in HTTP 1.1 to include thehost header, Nortel Application Switch Operating System enables serviceproviders to create a single virtual server IP address to host multiple Websites per customer, each with their own host name.

Note: For SLB, one HTTP header is supported per virtual server.

The following list provides more detail on virtual hosting with configurationinformation.

• An HTTP/1.0 request sent to an origin server (not a proxy server) is apartial URL instead of a full URL.

An example of the request that the origin server would see as follows:

GET /products/2424/ HTTP/1.0User-agent: Mozilla/3.0Accept: text/html, image/gif, image/jpeg

The GET request does not include the host name. From the TCP/IPheaders, the origin server knows the requests host name, port number,and protocol.

• With the extension to HTTP/1.1 to include the HTTPHOST: header, the above request to retrieve the URL "www.nortelnetworks.com/products/2424" would look like this:

GET /products/2424/ HTTP/1.1Host: www.nortelnetworks.comUser-agent: Mozilla/3.0




.

http://www.nortel.com/


Accept: text/html, image/gif, image/jpeg

The Host: header carries the hostname used to generate the IP addressof the site.

• Based on the Host: header, the switch forwards the request to serversrepresenting different customers’ Web sites.

• The network administrator needs to define a domain name as part ofthe 128 supported URL strings.

• The switch performs string matching; that is, the string"nortelnetworks.com" or "http://www.nortel.com/" will match"http://www.nortel.com/".

Virtual Hosting Configuration OverviewThe sequence of events for configuring virtual hosting based on HTTP Host:headers is described below:

Step Action

1 The network administrator defines a domain name as part ofthe 128 supported URL strings.

Both domain names "www.company-a.com" and "www.company-b.com" resolve to the same IP address. In this example, the IPaddress is for a virtual server on the switch.

2 "www.company-a.com" and "www.company-b.com" are definedas URL strings.

3 Server Group 1 is configured with Servers 1 through 8.

Servers 1 through 4 belong to "www.company-a.com" and Servers 5through 8 belong to "www.company-b.com."

4 The network administrator assigns string "www.company-a.com" to Servers 1 through 4 and string "www.company-b.com"to Servers 5 through 8.

5 The application switch inspects the HTTP host header inrequests received from the client.

• If the host header is "www.company-a.com," the switch directsrequests to one of the Servers 1 through 4.

• If the host header is "www.company-b.com," the switch directsrequests to one of the Servers 5 through 8.

—End—




.




Configuring the Host Header for Virtual HostingTo support virtual hosting, configure the switch for Host header-based loadbalancing with the following procedure:

Step Action

1 Before you can configure host header-based server loadbalancing, ensure that the switch has already been configuredfor basic SLB:




• Assign servers to real server groups.

• Define virtual servers and services.

For information on how to configure your network for server loadbalancing, see "Server Load Balancing" (page 188).

2 Turn on URL parsing for the virtual server for virtual hosting.

>> # /cfg/slb/virt 1 (Select the virtual IP forhost header-based SLB)

>> Virtual Server 1 # service80

(Select the HTTP service)

>> Virtual Server 1 http Service # httpslb host

3 Define the host names.

>> # /cfg/slb/layer7/slb/addstr "www.customer1.com">> Server Loadbalance Resource# addstr "www.customer2.com">> Server Loadbalance Resource# addstr "www.customer3.com"

4 Configure the real server(s) to handle the appropriate loadbalancing string(s).

To add a defined string:

>> # /cfg/slb/real 2 (Select the real server)

>> Real Server 2 # Layer7

>> Real Server 2 Layer 7Commands # addlb

<ID>(Specify the string ID)




.


where


Note: If you don’t add a defined string (or add the defined stringany), the server will handle any request.

—End—

Cookie-Based Preferential Load BalancingCookies can be used to provide preferential services for customers,ensuring that certain users are offered better access to resources than otherusers when site resources are scarce. For example, a Web server couldauthenticate a user via a password and then set cookies to identify them as"Gold," "Silver," or "Bronze" customers. Using cookies, you can distinguishindividuals or groups of users and place them into groups or communitiesthat get redirected to better resources and receive better services thanall other users.

Note: Cookie-based persistent load balancing is described in"Persistence" (page 588) "Persistence" (page 588)."

Cookie-based preferential services enable the following support:

• Redirect higher priority users to a larger server or server group.

• Identify a user group and redirect them to a particular server.

• Serve content based on user identity.

• Prioritize access to scarce resources on a Web site.

• Provide better services to repeat customers, based on access count.

Clients that receive preferential service can be distinguished from otherusers by one of the following methods:

• Individual User

Specific individual user could be distinguished by IP address, loginauthentication, or permanent HTTP cookie.

• User Communities

Some set of users, such as "Premium Users" for service providers whopay higher membership fees than "Normal Users" could be identified bysource address range, login authentication, or permanent HTTP cookie.

• Applications




.


Users could be identified by the specific application they are using. Forexample, priority can be given to HTTPS traffic that is performing creditcard transactions versus HTTP browsing traffic.

• Content

Users could be identified by the specific content they are accessing.

Based on one or more of the criteria above, you can load balance requeststo different server groups.

Configuring Cookie-Based Preferential Load BalancingTo configure cookie-based preferential load balancing, perform the followingprocedure.

Step Action

1 Before you can configure header-based load balancing, ensurethat the switch has already been configured for basic SLB withthe following tasks:







2 Turn on URL parsing for the virtual server.

>> # /cfg/slb/virt 1>> Virtual Server 1 # service 80>> Virtual Server 1 http Service # httpslb cookieEnter Cookie Name: sidEnter the starting point of the Cookie value [1-64]:1Enter the number of bytes to extract [1-64]: 6Look for Cookie in URI [e|d]: d

where

sid = cookie name1 = offset (the starting position of the value to be used for hashing)6 = length (the number of bytes in the cookie value)




.


d = looks for the cookie in the cookie header instead of the URI(disables searching for cookie in the URI)

3 Define the cookie values.

>> # /cfg/slb/layer7/slb/addstr "Gold">> # addstr "Silver">> # addstr "Bronze"

Since a session cookie does not exist in the first request of an HTTPsession, a default server or any server is needed to assign cookiesto a None cookie HTTP request.

Example:

• Real Server 1: Gold handles gold requests.

• Real Server 2: Silver handles silver request.

• Real Server 3: Bronze handles bronze request.

• Real Server 4: any handles any request that does not have acookie or matching cookie.

With servers defined to handle the requests listed above, here iswhat happens:

• Request 1 comes in with no cookie; it is forwarded to Real Server4 to get cookie assigned.

• Request 2 comes in with "Gold" cookie; it is forwarded to RealServer 1.

• Request 3 comes in with "Silver" cookie; it is forwarded to RealServer 2.

• Request 4 comes in with "Bronze" cookie; it is forwarded to RealServer 3.

• Request 5 comes in with "Titanium" cookie; it is forwarded toReal Server 4, since it does not have an exact cookie match(matches with "any" configured at Real Server 4).

4 Configure the real server(s) to handle the appropriate loadbalance string(s).



where





.



5 Enable DAM on the switch or configure proxy IP addresses andenable proxy on the client port.

To use cookie-based preferential load balancing without DAM, youmust configure proxy IP addresses.

Enable proxy load balancing on the port used for cookie-basedpreferential load balancing. If Virtual Matrix Architecture (VMA) isenabled on the switch, you can choose to configure the remainingports with proxy disabled.

—End—

Browser-Smart Load BalancingHTTP requests can be directed to different servers based on browser typeby inspecting the "User-Agent" header. For example,

GET /products/2424/ HTTP/1.0User-agent: Mozilla/3.0Accept: text/html, image/gif, image/jpeg

To allow the switch to perform browser-smart load balancing, perform thefollowing procedure.

Step Action

1 Before you can configure browser-based load balancing,ensure that the switch has already been configured for basicSLB with the following tasks:






2 Turn on URL parsing for the virtual server for "User-Agent:"header.

>> # /cfg/slb/virt 1/service 80/httpslb browser




.



>> # /cfg/slb/layer7/slb/addstr "Mozilla">> Server Loadbalance Resource# addstr "InternetExplorer">> Server Loadbalance Resource# addstr "Netscape"

4 Configure the real server(s) to handle the appropriate loadbalancing string(s).


Use the following command to add a defined string:


where


—End—

URL Hashing for Server Load BalancingBy default, hashing algorithms use the IP source address and/or IPdestination address (depending on the application area) to determinecontent location. The default hashing algorithm for SLB is the IP sourceaddress. By enabling URL hashing, requests going to the same page of anorigin server are redirected to the same real server or cache server.

Load Balancing Nontransparent CachesYou can deploy a cluster of non-transparent caches and use the virtualserver to load balance requests to the cache servers. The client’s browseris configured to send Web requests to a nontransparent cache (the IPaddress of the configured virtual server).

If hash is selected as the load-balancing algorithm, the switch hashesthe source IP address to select the server for SLB. Under this condition,the switch may not send requests for the same origin server to the sameproxy cache server. For example, requests made from a client to "http://www.nortelnetworks.com/products"from different clients may get sentto different caches.




.

http://www.nortelnetworks.com/products

http://www.nortelnetworks.com/products


Using URL hashing to Load Balance Nontransparent Caches

Configuring URL HashingYou can direct the same URL request to the same cache or proxy serverby using a virtual server IP address to load balance proxy requests. Byconfiguring hash or minmisses as the metric, the switch uses the number ofbytes in the URI to calculate the hash key.

If the host field exists and the switch is configured to look into the Host:header, the switch uses the Host: header field to calculate the hash key.

To configure URL hashing, perform the following procedure:

Step Action

1 Before you can configure URL hashing, ensure that the switchhas already been configured for basic SLB with the followingtasks:






• Configure load-balancing algorithm for hash or minmiss.

• Enable SLB.

For information on how to configure your network for SLB, see"Server Load Balancing" (page 188)."

• Define server port and client port.

2 Enable URL hashing.




.


>> # /cfg/slb/virt 1>> Virtual Server 1 # service 80>> Virtual Server 1 http Service # httpslb urlhashEnter new hash length [1-255]: 25

Hashing is based on the URL, including the HTTP Host: header (ifpresent), up to a maximum of 255 bytes.

3 Set the metric for the real server group to minmisses or hash.

>> # /cfg/slb/group 1/metric <hash|minmisses>

—End—

Header Hash Load BalancingNortel Application Switch Operating System allows you to hash on anyselected HTTP header. To configure the application switch for loadbalancing based on header hash, perform the following procedure:

Step Action

1 Ensure that the switch has already been configured for basicSLB:






2 Enable header hashing.

>> # /cfg/slb/virt 1>> Virtual Server 1 # service 80>> Virtual Server 1 http Service # httpslb headerhashSelect Operation: noneEnter new HTTP header name: User-agentEnter new hash length [1-255]: 25

3 Set the metric for the real server group to minmisses or hash.

>> # /cfg/slb/group 1/metric <hash|minmisses>




.


—End—

Inserting the X-Forwarded-For Header in HTTP RequestsNortel Application Switch Operating System can insert the inclusion of the"X-Forwarded-For" header in client HTTP requests, in order to preserveclient IP information. This feature is useful in proxy mode, where the clientsource IP information is replaced with the proxy IP address. However, itmay also be used for all Layer 4, load balancing in both proxy and non-proxymode, if there is a need to include the "X-Forwarded-For" header. Thisfeature is not supported at Layer 7.

To configure the application switch to insert the "X-Forwarded-For" header,perform the following procedure:

Step Action

1 Ensure that the switch has already been configured for basicSLB:






2 Enable client proxy operation mode on the real servers usedin load balancing.

>> # /cfg/slb/real 1/proxy ena

3 On the virtual server attached to the real servers, enable theX-Forwarded-For header.

>> # /cfg/slb/virt 1/service 80/xforward ena


>> # apply>> # save

—End—




.


Extending SLB TopologiesFor standard SLB, all client-to-server requests to a particular virtual serverand all related server-to-client responses must pass through the sameNortel Application Switch. In complex network topologies, routers and otherdevices can create alternate paths around the Nortel Application Switchmanaging SLB functions (see "SLB Client/Server Traffic Routing" (page193)). Under such conditions, the Nortel Application Switch with NortelApplication Switch Operating System provides the following solutions:

• "Virtual Matrix Architecture" (page 227)

• "Proxy IP Addresses" (page 228)

• "Mapping Ports" (page 234)

• "Direct Server Return" (page 238)

• "Direct Access Mode" (page 239)

• "Delayed Binding" (page 242)

Virtual Matrix ArchitectureVirtual Matrix Architecture (VMA) is a hybrid architecture that takes fulladvantage of the distributed processing capability in Nortel ApplicationSwitches. With VMA, the switch makes optimal use of system resourcesby distributing the workload to multiple processors, thereby improvingswitch performance and increasing session capacity. VMA also removesthe topology constraints introduced by using Direct Access Mode(DAM). By default, VMA is enabled on the Nortel Application Switch(/cfg/slb/adv/matrix).

In previous versions of the Nortel Application Switch Operating System,VMA hashing only took into account the source IP address. This approachwas ineffective when mega proxies are used.

To improve the distribution, there are two VMA configurable options.

VMA configurable options

VMA with source port>> /cfg/slb/adv/vmasport

Source IP and source port are used todetermine the processor.

VMA with destination IP>> /cfg/slb/adv/vmadip

Source IP and destination IP are used todetermine the processor. Both options canbe enabled together wherein source IP,source port and destination IP are used todetermine the processor.




.


Note: It is not advisable to change VMA option while switch is inoperation since that may result in temporary disconnection of clients.

Maintenance mode command /maint/debug/vmasp can be used tofind the processor for any combination of source IP, source port (if VMAwith source port is enabled) and destination IP (if VMA with destinationIP is enabled).

Miscellaneous DebugWhen VMA with destination IP is enabled:

>> /cfg/slb/adv/vmadip ena Current VMA with destinationIP: disabledNew VMA with destination IP:enabledWARNING!! Changing VMA optionmay result in temporarydisconnection of clients.Do you want to continue?[y/n][n]

Proxy IP AddressesIn complex network topologies (see "SLB Client/Server Traffic Routing"(page 193)), SLB functions can be managed using a proxy IP address onthe client switch ports.

When the client requests services from the switch’s virtual server, theclient sends its own IP address for use as a return address. If a proxy IPaddress is configured for the client port on the switch, the switch replacesthe client’s source IP address with the switch’s own proxy IP address beforesending the request to the real server. This creates the illusion that theswitch originated the request.

The real server uses the switch’s proxy IP address as the destinationaddress for any response. SLB traffic is forced to return through the properswitch, regardless of alternate paths. Once the switch receives the proxieddata, it puts the original client IP address into the destination address andsends the packet to the client. This process is transparent to the client.

Note: Because requests appear to come from the switch proxyIP address rather than the client source IP address, the networkadministrator should be aware of this behavior during debugging andstatistics collection.

The proxy IP address can also be used for direct access to the real servers(see "Direct Access Mode" (page 239)).




.


Proxy IP Address ConfigurationProxy IP addresses are no longer tied to the switch processor. The proxyaddress can be associated with a port or VLAN. A proxy IP address can bebased on a port or a VLAN. Up to 1024 proxy IP addresses in total can beconfigured per switch.

• When configuration is port-based, the Nortel Application Switch usesthe ingress port to select a proxy IP address.

• When configuration is VLAN-based, the switch uses the ingress VLANto select a proxy IP address.

Proxy IP addresses can also be assigned based on egress port or VLAN(see "Selecting a Proxy IP Based on the Egress Port or VLAN" (page 230)).

To use Proxy IP addresses on the physical port or VLAN:

>> # /cfg/slb/pip/type port|vlan (Set base pip type to port orVLAN)

Port-based Proxy IP AddressesThe creation of a port-based proxy IP address is a two step process. Thetype command is first used to specify the address type:

/cfg/slb/pip/type port

The address is then specified using either the add or add6 command. Thecommand is dependent on the IP protocol version in use. For an IPv4address, the add command is used:

/cfg/slb/pip/add

For an IPv6 address, the add6 command is used:

/cfg/slb/pip/add6

The following example demonstrates the configuration of an IPv4 port-basedproxy IP address. To configure an IPv6 address, substitute the add6command for the add command and enter an IPv6 address.

>> # /cfg/slb/pip/type port (Select port-based proxy IPaddress)

>> # /cfg/slb/pip/add (Add a proxy IP address)

Enter Proxy IP address: 10.10.10.1Enter port <1 to 28> or block <first-last>: e.g. 1 2 3-10

1-3 (Add proxy IP address to ports1-3)

New pending: 1: 10.10.10.1 port 1-3




.


Once enabled, the port-based proxy IP addressing is the active mode, andVLAN-based proxy IP addressing is inactive. Any VLAN-based proxy IPaddresses that may have been configured are now inactive on the NortelApplication Switch.

Note: WAN Link Load Balancing (see " WAN Link Load Balancing"(page 327)) requires use of port-based proxy IP addresses; VLAN-basedproxy IP addresses cannot be used.

VLAN-based Proxy IP AddressesSince traffic is usually segregated by VLANs, selection of proxy IP addresscan be determined based on the VLAN information contained in the packet.

The creation of a VLAN-based proxy IP address is a two step process. Thetype command is first used to specify the address type:

/cfg/slb/pip/type vlan

The address is then specified using either the add or add6 command. Thecommand is dependent on the IP protocol version in use. For an IPv4address, the add command is used:

/cfg/slb/pip/add

For an IPv6 address, the add6 command is used:

/cfg/slb/pip/add6

The following example demonstrates the configuration of an IPv4VLAN-based proxy IP address. To configure an IPv6 address, substitute theadd6 command for the add command and enter an IPv6 address

>> # /cfg/slb/pip/type vlan (Choose VLAN as the pip type)

>> Proxy IP Address# add (Add a proxy IP address)

Enter Proxy IP address: 10.10.10.1Enter VLAN <1 to 4090> or block <first-last>: e.g. 1 23-10

2 (Assign proxy IP address toVLAN 2)

New Pending: 1: 10.10.10.1 vlan 2

Selecting a Proxy IP Based on the Egress Port or VLANBy default, the switch selects the proxy IP address based on the ingress portor VLAN. However, a proxy IP can also be selected based on the egressport or VLAN. Selection of the egress port or VLAN can be enabled on avirtual service, or on a filter. Egress port or VLAN-based proxy IP addressshould be applied only to Web Cache Redirection (WCR) filtering.




.


>> # /cfg/slb/virt <x> /service <y>/epip ena

(Select proxy IP based onegress port or VLAN for thisvirtual service)

>> # /cfg/slb/filt <x> /adv/proxyadv/epip ena

(Select proxy IP based onegress port or VLAN for a WCRfilter)

Use of a port-based proxy IP or a VLAN-based proxy IP depends onwhether you have selected the proxy IP type as port or VLAN.

Proxy IP Addresses in FiltersIn previous releases of Nortel Application Switch Operating System, onlyfour proxy IP addresses could be configured, and client proxy was enabledin the filtering advanced menu. The application switch used the configuredproxy IP address for the VMA switch port (SP) to replace client’s sourceIP address. Now you can configure a unique proxy IP address for a filterin the filtering advanced menu. To configure a proxy IP address on a filter,enter the following commands.

Note: The filter proxy/proxyip function applies only when the filter actionis NAT.

>> # /cfg/slb/filt <filter #> /adv/proxyipCurrent proxy IP address: any

Enter new proxy IP address or any: <proxy IP address> (Add aproxy IP to this filter)

>> Filter 2 Advanced# proxy ena (Enable use of proxy IP on thisfilter)

If no proxyip is configured in Filter Advanced menu then the NortelApplication Switch uses the proxy IP address configured in /cfg/slb/pipmenu. If proxy IP addresses are configured in both the Filter Advancedmenu and the /cfg/slb/pip menus, then the Proxy IP address in FilterAdvanced menu takes precedence over the Proxy IP address in the/cfg/slb/pip menu.

Using a Virtual Server IP Address as the Proxy IP AddressFor outgoing proxy servers that initiate flows from within the server farm, avirtual server IP address configured on the Nortel Application Switch can besubstituted as the proxy server’s source IP address. To do so, the NortelApplication Switch allows a virtual server IP address configured on theswitch, to also be used as a proxy IP address.




.


Using a virtual server IP address as the proxy IP address allowsconservation of public IP addresses. When proxy servers initiate requeststo the web, they require a public IP address for their source IP address.In previous versions of Nortel Application Switch Operating System, thisrequired Network Address Translation (NAT) to substitute the private sourceIP address of the proxy server, with one of only four available proxy IPaddresses. The previous limitation of four proxy IP addresses meant thatonly four addresses were available as public IP addresses for outgoingproxy traffic. In the current release, Nortel Application Switch OperatingSystem can mask real IP addresses of the servers in the server farm withthe virtual server IP address configured on the Nortel Application Switch,when the real servers initiate traffic flows. The benefit of using a virtualserver IP address as the proxy IP address is that multiple proxy servers canshare the same virtual server IP address and embed that address as theirsource IP address, thus conserving use of Public IP addresses.

For example, if virtual server IP 50.50.50.1 is configured on the switch, andproxy servers are to share this address, configure both proxy and virtualserver IPs with the same address:

>> # /cfg/slb/virt 1/vip 50.50.50.1>> # /cfg/slb/pip/add 50.50.50.1

Configuring Proxy IP AddressesThe following procedure can be used for configuring proxy IP addresses:

Step Action

1 Disable server processing on affected switch ports.

When implementing proxies, switch ports can be reconfigured todisable server processing. Referring to the "Web Host Example: PortUsage" (page 197), the following revised port conditions are used:

Proxy Example: Port Usage


1 Server A None

2 Server B None

3 Server C None

4 Back-end NFS server provides centralizedcontent for all three real servers. This portdoes not require switching features.

None




.



5 Client router A connects the switch to theInternet where all client requests originate.

Client

6 Client router B also connects the switch to theInternet where all client requests originate.

Client

The following commands are used to disable server processing onports 1-3:

>> # /cfg/slb/port 1 (Select switch port 1)

>> SLB port 1# server dis (Disable server processingon port 1)

>> SLB port 1# /cfg/slb/port 2 (Select switch port 2)


>> SLB port 2# /cfg/slb/port 3 (Select switch port 3)


2 Configure a unique proxy address and enable proxy for theclient ports.

Configure a unique proxy IP address and enable proxy on the clientports:

>> Main # /cfg/slb/pip (Select proxy IP menu)

>> Proxy IP Address# type port (Set proxy IP base type toport)

>> Proxy IP Address# add 200.200.200.68 5-6 (Set proxyIP address)

>> Main # /cfg/slb/port 5/proxyena

(Select network port 5 andenable proxy)

>> SLB port 5# /cfg/slb/port 6 (Select network port 6)

>> SLB port 6# proxy ena (Enable proxy)

The proxies are transparent to the user.

3 Apply and save your changes.

Note: Remember that you must apply any changes in order forthem to take effect, and you must save them if you wish themto remain in effect after switch reboot. Also, the /info/slb




.


command is useful for checking the state of Server LoadBalancing operations.

—End—

Proxy IP LimitationIf a Proxy IP address is enabled, the Selected DAM feature should also beenabled. When Selective DAM is disabled for a service and traffic ingressesa port with a port or VLAN based Proxy IP, the client traffic still uses a proxyport. This causes client port network address translation (NAT). This in turncauses a failure when the traffic comes back to the switch from the server.

Mapping PortsA Nortel Application Switch allows you to hide the identity of a port forsecurity by mapping a virtual server port to a different real server port.

Mapping a Virtual Server Port to a Real Server PortIn addition to providing direct real server access in some situations (see"Mapping Ports" (page 241)), mapping is required when administratorschoose to execute their real server processes on different ports than thewell-known TCP/UDP ports. Otherwise, virtual server ports are mappeddirectly to real server ports by default and require no mapping configuration.

Port mapping is configured from the Virtual Server Services menu. Forexample, to map the virtual server TCP/UDP port 80 to real serverTCP/UDP port 8004, you could enter the following:

>> # /cfg/slb/virt 1/service 80 (Select virtual server port 80)

>> Virtual Server 1 http Service#rport 8004

(Map to real port 8004)

Note: If filtering is enabled, a proxy IP address is configured, or URLparsing is enabled on any switch port, then port mapping is supportedwith Direct Access Mode (DAM). For information about DAM, refer to"Direct Access Mode" (page 239).

Mapping aVirtual Server Port to Multiple Real Server PortsTo take advantage of multi-CPU or multi-process servers, Nortel ApplicationSwitch Operating System can be configured to map a single virtual port tomultiple real ports. This capability allows the site managers, for example, todifferentiate users of a service by using multiple service ports to processclient requests.




.


A Nortel Application Switch supports up to 16 real ports per server whenmultiple rports are enabled. This feature allows the network administratorto configure up to 16 real ports for a single service port. This feature issupported in Layer 4 and Layer 7 and in cookie-based and SSL persistenceswitching environments.

When multiple real ports on each real server are mapped to a virtual port,the Nortel Application Switch treats the real server IP address/port mappingcombination as a distinct real server.

Note: For each real server, you can only configure one service withmultiple real ports.

Consider the following network:

Basic Virtual Port to Real Port Mapping Configuration

DomainName

Virtual ServerIP Address

PortsActivated

Port Mapping Real ServerIP Address

www.abcxyz.com

192.168.2.100 80 (HTTP) 8001 (rport1)8002 (rport2)

192.168.2.1(RIP 1)192.168.2.2(RIP 2)192.168.2.3(RIP 3)192.168.2.4(RIP 4)




.


In this example, four real servers are used to support a single service(HTTP). Clients access this service through a virtual server with IP address192.168.2.100 on virtual port 80. Since each real server uses two ports(8001 and 8002) for HTTP services, the logical real servers are:

• 192.168.2.1/8001

• 192.168.2.1/8002

• 192.168.2.2/8001

• 192.168.2.2/8002

• 192.168.2.3/8001

• 192.168.2.3/8002

• 192.168.2.4/8001

• 192.168.2.4/8002

Load Balancing MetricFor each service, a real server is selected using the configured loadbalancing metric (hash, leastconns, minmisses, or roundrobin). To ensureeven distribution, once an available server is selected, the switch uses theroundrobin metric to choose a real port to receive the incoming connection.

If the algorithm is leastconns, the switch sends the incoming connectionsto the logical real server (real server IP address/port combination) with theleast number of connections.

The /cfg/slb/virt command defines the real server TCP or UDPport assigned to a service. By default, this is the same as the virtual port(service virtual port). If rport is configured to be different from the virtual portdefined in /cfg/slb/virt <virtual server number> / service<virtual port>, the switch maps the virtual port to the real port.

Note: To use the single virtual port to multiple rport feature, configurethis real server port option to be a value of 0. However, note that youcannot configure multiple services with multiple rports in the sameserver if the multiple rport feature is enabled.

Configuring Multiple Service PortsTwo commands, addport and remport, under the real server menu allowusers to add or remove multiple service ports associated with a particularserver. (A service port is a TCP or UDP port number.) For example:addport 8001 and remport 8001.

Step Action

1 Configure the real servers.




.


>> # /cfg/slb/real 1/rip 192.168.2.1/ena>> # /cfg/slb/real 2/rip 192.168.2.2/ena>> # /cfg/slb/real 3/rip 192.168.2.3/ena>> # /cfg/slb/real 4/rip 192.168.2.4/ena

2 Add all four servers to a group.

>> # /cfg/slb/group 1>> Real server Group 1# add 1>> Real server Group 1# add 2>> Real server Group 1# add 3>> Real server Group 1# add 4

3 Configure a virtual server IP address.

>> # /cfg/slb/virt 1/vip 192.168.2.100/ena

4 Turn on multiple rport for Port 80.

>> # /cfg/slb/virt 1/service 80/rport 0

5 Add the ports to which the Web server listens.

>> # /cfg/slb/real 1/addport8001

(Add port 8001 to real server 1)

>> # addport 8002 (Add port 8002 to real server 1)










—End—




.


Direct Server ReturnSome clients may need Direct Server Return (DSR) feature allows the serverto respond directly to the client. This capability is useful for sites where largeamounts of data are flowing from servers to clients, such as with contentproviders or portal sites that typically have asymmetric traffic patterns.

DSR and content-intelligent Layer 7 switching cannot be performed at thesame time because content intelligent switching requires that all frames goback to the switch for connection splicing.

Note: DSR requires that the server be set up to receive frames that havea destination IP address that is equal to the virtual server IP address.

How Direct Server Return WorksThe sequence of steps that are executed in this scenario are shown in"Direct Server Return" (page 238):

Direct Server Return

Step Action

1 A client request is forwarded to the Nortel Application Switch.

2 Because only MAC addresses are substituted, the switchforwards the request to the best server, based on the configuredload-balancing policy.

3 The server responds directly to the client, bypassing the switch,and using the virtual server IP address as the source IP address.

To set up DSR, use the following commands:

>> # /cfg/slb/real <real server number> /submac ena>> # /cfg/slb/virt <virtual server number> /service<service number> /nonat ena




.


—End—

Direct Access ModeDirect Access Mode (DAM) allows any client to communicate with any realserver’s load-balanced service. Also, with DAM enabled, any number ofvirtual services can be configured to load balance a real service.

Direct Access Mode enables both Client and Server processing on thesame port to handle traffic that requires direct access to real servers.

Configuring Global Direct Access ModeDirect access mode can be configured globally on the switch using thefollowing command:

>> Main# /cfg/slb/adv/direct eCurrent Direct Access Mode: disabledNew Direct Access Mode: enabled

When DAM (/cfg/slb/adv/direct) is enabled on a switch, any clientcan communicate with any real server’s load-balanced service. Also, withDAM enabled, any number of virtual services can be configured to loadbalance a real service.

With Direct Access Mode, traffic that is sent directly to real server IPaddresses (instead of the virtual server IP address) is excluded from loadbalancing decisions. The same clients may also communicate to the virtualserver IP address for load-balanced requests.

Direct access mode is necessary for applications such as:

• Direct access to real servers for management or administration

• One real server serving multiple virtual server IP (VIP) addresses

• Content intelligent switching, which requires traffic to go to specific realservers based on inspection of HTTP headers, content identifiers suchas URLs and cookies, and the parsing of content requests.

For more information see "Content Intelligent Server Load Balancing"(page 210).

Note: When DAM is enabled on a switch, port mapping and defaultgateway load balancing is supported only when filtering is enabled, aproxy IP address is configured, or URL parsing is enabled on any switchport.




.


Blocking Direct Access Mode on Selected ServicesWhen Direct Access Mode is enabled globally on the switch, it can also bedisabled on selected virtual servers and virtual services.

For example, you have enabled direct access mode on the switch so that itcan support content-intelligent load balancing applications such as thosedescribed in "Content Intelligent Server Load Balancing" (page 210).

However, you also wish to load balance a stateless protocol such as UDP,which by its nature cannot be recorded in a session entry in the switch’ssession table.

In order to block use of DAM for the UDP protocol (service port 9200), enterthe following commands:

>> Main# /cfg/slb/adv/direct e (Enable DAM globally on the switch)

>> /cfg/slb/virt 1/service 9200/direct disable

Note 1: The /cfg/slb/virt <x> /service <y> /direct commandrequires that DAM be enabled globally on the switch. If DAM is notenabled globally on the switch, the direct disable command has noeffect. When direct access mode is enabled on the switch and disabledon a virtual server/virtual port pair, direct access to other real servers(those servers that are not servicing a virtual server/virtual port pair withdirect access mode disabled) is still allowed.

Note 2: DAM cannot be disabled for FTP and RTSP services.

Assigning Multiple IP AddressesOne way to provide both SLB access and direct access to a real server isto assign multiple IP addresses to the real server. For example, one IPaddress could be established exclusively for SLB and another could beused for direct access needs.

Using Proxy IP AddressesProxy IP addresses are used primarily to eliminate SLB topology restrictionsin complex networks (see "Proxy IP Addresses" (page 228)). Proxy IPaddresses can also provide direct access to real servers.

If the switch is configured with proxy IP addresses and the client port isenabled for proxy, the client can access each real server directly usingthe real server’s IP address. To directly access a real server, the switchport connected to the real server must have server processing disabled.However, if DAM is enabled (/cfg/slb/adv/direct ena), serverprocessing must be enabled on the server port regardless of the proxysetting and SLB is still accessed using the virtual server IP address.




.


Mapping PortsWhen SLB is used without proxy IP addresses and without DAM, the NortelApplication Switch must process the server-to-client responses. If a clientwere to access the real server IP address and port directly, bypassing clientprocessing, the server-to-client response could be mishandled by SLBprocessing as it returns through the Nortel Application Switch, with the realserver IP address getting remapped back to the virtual server IP address onthe Nortel Application Switch.

First, two port processes must be executed on the real server. One realserver port handles the direct traffic, and the other handles SLB traffic.Then, the virtual server port on the Nortel Application Switch must bemapped to the proper real server port.

In "Mapped and Nonmapped Server Access" (page 241), clients can accessSLB services through well-known TCP port 80 at the virtual server’s IPaddress. The Nortel Application Switch behaving like a virtual serveris mapped to TCP port 8000 on the real server. For direct access thatbypasses the virtual server and SLB, clients can specify well-known TCPport 80 as the real server’s IP address.

Mapped and Nonmapped Server Access

Note: Port mapping is supported with DAM when filtering is enabled,a proxy IP address is configured, or URL parsing is enabled on anyswitch port.

For more information on how to map a virtual server port to a real serverport, see "Mapping Ports" (page 234).




.


Monitoring Real ServersTypically, the management network is used by network administrators tomonitor real servers and services. By configuring the mnet and mmaskoptions of the SLB Configuration Menu (/cfg/slb/adv), you can accessthe real services being load balanced.

Note: Clients on the management network do not have access to SLBservices and cannot access the virtual services being load balanced.

The mnet and mmask options are described below:

• mnet

If defined, management traffic with this source IP address is alloweddirect (non-SLB) access to the real servers. Only specify an IP addressin dotted decimal notation. A range of IP addresses is produced whenused with the mmask option.

• mmask

This IP address mask is used with mnet to select management trafficthat is allowed direct real server access only.

Delayed BindingThe delayed binding feature on the switch prevents SYN Denial-of-Service(DoS) attacks on the server. DoS occurs when the server or switch is deniedservicing the client because it is saturated with invalid traffic.

Typically, a three-way handshake occurs before a client connects to a server.The client sends out a synchronization (SYN) request to the server. Theserver allocates an area to process the client requests, and acknowledgesthe client by sending a SYN ACK. The client then acknowledges the SYNACK by sending an acknowledgement (ACK) back to the server, thuscompleting the three-way handshake.

"DoS SYN Attacks without Delayed Binding" (page 243) illustrates a classictype of SYN DoS attack. If the client does not acknowledge the server’sSYN ACK with a data request (REQ) and, instead, sends another SYNrequest, the server gets saturated with SYN requests. As a result, all of theservers resources are consumed and it can no longer service legitimateclient requests.




.


DoS SYN Attacks without Delayed Binding

Using a Nortel Application Switch with delayed binding, as illustrated in"Repelling DoS SYN Attacks With Delayed Binding" (page 244), the NortelApplication Switch intercepts the client SYN request before it reaches theserver. The Nortel Application Switch responds to the client with a SYNACK that contains embedded client information. The Nortel ApplicationSwitch does not allocate a session until a valid SYN ACK is received fromthe client or the three-way handshake is complete.




.


Repelling DoS SYN Attacks With Delayed Binding

Once the Nortel Application Switch receives a valid ACK or DATA REQ fromthe client, the Nortel Application Switch sends a SYN request to the serveron behalf of the client, waits for the server to respond with a SYN ACK, andthen forwards the clients DATA REQ to the server. Basically, the NortelApplication Switch delays binding the client session to the server until theproper handshakes are complete.

Thus, with delayed binding, two independent TCP connections span asession: one from the client to the Nortel Application Switch and the secondfrom the switch to the selected server. The switch temporarily terminateseach TCP connection until content has been received, thus preventing theserver from being inundated with SYN requests.

Note: Delayed binding is automatically enabled when content intelligentswitching features are used. However, if you are not parsing content,you must explicitly enable delayed binding if desired.

Configuring Delayed BindingTo configure your switch for delayed binding, use the following command:




.


>> # /cfg/slb/virt <virtual server number> /service <servicetype> /dbind

Note: Enable delayed binding without configuring any HTTP SLBprocessing or persistent binding types.

To configure delayed binding for cache redirection, see "Delayed Bindingfor Cache Redirection" (page 417).

Detecting SYN AttacksIn Nortel Application Switch Operating System, SYN attack detection isenabled by default, whenever delayed binding is enabled. SYN attackdetection:

• Provides a way to track half open connections

• Activates a trap notifying that the configured threshold is exceeded

• Monitors DoS attacks and proactively signals alarm

• Provides enhanced security

• Improves visibility and protection for DoS attacks

The probability of a SYN attack is higher if excessive half-open sessionsare being generated on the Nortel Application Switch. Half-open sessionsshow an incomplete three-way handshake between the server and theclient. You can view the total number of half-open sessions from the/stat/slb/layer7/maint menu.

To detect SYN attacks, the Nortel Application Switch keeps track of thenumber of new half-open sessions for a set period of time. If the valueexceeds the threshold, then a syslog message and an SNMP trap aregenerated.

You can change the default parameters for detecting SYN attacks in the/cfg/slb/adv/synatk menu. You can specify how frequently you wantto check for SYN attacks, from 2 seconds to a minute and modify the defaultthreshold representing the number of new half-open sessions per second.

Session Timeout Per ServiceThe Nortel Application Switch Operating System implements a feature thatallows for the configuration of session timeout based on a service timeoutinstead of the real server timeout.

With this feature, by default the timeout value for the service is set to 0.When the value is 0, the service uses the real server timeout value. Oncethe timeout value for the service is configured that will be used instead. This




.


is useful in instances where sessions need to be kept alive after their realserver configured timeout expires. An FTP session could be kept alive afterits server defined timeout period for example.

The following is an example of how a timeout of 10 minutes would beconfigured for HTTP (service 80) on virtual server 1:

Step Action

1 Select service 80.

>> Main# /cfg/slb/virt 1/service 80

2 Set the service timeout value.

>> Virtual Server 1 http Service# tmout 10

3 Save configuration.

>> Virtual Server 1 http Service# apply>> Virtual Server 1 http Service# save

—End—

IPv6 and Server Load BalancingThe Nortel Application Switch Operating System provides a full range ofserver load balancing options for IPv6. IPv6 virtual address traffic can eitherbe load balanced to IPv4 or IPv6 real servers. In the case of IPv4 realservers, the Nortel Application Switch Operating System converts the IPv6client packet to an IPv4 packet before it is forwarded to the server. Thispacket is transmitted directly to IPv4 servers.

Note: Since IPv6 does not allow intermediary routers or switches tofragment packets, internal translation of the maximum IPv4 packet (MTUof 1500) cannot be translated without fragmenting. It is therefore arequirement for all IPv4 Real Servers using IPv6 SLB to be configuredwith a maximum MTU less than or equal to 1440. For example,in the Windows 2003 environment, run REGEDIT in the Windowsplatform real servers to add a new parameter to the registry with thekeyword MTU, using REG_DWORD with a decimal value of 1440,in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Ser-vices\Tcpip\Parameters\Interfaces \XX where XX is the correctinterface for the configured IP address.




.


To implement IPv6 server load balancing, real servers are set to be eitherIPv4 or IPv6 servers. Similarly, real server groups are set to contain eitherIPv4 or IPv6 servers. Combinations of the two server types are not allowed.

Proxy IP addresses can be in either IPv4 or IPv6 format as well. Switchports and VLANs can be assigned either one type or the other or both.The appropriate PIP is used in load balancing operations based on theIP version of the incoming packet.

Note: Only basic Layer 4 server load balancing is supported andincludes support for Direct Access Mode (DAM). For conceptualinformation on basic Layer 4 load balancing, refer to "UnderstandingServer Load Balancing" (page 188) and "Implementing Basic ServerLoad Balancing" (page 191).

IPv6 server load balancing supports the following metrics:

• Roundrobin

• Leastconn

• Minmisses

• Hash

IPv6 server load balancing does not support the following metrics:

• Not support

• Phash

• Bandwidth

• Delay

Note: IPv6 fragments are only supported on a client-enabled port andwhen the fragments are in order.

IPv6 to IPv4 Server Load Balancing"IPv6 to IPv4 Layer 4 SLB Example" (page 248) demonstrates server loadbalancing between IPv6 clients and IPv4 servers.




.


IPv6 to IPv4 Layer 4 SLB Example

The following procedure is used to configure IPv6 support for load balancingIPv4 real servers. The specific commands, as presented in the example,would replicate the topology in "IPv6 to IPv4 Layer 4 SLB Example" (page248).

Step Action

1 Configure IPv6 network interface.

>> Main# /cfg/l3/if 1>> IP Interface 1# ena>> IP Interface 1# ipver v6>> IP Interface 1# addr 2005:0:0:0:0:0:0:1>> IP Interface 1# mask 64>> IP Interface 1# apply

2 Configure VLAN for Interface 1.




.


>> Main# /cfg/l2/vlan 3>> VLAN 3# ena>> VLAN 3# add 13Port 13 is an UNTAGGED port and its current PVID is1.Confirm changing PVID from 1 to 3 [y/n]: y>> VLAN 3# add 14Port 14 is an UNTAGGED port and its current PVID is1.Confirm changing PVID from 1 to 3 [y/n]: y>> VLAN 3# add 15Port 15 is an UNTAGGED port and its current PVID is1.Confirm changing PVID from 1 to 3 [y/n]: y

3 Configure IPv4 network interface for the real servers.

>> Main# /cfg/l3/if 3>> Interface 3# ena>> Interface 3# ipver v4>> Interface 3# addr 30.1.1.1>> Interface 3# mask 255.255.255.0>> Interface 3# broad 30.1.1.255>> Interface 3# vlan 3

4 Configure IPv6 default gateway.

>> Main# /cfg/l3/gw 5>> Default gateway 5# ena>> Default gateway 5# ipver v6>> Default gateway 5# addr 2005:0:0:0:0:0:0:24>> Default gateway 5# vlan 1

5 Configure IPv6 virtual server IP address.

>> Main# /cfg/slb/virt 1>> Virtual Server 1# ena>> Virtual Server 1# ipver v6>> Virtual Server 1# vip 2005:0:0:0:0:0:0:100

6 Assign HTTP service to virtual server.

>> Main# /cfg/slb/virt 1/service http>> Virtual Server 1 http Service# group 1

7 Enable Server Load Balancing.




.


>> Main# /cfg/slb/on

8 Configure Real Servers and Real Server Group.

>> Main# /cfg/slb/real 1>> Real Server 1# ena>> Real Server 1# rip 30.1.1.13>> Main# /cfg/slb/real 2>> Real Server 2# ena>> Real Server 2# rip 30.1.1.14>> Main# /cfg/slb/real 3>> Real Server 3# ena>> Real Server 3# rip 30.1.1.15>> Main# /cfg/slb/group 1>> Real Server Group 1# ena>> Real Server Group 1# health http>> Real Server Group 1# add 1>> Real Server Group 1# add 2>> Real Server Group 1# add 3

9 Configure Client and Server Processing on Client and Serverports.

>> Main# /cfg/slb/port 1>> SLB Port 1# client ena>> Main# /cfg/slb/port 13>> SLB Port 13# server ena>> Main# /cfg/slb/port 14>> SLB Port 14# server ena>> Main# /cfg/slb/port 15>> SLB Port 15# server ena

10 Configure a proxy IP and enable it on the client port.

The proxy IP address is used to converge the IPv4 and IPv6traffic. Optionally, the proxy IP address can be assigned to a VLANinstead of the port. To enable it on the VLAN use the command/cfg/slb/pip/type vlan instead of /cfg/slb/pip/typeport.

>> Main# /cfg/slb/pip/type port>> Proxy IP Address# add 70.1.1.1 1>> Main# /cfg/slb/port 1>> SLB Port 1# proxy ena





.


>> Management Port# apply>> Management Port# save

—End—

IPv6 to IPv6 Server Load Balancing"IPv6 to IPv6 Layer 4 SLB Example" (page 251) demonstrates loadbalancing between IPv6 clients and IPv6 servers.

IPv6 to IPv6 Layer 4 SLB Example

The following procedure is used to configure IPv6 support for load balancingIPv6 real servers. The specific commands, as presented in the example,would replicate the topology in "IPv6 to IPv6 Layer 4 SLB Example" (page251).




.


Step Action

1 Configure IPv6 network interface.

>> Main# /cfg/l3/if 1>> Interface 1# ena>> Interface 1# ipver v6>> Interface 1# addr abcd:0:0:0:0:0:0:253>> Interface 1# mask 64

2 Globally enable load balancing.

>> Main# /cfg/slb>> Layer 4# on

3 Configure IPv6 real servers.

>> Main# /cfg/slb/real 1>> Real Server 1# ena>> Real Server 1# ipver v6>> Real Server 1# rip abcd:0:0:0:0:0:0:11>> Main# /cfg/slb/real 2>> Real Server 2# ena>> Real Server 2# ipver v6>> Real Server 2# rip abcd:0:0:0:0:0:0:12

4 Configure IPv6 real server groups.

>> Main# /cfg/slb/group 1>> Real Server Group 1# ipver v6>> Real Server Group 1# add 1>> Real Server Group 1# add 2

5 Enable client processing on the SLB ports.

>> Main# /cfg/slb/port 1>> SLB Port 1# client ena>> Main# /cfg/slb/port 2>> SLB Port 2# client ena

6 Enable server processing on the SLB ports.

>> Main# /cfg/slb/port 21>> SLB Port 21# server ena>> Main# /cfg/slb/port 22>> SLB Port 22# server ena




.


7 Create the IPv6 virtual servers.

>> Main# /cfg/slb/virt 1>> Virtual Server 1# ena>> Virtual Server 1# ipver v6>> Virtual Server 1# vip abcd:0:0:0:0:0:0:100

8 Assign the desired service to the IPv6 virtual server group.

>> Main# /cfg/slb/virt 1/service http>> Virtual Server 1 http Service# group 1

—End—

IPv6 Layer 4 SLB InformationThe following three commands are used to acquire IPv6 Layer 4 sessioninformation:

• IPv6-related items in the SLB session dump

>> Main# /info/slb/sess/dump

• IPv6 client IP addresses in the SLB session dump

>> Main# /info/slb/sess/cip6

• IPv6 destination IP addresses in the SLB session dump

>> Main# /info/slb/sess/dip6

IPv6 Real Server Health ChecksHealth checking is supported for IPv6 real servers. ICMP, TCP, HTTP, andscript health checking are supported. For information on the configurationand management of health checking, refer to the following topics:

• "Real Server Health Checks" (page 465)

• "TCP Health Checks" (page 469)

• "ICMP Health Checks" (page 470)

• "Script-Based Health Checks" (page 470)

• "HTTP Health Checks" (page 479)




.


Load Balancing Special Services

This chapter discusses server load balancing based on special services,such as source IP addresses, FTP, LDAP, RTSP, DNS, WAP, IDS, and SIP.


• "IP Server Load Balancing" (page 254)

• "FTP Server Load Balancing" (page 255)

• "TFTP Server Load Balancing" (page 256)

• "Lightweight Directory Access Server SLB" (page 257)

• "Domain Name Server (DNS) SLB" (page 261)

• "Real Time Streaming Protocol SLB" (page 268)

• "Wireless Application Protocol SLB" (page 279)

• "Intrusion Detection System SLB" (page 290)

• "Session Initiation Protocol Server Load Balancing" (page 310)

• "SoftGrid Load Balancing" (page 319)

• "Workload Manager Support" (page 322)

For additional information on SLB commands, refer Nortel ApplicationSwitch Operating System Command Reference.

IP Server Load BalancingIP server load balancing allows you to configure your Nortel ApplicationSwitch for server load balancing based on client’s IP address only. Typically,the client IP address is used with the client port number to produce asession identifier. When the Layer 3 option is enabled, the switch uses onlythe client IP address as the session identifier.

To configure the switch for IP load balancing:

>> # /cfg/slb/virt <virtual server number>

>> Virtual Server 1# layr3 ena

>> Virtual Server 1# service ip

>> Virtual Server 1 IP Service# group <group number >




.

Load Balancing Special Services 255

FTP Server Load BalancingAs defined in RFC 959, FTP uses two connections—one for controlinformation and another for data. Each connection is unique. Unless theclient requests a change, the server always uses TCP port 21 (a well-knownport) for control information, and TCP port 20 as the default data port.

FTP uses TCP for transport. After the initial three-way handshake, aconnection is established. When the client requests any data informationfrom the server, it issues a PORT command (such as ls, dir, get, put, mgetand mput) via the control port.

There are two modes of FTP operation, active and passive:

• In Active FTP, the FTP server initiates the data connection.

• In Passive FTP, the FTP client initiates the data connection. Becausethe client also initiates the connection to the control channel, the passiveFTP mode does not pose a problem with firewalls and is the mostcommon mode of operation.

Nortel Application Switch Operating System supports both active andpassive modes of FTP operation. You can switch from active to passive orvice versa in the same FTP session.

Active FTP ConfigurationTo create an Active FTP configuration both the FTP and FTP-Data servicesmust be enabled on the virtual server. Perform the following procedure tocreate an Active FTP configuration on the switch:

Step Action

1 Add the FTP virtual service to the virtual server.


2 Add the FTP-Data virtual service to the virtual server.



>> Main# apply>> Main# save

—End—




.


FTP Network Topology RestrictionsFTP network topology restrictions are listed below:

• FTP control and data channels must be bound to the same real server.

• FTP with port mapping is not supported.

Configuring FTP Server Load Balancing

Step Action

1 Make sure that a proxy IP address is enabled on the clientport(s) or DAM is enabled.

2 Make sure the virtual port for FTP is set up for the virtual server.

>> Main# /cfg/slb/virt 1/service ftp

3 (Optional) Enable FTP parsing on the FTP service.

>> Main# /cfg/slb/virt 1/service 21/ftpp ena

4 To make your configuration changes active, enterapplyat anyprompt in the CLI.

>> Virtual Server 1 ftp Service# apply

—End—

TFTP Server Load BalancingAs defined in RFC 1350, Trivial File Transfer Protocol (TFTP) can only readand write files from/to a remote server. TFTP uses UDP datagrams totransfer data. A transfer begins with a request to read or write a file, whichalso serves to request a connection. If the server grants the request, theconnection is opened and the file is sent in fixed length blocks of 512 bytes.

Each data packet contains one block of data, and must be acknowledgedby an acknowledgment packet before the next packet can be sent. A datapacket of less than 512 bytes signals termination of a transfer.

TFTP server load balancing server is similar to other types of serverload balancing. It uses configured SLB metric to select TFTP server. Noadditional commands are required to load balance to TFTP servers.




.


Requirements

• Load balancing service port 69 must be selected.

• DAM must be enabled.

• UDP must be enabled (/cfg/slb/virt <x> /service tftp/udpena)

• PIP is not supported because the server port is changed. PIP usesserver port for allocating a pport.

• Multiple rports are not supported.

Configuring TFTP Server Load Balancing

Step Action

1 Make sure that Direct Access Mode (DAM) is enabled.

2 Make sure the virtual port for TFTP is set up for the virtualserver.

>> # /cfg/slb/virt 1/service tftp

3 To make your configuration changes active, enter apply at anyprompt in the CLI.

>> Virtual Server 1 ftp Service# apply

—End—

Lightweight Directory Access Server SLBAs defined in RFC 2251, Lightweight Directory Access Protocol (LDAP)is an application-level protocol between LDAP clients and servers, whichallows clients to retrieve LDAP directory entries via the Internet. The clientsends a protocol operation request to the server and the server respondswith a response. If it is based on TCP, port 389 is used. Once a connectionis setup between client and server, client issues operations to the server,and server sends responses back to the client. Before LDAP directoryoperations can be issued, in general a bind operation is issued, in whichauthorization is sent as well.




.


LDAP Operations and Server TypesThere are two kinds of LDAP operations, read and write. Clients use readoperations to browse directory on server, and use write operations to modifydirectory on server. LDAP servers are categorized into two kinds, read andwrite servers. Read servers only conduct read operations, and write serversperform both read and write operations.

How LDAP SLB WorksAn LDAP connection is set up via L4 load balancing and is bound to a readserver. After that, operation frames received by the switch are checked(at Layer 7) to determine if there are any write operations. The bind andwrite operation data frames are stored for potential later use. When a writeoperation arrives, the switch disconnects the connection to the read serverand reinitiate another connection with the write server without the client’sknowledge. Once the connection is set up with write server, all the laterrequests goes to the write server until unbind request is received by theswitch. All these operations occur within one TCP connection.

After the reset is sent to the old server, connection is set up to the newserver. Stored data frames are forwarded to the server. After write operationis forwarded to the server, the connection is spliced.

Selectively Resetting a Real ServerIf a long-lived LDAP connection exceeds the Nortel Application Switch’smaximum session length (32,768) minutes, the session will age out beforethe LDAP connection is closed. The Nortel Application Switch may thencreate another session to accept the same connection data. To prevent this,Nortel Application Switch Operating System can be configured to senda reset to a real server whose session has timed out before the LDAPconnection is closed.

To enable a session reset for a virtual server that is running the LDAPservice, enter the following command:

>> # /cfg/slb/virt 1/service ldap/reset enable

"Layer 4 DNS Load Balancing" (page 261) shows four LDAP servers loadbalancing LDAP queries.




.


LDAP Load Balancing

Configuring LDAP SLB

Step Action

1 Enable server load balancing.

>> # /cfg/slb/on

2 Configure the four real LDAP servers and their real IPaddresses.

>> # /cfg/slb/real 20

>> Real server 20 # ena (Enable real server 20)

>> Real server 20 # rip10.10.10.20

(Specify the IP address)

>> Real server 20 # layer7/ (Select the Layer 7 menu)

>> Real Server 20 Layer 7Commands# ldapwr e

(Enable LDAP read-write)

/cfg/slb/real 21/ena/rip 10.10.10.21/layer7/ldapwr e

(Configure and enableLDAP write server 21)





3 Configure group 1 for LDAP.




.


>> # /cfg/slb/group 1 (Select real server group 1)

>> Real server group 1 # metricroundrobin

(Specify the load balancingmetric for group 1)

>> Real server group 1 # add 20 (Add real server 20)




—End—

Step Action

1 Configure and enable a virtual server IP address 1 on the switch.

>> # /cfg/slb/virt 1/vip20.20.20.20

(Specify the virt server IPaddress)

>> Virtual Server 1# ena (Enable the virtual server)

2 Set up the LDAP service for the virtual server, and add realserver group 1.

>> Virtual Server 1# serviceldap

(Specify the LDAP service)

>> Virtual Server 1 LDAPService# group 1

(Select the real servergroup)

3 Enable delayed binding.

Delayed binding is required in order to process session requestswith a TCP three-way handshake.

>> Virtual Server 1 LDAPService# dbind ena

(Enable delayed binding)

4 Enable LDAP load balancing.

>> # /cfg/slb/virt 1/serviceldap/ldapslb ena

(Enable LDAP balancing)

5 (Optional) Enable session reset for long LDAP connections.

>> # /cfg/slb/virt 1/service ldap/reset enable




.


6 Apply and save your configuration.

>> Virtual Server 1 LDAP Service# apply>> Virtual Server 1 LDAP Service# save

—End—

Domain Name Server (DNS) SLBIn Nortel Application Switch Operating System, DNS load balancing allowsyou to choose the service based on the two forms of DNS queries: UDPand TCP. This enables the switch to send TCP DNS queries to one group ofreal servers and UDP DNS queries to another group of real servers. Therequests are then load balanced among the real servers in that group.

"Layer 4 DNS Load Balancing" (page 261) shows four real servers loadbalancing UDP and TCP queries between two groups.

Layer 4 DNS Load Balancing




.


Note: You can configure both UDP and TCP DNS queries for the samevirtual server IP address.

Preconfiguration Tasks

Step Action


>> # /cfg/slb/on

2 Configure the four real servers and their real IP addresses.



>> Real server 20 # rip10.10.10.20




>> Real server 21 # rip10.10.10.21




>> Real server 22 # rip10.10.10.22






.



>> Real server 26 # rip10.10.10.26


3 Configure group 1 for UDP and group 2 for TCP.

>> Main # /cfg/slb/group 1 (Select real server group 1)



>> Real server group 1 # healthudpdns

(Set the health check toUDP)



>> Real server group 1 # /cfg/slb/group 2



>> Real server group 2 # healthdns

(Set the health check toTCP)



For more information on configuring health check, see "UDP-BasedDNS Health Checks" (page 481).

4 Define and enable the server ports and the client ports.

For more information, see step 6 step 6. Some DNS servers initiateupstream requests and must be configured both as server and client.

—End—

Configuring UDP-based DNS Load Balancing

Step Action

1 Configure and enable a virtual server IP address 1 on the switch.

>> # /cfg/slb/virt 1/vip20.20.20.20






.


2 Set up the DNS service for the virtual server, and add realserver group 1.

>> Virtual Server 1# servicedns

(Specify the DNS service)

>> Virtual Server 1 DNSService# group 1


3 Disable delayed binding.

Delayed binding is not required because UDP does not processsession requests with a TCP three-way handshake.

>> Virtual Server 1 DNSService# dbind dis

(Disable delayed binding)

4 Enable UDP DNS queries.

>> Virtual Server 1 DNSService# udp ena

(Enable UDP balancing)


>> Virtual Server 1 DNS Service# apply>> Virtual Server 1 DNS Service# save

—End—

Configuring TCP-based DNS Load Balancing

Step Action

1 Configure and enable the virtual server IP address 2 on theswitch.

>> # /cfg/slb/virt 2/vip20.20.20.20



2 Set up the DNS service for virtual server, and select real servergroup 2.




.


>> Virtual Server 2# servicedns

(Specify the DNS service)

>> Virtual Server 2 DNSService# group 2


3 Enable delayed binding.

>> Virtual Server 2 DNSService# dbind ena

(Enable delayed binding)

4 As this is TCP-based load balancing, make sure to disable UDPDNS queries.

>> Virtual Server 2 DNSService# udp dis

(Disable UDP balancing)


>> Virtual Server 2 DNS Service# apply>> Virtual Server 2 DNS Service# save

—End—

Layer 7 DNS Load BalancingThe Internet name registry has become so large that a single server cannotkeep track of all the entries. This is resolved by splitting the registry andsaving it on different servers.

If you have large DNS server farms, Nortel Application Switch OperatingSystem allows you to load balance traffic based on DNS names. To loadbalance DNS names, the host name is extracted from the query, processedby the regular expressions engine, and the request is sent to the appropriatereal server.

For example, "Load Balancing DNS Queries" (page 266) shows a DNSserver farm load balancing DNS queries based on DNS names. Requestswith DNS names beginning with A through G are sent to Server 1; DNSnames beginning with H through M are sent to Server 2; DNS namesbeginning with N through T are sent to Server 3; DNS names beginning withU through Z are sent to Server 4.




.


Load Balancing DNS Queries

To configure the switch for DNS load balancing, perform the followingprocedure:

Step Action

1 Before you can configure DNS load balancing, ensure that theswitch has already been configured for basic SLB with thefollowing tasks:



• Define each real server (DNS server address).



• Enable SLB.

For information on how to configure your network for SLB, see"Server Load Balancing" (page 188)."

• Define server port and client port.

2 Enable DNS load balancing.

>> # /cfg/slb/virt 1 (Select the virtual server)


(Select the DNS service)

>> Virtual Server 1 DNS Service# dnsslb ena

(Enable DNS SLB)




.


3 If using a TCP-based DNS server, enable delayed binding (ifusing a UDP-based DNS server, do not enable delayed binding).

>> Virtual Server 1 DNS Service# dbind ena


>> # /cfg/slb/layer7/slb/addstr [abcdefg]+\.com>> Server Loadbalance Resource# addstr [hijklm]+\.com>> Server Loadbalance Resource# addstr [nopqrst]+\.com>> Server Loadbalance Resource# addstr [uvwxyz]+\.com




For easy configuration and identification, each defined string has anID attached, as shown in the following example:

ID SLB String

1 any, cont 1024

2 www.[abcdefg]*.com, cont 1024

3 www.[hijklm]*.com, cont 1024

4 www.[nopqrst]*.com, cont 1024

5 www.[uvwxyz]*.com, cont 1024

7 Add the defined string IDs to the real server using the followingcommand:

>> # /cfg/slb/real 1/layer7/addlb 2>> # /cfg/slb/real 2/layer7/addlb 3>> # /cfg/slb/real 3/layer7/addlb 4

Note: If you don’t add a defined string (or add the defined stringany) the server handles any request.

—End—




.


Real Time Streaming Protocol SLBReal Time Streaming ProtocolRTSP) is an application-level protocol forcontrol over the delivery of data with real-time properties as documented inRFC 2326. RTSP is the proposed standard for controlling streaming dataover the Internet. RTSP uses RTP (Real-Time Transport Protocol) to formatpackets of multimedia content. RTSP is designed to efficiently broadcastaudio-visual data to large groups.

Typically, a multimedia presentation consists of several streams of data (forexample, video stream, audio stream, and text) that must be presentedin a synchronized fashion. A multimedia client like Real Player or QuickTime Player downloads these multiple streams of data from the multimediaservers and presents them on the player screen.

RTSP is used to control the flow of these multimedia streams. Eachpresentation uses one RTSP control connection and several otherconnections to carry the audio/video/text multimedia streams. In thisdocument, the term RTSP server refers to any multimedia server thatimplements the RTSP protocol for multimedia presentation.

Note: RTSP Server Load Balancing cannot be set to None for theRTSP service 554.

How RTSP Server Load Balancing WorksThe objective of RTSP server load balancing is to intelligently switch anRTSP request, and the other media streams associated with a presentation,to a suitable RTSP server based on the configured load-balancing metric.Typically, an RTSP client establishes a control connection to an RTSPserver over TCP port 554 and the data flows over UDP or TCP. This portcan be changed however.

Nortel Application Switch Operating System supports two layer 7 metrics(URL hashing and URL pattern matching) and all layer 4 load-balancingmetrics. This section discusses load balancing RTSP servers for layer4; for information on load balancing RTSP servers for layer 7, see"Content-Intelligent RTSP Load Balancing" (page 273).

For information on using RTSP with cache redirection, see "RTSP CacheRedirection" (page 417).

Note: This feature is not applicable if the streaming media (multimedia)servers use HTTP protocol to tunnel RTSP traffic. To ensure that RTSPserver load balancing works, make sure the streaming media serveris configured for RTSP protocol.




.


Supported RTSP ServersIn a typical scenario, the RTSP client issues several sequences ofcommands to establish connections for each component stream of apresentation. There are several variations to this procedure, dependingupon the RTSP client and the server involved. For example, there are twoprominent RTSP server and client implementations.

The RTSP stream setup sequence is different for these two servers, and theswitch handles each differently as shown below:

• Real Server

Real Server from RealNetworks Corporation supports both UDP andTCP transport protocols for the RTSP streams. The actual transport isnegotiated during the initialization of the connection. If TCP transport isselected, then all streams of data will flow in the TCP control connectionitself. If UDP transport is chosen, the client and server negotiate a clientUDP port, which is manually configurable.

The real media files that the Real Server plays have the extension ".rm",".ram" or ".smil".

• QuickTime Streaming Server

QuickTime Streaming Server from Apple Incorporated supports aQuickTime presentation that typically has two streams and thereforeuses four UDP connections exclusively for transport and one TCPcontrol connection. QuickTime clients use a UDP port, which is manuallyconfigurable. The QuickTime files have the extension ".mov".

Nortel Application Switch Operating System can also support otherRTSP-compliant applications such as Microsoft Windows Media Server 9.

RTSP Port ConfigurationNortel Application Switch Operating System 24.0 features the ability toconfigure RTSP to use a port other than the default of 554.

The following sample configuration outlines the steps necessary for RTSPport configuration:

Step Action

1 Select a non-standard port to use for RTSP.


2 Configure RTSP load balancing on the selectedport.




.


>> Main# /cfg/slb/virt 1/service 808/rtsp>> Main# /cfg/slb/virt 1/service 808/rtsp/rtspslbhashNote: The rtspslb options are: hash, pattern,l4hash, and none.

—End—

Configuring RTSP Load BalancingIn this example, the Nortel Application Switch is load balancing RTSPtraffic between two media server farms as shown in "Load Balancing RTSPServers" (page 270). One group of media servers consist of QuickTimeservers and the other group of servers consist of RealNetworks servers.Each group has its own virtual server IP address. For example, threeReal Networks servers host media files for NortelNews; similarly, anotherthree QuickTime servers host media files for AlteonNews. The contentis duplicated among the servers in each group. Depending on the clientrequest type, the Nortel Application Switch is configured to load balancein the following way:

• Retrieving files from the Real Networks server group

RTSP://www.NortelNews.com/*.ram, RTSP://www.Nortel-News.com/*.rm, and RTSP://www.NortelNews.com/*.smil are loadbalanced among the Real Networks media servers using virtual IPaddress 30.30.30.100.

• Retrieving files from the QuickTime server group

RTSP://www.NortelNews.com/*.mov is load balanced among the QuickTime media servers using virtual IP address 40.40.40.100.

Load Balancing RTSP Servers




.


Follow this procedure to configure the topology illustrated in "Load BalancingRTSP Servers" (page 270):

Step Action

1 At the Nortel Application Switch, before you start configuringRTSP load balancing:

• Connect each QuickTime server to the layer 2 switch

• Connect each RealNetworks server to the layer 2 switch

• Configure the IP addresses on all devices connected to theNortel Application Switch

• Configure the IP interfaces on the switch

• Enable Direct Access Mode (DAM)

• Disable Bandwidth Management

• Disable proxy IP addressing


>> # /cfg/slb/on

3 Configure IP addresses for the real servers.

>> # /cfg/slb/real 1/rip30.30.30.10/ena

(Define IP address for Realserver 1)











4 Create a group to support RealNetworks servers.

>> # /cfg/slb/group 100 (Define a group)

>>Real Server Group 100# add 1 (Add real server 1)




.




5 Create a group to support QuickTime servers.





6 Create a virtual server for the RealNetworks servers.

To configure a virtual server for layer 4 load balancing of RTSP,select rtsp or port 554 as a service for the virtual server.


>>Virtual Server 1# vip30.30.30.100

(Set IP address for thevirtual server

>>Virtual Server 1# service 554 (Add the RTSP service forthe virtual server)

>>Virtual Server 1 rtspService# group 100

(Set the real server group)

>>Virtual Server 1 rtsp Service# /cfg/slb/virt 1/ena

(Enable virtual server)

7 Create a virtual server for the QuickTime servers.

To configure a virtual server for Layer 4 load balancing of RTSP,select rtsp or port 554 as a service for the virtual server.






(Set the Quicktime servergroup)

>>Virtual Server 2 rtsp Service# /cfg/slb/virt ena


8 Enable server and client processing at the port level.




.


>> # /cfg/slb/port 25 (Select the client port)

>>SLB port 25# client ena (Enable client processing)

>>SLB port 1# /cfg/slb/port 2 (Select the server port)

>>SLB port 2# server ena (Enable server processing)












>> SLB port 15# apply>> SLB port 15# save

Clients retrieving files of type RTSP://nortelnews.com/headlines.ramuse virtual IP address 30.30.30.100 of the RealNetworksserver group and clients retrieving files of type RTSP://nortel-news.com/headlines.mov use virtual IP address 40.40.40.100 of theQuickTime server group.

—End—

Content-Intelligent RTSP Load BalancingNortel Application Switch Operating System supports RTSP load balancingbased on URL hash metric or string matching to load balance mediaservers that contain multimedia presentations. Because multimediapresentations consume a large amount of Internet bandwidth, and theircorrect presentation depends upon the real time delivery of the data overthe Internet, several media servers contain the same multimedia data.

For more conceptual information on RTSP, refer to "Real Time StreamingProtocol SLB" (page 268).




.


"Layer 7 RTSP Load Balancing" (page 275) shows two groups of mediaservers: Group 1 is configured for URL hashing and group 2 is configuredfor string matching. The media servers are cache servers configured inreverse proxy mode.

URL HashUse the URL hash metric to maximize client requests to hash to the samemedia server. The original servers push the content to the cache serversahead of time. For example in "Layer 7 RTSP Load Balancing" (page 275),an ISP is hosting audio-video files for NortelNews on media servers 1, 2,3, and 4. The domain name nortelnews.com associated with the virtual IPaddress 120.10.10.10 is configured for URL hash.

The first request for http://nortelnews.com/saleswebcast.rm hashes to mediaserver 1. Subsequent requests for http://nortelnews.com/saleswebcast.rmfrom other clients or from client 1 will hash to the same server 1. Similarly,another request for http://nortelnews.com/marketingwebcast.rm may hashto media server 2, provided saleswebcast and marketingwebcast mediafiles are located in the origin servers.

Typically, a set of related files (audio, video, and text) of a presentation areusually placed under the same directory (called container directory). NortelApplication Switch Operating System URL hashing ensures that the entirecontainer is cached in a single cache by using the entire URL to computethe hash value and omitting the extension (for example, .ram, .rm, .smil)occurring at the end of the URL.

String MatchingUse the string matching option to populate the RTSP servers withcontent-specific information. For example, you have clients accessingaudio-video files on Nortel1 and clients accessing audio-video files onNortel2. You can host theNortel1 media files on media servers 5 and 6 andhost Nortel2 media files on media servers 7 and 8.




.


Layer 7 RTSP Load Balancing

Follow this procedure to configure the topology illustrated in "Layer 7 RTSPLoad Balancing" (page 275):

Step Action

1 Before you start configuring RTSP load balancing, configurethe application switch for standard server load balancing asdescribed in "Configuring Server Load Balancing" (page 194):

• Connect each Media server to the application switch

• Configure the IP addresses on all devices connected to theswitch


• Enable server load balancing (/cfg/slb/on)

• Enable client processing at the client port (/cfg/slb/port1/client ena)

• Enable server processing at the server ports 2 and 7

(for example, /cfg/slb/port 2/server ena)


• Disable Bandwidth Management




.



2 Configure IP addresses for the real servers.

















3 Create a group to support RealNetworks servers.






4 Create a group to support QuickTime servers.






5 Create a virtual server for group 1 media servers.

Configure a virtual server and select rtsp or port 554 as a servicefor the virtual server.




.








>>Virtual Server 1 rtsp Service# /cfg/slb/virt 1 ena


6 Configure URL hash-based RTSP load balancing for group1 servers.

URL hashing maintains persistency by enabling the client to hash tothe same media server.

>> Virtual Server 1 rtsp Service# rtspslb hash

7 Create another virtual server for group 2 media servers.

Configure a virtual server and select rtsp or port 554 as a servicefor the virtual server.



(Set IP address for thevirtual server)




>>Virtual Server 2 rtsp Service# /cfg/slb/virt 2 ena


8 Configure string matching-based RTSP load balancing forgroup 2 servers.

• Enable layer 7 pattern matching

>> Virtual Server 2 rtsp Service# rtspslb pattern

(Enable Layer 7 patternmatching)

• Add URL strings.




.


>> # /cfg/slb/layer7/slb/addstr nortel1.mov

(Add URL strings)

>> Server Loadbalance Resource# addstr nortel2.mov

• Apply and save the configuration.

>> Server Loadbalance Resource# apply>> Server Loadbalance Resource# save

• Identify the defined string IDs.

>> Server Loadbalance Resource# cur

For easy configuration and identification, each defined string hasan ID attached, as shown in the following example:

Number of entries: three

ID SLB String

1 any, cont 1024

2 nortel1.mov, cont 1024

3 nortel2.mov, cont 1024

• Add the defined string IDs to the real servers as shown in "Layer7 RTSP Load Balancing" (page 275).

>> # /cfg/slb/real 5/layer7>> Real server 5 Layer 7 Commands# addlb 2>> Real server 5# /cfg/slb/real 6/layer7>> Real server 6 Layer 7 Commands# addlb 2>> Real server 6# /cfg/slb/real 7/layer7>> Real server 7 Layer 7 Commands# addlb 3>> Real server 7# /cfg/slb/real 8/layer7>> Real server 8 Layer 7 Commands# addlb 3


>> Real server 8# apply>> Real server 8# save

Clients retrieving RTSP://nortelnews.com/saleswebcast.rm hash tothe same media server—1, 2, 3, or 4.




.


A client request of the form RTSP://120.10.10.20/../nortel1.mov isload balanced between RTSP servers 5 and 6 using string matching.A client request of the form RTSP://120.10.10.20/../nortel2.mov isload balanced between RTSP servers 7 and 8.

—End—

Wireless Application Protocol SLBWireless Application Protocol ( WAP) is an open, global specification for asuite of protocols designed to allow wireless devices to communicate andinteract with other devices. It empowers mobile users with wireless devicesto easily access and interact with information and services instantly byallowing non-voice data, such as text and images, to pass between thesedevices and the Internet. Wireless devices include cellular phones, pagers,Personal Digital Assistants (PDAs), and other hand-held devices.

WAP supports most wireless networks and is supported by all operatingsystems—with the goal of inter-operability. A WAP Gateway translatesWireless Markup Language (WML)—which is a WAP version of HTML—intoHTML/HTTP so that requests for information can be serviced by traditionalWeb servers.

To load balance WAP traffic among available parallel servers, the switchmust provide persistency so that the clients can always go to the same WAPgateway to perform WAP operation.

"Load Balancing WAP Gateways" (page 279) shows the user is firstauthenticated by the remote access server. In this example the RADIUSservers are integrated with the WAP gateways.

Load Balancing WAP Gateways




.


Nortel Application Switch Operating System allows you to configure theNortel Application Switch to select a WAP gateway for each client requestbased on one of the following three methods: static session entry via TPCP,RADIUS snooping, or RADIUS/WAP persistence.

The following topics are discussed in this section:

• "WAP SLB with RADIUS Static Session Entries" (page 280)

• "WAP SLB with RADIUS Snooping" (page 283)

• "WAP SLB with Radius/WAP Persistence" (page 287)

WAP SLB with RADIUS Static Session EntriesRADIUS, a proposed IETF standard is a client/server protocol that enablesremote access servers to communicate with a central server to authenticatedial-in users and authorize their access to the requested network or service.RADIUS allows a company to maintain user profiles in a central databasethat all remote servers can share. It provides better security, allowing acompany to set up a policy that can be applied at a single administerednetwork point.

The RADIUS server uses a static session entry to determine which realWAP gateway should receive the client sessions. Typically, each WAPgateway is integrated with a RADIUS server on the same host, and aRADIUS request packet is allowed to go to any of the RADIUS servers.Upon receiving a request from a client, the RADIUS server instructs theswitch to create a static session entry in the switch via Transparent ProxyControl Protocol (TPCP). TPCP is an Nortel proprietary protocol that is usedto establish communication between the RADIUS servers and the NortelApplication Switch. It is UDP-based and uses ports 3121, 1812, and 1645.

The RADIUS servers use TPCP to add or delete static session entries onthe switch. Typically, a regular session entry is added or removed by theswitch itself. A static session entry, like a regular session entry, containsinformation such as the client IP address, the client port number, real portnumber, virtual (destination) IP address, virtual (destination) port number.

A static session entry added via TPCP to the switch does not age out.The entry will only be deleted by another TPCP Delete Session request.If the user adds session entries using the traditional server load balancingmethods, the entries will continue to age out.

Because TPCP is UDP-based, the Add/Delete Session requests may getlost during transmission. The WAP gateway issues another Add Sessionrequest on detecting that it has lost a request. The WAP gateway detectsthis situation when it receives WAP traffic that does not belong to that WAPgateway. If a Delete Session request is lost, it is overwritten by anotherAdd Session request.




.


How WAP SLB Works with Static Session Entries

1. On dialing, the user is first authenticated by the Remote AccessServer (RAS).

2. The RAS sends a RADIUS authentication request to one of theRADIUS servers, which can be integrated with a WAP gateway.

3. If the user is accepted, the RADIUS server determines which WAPgateway is right for this user and informs the switch of the decisionvia TPCP.

4. The switch receives a request from the RADIUS server and addsa session entry to its session table to bind a WAP gateway withthat user.

5. A response packet is sent back to the RAS by the RADIUS server.

6. The RAS receives the packet and allows the WAP traffic for thatuser.

7. If the user disconnects, the RAS detects it and sends thisinformation to the RADIUS server.

8. The RADIUS server removes the session entry for that user.

Configuring WAP SLB using Static Session EntriesFollow this procedure to configure the topology illustrated in "Load BalancingWAP Gateways" (page 279):

Step Action

1 Before you start configuring WAP load balancing:

• Enable layer 3 server load balancing.

>> # /cfg/slb/virt <number> /layr3 ena

• Enable UDP under the WAP services (ports 9200 to 9203) menu.

>> # /cfg/slb/virt <number> /service <name|number>/udp ena

• Configure for RADIUS services 1812, 1813, and 1645.


Note: The radius service number specified on the switch mustmatch with the service specified on the server.




.


2 At the Nortel Application Switch, configure the switch for basicSLB.

>> # /cfg/slb/on

3 Configure IP addresses for the RADIUS/WAP Gateways.

>> # /cfg/slb/real 1/rip1.1.1.100

(Define address for WAPGateway1)


>> # /cfg/slb/real 2/rip2.2.2.100

(Define address for WAPGateway 2)


>> # /cfg/slb/real 3/rip3.3.3.100



4 Create a group to load balance the WAP Gateways.





5 Enable the external notification from WAP gateway to add anddelete session request if you are using static session via TPCP.

>> # cfg/slb/adv/tpcp ena

6 Enable TPCP for adding and deleting WAP sessions.

>> # cfg/slb/wap/tpcp ena


>> WAP Options# apply>> WAP Options# save

—End—




.


WAP SLB with RADIUS SnoopingRADIUS snooping is similar to the static session entry method in the waythat a static session entry is added to (or removed from) the switch for theWAP traffic for a user; it is different from the static session entry methodin the way that RADIUS accounting packets are snooped by the NortelApplication Switch instead of by the RADIUS server using TPCP.

Radius snooping allows the Nortel Application Switch to examine RADIUSaccounting packets for client information. This information is needed to addto or delete static session entries in the switch’s session table so that it canperform the required persistency for load balancing. A static session entrydoes not age out. Such an entry, added using RADIUS snooping, will onlybe deleted using RADIUS snooping. The switch load balances both theRADIUS and WAP gateway traffic using the same virtual server IP address.

How WAP SLB Works with RADIUS SnoopingBefore the RAS allows the WAP traffic for a user to pass in and out ofthe gateway, it sends a RADIUS Accounting Start message to one of theRADIUS servers. The switch then snoops on the packet to extract therequired information. It needs to know the type of the RADIUS Accountingmessage, the client IP address, the caller ID, and the user’s name. If itfinds this information, the switch adds a session entry to its session table.If any of this information is missing, the switch does not take any actionto handle the session entry.

When the client ends the WAP connection, RAS sends RADIUS AccountingStop packet. If the switch finds the needed information in a RADIUSAccounting Stop packet, it removes the corresponding session entry from itstable. The following steps occur for RADIUS snooping:

Step Action

1 The user is authenticated on dialing.

2 The RAS establishes a session with the client and sends aRADIUS Accounting Start message with the client IP addressto the RADIUS server.

3 The switch snoops on the RADIUS accounting packet and addsa session entry if it finds enough information in the packet.

4 The switch load balances the WAP traffic to a specific WAPgateway.

5 When the client terminates the session, the RAS sends anAccounting Stop message to the RADIUS server, and thesession entry is deleted from the switch.




.


Consider the following items before configuring RADIUS snooping:

• The same virtual server IP address must be used when loadbalancing both the RADIUS accounting traffic and WAP traffic.

• All the RADIUS servers must use the same UDP port forRADIUS accounting services.

• Before a session entry is recorded on the switch, WAP packetsfor a user can go to any of the real WAP gateways.

• If a session entry for a client cannot be added because ofresource constraints, the subsequent WAP packets for that clientwill not be load balanced correctly. The client will need to dropthe connection and then reconnect to the wireless service.

• The persistence of a session cannot be maintained if the numberof healthy real WAP gateways changes during the session. Forexample, if a new WAP server comes into service or some of theexisting WAP servers are down, the number of healthy WAPgateway changes and, in this case, the persistence for a usercannot be maintained.

• Persistence cannot be maintained if the user moves from oneISP to another, or if the base of the user’s session changes(that is, from CALLING_STATION_ID to USER_NAME, orvice versa). For example, if a user moves out of a roamingarea, it is possible that his/her CALLING_STATION_ID isnot available in the RADIUS Accounting packets. In such acase, the switch uses USER_NAME to choose a WAP serverinstead of CALLING_STATION_ID. Thus, persistence cannotbe maintained.

—End—

Configuring WAP SLB using Radius SnoopingFollow this procedure to configure the topology illustrated in "Load BalancingWAP Gateways" (page 279):

Step Action

1 Before you start configuring WAP load balancing:

• Enable layer 3 server load balancing.

>> # /cfg/slb/virt <number> /layr3 ena

• Enable UDP under the WAP services (ports 9200 to 9203) menu.




.



• Configure for RADIUS services 1812, 1813, and 1645.




>> # /cfg/slb/on


>> # /cfg/slb/real 1/rip1.1.1.100



>> # /cfg/slb/real 2/rip2.2.2.100



>> # /cfg/slb/real 3/rip3.3.3.100








5 Enable the external notification from WAP gateway to add anddelete session request if you are using static session via TPCP.

>> # cfg/slb/adv/tpcp ena

6 Enable TPCP for adding and deleting WAP sessions.




.


>> # cfg/slb/wap/tpcp ena

7 Configure the following filter on the switch to examine aRADIUS accounting packet. Set the basic filter parameters

>> # /cfg/slb/filt 1 (Select the filter)

>> Filter 1 # ena (Enable the filter)

>> Filter 1 # dip 10.10.10.100 (Set the destination IPaddress)

>> Filter 1 # dmask255.255.255.255

(Set the destination IPmask)

>> Filter 1 # proto udp (Set the protocol to UDP)

>> Filter 1 # dport 1813 (Set the destination port)

>> Filter 1 # action redir (Set the action to redirect)

>> Filter 1 # group 1 (Set the group forredirection)

>> Filter 1 # rport 1813 (Set server port forredirection)

8 Enable proxy and RADIUS snooping.

>> Filter 1 # adv (Select the advanced filtermenu)

>> Filter 1 Advanced# proxy ena (Enable proxy)

>> Filter 1 Advanced# layer7 (Select the Layer 7advanced menu)

>> Layer 7 Advanced# rdsnp ena (Enable RADIUS snooping)


>> Layer 7 Advanced# apply>> Layer 7 Advanced# save

Note: Nortel Application Switch Operating System supportsVirtual Router Redundancy Protocol (VRRP) and statefulfailover, using both static session entries and RADIUS snooping.However, active-active configuration with Stateful Failover is notsupported.

—End—




.


WAP SLB with Radius/WAP PersistenceThis feature allows for RADIUS and WAP persistence by binding both(RADIUS accounting and WAP) sessions to the same server.

A WAP client is first authenticated by the RADIUS server on UDP port1812. The server replies with a Radius Accept or Reject frame. The switchforwards this reply to the RAS. After the RAS receives the Radius acceptpacket, it sends a RADIUS accounting start packet on UDP port 1813 to thebound server. The application switch snoops on the RADIUS accountingstart packet for the "framed IP address" attribute. The "framed IP address"attribute is used to rebind the RADIUS accounting session to a new server.

The following steps occur for RADIUS/WAP persistence:

Step Action

1 The user is authenticated on dialing.

The RAS sends a RADIUS authentication request on UDP port1812 to one of the servers. The switch receives the authenticationrequest. If there is no session corresponding to this request, a newsession is allocated and the client is bound to a server. The switchthen relays the authentication request to the bound server.

2 The RAS establishes a session with the client and sends aRADIUS Accounting Start message to the RADIUS server onUDP port 1813.

3 The switch snoops on the RADIUS accounting start packet forthe "framed IP address" attribute.

This attribute in a RADIUS accounting packet contains the IPaddress of the specific client (the IP address of the wireless device).

Note: The RADIUS accounting packet and the RADIUSaccounting service must share the same rport.

4 The "framed IP address" attribute is used to rebind the RADIUSsession to a new server.

The application switch hashes on the framed IP address to selecta real server for the RADIUS accounting session. If the "framedIP address" is not found in the Radius accounting packet, thenpersistence is not maintained for the Radius/WAP session. Theload balancing metric of the real server group has to be hash forRadius/WAP Persistence

5 When the client begins to send WAP requests to the WAPgateways on ports 9200–9203, a new session is allocated and aserver is bound to the WAP session.




.


The RADIUS session and the WAP session are now both bound tothe same server because both sessions are using the same sourceIP address.

—End—

Configuring WAP SLB using Radius/WAP PersistenceFollow this procedure to configure the topology illustrated in "Load BalancingWAP Gateways" (page 279):

Step Action


>> # /cfg/slb/on


>> # /cfg/slb/real 1/rip1.1.1.100



>> # /cfg/slb/real 2/rip2.2.2.100



>> # /cfg/slb/real 3/rip3.3.3.100





>>Real Server Group 100# metrichash

(Select hash as loadbalancing metric)




4 Configure a virtual server.




.


>> # cfg/slb/virt 1/vip10.10.10.10

>>Virtual Server 1# ena (Enable virtual server 1)

5 Configure the services for virtual server 1.


>>Virtual Server 1# service 1812>>Virtual Server 1 radius-auth service# udp ena>>Virtual Server 1 radius-auth service# /cfg/slb/virt1/service 1813>>Virtual Server 1 radius-acc service# udp ena>>Virtual Server 1 radius-auth service# /cfg/slb/virt1/service 9200>>Virtual Server 1 9200 service# udp ena>>Virtual Server 1 radius-auth service# /cfg/slb/virt1/service 9201>>Virtual Server 1 9201 service# udp ena>>Virtual Server 1 radius-auth service# /cfg/slb/virt1/service 9202>>Virtual Server 1 9202 service# udp ena>>Virtual Server 1 radius-auth service# /cfg/slb/virt1/service 9203>>Virtual Server 1 9203 service# udp ena

6 Configure the following filter on the switch to examine aRADIUS accounting packet. Set the basic filter parameters.


>> Filter 1 # ena (Enable the filter)

>> Filter 1 # dip 10.10.10.10 (Set the destination IPaddress)

>> Filter 1 # dmask255.255.255.255

(Set the destination IPmask)

>> Filter 1 # proto udp (Set the protocol to UDP)

>> Filter 1 # dport 1813 (Set the destination port)

>> Filter 1 # action redir (Set the action to redirect)

>> Filter 1 # group 100 (Set the group forredirection)

>> Filter 1 # rport 1813 (Set server port forredirection)

7 Enable RADIUS/WAP persistence.




.



>> Layer 7 Advanced# rdswap ena (Enable RADIUS/WAPpersistence)

8 Enable client and server ports and enable filtering on clientports.

>> # /cfg/slb/port 1/client ena

>> SLB port 1# filt ena (Enable filtering on port 1)

>> SLB port 1# /cfg/slb/port 2>> SLB port 2# /cfg/slb/server ena>> SLB port 1# /cfg/slb/port 3>> SLB port 3# /cfg/slb/server ena>> SLB port 3# /cfg/slb/port 4>> SLB port 4# /cfg/slb/server ena



—End—

Intrusion Detection System SLBIntrusion Detection System (IDS) is a type of security management systemfor computers and networks. An Intrusion Detection System gathers andanalyzes information from various areas within a computer or a networkto identify possible security breaches, which include both intrusions(attacks from outside the organization) and misuse (attacks from withinthe organization).

Intrusion detection functions include:

• Monitoring and analyzing both user and system activities

• Analyzing system configurations and vulnerabilities

• Assessing system and file integrity

• Recognizing patterns typical of attacks

• Analyzing abnormal activity patterns

• Tracking user policy violations




.


Intrusion detection devices inspect every packet before it enters a network,looking for any signs of an attack. The attacks are recorded and logged inan attempt to guard against future attacks and to record the informationabout the intruders.

IDS server load balancing helps scale intrusion detection systems since it isnot possible for an individual server to scale information being processed atGigabit speeds.

How Intrusion Detection Server Load Balancing WorksNortel Application Switch Operating System allows the switch to forward acopy of the IP packets to an Intrusion Detection server. IDS SLB must beenabled on the incoming ports and enabled for the groups containing theIDS real servers. The IDS SLB-enabled switch copies packets enteringIDS-enabled ports. An SLB session is created on the switch to a group ofintrusion detection servers. The IDS server is selected based on the IDSgroup metric.

The following list summarizes the primary steps involved in configuringIDS load balancing:

Step Action

1 Set up the IDS servers.

Determine if you want to setup the IDS servers in stealth mode(without IP addresses) or with non-routable IP addresses. See"Setting Up IDS Servers" (page 292) for more information aboutsetting up IDS servers.

2 Create the IDS groups.

Create real server groups for the IDS servers. You may createmultiple IDS groups to segregate incoming traffic based on protocols.

• Choose the metric for the group: hash

• Choose the health check for the group: link, icmp, arp, or snmp

• Enable IDS on the group

• Select the type of traffic that is captured by the group by definingthe IDS rport value. (The default for IDS rport is any).

If multiple groups are configured for the same rport then onlyONE of the groups is used for server load balancing.

3 Enable IDS on the incoming ports (both client and server ports).

Enabling IDS at the port level enables the Nortel Application Switchto make a copy of the frames ingressing the port and forward thecopy to the IDS server group.




.


4 Configure filter processing on the incoming ports with the IDShash metric.

This allows a session entry to be created for frames ingressing theport. IDS load balancing requires a session entry to be created inorder to store the information regarding which IDS server to sendthe request.

If the allow filter is configured to hash on both the client and serverIP address, then this ensures that both client and server trafficbelonging to the same session is sent to the same IDS server. Formore information, see "Example 2: Load Balancing to Multiple IDSGroups" (page 298). If the port is configured for client processingonly, then the switch hashes on the source IP address only.

—End—

Setting Up IDS Servers"Setting Up IDS Servers" (page 292) shows how an Nortel ApplicationSwitch can be configured depending on the type of IDS server.

Setting Up IDS Servers

IDS ServerConfiguration

HealthCheckType

Port Configuration Explanation

Stealth mode (without IPaddressesor dummy IPaddresses)

Link –IDS servers mustdirectly connect toseparate physicalports on the switch.–Real server # of IDSserver must matchthe physical port # (1to 26) on the switch

To send packets to differentIDS servers you must connectIDS servers to separate switchports and associate them withdifferent VLANs and tag thepackets accordingly. Becauseunmodified frames are sent to theIDS servers, the switch does notuse the L2 destination field of thepacket to direct it to the correctIDS server.

The switch port or the VLAN tagis used to identify the destinationIDS server. However, if theingress packet is already tagged,then you must use different switchports for different IDS servers.




.


IDS ServerConfiguration

HealthCheckType

Port Configuration Explanation

Stealth mode (without IPaddressesor dummy IPaddresses)

SNMP

IDS servers need notbe directly connectedto the applicationswitch.The IDSservers may beconnected toanother switch viaan interswitch linkbetween it and theapplication switch.SNMP health checksare used to check thestatus of a port on theremote switch, that isconnected to an IDSserver.

To send packets to different IDSservers you must connect IDSservers to separate switch portsand associate them with differentVLANs. Because unmodifiedframes are sent to the IDSservers, the switch does not usethe L2 destination field of thepacket to direct it to the correctIDS server.

The VLAN tag is used to identifythe destination IDS server.However, if the ingress packet isalready tagged, then you mustuse different VLANs for differentIDS servers.

With IPaddresses

ICMP orARP

IDS servers need notbe directly connectedto the applicationswitch.The IDSservers may beconnected via anNortel ApplicationSwitch or a Layer 2switch.

The data packet is modified,so that it is addressed to theIDS servers. Destination MACaddress is changed to Real serverMAC address.

IDS Load Balancing ConfigurationsThe following three examples illustrate IDS load balancing in two differentnetwork environments. In "Example 1: Load Balancing to a Single IDSGroup" (page 294), one switch is dedicated to load balancing two IDSservers in a single group and a second switch is performing standardserver load balancing. In "Example 2: Load Balancing to Multiple IDSGroups" (page 298), a single switch is performing both IDS load balancingand standard server load balancing. In example 2, two IDS groups areconfigured—IDS group 51 is for HTTP traffic only and IDS group 52 is for allother traffic. In "Example 3: Load Balancing IDS Servers Across MultipleSwitches" (page 303), two switches in a high availability configuration areconnected to each other via a trunked interswitch link that is associatedwith all VLANs configured on the switch. Each switch is connected to IDSservers that are each on different VLANs but belong to the same IDS group.




.


A feature to disable source MAC address learning across the interswitchlink, allows traffic to reach real servers even when one switch goes intothe Standby state.

Example 1: Load Balancing to a Single IDS Group"Server Load Balancing and IDS Load Balancing to a Single Group" (page294) illustrates a basic configuration for load balancing client and servertraffic to the IDS servers. Nortel Application Switch 1 (an Nortel ApplicationSwitch 2424) is performing IDS load balancing and Nortel ApplicationSwitch 2 is performing standard server load balancing. IDS is enabled onthe client port (port 25) and both the firewall ports (ports 26 and 27).

Note: While this example assumes use of an Nortel Application Switch2424, you may adapt this example according the ports available on yourparticular Nortel Application Switch model.

Server Load Balancing and IDS Load Balancing to a Single Group

When the client request enters port 25 on Nortel Application Switch 1, theswitch makes a copy of the packet. The switch load balances the copiedpacket between the two IDS servers based on the configured load balancingmetric (hash). The original data packet however, enters Nortel ApplicationSwitch 2 through the firewall and Nortel Application Switch 2 performsstandard server load balancing on the client data between the three realservers. The client request is processed and returned to Nortel Application




.


Switch 1 via the firewall. An allow filter at ports 26 and port 27 causes theNortel Application Switch to make a copy of the request and directs thecopy to the IDS server group.

Follow this procedure to configure the topology illustrated in "Server LoadBalancing and IDS Load Balancing to a Single Group" (page 294):

Step Action


To configure the IDS servers as real servers you must considerthe setup of the IDS servers and the selection of the health check.Typically, most IDS servers are setup in stealth mode (withoutIP addresses); but, they can also be set up with non-routable IPaddresses. See "Setting Up IDS Servers" (page 292) for moreinformation about setting up IDS servers.

2 At the Nortel Application Switch, configure the IDS servers asreal servers.

In "Server Load Balancing and IDS Load Balancing to a SingleGroup" (page 294) the IDS servers are configured in stealth mode.Match the real server number with the physical port number to whichthe IDS servers are connected, and configure dummy IP addresses.The real servers must be numbered between 1-63.


(Define a dummy IPaddress for IDS server 6)


(Define a dummy IPaddress for IDS server 7)

3 Create a group and add the IDS servers.

The group must be numbered between 1–63.


>>Real Server Group 50# add 6 (Add IDS server 6)


4 Define the group metric for the IDS server group.

IDS server load balancing supports the hash metric only.


(Set the metric to hash)

5 Define the health check for the group.




.


Configure link health check which is specifically developed for IDSservers set up in stealth mode (without IP addresses).

>>Real Server Group 50# healthlink

(Set the health check tolink)

6 Define the group for IDS server load balancing.

>>Real Server Group 50# ids ena (Enable IDS for the servergroup)

7 Select the rport for the IDS group.

>>Real Server Group 50# idsrprt any

8 Enable IDS on the client and server ports.

This enables frames ingressing the port to be copied to the IDSservers.

>># /cfg/slb/port 25/ids ena (Enable IDS processing forport 25)

>>SLB port 25# /cfg/slb/port26/ids ena

(Enable IDS processing forport 26)



In addition to enabling IDS at the port level, a filter must beconfigured to create a session entry for non-SLB frames ingressingthe port. IDS load balancing requires a session entry to be createdto store the information regarding which IDS server to send to.

9 Create an allow filter and configure the filter with the idshashmetric.

>> # /cfg/slb/filt 2048 (Select the menu for Filter2048)

>> Filter 2048# sip any (From any source IPaddress)

>> Filter 2048# dip any (To any destination IPaddress)

>> Filter 2048# action allow (Allow matching traffic topass)




.


>> Filter 2048# ena (Enable the filter)

>> Filter 2048# adv/idshashboth

(Set the hash metricparameter)

The IDS hash metric is set to hash on both the source anddestination IP addresses. Hashing on both source and destinationIP address ensures that the returning traffic goes to the same IDSserver. If the port is configured for client processing only, then theswitch hashes on the source IP address. By default, the IDS hashmetric hashes on the source IP address only.

10 Apply the allow filter to ports 25, 26, and 27.

The allow filter must be applied on all ports that require layer 4 trafficto be routed to the IDS servers.

>> Filter 2048# /cfg/slb/port25

(Select the client port)

>> SLB Port 25# add 2048 (Apply the filter to the clientport)

>> SLB Port 25# filt ena (Enable the filter)

>> SLB Port 25# /cfg/slb/port26

(Select port 26)

>> SLB Port 26# add 2048 (Apply the filter to port 26)



(Select port 27)



All ingressing traffic at these ports that match any of the filtersconfigured for that port will be load balanced to the IDS groups. Theallow filter is used at the end of the filter list to make sure that alltraffic matches a filter. A deny all filter could also be used as the finalfilter instead of an allow all filter.


>> SLB Port 25# apply>> SLB Port 25# save

12 Configure Nortel Application Switch 2 to load balance the realservers as described in "Configuring Server Load Balancing"(page 194) .




.



• Configure the SLB real servers and add the real servers to thegroup

• Configure the virtual IP address

• Configure the SLB metric

• Enable SLB

A copy of layer 4 traffic from clients A, B, and C and from the realservers are directed to the IDS servers and load balanced betweenIDS servers 6 and 7.

—End—

Example 2: Load Balancing to Multiple IDS Groups"Server Load Balancing and IDS Load Balancing" (page 298) illustratesa single Nortel Application Switch performing both standard server loadbalancing and IDS server load balancing. In this example, two IDS groupsare configured—IDS group 51 is for HTTP traffic only and IDS group 52is for all other traffic.

Server Load Balancing and IDS Load Balancing

When the same Nortel Application Switch is configured to load balancereal servers and IDS servers as shown in "Server Load Balancing and IDSLoad Balancing" (page 298), filter processing is not required on the clientprocessing port (port 25). To maintain session persistency however, if you




.


add the filter to the client port, the switch can be configured to hash on boththe client IP and virtual server IP. This ensures that both client and servertraffic belonging to the same session is sent to the same IDS server. Ifyou do not add the filter on port 25, then the switch hashes on the clientIP address only.


Follow this procedure to configure the topology illustrated in "Server LoadBalancing and IDS Load Balancing" (page 298):

Step Action


Refer to "Setting Up IDS Servers" (page 292) for information onsetting up the IDS servers. To configure the IDS servers as realservers you must consider the following:

• Connecting the IDS servers

• Choosing the health check

• Configuring the IP addresses

For more information on each of the above items, see step 1 onstep 1.

2 Configure the IDS servers as real servers.

In "Server Load Balancing and IDS Load Balancing" (page 298) theIDS servers are setup with non-routable IP addresses. The realservers must be numbered 1-63.


(Specify IP address for IDSserver 6)


(Specify IP address forIDS server 7)


(Specify IP address for IDSserver 8)

3 Create two IDS groups and add the IDS servers.

Define the two IDS groups 51 and 52. The IDS group numbers mustbe between 1 to 63.




.





>>Real Server Group 51#/cfg/slb/group 52

(Define another group)


4 Define the group metric for the IDS server groups.





(Select the other IDS group)



The hash metric is implemented in two ways. For more information,see step 4 on step 4.


Configure ICMP health check for the group.

>>Real Server Group 51# healthicmp

(Set the health check toICMP)



>>Real Server Group 52# healtharp

(Set the health check toARP)


>>Real Server Group 51# idslbena

(Enable IDS for the IDSserver group)



>>Real Server Group 52# idslbena

(Enable IDS for the IDSserver group)





.


>> # /cfg/slb/group 51 (Select the IDS group)

>>Real Server Group 51# idsrprthttp

(Select HTTP traffic for IDSgroup)


(Select the IDS group)

>>Real Server Group 52# idsrprt any (Select non-HTTP trafficfor IDS group)

8 Enable IDS on the client and server processing ports.

This enables frames ingressing the port to be copied to the IDSservers.

>># /cfg/slb/port 25/idslb ena (Enable IDS SLB for port25)

>>SLB port 25# /cfg/slb/port2/idslb ena

(Enable IDS SLB for port 2)












>> Filter 2048# adv/idshashboth

(Set the hash metricparameter)




.


The IDS hash metric is set to hash on both the source anddestination IP addresses. Hashing on both source and destinationIP address ensures that the returning traffic goes to the same IDSserver. By default, the IDS hash metric hashes on the source IPaddress only.

10 Apply the filter to ports 2, 3, 4 and 25 only.

Enable filter processing on all ports that have IDS enabled.

If you add the allow filter to the client port 25, the switch will hashon client IP and virtual server IP address for both client and serverframes. This ensures that both client and server traffic belongingto the same session is sent to the same IDS server. If you do notadd the allow filter on port 25, then the switch hashes on client IPonly for client frames and hashes on client IP and virtual server IPaddress for server frames.

>> # /cfg/slb/port 2 (Select the port menu)



>> SLB Port 2# /cfg/slb/port 3 (Select port 3)











A copy of layer 4 Web traffic from clients A, B, and C and from thereal servers 1, 2, and 3 is load balanced between IDS servers 6 and7. A copy of all non-HTTP traffic is directed to IDS server 8.

12 Configure the switch for server load balancing the real serversas described in "Configuring Server Load Balancing" (page 194).





.


• Configure and create a group for the SLB real servers



• Enable SLB

—End—

Example 3: Load Balancing IDS Servers Across MultipleSwitchesNortel Application Switch Operating System supports load balancingIDS servers across multiple Application switches in a high availabilityconfiguration. By allowing the administrator to disable learning of clientand server source MAC addresses over the interswitch link, client requestpackets are able to reach the real servers when switch failover occurs.

In "Load Balancing IDS Servers Across Two Switches" (page 303), theswitches are connected to each other via a trunked interswitch link (ports25 and 26) that is associated with all VLANs configured on the switch.Each switch is connected to IDS servers that are each on different VLANsbut belong to the same IDS group. For VLAN-based IDS load balancing,the ingress packets are copied by the master switch and flooded to theIDS servers for monitoring through the path associated with an IDS VLAN.Since the inter-switch link is also associated with this IDS VLAN, the copiedpacket passes through the inter-switch link and is flooded to the IDS VLANon the standby switch.

Load Balancing IDS Servers Across Two Switches




.


Normally, the standby switch will learn the source MAC address of clients inthe copied packet from the port that is connected to the inter-switch link.The standby switch also learns the source MAC address of the server whenthe server response packets enter the master switch and are flooded to theIDS VLAN over the interswitch link.

In a high availability configuration, the standby switch becomes the masterif the current master switch fails. The new master switch forwards trafficbetween clients and servers. Because the MAC addresses of the realservers are learned via the inter-switch link port, the request packets fromclients are forwarded to the inter-switch link port on the new master switch,and are received by the new standby switch. Because the standby switchdoes not forward traffic, the request packets would not normally reach thereal servers.

Nortel Application Switch Operating System remedies this situation byallowing the administrator to disable learning of client and server sourceMAC addresses over the interswitch link, thus ensuring that when switchfailover occurs, the client request packets reach the real servers.


Follow this procedure to configure the topology illustrated in "Load BalancingIDS Servers Across Two Switches" (page 303):

Step Action


Refer to "Setting Up IDS Servers" (page 292) for information onsetting up the IDS servers. To configure the IDS servers as realservers you must consider the following:

• Connecting the IDS servers

• Choosing the health check—in this case, use SNMP health check

• Configuring the IP addresses

For more information on each of the above items, see step 1 onstep 1.

2 On the Nortel Application Switch, configure the interswitch linkports for the IDS VLAN.

/cfg/port 25/tag ena/pvid 1000/cfg/port 26/tag ena/pvid 1000

3 Configure trunk groups.




.


/cfg/l2/trunk 1/ena/add 25/add26

(Add ports 25, 26 to trunkgroup 1)

/cfg/l2/trunk 2/ena/add 27/add28

(Add ports 27, 28 to trunkgroup 2)

4 Configure an IP interface for the SNMP health check to theother switch.

/cfg/l3/if 3/addr 11.11.11.1/mask 255.255.255.255/vlan 1000

5 Configure VLANs. Make sure to disable source MAC addresslearning only on the IDS VLANs.

The following VLANS are configured on the switch:

• VLAN 1: for load balancing traffic to the real servers

• VLAN 1000: for performing SNMP health check on switch 2

• VLAN 1001: for IDS server 1



• VLAN 1004: for IDS server 4.

>> Main# /cfg/l2/vlan 1001/ena

>> VLAN 1001# learn dis (Disable source MAClearning on the IDS VLAN)

:

>> VLAN 1001# add 25/add 26 (Set port members of theVLAN)

Port 25 is an UNTAGGED port and its current PVID is1.Confirm changing PVID from 1 to 1001 [y/n]: yPort 26 is an UNTAGGED port and its current PVID is1.Confirm changing PVID from 1 to 1001 [y/n]: y

>> Layer 2# /cfg/l2/vlan 1001/ena/learn dis/add25/add 26>> Layer 2# /cfg/l2/vlan 1002/ena/learn dis/add25/add 26>> Layer 2# /cfg/l2/vlan 1003/ena/learn dis/add25/add 26>> Layer 2# /cfg/l2/vlan 1004/ena/learn dis/add25/add 26




.


6 Configure the IDS servers as real servers.

In "Server Load Balancing and IDS Load Balancing" (page 298) theIDS servers are setup with non-routable IP addresses. Thereal servers must be numbered 1-63. SNMP health checks areconfigured to check the status of the ports on switch 2 that areconnected to the IDS servers.


(Set IP address for IDSserver 1)

>> Real server 1 # ids/idsvlan1001

(Set IDS VLAN for IDSserver 1)

>> Real Server 1 IDS# idsport25

(Set IDS VLAN port)

>> Real Server 1 IDS# oid 1.3.6.1.2.1.2.2.1.8.257

(Set OID to health checkport 1)

>> # /cfg/slb/real 2/rip 11.11.11.1/ena >>

Real server 2 # ids/idsvlan 1002

>> Real Server 2 IDS# idsport 25

>> Real Server 2 IDS# oid 1.3.6.1.2.1.2.2.1.8.258

(Set OID to health checkport 2)


(Set the IP interface forswitch 2)

>> Real server 3 # ids/idsvlan 1003


>> Real Server 3 IDS# oid 1.3.6.1.2.1.2.2.1.8.259 (SetOID to health check port 3 on switch 2)

>> # /cfg/slb/real 4/rip 11.11.11.100/ena

>> Real server 4 # ids/idsvlan 1004


>> Real Server 4 IDS# oid 1.3.6.1.2.1.2.2.1.8.260 (SetOID to health check port 4 on switch 2)

7 Create an IDS group and add the IDS servers.

Define the IDS group. The IDS group numbers must be between1 to 63.






.





8 Define the group metric for the IDS server group.





>>Real Server Group 50# healthsnmp1

(Set the health check tolink)


>>Real Server Group 50# ids ena (Enable IDS for the servergroup)


>>Real Server Group 50# idsrprt80

(Set for service HTTP)

12 Enable IDS on the client and server ports.

This enables frames ingressing the traffic ports to be copied to theIDS servers.

/cfg/slb/port 4/ids ena (Enable IDS processing forport 4)

>>SLB port 4# /cfg/slb/port 7ids ena


>>SLB port 7# /cfg/slb/port 8ids ena









.



13 Configure an integer value for the switch to accept the SNMPhealth check.

If the value returned by the real server for the MIB variable does notmatch the expected value configured in the rcvcnt field, then theserver is marked down; the server is marked back up when it returnsthe expected value.

In this step, the server is marked down if the switch receives a value1; the real server is considered as health check failed.

>>SLB port 27# /cfg/slb/advhc/snmphc 1/rcvcnt "1"


The IDS hash metric is set to hash on both the source anddestination IP addresses. Hashing on both source and destinationIP address ensures that the returning traffic goes to the same IDSserver. If the port is configured for client processing only, then theswitch hashes on the source IP address. By default, the IDS hashmetric hashes on the source IP address only.

15 Apply the allow filter to ports 4, 7, 8, 27, and 28, to enable filterprocessing on all ports that have IDS enabled.

If you add the allow filter to the client port 4, the switch will hashon client IP and virtual server IP address for both client and serverframes. This ensures that both client and server traffic belonging tothe same session is sent to the same IDS server. If you do not addthe allow filter on port 5, then the switch hashes on client IP only forclient frames and hashes on client IP and virtual server IP addressfor server frames. The allow filter must be applied on all ports thatrequire layer 4 traffic to be routed to the IDS servers.

>> Filter 2048# /cfg/slb/port 4 (Select the client port)

>> SLB Port 4# add 2048 (Apply the filter to the IDSport)


>> SLB Port 4# /cfg/slb/port 7 (Select the IDS server 7port)

>> SLB Port 7# add 2048 (Apply the filter to the IDSport)




.



>> SLB Port 7# /cfg/slb/port 8 (Select the IDS server 8port)

>> SLB Port 2# add 2048 (Apply the filter to the clientport)


>> SLB Port 2# /cfg/slb/port 27 (Select the interswitch linkfor IDS)

>> SLB Port 27# add 2048 (Apply the filter to trafficport 27)



(Select the interswitch linkfor IDS)

>> SLB Port 28# add 2048 (Apply the filter to trafficport 28)


All ingressing traffic at these ports that match any of the filtersconfigured for that port will be load balanced to the IDS groups. Theallow filter is used at the end of the filter list to make sure that alltraffic matches a filter. A deny all filter could also be used as the finalfilter instead of an allow all filter.



17 Configure Nortel Application Switch 2 to load balance the realservers as described in "Configuring Server Load Balancing"(page 194).


• Configure the SLB real servers and add the real servers to thegroup



• Enable SLB

—End—




.


Session Initiation Protocol Server Load BalancingSession Initiation Protocol (SIP) is an application-level control (signalling)protocol for Internet multimedia conferencing, telephony, event notification,and instant messaging. The protocol initiates call setup, routing,authentication and other feature messages to endpoints within an IP domain.

SIP protocol is used to locate users (where the caller and called partiesare at), determine user capability (what type of protocol TCP, UDP, andother capabilities the user can support), user availability, call setup (howto create the call), and call handling (how to keep the call up and how tobring down the call).

This feature load balances SIP proxy servers such as Nortel MCS(Multimedia Communications Server) and TCP based implementations likeMicrosoft LCS (Live Communications Server).

SIP Processing on the SwitchSIP over UDP processing provides the capability to scan and hash callsbased on a SIP Call-ID header to a SIP server. The Call-ID uniquelyidentifies a specific SIP session. Future messages from the same Call-IDis switched to the same SIP server. This involves stateful inspection ofSIP messages.

SIP is a text based protocol with header lines preceding the content. LikeHTTP, the first header line has the method specification followed by otherheader lines that specify other parameters like Call-ID etc.

TCP based SIP ServersSIP processing provides the capability to hash calls based on the metricconfigured in the group.

TCP Health Check is new in this Release. It enhances TCP load balancingwith SIP ports.

Configuring SIP Server Load Balancing"Server Load Balancing and IDS Load Balancing" (page 298) illustrates anNortel Application Switch performing TCP-based SIP server load balancing.In this example, three SIP proxy servers are configured in a Real ServerGroup 100. The application switch is configured for SIP service (port 5060)for virtual server 40.40.40.100.




.


SIP Load Balancing

Follow this procedure to configure the topology illustrated in "SIP LoadBalancing" (page 311):

Step Action

1 At the Nortel Application Switch, before you start configuringSIP load balancing:

• Connect each SIP proxy server to the application switch

• Configure the IP addresses on all devices connected to theapplication switch

• Configure the IP interfaces on the application switch




>> # /cfg/slb/on

3 Configure IP addresses for the SIP proxy servers.

>> # /cfg/slb/real 1/rip10.10.10.1

(Define address for MCS 1)


>> # /cfg/slb/real 2/rip10.10.10.2





.



>> # /cfg/slb/real 3/rip10.10.10.3



4 Create a group to load balance the SIP proxy servers.





5 Define the group metric for the server group.

TCP based SIP load balancing supports all metrics. For example,set the metric to minmisses.

>>Real Server Group 100# metricminmiss

(Set the metric tominmisses)


The health check is TCP for TCP based SIP load balancing.

>>Real Server Group 100# healthtcp

(Set the health check to tcp)

7 Configure a virtual server for Layer 4 SIP load balancing.

>> # /cfg/slb/virt 1 (Select virtual server 1)



>>Virtual Server 1# virt ena (Enable virtual server)

8 Configure the SIP service 5060 for virtual server 1.

>> # /cfg/slb/virt 1/service5060

(Add the SIP service for virt1)

>> # /cfg/slb/virt 1/service5060 Group 100

(Add the real server groupto the service)

9 Configure the SIP TLS service 5061 for virtual server 1.




.


>> # /cfg/slb/virt 1/service5061/Group 100

(Configure the SIP TLSservice)

10 Enable DAM.


11 Increase the timeout for idle sessions.

SIP sessions are quite long and data may be flowing while thesignalling path is idle. Because the switch resides in the signallingpath, it is recommended to increase the Real server session timeoutvalue to 30 minutes (default value is 10 minutes).

>> # /cfg/slb/real 1/tmout 30 (Increase Real 1 sessiontimeout)



12 Configure Virtual service for RPC load balancing

>> /cfg/slb/virt/service 135

>>Virtual Server 1 135 service #group 1











>> SLB port 7# apply

>> SLB port 7# save




.


—End—

UDP based SIP serversSIP processing provides the capability to scan and hash calls based on aSIP Call-ID header to a SIP server. The Call-ID uniquely identifies a specificSIP session. Future messages from the same Call-ID is switched to thesame SIP server. This involves stateful inspection of SIP messages.

SIP is a text based protocol with header lines preceding the content. LikeHTTP, the first header line has the method specification followed by theother header lines that specify other parameters like Call-ID etc.

Configuring SIP Server Load Balancing"Server Load Balancing and IDS Load Balancing" (page 298) illustrates anNortel Application Switch performing UDP-based SIP server load balancing.In this example, three SIP proxy servers are configured in a Real ServerGroup 100. The application switch is configured for SIP service (port 5060)for virtual server 40.40.40.100.

SIP Load Balancing

Follow this procedure to configure the topology illustrated in "SIP LoadBalancing" (page 311):

Step Action

1 At the Nortel Application Switch, before you start configuringSIP load balancing:

• Connect each SIP proxy server to the application switch




.


• Configure the IP addresses on all devices connected to theapplication switch

• Configure the IP interfaces on the application switch




>> # /cfg/slb/on

3 Configure IP addresses for the SIP proxy servers.

>> # /cfg/slb/real 1/rip10.10.10.1



>> # /cfg/slb/real 2/rip10.10.10.2



>> # /cfg/slb/real 3/rip10.10.10.3



4 Create a group to load balance the SIP proxy servers.





5 Define the group metric for the server group.

Because SIP load balancing is done based on Call-ID, minmissesmetric only is supported to ensure persistency.

>>Real Server Group 100# metricminmiss

(Set the metric tominmisses)


Configure SIP PING request health check which is specificallydeveloped for SIP-enabled servers.




.


>>Real Server Group 100# healthsip

(Set the health check to sip)

7 Configure a virtual server for Layer 4 SIP load balancing.

>> # /cfg/slb/virt 1 (Select virtual server 1)



>>Virtual Server 1# virt ena (Enable virtual server)

8 Configure the SIP service 5060 for virtual server 1.

>>> # /cfg/slb/virt 1/service5060

(Add the SIP service for virt1)

>> # /cfg/slb/virt 1/service5060 Group 100

(Add the real server groupto the service)

9 Enable SIP server load balancing.

>>Virtual Server 1 sip Service# sip/sip ena

Enable SIP for virtual server1)

10 Enable DAM.

>>Virtual Server 1 sip Service # direct ena

11 Enable UDP load balancing

12 Increase the timeout for idle sessions.

SIP sessions are quite long and data may be flowing while thesignalling path is idle. Because the switch resides in the signallingpath, it is recommended to increase the Real server session timeoutvalue to 30 minutes (default value is 10 minutes).

When the call terminates with a BYE command, the applicationswitch releases the session entry immediately.







.


When the call terminates with a BYE command, the applicationswitch releases the session entry immediately.











>> SLB port 7# apply

>> SLB port 7# save

—End—

Enhancements to SIP Server Load BalancingNortel Application Switch Operating System 24.0 supports the followingenhancements to SIP server load balancing:

• User-defined SIP port

Allows you to modify the SIP port (previously, SIP port was supportedon UDP 5060 only).

To define the SIP port, enter the command:

>> Main# /cfg/slb/virt <Virtual Server> /service5060/rport <Port>

• Session persistency using the refer method

The refer method of load balancing SIP servers is required for ’calltransfer’ services. The refer method indicates that the recipient shouldcontact a third party using the contact information provided in therequest.

To maintain session persistency, the new request from the recipientto the third party should also hash the same real server. To maintain




.


persistency, whenever the switch receives a session configured for refermethod, Nortel Application Switch Operating System 24.0 creates apersistent session.

When creating a session for a new request Nortel Application SwitchOperating System looks up the session table and selects the correct realserver. If there is a persistent session, then the real server specified inthe session entry is used if that real server is up, otherwise the normalminmiss method is used to select the real server.

• Supports standard health check options

Nortel Application Switch Operating System 24.0 supports the standardmethod to health check SIP servers. The options method (like HTTPand RTSP) is supported by all RFC 3261 compliant proxies.

The application switch sends an options request to the SIP server whenconfigured to use the SIP options health check. If the response fromthe server is a "200 OK," then the server is operational, otherwise theserver is marked down.

To configure the SIP options health check, use the following command:

>> Main# /cfg/slb/virt<Virtual Server>/service5060/rport<Port>>> Main# /cfg/slb/group <Real ServerGroup> /health sipoptions

• Support for RTP (SDP) Media Portal NAT

This feature is useful if you have several media portal servers withprivate IP addresses. When the proxy servers respond to an INVITErequest, the private IP address of the Media Portal is embedded in theSDP. The switch translates this private IP address to a public IP address.

The private media portal address is sent in the response to an INVITErequest. The switch replaces the private IP with the public IP addressin the SDP.

To support media portal NAT, you must configure the following:

Step Action

1 Configure the private to public address mapping

>> Main# /cfg/slb/layer7>> Layer 7 Resource Definition# sdp>> SDP Mapping# add <private_IP> <public_IP>

2 Enable SDP Media Portal NAT.




.


>> Main# /cfg/slb/virt 1>> Virtual Server 1# service 14>> Virtual Server 1 14 Service# sip>> SIP Load Balancing# sdpnat

3 Create static NAT filters.

This allows RTP traffic destined for the public media portal addressto be translated to the actual private media portal address. Createstatic NAT filters to operate in both directions; one to translate thepublic address to the private address and one to translate the privateaddress to the public address.

For more information on static NAT filters, refer to "Static NAT" (page386).

—End—

SoftGrid Load BalancingSoftricity SoftGrid platform is used to provide sequenced applications froma SoftGrid Server to a SoftGrid Client. The Nortel Application SwitchOperating System supports load balancing tailored to the SoftGrid suite forthe delivery of sequenced applications and the maintaining of persistencywhile applications are launched from SoftGrid Client. Once an application isdelivered to SoftGrid Client it can be run on the client computer.

"SoftGrid Load Balancing Network Topology" (page 320) illustrates anexample of a SoftGrid Load Balancing network topology.




.


SoftGrid Load Balancing Network Topology

The SoftGrid platform supports TCP unicast connections using the followingprotocols:

Step Action

1 Real Time Streaming Protocol (RTSP)

RTSP is an application level protocol that is responsible for controllingthe transport of multimedia content, session announcements, andtear downs.

2 Real Time Transport Protocol (RTP)

RTP is used to transport the application data between server andclient.

3 Real Time Control Protocol (RTCP)

RTCP is used to control the streaming of the application data that istransported by RTP.

The SoftGrid platform uses three channels to complete theapplication delivery process. Initially, the SoftGrid Client uses theRTSP channel to create a connection with the SoftGrid Server.




.


The SoftGrid Server then opens two ports for the RTP and RTCPchannels and sends these port numbers to the Client. The Clientthen opens TCP connections to the ports created on the Server. Therequested application is then streamed over the RTP channel whilethe RTCP channel provides control over the RTP channel.

—End—

Configuring SoftGrid Load BalancingTo configure the SoftGrid Load Balancing feature, perform this procedure:

Step Action

1 Configure a host name for the Virtual IP address on the DNSserver.

Note: This step is performed on the network domain controller.

Make an entry in the network domain controller for the SoftGridServer. For example, <sw_name> 10.10.10.10 where <sw_name>was configured on the switch using the command cfg/slb/virt1/vname <sw_name>.

2 Edit the SoftGrid Server OSD files.

When the SoftGrid Platform is set up for load balancing, the .OSDfiles in SoftGrid Servers must be changed to point to the virtual IPaddress or virtual server name of the Nortel Application Switch inthe following manner:

rtsp:// <Switch VIP> :554/DefaultApp.sft ORrtsp:// <Switch Virtual NAME> :554/DefaultApp.sft

3 Enable SoftGrid Load Balancing.

>> Main# /cfg/slb/virt <virtual server number>/service rtsp/softgrid enable

If softgrid is enabled for a RTSP service, the softgrid RTSP modeperforms the RTSP server load balancing for that service.

—End—




.


Workload Manager SupportNortel Application Switch Operating System 24.0 supports theServer/Application State Protocol (SASP) used by the Enterprise WorkloadManagement (WLM).

The Workload Manager feature is used to monitor server resources andprovide additional input on load balancing decisions. The WorkloadManager takes into account a server’s CPU, storage capacity, and networktraffic in any final weighting decisions. The Workload Manager uses animplementation of the SASP protocol to perform this task.

The WLM software developed by IBM allows you to specify end-to-endperformance goals for distributed requests. WLM runs on an entityresponsible for reporting or managing a group of members. This entity isknown as the Domain Manager (DM). DM recommends a weight for eachapplication/server in the group. This weight recommendation is based onthe business importance, topology and ability of the system to meet itsbusiness goals. This recommended weights helps the application switchmake intelligent server load balancing decisions.

Nortel Application Switch Operating System 24.0 also supports WLM in theredirect filter environment.

The SASP protocol enables the application switch to

• receive traffic weight recommendations from DM

• register members of the application switch with DM

• enable GWM to propose new group members to the application switch

How the Application Switch works with the DMThe application switch initiates a TCP connection with the GWM for all theconfigured IP address and port numbers. After establishing the connection,the application switch registers various WLM-configured groups of realservers with the GWM.

In case of application load balancing, the representation of a member is thereal servers’s IP address and the application’s port and protocol. When themembers are registered, the GWM starts monitoring and computes theweight. The DM periodically sends the weights for all the registered groups.

When a real server is disabled/enabled operationally the switch sends arequest to temporarily remove the server from the weight calculation.

Configuring WLM SupportBefore you start configuring for WLM support, make sure you haveconfigured the following on the switch for all the groups and real serversparticipating in dynamic weights with WorkLoad Managers (WLM):

• switch name (/cfg/sys/ssnmp/name)




.


• group name (/cfg/slb/group #/name)

• real server names (/cfg/slb/real #/name)

You can configure up to 16 Work Load Managers (WLM).

Step Action

1 Configure the IP address and the TCP port number to connectto the WLM.

>> Main# /cfg/slb/wlm 11

>> Workload Manager 1# addr10.10.10.10

(IP address of the WLM)

>> Workload Manager 1# port 10 (TCP port to connect to theWLM)

2 Assign the WLM number to the server/application group.

>> Main# /cfg/slb/group 2>> Real Server Group 1# wlm 11>> Default gateway 1# apply

If the WLM number is not specified, then this group is not registeredwith the WLM. As a result, dynamic weights are not used for thisgroup.

3 Specify if WLM should use data or management port.

>> Main# /cfg/slb/mmgmt>> Management Port# wlm mgmt


>> Management Port# apply>> Management Port# save

—End—

Verifying WLM ConfigurationVerify WLM configuration with one or more of the following commands:

• Display WLM information.




.


>> Main# /info/slb/wlmWorkload Manager Information:ID IP address Port State1 47.81.25.66 3860 Connected

10 47.80.23.245 3860 Not Connected

• Display statistics on Work Load Manager 11.

>> Main# /stats/slb/wlm 11Workload Manager 11 Statistics:Registration Requests: 1Registration Replies: 1Registration Reply Errors: 0

Deregisteration Requests: 1Deregisteration Replies: 1Deregisteration Reply Errors: 0

Set LB State Requests: 1Set LB State Replies: 1Set LB State Reply Errors: 0

Set Member State Requests: 0Set Member State Replies: 0Set Member State Reply Errors: 0

Send Weights Messages received: 47Send Weights Message Parse Errors: 0Total Messages with Invalid LB Name: 0Total Messages with Invalid Group Name: 0Total Messages with Invalid Real Server Name: 0Messages with Invalid SASP Header: 0Messages with parse errors: 0Messages with Unsupported Message Type: 0

• Display weights updates for the WLM-configured group.




.


>> Main# /stats/slb/group 2Real server group 2 stats:

Total weight updates from WorkLoad Manager : 10

CurrentTotal HighestReal IP address Sessions SessionsSessions Octets---- ----------------- -------- ----------------- --------

1 1.1.1.1 0 0 0 02 2.2.2.2 0 0 0 03 3.3.3.3 0 0 0 04 4.4.4.4 0 0 0 0

---- ----------------- -------- ----------------- --------

group 2 0 0 0 0

• (Application load balancing) Display the current weight for the realservers for a particular service.

Note that the WLM-assigned weights are displayed as dynamic weight.

>> Main# /info/slb>> Server Load Balancing Information# virt 1

1: 10.10.7.1, 00:01:81:2e:a0:8evirtual ports:http: rport http, group 1, backup none, slowstart

real servers:1: 192.168.2.11, backup none, 0

ms, group ena, updynamic weight 20

2: 192.168.2.12, backup none, 0ms, group ena, up

dynamic weight 40

• (Application Redirection) Display the current weight for the real server.




.


>> Main# /info/slb>> Server Load Balancing Information# filt 224224: action allow

group 1, health 3, backup none, vlan any,content web.gif

thash auto, idsgrp 1proxy: enabledlayer 7 parse all packets: enabledreal servers:

1: 192.168.2.11, backup none, 0 ms, group ena, updynamic weight 40

• Clear WLM SASP statistics.

>> Main# /stats/slb/wlm <#> clear

Limitations for WLM SupportNortel Application Switch Operating System 24.0 does not support

• SASP over SSL

• Real server weights per service

If multiple services are configured to use the same group, then changingthe weight for one service affects the weight of real server for all otherservices.

• Workload manager deregistration after L2/L3 change

If you make any changes to the VLAN or IP Interface as the eWLMenvironment, then WLM-Deregistration updates is sent to all the DMs.

• Workload manager Deregistration after SLB change

WLM-deregistration is sent to all DMs after an SLB update.




.

WAN Link Load Balancing 327

WAN Link Load Balancing

WAN Link Load Balancing allows you to configure the Nortel ApplicationSwitch to balance user session traffic among a pool of available WAN Links.The following sections in this chapter provides conceptual information onWAN Link Load balancing:

• "Multi-homing" (page 327). This section provides an overview of theproduct and benefits of WAN link load balancing.

• "How WAN Link Load Balancing Works" (page 330). This sectiondiscusses in detail the path of the outbound and inbound traffic in aWAN link load balancing environment.

• "Configuring WAN Link Load Balancing" (page 336). This sectionprovides step-by-step procedures to configure the Nortel ApplicationSwitch for load balancing the WAN links in different environments.

— "Example 1: Simple WAN Link Load Balancing" (page 338)

— "Example 2: WAN Link Load Balancing with Server Load Balancing"(page 350)

For additional information on WAN link commands, refer Nortel ApplicationSwitch Operating System Command Reference.

Although WAN Link Load Balancing supports most IPv4 protocols,the following protocols may not be supported by this feature in typicalimplementations:

• IPv6-related protocols

• IP-within-IP Encapsulation Protocol (IPIP)

• Generic Routing Encapsulation (GRE)

• Encap Security Payload/Authentication Header (ESP/AH)

Multi-homingWAN link load balancing enables the Nortel Application Switch to provideFast Ethernet and Gigabit connectivity from corporate resources to multipleISP links to the Internet.

To handle the high volume of data on the Internet, corporations are usingmore than one Internet Service provider (ISP) as a way to increase reliabilityof Internet connections. Such enterprises with more than one ISP arereferred to as being multi-homed. In addition to reliability, a multi-homednetwork architecture enables enterprises to distribute load among multipleconnections and to provide more optimal routing.




.


Multi-homing is becoming essential for reliable networks, providingcustomers with protection against connectivity outages and unforeseen ISPfailures. Multi-homing also presents other clear opportunities for enterprisesto intelligently manage how WAN links are used. With link load balancingorganizations have greater flexibility to scale bandwidth and reducespending for corporate connectivity.

Nortel Application Switch software provides a solution for enterprises thatwish to optimize utilization of Internet connectivity. This comprehensivesolution helps enterprises to direct traffic over the best connection tomaximize performance, maximize corporate bandwidth investments, andeffectively remove existing deployment and management barriers formulti-homed networks.

Benefits of WAN Link Load BalancingTraditionally, corporations have used Border Gateway Protocol (BGP)to determine the optimal path of the WAN link for load balancing traffic.However, "WAN Link Load Balancing versus BGP" (page 328) shows theadvantages of implementing WAN link load balancing versus using BGP.

WAN Link Load Balancing versus BGP

WAN Link Load Balancing BGP

• easy to configure

• redundancy (if one of the ISP links godown, then the other ISP link takesover)

• backup (you can use a low speed ISPlink as a backup for a high speed ISPlink)

• ISP reaches its session limit, thenNortel Application Switch automaticallydeletes it from the group

• easy to manage

• complex to implement

• laborious to manage

• difficult to get an autonomoussystem number

• does not allow you to monitorthe WAN links for load, speedor health of devices on theother end of the link.

WAN link load balancing benefits your network in a number of ways:

• Performance is improved by balancing the request load across multipleWAN links. More WAN links can be added at any time to increaseprocessing power.

• Increased efficiency for WAN link utilization and network bandwidth

Your Nortel Application Switch is aware of the shared services providedby your WAN link pool and can then balance user traffic among theavailable WAN links. Important WAN link traffic gets through more




.


easily, reducing user competition for connections on overutilized links.For even greater control, traffic is distributed according to a variety ofuser-selectable rules.

• Increased reliability

Reliability is increased by providing multiple paths from the clients to theNortel Application Switch and by accessing a pool of WAN links. If oneWAN link fails, the others can take up the additional load.

• Increased scalability of services

As traffic increases and the WAN link pool’s capabilities are saturated,new WAN links can be added to the pool transparently.

• For ease of maintenance, WAN links can be added or removeddynamically, without interrupting traffic.

Identifying Your Network NeedsWAN Link Load balancing may be the right option for addressing thesevital network concerns:

• A single WAN link no longer meets the demand for increased traffic.

• The connection from your LAN to the Internet overloads the WAN link’scapacity.

• Your WAN links must remain available even in the event of a link failure.

• Your WAN links are being used as a way to do business and for takingorders from customers. It must not become overloaded or unavailable.

• You want to use multiple WAN links or hot-standby WAN links formaximum server uptime.

• You must be able to scale your applications to meet client and LANrequest capacity.

• You can’t afford to continue using an inferior load-balancing technique,such as DNS round robin or a software-only system.

What is Load Balancing?The Nortel Application Switch acts as a front-end to the WAN links,interpreting user session requests and distributing them among the availableWAN links. Load balancing in Nortel Application Switch Operating Systemcan be done in the following ways:

• Filtered-based load balancing

A filter allows you to control the types of traffic permitted through theNortel Application Switch. Filters are configured to allow, deny, orredirect traffic according to the IP address, protocol, or Layer 4 portcriteria. In filtered-based load balancing, a filter is used to redirect trafficto a real server group. If the group is configured with more than one real




.


server entry, redirected traffic is load balanced among the availablereal servers in the group.

WAN links use redirection filters to load balance outbound traffic. Formore information, see "Outbound Traffic" (page 330).

• Virtual server-based load balancing

This is the traditional load balancing method. The Nortel ApplicationSwitch is configured to act as a virtual server and is given a virtualserver IP address (or range of addresses) for each collection of servicesit will distribute. Depending on your application switch model, there canbe as many as 1024 virtual servers, each distributing up to 8 differentservices (up to a total of 1023 services).

Each virtual server is assigned a real server. When the user stationsrequest connections to a service, they will communicate with a virtualserver on the Nortel Application Switch. When the application switchreceives the request, it binds the session to the IP address of thecorresponding real server and remaps the fields in each frame fromvirtual addresses to real address.

This method of load balancing is used to load balance inbound traffic.For more information, see "Inbound Traffic" (page 332).

How WAN Link Load Balancing WorksTo effectively use multiple ISP links, it is recommended that bothtraffic—outbound and inbound is load balanced on the Nortel ApplicationSwitch. Nortel Application Switch Operating System can be configured toload balance up to 8 ISP links. The Nortel Application Switch regularlychecks the health of the upstream routers and measures the condition ofthe link. When traffic is to be sent to the link, the Nortel Application Switchchooses the most optimal link for that session.

The next two sections explain how WAN link load balancing works differentlyfor outbound traffic versus inbound traffic.

Outbound TrafficOutbound traffic is data from the intranet that accesses content acrossthe Internet. Nortel Application Switch Operating System load balancesoutbound traffic using redirection filters to redirect traffic initiated from withinthe user’s network to a group of devices that exist at the other end of theWAN link. These filters determine which link is the best at the time therequest is generated.




.


The design of outbound WAN link load balancing is identical to standardredirection, except that Nortel Application Switch Operating Systemsubstitutes the source IP address of each frame with the proxy IP addressof the port to which the WAN link is connected. This substitution ensuresthat the returning response traverse the same link.

In "Outbound Traffic" (page 331), client 1 at IP address 1.1.1.2 sends aHTTP request to the Internet. Outbound traffic from client 1 reaches port5 on the Nortel Application Switch which is configured with a redirectionfilter for link load balancing. The traffic is load balanced between ports2 and 7 depending on the metric of the WAN group (configured as realserver 1 and 2).

Outbound Traffic

The outbound traffic resolution in "Outbound Traffic" (page 331) is describedin detail in the following section:

Step Action

1 Client 1 makes a data request for content on the Internet.

2 When the request reaches port 5, the redirection filter istriggered and the Nortel Application Switch selects the optimalWAN link.

3 Before the packets leave the WAN link ports, the client IPaddress is substituted with the configured proxy IP addresson port 2 or 7. Proxy IP address maintains persistency for thereturning request.

4 The Nortel Application Switch sends the request to thedestination IP address.

5 The returning request from the Internet uses the same WANlink because the destination IP address responds to the proxyIP address, thereby maintaining persistency. The selected ISPprocesses the packet.




.


6 The Application Switch converts the proxy IP address to theclient IP address and the request is returned to the client.

—End—

Inbound TrafficInbound traffic is data from an external client on the Internet that enters theNortel Application Switch to access an internal service, such as corporateWeb servers or FTP servers.

Nortel Application Switch Operating System allows you to load balancethe inbound traffic by providing access to the external client with thebest available WAN link. This is implemented by configuring the NortelApplication Switch as an authoritative name server. The application switchdynamically determines the best ISP link to use at the time the requestis generated. The best link is determined by the configured metric, theload on the ISP, and periodic health checks on the upstream routers. Formore information on load balancing metrics, see "Metrics for Real ServerGroups" (page 202). Real server weighting can also be used to determinethe best link when using the hash metric for load balancing inbound WANlinks. For more information on real server weighting, see "Weights for RealServers" (page 206).

When the external client makes a DNS request, the application switchresponds with the IP address of the best available WAN link (ISP).

Return-to-SenderEnabling Return-to-Sender (RTS) allows the application switch to associatethe session with the MAC address of the WAN router. This ensures that thereturning traffic takes the same ISP path as the incoming traffic. RTS isenabled on the incoming WAN ports (port 2 and 7) to maintain persistencefor the returning traffic. Data leaves the Nortel Application Switch from thesame WAN link that it used to enter, thus maintaining persistency.

If you want the incoming DNS request to go through the same ISP,then configure VLAN for gateways as described in "VLANs and DefaultGateways" (page 75).

Tracing the Data PathIn "Inbound Traffic for non-SLB server" (page 333), the client request entersthe Nortel Application Switch via ISP A or ISP B. ISP A is configured asreal server 1 and ISP B is configured as real server 2. A virtual server IPaddress is configured for each ISP and each domain. The virtual server IPaddresses for each ISP must be configured in the ISP’s address range.




.


As shown in "Inbound Traffic for non-SLB server" (page 333), two virtualserver IP addresses—virtual server IP address 1 and virtual server IPaddress 2 are configured for nortelnetworks.com in each of the ISP’saddress range. Once the application switch responds with the best virtualserver IP address, all subsequent traffic from the clients to this Domain issent to the same virtual server IP address, thereby passing through thesame ISP.

External client request can be one of the following ways:

• External client accessing data from non-SLB group

• External client accessing data from an SLB group

External client accessing data from non-SLB group In"Inbound Traffic for non-SLB server" (page 333), a client request forhttp://www.nortelnetworks.com enters the Nortel Application Switch viaan ISP. The non-SLB server (real server 3) can be directly or indirectlyconnected to the application switch. A real server 4 is configured on theNortel Application Switch with the IP address of real server 3. Real server 4is added to a server group and that group is advertised in VIP 1 and VIP 2.

Inbound Traffic for non-SLB server

The inbound traffic resolution in "Inbound Traffic for non-SLB server" (page333) is described in detail in the following section:




.

http://www.nortelnetworks.com


Step Action

1 Client makes a request to www.nortel.com.

2 The client query does not exist in local DNS database. LocalDNS queries the Domain Name Server on the Nortel ApplicationSwitch.

3 The Nortel Application Switch monitors WAN links andresponds with the virtual IP address of the optimal ISP.

Default gateways for each ISP VLAN is recommended to avoidasymmetric routing.

4 Client again requests www.nortel.com with the provided virtualIP address.

5 The server responds to the content request.

An allow filter at port 5 processes the data for the services configuredon the server. For example, if the client sends HTTP request toserver 3, then the allow filter should be configured for source port80. Similarly, if the client sends SMTP request to server 3, then theallow filter should be configured for source port 25.

6 The RTS feature on the WAN ports maintains persistency, sothat the traffic returns via the same ISP.

—End—

External client accessing data from an SLB group In www.nortel.com,the client request is for www.nortel.com. The client request should be loadbalanced between SLB servers 5 and 6.




.






Inbound Traffic for SLB group

The inbound traffic resolution in "Inbound Traffic for SLB group" (page335) is described in detail in the following section:

Step Action

1 Client makes a request to www.nortel.com.

2 The client query does not exist in local DNS database. LocalDNS queries the Domain Name Server on the Nortel ApplicationSwitch.

3 The Nortel Application Switch monitors WAN links andresponds with the virtual IP address of the optimal ISP.

4 Client makes the request again to www.nortel.com with theprovided virtual IP address.

5 The SLB servers responds to the content request, because realserver 7 IP address on the Nortel Application Switch is thevirtual server address of www.nortel.com.

The session request egresses from port 1 and port 11 of the NortelApplication Switch where it is then load balanced between the SLBservers. The virtual server IP address for the SLB servers on the




.





application switch is configured as a real server IP address (Real 7IP: 30.30.30.2) on the Nortel Application Switch. Real 7 is added toa group on the Nortel Application Switch.

6 The returning data from the SLB server reaches port 1, which isenabled for server processing.

For information on server processing, see "Network TopologyRequirements" (page 192). The RTS feature on the WAN portsmaintains persistency, so that the traffic returns via the same ISP.

—End—

Configuring WAN Link Load BalancingThis section provides step-by-step procedures to configure the NortelApplication Switch for load balancing the WAN links in differentenvironments:

• "Before You Begin" (page 336)

• "Configuration Summary" (page 336)

• "Example 1: Simple WAN Link Load Balancing" (page 338)

• "Example 2: WAN Link Load Balancing with Server Load Balancing"(page 350)

Before You BeginThe following is required prior to configuration:

• You must be connected to the Nortel Application Switch Command LineInterface (CLI) as the administrator.

• Connect each WAN link to a separate port on the Nortel ApplicationSwitch.

Do not connect two or more WAN links to the same Nortel ApplicationSwitch port using a layer 2 switch. WAN link load balancing uses theproxy IP address of the destination port when translating the sourceIP address of the requests.

• Do not configure your WAN link ports into trunk groups.

Configuration Summary"Configuration Summary" (page 337) summarizes the steps involved toconfigure the Nortel Application Switch for WAN link load balancing.




.


Configuration Summary

Configuring Outbound Traffic Configuring Inbound Traffic

1. Configure the basic parameters.This includes configuring VLAN, IPinterfaces, and defining gateways perVLAN.

1. Configure the basic parameters.This includes configuring VLAN, IPinterfaces, and defining gateways perVLAN.

2. Configure the load balancingparameters for the ISP WAN links.

• Configure the ISP routers as realservers

• Add it to a group

• Define the metric and health

• Enable SLB

2. Configure the load balancingparameters for the ISP WAN links.

• Configure the ISP routers as realservers

• (Optional) assign weight to realservers

• Add it to a group

• Define the metric and health

• Enable SLB

3. Configure the WAN link ports.

• Configure proxy IP address

3. Configure the WAN link ports.

• Enable client processing

• Enable RTS

• Enable DAM

4. Configure the outbound client ports.

• Configure the redirection filter andenable it for link load balancing

• Apply the filter to the client ports

4. Configure the inbound server ports.

• Create a group with the realserver(s)

• Enable server processing

• Enable link load balancing

• Enable filter processing

A real server is configured for everySLB group on the Nortel ApplicationSwitch.

5. Configure virtual server IP addressesand services for each ISP.For each ISP link, configure a virtualserver IP address per domain.




.


Configuring Outbound Traffic Configuring Inbound Traffic

6. Configure the Nortel ApplicationSwitch to behave like a Domain NameServer.This involves defining the domainrecord name and mapping the virtualserver and real server addresses (ISProuter) for each WAN link.

Note: For details about any of the menu commands described in theexamples, refer Nortel Application Switch Operating System CommandReference.

In the following procedure, many of the load balancing options are left totheir default values. See "Additional Server Load Balancing Options" (page199) for details on other options.

Example 1: Simple WAN Link Load Balancing"Simple WAN Link Load Balancing" (page 339) illustrates a simple topologywith two WAN links. Two ISPs, a server, and a client are directly connectedto the Nortel Application Switch. The Nortel Application Switch loadbalances traffic between the two WAN links for both inbound and outboundtraffic.

The server hosting www.nortel.comis directly connected to a port on theapplication switch. To illustrate outbound traffic, a client is directly connectedto another port on the application switch.




.



Simple WAN Link Load Balancing

"Configuring Simple WAN Link Load Balancing" (page 339) gives anoverview of the steps described in the following procedure.

Configuring Simple WAN Link Load Balancing

For outbound traffic For inbound traffic

"Step 1: Configure basic parameters on the Nortel Application Switch" (page 340)

"Step 2: Configure the load balancing parameters for ISP routers" (page 342)

"Step 3a (outbound traffic): Configurethe WAN link ports" (page 343)

"Step 3b (inbound traffic): Configurethe WAN link ports" (page 344)

"Step 4a (outbound traffic): Configurethe client ports" (page 345)

"Step 4b (inbound traffic): Configureserver ports" (page 346)

"Step 5: Configure the virtual server IPaddress and the services for each ISP"(page 346)




.



"Step 6: Configure the ApplicationSwitch as a Domain Name Server"(page 348)

"Step 7: Apply and save your changes" (page 349)

To configure the topology illustrated in "Simple WAN Link Load Balancing"(page 339), follow this procedure on the Nortel Application Switch:

Step 1: Configure basic parameters on the Nortel ApplicationSwitch This includes configuring VLAN, IP interfaces, and defininggateways per VLAN. Gateways per VLAN is recommended if you havenot configured other routing protocols. For each ISP, configure a defaultgateway for each VLAN.

Step Action

1 Assign an IP address to each of the ISP links.

The WAN links in any given real server group must have an IP routeto the application switch that performs the load balancing functions.For this example, the two ISP links must be given the following IPaddresses on different IP subnets:

ISP links: Real Server IP Addresses

WAN links IP address

ISP 1 50.1.1.1

ISP 2 80.1.1.1

2 Configure the IP interfaces on the Nortel Application Switch.

The Nortel Application Switch must have an IP route to all of thereal servers that receive switching services. For load balancing thetraffic, the Nortel Application Switch uses this path to determine thelevel of TCP/IP reach of the WAN links.

>> Main # /cfg/l3/if 2 (Define interface 2 for ISP1)

>> IP Interface 2# ena (Enable interface 2)


(Define the IP address forinterface 2)


(Define the mask forinterface 2)




.


>> IP Interface 2# broad50.1.1.255

(Define the broadcast forinterface 2)

>> IP Interface 2# vlan 2 (Specify the VLAN forinterface 2)

>> Main # /cfg/l3/if 7 (Define interface 7 for ISP2)









>> Main # /cfg/l3/if 1 (Define interface 1 for Realserver 3)


>> IP Interface 1# addr 1.1.1.1 (Define the IP address forinterface 1)






>> Main # /cfg/l3/if 5 (Define interface 5 forinternal client)








3 Configure VLANs.




.


The real server IP addresses (WAN links and real server 3) andthe respective IP interfaces must be on different VLANs. The pvidcommand sets the default VLAN number which is used to forwardframes which are not VLAN tagged. The default number is 1.

>> # /cfg/port 25/pvid 2 (Sets the default VLANnumber)




>> # /cfg/vlan 2/ena (Enable VLAN 2)

>> # /cfg/vlan 2/def 25 (Add port 25 to VLAN 2)







>> # /cfg/l2/stg 1/off (Disable STG)

>> # /cfg/l2/stg 1/clear (Clear STG)

>> # /cfg/l2/stg 1/port 1 2 5 7 (Add ports 1, 2, 5, and 7 toSTG 1)

—End—

Step 2: Configure the load balancing parameters for ISP routers Onthe Nortel Application Switch, configure the ISP routers with load balancingparameters: real servers, group, metric, and health.

Step Action

1 At the Nortel Application Switch, configure IP addresses forWAN link routers.

Proxy is disabled on the real servers, so that the original destinationIP address is preserved.




.


>> # /cfg/slb/real 1/rip50.1.1.1

(Define IP address for WANlink 1)


>> Real server 1# proxy dis (Disable proxy)





2 Create a group to load balance the WAN link routers.




3 Assign the response metric for the WAN link group.

>>Real Server Group 100# metricresponse

(Set the metric to response)

Any of the server load balancing metrics may be used, but responseor bandwidth metric is recommended.

4 Configure health check for the WAN link group.


(Set health check to ICMP)

5 Enable SLB.

>> # /cfg/slb/on (Enable load balancing)

—End—

Step 3a (outbound traffic): Configure the WAN link ports

Step Action

1 Configure proxy IP addresses on ports 25 and 26 for WAN linkload balancing.




.


>> # /cfg/slb/pip/type port (Set base type of proxy IPaddress)

>> # /cfg/slb/pip

>> Proxy IP Address# add50.1.1.3 25

(Set proxy IP address forport 25)



Each proxy IP address must be unique on your network.

—End—

Step 3b (inbound traffic): Configure the WAN link ports

Step Action

1 Enable client processing for ports 25 and 26.

This enables inbound traffic to access the virtual server IP address.

>> # /cfg/slb/port 25/clientena

(Enable client processingfor port 25)



2 Enable the Return to Sender (RTS) feature for ports 25 and 26.

Enable RTS to ensure the returning traffic from all servers to go backto the same ISP router.

>> # /cfg/slb/port 25/rts ena (Enable rts for port 25)


3 Enable WAN link load balancing

>> # /cfg/slb/linklb (Select the link loadbalancing menu)

>> # /cfg/slb/linklb/group 100 (Specify the ISP group ofreal servers)

>> # /cfg/slb/linklb/ena (Enable link load balancing)

4 Enable Direct Access Mode (DAM).




.


Typically, you have two or more virtual server IP addressesrepresenting the same real service. On the return path, DAMensures that the real server IP address is mapped to the correctvirtual IP address.


For information about DAM, refer to "Direct Access Mode" (page239).

—End—

Step 4a (outbound traffic): Configure the client ports Configure theredirection filter and enable the filter for link load balancing. This is requiredto translate (NAT) the client IP address to the proxy IP address.

Step Action

1 Define the WAN link load balancing redirection filter.

>> # /cfg/slb/filt 100>> Filter 100# ena>> Filter 100# action redir

>> Filter 100# group 100 (Select the ISP group ofreal servers)

2 Enable WAN link load balancing for the redirection filter.

>> Filter 100# adv>> Filter 100 Advanced# linklb ena

3 Add the link load balancing filter 100 to the outbound client port

>> # /cfg/slb/port 5 (Select port 5)

>> SLB Port 5# add 100 (Add filter 100 to port 5)


If you are configuring link load balancing for outbound traffic only,then go to "Step 7: Apply and save your changes" (page 349). Theremaining steps in this procedure are used for load balancing ofinbound traffic only.

—End—




.


Step 4b (inbound traffic): Configure server ports For each real serverconnected to the Nortel Application Switch, assign a real server number,specify its IP address and enable the real server. Define a real server groupand add the real server to the group.

Step Action

1 Configure real server and create a group.


(Define IP address for realserver 3)



>> Real server Group 3# add 3 (Add Real server 3)

2 Enable server processing.

>> # /cfg/slb/port 1/server ena (Enable server processingfor port 1)

3 Enable filter on server port 1.

Filter is enabled on port 1, because you want the Nortel ApplicationSwitch to look up the session table for the RTS entry.



—End—

Step 5: Configure the virtual server IP address and the services foreach ISP All client requests is addressed to a virtual server IP addressdefined on the Nortel Application Switch. Clients acquire the virtual serverIP address through normal DNS resolution. In this example, HTTP andFTP are configured as the services running on this virtual server, and thisservice is associated with the real server group.

Other TCP/IP services can be configured in a similar fashion. For a list ofother well-known services and ports, see "Well-Known Application Ports"(page 199). To configure multiple services, see "Configuring MultipleServices" (page 202).




.


Note: Define a virtual server IP address for each ISP.

Step 5a: Configure the virtual server IP address and the services forISP 1 Define a virtual server and add the services and real server groupfor ISP 1.

Step Action

1 Configure a virtual server for ISP 1.



(Set IP address from theISP 1 subnet)

>>Virtual Server 1# ena (Enable virtual server)

2 Add HTTP and FTP services for the virtual server.


>>Virtual Server 1# service 80 (Add the HTTP service)

>>Virtual Server 1 HTTPService# group 3

(Add real server group)

>>Virtual Server 1 HTTPService# ..

(Go to the virtual servermenu)

>>Virtual Server 1# service ftp (Add the FTP service)

>>Virtual Server 1 ftp Service#group 3


—End—

Step 5b: Configure the virtual server IP address and the services forISP 2 Define a virtual server and add the services and real server groupfor ISP 2.

Step Action









.





>>Virtual Server 2 HTTPService# ena

(Enable the service)



>>Virtual Server 2 HTTPService# ..



>>Virtual Server 2 ftp Service#ena




—End—

Step 6: Configure the Application Switch as a Domain NameServer Define the domain record name and map the virtual server andreal server (ISP router) for each WAN link.

Step Action

1 Configure the Domain record for the application switch tobehave as a Domain Name Server.

>> # /cfg/slb/linklb/drecord 1 (Select the Domain recordmenu)

>> Domain record 1# domain nortelnetworks.com (Define the Domainname)

>> Domain Record 1# ena (Enable the Domain)

2 Configure an entry for each ISP and specify the virtual serverand real server (ISP router).

You must map the domain record, nortelnetworks.com to each ISP.Each ISP has two parameters—virtual IP address and real server IPaddress. The virtual IP address is used to respond to the DNS queryfor the nortelnetworks.com domain. The real server IP address isused to measure the ISP load and ISP health. These commandsmap the two parameters to the ISP link




.


>> Domain record 1# entry 1/ena (Define entry for ISP 1)

>> Virt Real Mapping# virt 1 (Select virtual server 1 forISP 1)

>> Virt Real Mapping# real 1 (Select real server for ISP1)




—End—

Step 7: Apply and save your changes You must apply in order forthese changes to take effect, and you must save changes if you wish themto remain in effect after reboot.

Step Action






>> Layer 4# save (Save for restore afterreboot)

3 Check the load balancing information.


Check that all load balancing parameters are working accordingto expectation. If necessary, make any appropriate configurationchanges and then check the information again.

—End—




.


Example 2: WAN Link Load Balancing with Server Load BalancingIn this example (shown in "WAN Link Load Balancing with SLB" (page350)), the Nortel Application Switch is configured for standard server loadbalancing. The Nortel Application Switch is configured to load balance theWAN links for both outbound and inbound traffic and perform server loadbalancing for inbound traffic.

The configuration is similar to Example 1 except that the virtual serverIP addresses on the application switch is configured as real server IPaddresses and are added to a group.

WAN Link Load Balancing with SLB

"Configuring WAN Link Load Balancing with SLB" (page 351) gives anoverview of the steps described in the following procedure.




.


Configuring WAN Link Load Balancing with SLB


"Step 1: Configure basic parameters on the Nortel Application Switch" (page 351)

"Step 2: Configure the load balancing parameters for ISP routers" (page 353)

"Step 3a (outbound traffic): Configurethe WAN link ports" (page 354)

"Step 3b (inbound traffic): Configurethe WAN link ports" (page 355)

"Step 4a (outbound traffic): Configurethe internal network port" (page 356)

"Step 4b (inbound traffic): Configurethe internal network" (page 356)

"Step 5: Configure the virtual server IPaddress and the services for each ISP"(page 358)

"Step 6: Configure the ApplicationSwitch as a Domain Name Server"(page 360)

"Step 7: Apply and save your changes" (page 361)

To configure the topology illustrated in "WAN Link Load Balancing with SLB"(page 350), follow this procedure on the Nortel Application Switch:

Step 1: Configure basic parameters on the Nortel ApplicationSwitch This includes configuring VLAN, interfaces, and defining gatewaysper VLAN. Gateways per VLAN is recommended if you have not configuredother routing protocols. Configure a default gateway per VLAN for each ISP.

Step Action

1 Assign an IP address to each of the ISP links.

The WAN links in any given real server group must have an IP routeto the application switch that performs the load balancing functions.For this example, the two ISP links must be given the following IPaddresses on different IP subnets:

ISP links: Real Server IP Addresses

WAN links IP address

ISP 1 80.1.1.1

ISP 2 30.1.1.1


The Nortel Application Switch must have an IP route to all of thereal servers that receive switching services. For load balancing thetraffic, the Nortel Application Switch uses this path to determine thelevel of TCP/IP reach of the WAN links.




.



>> # /cfg/if 1 (Define interface 1)


























4 On the Nortel Application Switch, configure VLANs.







.











>> # /cfg/stp 1/off (Disable STP)

>> # /cfg/stp 1/clear (Clear STP)

>> # /cfg/stp 1/add 1 25 26 5 (Add ports 1, 25, 26, 5 toSTP 1)

—End—

Step 2: Configure the load balancing parameters for ISP routers Onthe Nortel Application Switch, configure the ISP routers as if they were realservers, with SLB parameters: real servers, group, metric, and health.

Step Action

1 Configure IP addresses for WAN link routers.









Proxy is disabled on the real servers, because link load balancingand full NAT cache redirection cannot coexist.

2 Create a group to load balance the WAN link routers.




.





3 Assign the response metric for the WAN link group.

>>Real Server Group 100# metricresponse

(Set the metric to response)

Any of the server load balancing metrics may be used, but responseor bandwidth metric is recommended.

4 Configure health check for the WAN link group.


(Set health check to ICMP)

5 Enable SLB.

>> # /cfg/slb/on (Enable load balancing)

—End—

Step 3a (outbound traffic): Configure the WAN link ports

Step Action

1 Configure proxy IP addresses on ports 25 and 26.

>> # /cfg/slb/pip/type port (Set base type of proxy IPaddress)

>> # /cfg/slb/pip





Each proxy IP address must be unique on your network.

—End—




.


Step 3b (inbound traffic): Configure the WAN link ports

Step Action

1 Enable client processing at ports 25 and 26.





This enables inbound traffic to access the virtual server IP address.

2 Enable RTS for ports 25 and 26.

Enable RTS to ensure the returning traffic from all servers to go backto the same ISP router.



3 Enable WAN link load balancing.

>> # /cfg/slb/linklb (Select the link loadbalancing menu)

>> # /cfg/slb/linklb/group 100 (Specify the ISP group ofreal servers)

>> # /cfg/slb/linklb/ena (Enable link load balancing)

4 Enable Direct Access Mode (DAM).

Typically, you have two or more virtual server IP addressesrepresenting the same real service. On the return path, DAMensures that the real server IP address is mapped to the correctvirtual IP address.


For information about DAM, refer to "Direct Access Mode" (page239).

—End—




.


Step 4a (outbound traffic): Configure the internal networkport Configure the redirection filter and enable the filter for link loadbalancing. This is required to translate (NAT) the client IP address to theproxy IP address.

Step Action

1 Define the WAN link load balancing redirection filter.

>> # /cfg/slb/filt 100>> Filter 100# ena>> Filter 100# action redir

>> Filter 100# group 100 (Select the ISP group ofreal servers)

2 Enable WAN link load balancing for the redirection filter

>> Filter 100# adv>> Filter 100 Advanced# linklb ena

3 Add the link load balancing filter 100 to the outbound client port.




If you are configuring link load balancing for outbound traffic only,then go to "Step 7: Apply and save your changes" (page 349). Theremaining steps in this procedure are for load balancing inboundtraffic only.

—End—

Step 4b (inbound traffic): Configure the internal network Configurethe virtual server IP addresses on the Nortel Application Switch as realserver IP addresses. In this example, you will configure two real server IPaddresses for each of the two virtual server IP addresses. Then, define areal server group and add the real servers to the group.

Step Action


The real server IP address must be the virtual server IP address ofthe SLB servers that are hosting abc.com.




.


>> # /cfg/slb/real 7/rip1.1.1.100

(Define IP address forwww.abc.com)





The real server IP address must be the virtual server IP address ofthe SLB servers that are hosting xyz.com.

>> # /cfg/slb/real 8/rip1.1.1.200

(Define IP address forxyz.com)




3 Enable filter on server port 1.

Filter is enabled on port 1, because you want the Nortel ApplicationSwitch to look up the session table for the RTS entry.



4 Enable server processing on port 1.

>> # /cfg/slb/port 1/server ena (Enable server processingfor port 1)

5 Configure an allow filter for health checks to occur.

If you have enabled link load balancing filter and server processingon the same port, then an allow filter must be configured for healthchecks. The allow filter is activated before the link load balancingfilter, so that the health check traffic does not get redirected to theWAN links.

>> # /cfg/slb/filt 50

>> Filter 50# sip 1.1.1.0 (From server subnet)

>> Filter 50# smask 255.255.255.0




.


>> Filter 50# dip 1.1.1.1 (To IF 1 on the NortelApplication Switch)

>> Filter 50# action allow>> Filter 50# ena

For more information on health checking, see "Health Checks forReal Servers" (page 201).

6 Add the allow filter 50 to port 1.




Note: If you are using two Nortel Application Switches forredundancy, then must add allow filters for VRRP before theredirection filter. For more information on VRRP, see "HighAvailability" (page 508)"

—End—

Step 5: Configure the virtual server IP address and the services foreach ISP All client requests is addressed to a virtual server IP address ona virtual server defined on the Nortel Application Switch. Clients acquire thevirtual server IP address through normal DNS resolution. In this example,HTTP and FTP are configured as the services running on this virtual server,and this service is associated with the real server group.

Other TCP/IP services can be configured in a similar fashion. For a list ofother well-known services and ports, see "Well-Known Application Ports"(page 199). To configure multiple services, see "Configuring MultipleServices" (page 202).

Note: Define a virtual server IP address for each ISP.

Step 5a: Configure the virtual server IP address and the services forISP 1 Define a virtual server and add the services and real server groupfor ISP 1.

Step Action





.









>>Virtual Server 1 HTTPService# ena




>>Virtual Server 1 HTTPService#..



>>Virtual Server 1 ftp Service#ena




Step 5b: Configure the virtual server IP address and the servicesfor ISP 2

Define a virtual server and add the services and real server groupfor ISP 2.











>>Virtual Server 2 HTTPService#..





.





Note: Repeat Steps 5a and 5b for virtual server 3 and 4 and addgroup 4 for each of the services. This allows inbound traffic toaccess SLB servers hosting the XYZ.com.

—End—

Step 6: Configure the Application Switch as a Domain NameServer This involves configuring the domain record name and mappingthe virtual server and real server (ISP router) for each WAN link.

You must map the domain record, nortelnetworks.com to each ISP. EachISP has two parameters—virtual IP address and real server IP address.The virtual IP address is used to respond to the DNS query for thenortelnetworks.com domain. The real server IP address is used to measurethe ISP load and ISP health. These commands map the two parameters tothe ISP link

Step Action

1 Configure the Domain record for abc.com .



>> Domain record 1# domainabc.com

(Define the Domain name)

2 Configure an entry for each ISP and specify the virtual and realserver (ISP router).




.








3 Configure the Domain record for xyz.com .



>> Domain record 2# domainxyz.com

(Define the Domain name)

4 Configure an entry for each ISP and specify the virtual and realserver (ISP router).







—End—

Step 7: Apply and save your changes You must apply in order forthese changes to take effect, and you must save changes if you wish themto remain in effect after reboot.




.


Step Action







3 Check the load balancing information.


Check that all load balancing parameters are working accordingto expectation. If necessary, make any appropriate configurationchanges and then check the information again.

—End—

Health Checking and Multi-homingInstances can arise during WAN link load balancing where the disruptionof service on one link may not be readily evident through the use of healthchecking. This is due to the nature of the health checking mechanism andhow it interacts with the load balanced WAN environment.

Consider a Nortel Application Switch 2424 that is mult-homed to two serviceproviders. The switch has WAN link load balancing configured for incomingand outgoing traffic. If the link to the first service provider is removed,the health check for this link does not fail eventhough the correspondinginterface is down. This is due to the fact that the health check packet isstill being sent and received through the connection to the second serviceprovider. This is a by-product of the tendency of any routing protocol tore-route a packet to an active link.




.


To overcome this problem, two filters can be used to on the two loadbalanced ports to suppress the ICMP echo-reply which makes the healthcheck fail if the link fails. The following commands would apply Filter 10 tothe link to the first service provider:

/c/slb/filt 10enaaction denysip 80.1.1.1smask 255.255.255.255dip 50.1.1.2dmask 255.255.255.255proto icmpvlan any

/c/slb/filt 10/advicmp echorep

After the filter is applied to the first link, the filter on the second link wouldbe applied. The following commands would apply Filter 20 to the link tothe second service provider:

/c/slb/filt 20enaaction denysip 50.1.1.1smask 255.255.255.255dip 80.1.1.2dmask 255.255.255.255proto icmpvlan any

/c/slb/filt 20/advicmp echorep

In addition to the application of the filters, usage of a static route isrecommended.




.


Filtering

This chapter provides a conceptual overview of filters and includesconfiguration examples showing how filters can be used for network securityand Network Address Translation (NAT).


Note: IPv6 filters support the allow, deny, and redirection actions.

• "Overview" (page 365). This section describes the benefits and filteringcriteria to allow for extensive filtering at the IP and TCP/UDP levels.

— "Filtering Benefits" (page 365)

— "Filtering Criteria" (page 365)

— "Stacking Filters" (page 367)

— "Overlapping Filters" (page 367)

— "The Default Filter" (page 368)

— "VLAN-based Filtering" (page 373)

— "Optimizing Filter Performance" (page 369)

— "Filter Logs" (page 369)

— " IP Address Ranges" (page 369)

— "Cached versus Non-cached Filters" (page 371)

• "Tunable Hash for Filter Redirection" (page 377) allows you to select anyhash parameter for filter redirection.

• " Filter-based Security" (page 378). This section provides an example ofconfiguring filters for providing the best security.

• "Network Address Translation" (page 385). This section provides twoexamples: Internal client access to the Internet and external clientaccess to the server.

• "Matching TCP Flags" (page 394) and "Matching ICMP Message Types"(page 399). Describes the ACK filter criteria which provides greaterfiltering flexibility and lists ICMP message types that can be filteredrespectively.

• "Deny Filter Based on Layer 7 Content Lookup" (page 400)

• "Filtering on 802.1p Priority Bit in a VLAN Header" (page 376)

• "IPv6 Filtering" (page 406)




.

Filtering 365

OverviewNortel Application Switch are used to deliver content efficiently and secureyour servers from unauthorized intrusion, probing, and Denial-of-Service(DoS) attacks. Nortel Application Switch Operating System includesextensive filtering capabilities at the Layer 2 (MAC), Layer 3 (IP) and Layer4 (TCP/UDP) levels.

Filtering BenefitsFiltering give the network administrator a powerful tool with the followingbenefits:

• Filtering of Layer 2 non-IP frames. In the Nortel Application SwitchOperating System, a filter can specify only source MAC and destinationMAC addresses, and capture and apply an allow.

• Increased security for server networks

Filtering gives the administrator control over the types of traffic permittedthrough the switch. Filters can be configured to allow or deny traffic fromLayer 2 - Layer 7: MAC address, IP address, protocol, and Layer 4 port,and Layer 7 string or pattern content.

Layer 2 only filters, as described in "MAC-Based Filters for Layer 2Traffic" (page 372) can be configured to allow or deny non-IP traffic.

You can also secure your switch from further virus attacks by allowingyou to configure the switch with a list of potential offending stringpatterns. For more information, see "Deny Filter Based on Layer 7Content Lookup" (page 400).

Any filter can be optionally configured to generate system log messagesfor increased security visibility.

• Used to map the source or destination IP addresses and ports

Generic Network Address Translation (NAT) can be used to map thesource or destination IP addresses and the ports of private networktraffic to or from advertised network IP addresses and ports.

Filtering CriteriaUp to 2048 filters can be configured on the Nortel Application Switch.Descriptive names can be used to define filters. Each filter can be set toperform "Filtering Actions" (page 366), based on any combination of thefollowing filter options:

• smac: source MAC address.

• dmac: destination MAC address.

• sip: source IP address or range (see " IP Address Ranges" (page 369))

• dip: destination IP address or range (dip and dmask)




.


• proto: protocol number or name as shown in "Well-Known ProtocolTypes" (page 366).

Well-Known Protocol Types

Number Protocol Name

1 icmp

2 igmp

6 tcp

17 udp

89 ospf

112 vrrp

• sport: TCP/UDP application or source port as shown in "Well-KnownApplication Ports" (page 199), or source port range (such as31000-33000)

Note: The service number specified on the switch must match theservice specified on the server.

• dport: TCP/UDP application or destination port as shown in "Well-KnownApplication Ports" (page 199), or destination port range (such as31000-33000)

• invert: reverse the filter logic in order to activate the filter whenever thespecified conditions are not met.

• Advanced filtering options such as TCP flags ("Matching TCP Flags"(page 394)) or ICMP message types ("Matching ICMP Message Types"(page 399)) are also available.

Using these filter criteria, you could create a single filter that blocks externalTelnet traffic to your main server except from a trusted IP address. Anotherfilter could warn you if FTP access is attempted from a specific IP address.Another filter could redirect all incoming e-mail traffic to a server where itcan be analyzed for spam. The options are nearly endless.

Filtering ActionsA filtering action (/cfg/slb/filt/action) instructs the filter what to doonce the filtering criteria are matched.

• allow—Allow the frame to pass (by default).

• deny—Discard frames that fit this filter’s profile. This can be used forbuilding basic security profiles.




.

Filtering 367

• redir—Redirect frames that fit this filter’s profile, such as for webcache redirection. In addition, Layer 4 processing must be activatedusing the /cfg/slb/on command).

• nat—Perform generic Network Address Translation (NAT). This can beused to map the source or destination IP address and port informationof a private network scheme to/from the advertised network IP addressand ports. This is used in conjunction with the nat option (mentioned inthis table) and can also be combined with proxies.

• goto—Allows the user to specify a target filter ID that the filter searchshould jump to when a match occurs. The "goto" action causes filterprocessing to jump to a designated filter, effectively skipping over a blockof filter IDs. Filter searching then continues from the designated filter ID.To specify the new filter to goto, use the /cfg/slb/filt/adv/gotocommand.

Stacking FiltersStacking filters are assigned and enabled on a per-port basis. Each filtercan be used by itself or in combination with any other filter on any givenswitch port. The filters are numbered 1 through 2048 on Nortel ApplicationSwitches. When multiple filters are stacked together on a port, the filter’snumber determines its order of precedence: the filter with the lowestnumber is checked first. When traffic is encountered at the switch port, if thefilter matches, its configured action takes place and the rest of the filters areignored. If the filter criteria do not match, the next filter is tried.

As long as the filters do not overlap, you can improve filter performanceby making sure that the most heavily utilized filters are applied first. Forexample, consider a filter system where the Internet is divided according todestination IP address:

Assigning Filters According to Range of Coverage

Assuming that traffic is distributed evenly across the Internet, the largestarea would be the most utilized and is assigned to Filter 1. The smallestarea is assigned to Filter 4.

Overlapping FiltersFilters are permitted to overlap, although special care should be takento ensure the proper order of precedence. When overlapping filters arepresent, the more specific filters (those that target fewer addresses or ports)should be applied before the generalized filters.




.


Example:

Assigning Filters to Overlapping Ranges

In this example, Filter 2 must be processed prior to Filter 3. If Filter 3 waspermitted to take precedence, Filter 2 could never be triggered.

The Default FilterBefore filtering can be enabled on any given port, a default filter should beconfigured. This filter handles any traffic not covered by any other filter. Allthe criteria in the default filter must be set to the full range possible (any).For example:

Assigning a Default Filter

In this example, the default filter is defined as Filter 2048 in order to give itthe lowest order of precedence. All matching criteria in Filter 2048 are set tothe any state. If no other filter acts on the traffic, Filter 2048 processes it,denying and logging unwanted traffic.

>> # /cfg/slb/filt 2048(Select the default filter)

>> Filter 2048# sip any (From any source IPaddresses)

>> Filter 2048# dip any (To any destination IPaddresses)

>> Filter 2048# proto any (For any protocols)

>> Filter 2048# action deny (Deny matching traffic)

>> Filter 2048# name deny unwantedtraffic

(Provide a descriptive name forthe filter)

>> Filter 2048# ena (Enable the default filter)

>> Filter 2048# adv (Select the advanced menu)

>> Filter 2048 Advanced# log enable (Log matching traffic to syslog)




.

Filtering 369

Default filters are recommended (but not required) when configuring filtersfor IP traffic control and redirection. Using default filters can increasesession performance but takes some of the session binding resources. Ifyou experience an unacceptable number of binding failures, as shown in theServer Load Balancing Maintenance Statistics (/stats/slb/maint), youmay wish to remove some of the default filters.

Optimizing Filter PerformanceFilter efficiency can be increased by placing filters that are used most oftennear the beginning of the filtering list.

It is a recommended practice to number filters in small increments (5, 10,15, 20, etc.) to make it easier to insert filters into the list at a later time.However, as the number of filters increases, you can improve performanceby minimizing the increment between filters. For example, filters numbered2, 4, 6, and 8 are more efficient than filters numbered 20, 40, 60, and80. Peak processing efficiency is achieved when filters are numberedsequentially beginning with 1.

IP Address RangesYou can specify a range of IP addresses for filtering both the source and/ordestination IP address for traffic. When a range of IP addresses is needed,the source IP (sip) address or destination IP (dip) address defines the baseIP address in the desired range. The source mask (smask) or destinationmask (dmask) is the mask that is applied to produce the range.

For example, to determine if a client request’s destination IP address shouldbe redirected to the cache servers attached to a particular switch, thedestination IP address is masked (bit-wise AND) with the dmask and thencompared to the destination IP address.

As another example, the switch could be configured with two filters so thateach would handle traffic filtering for one half of the Internet. To do this, youcould define the following parameters:

Filtering IP Address Ranges

Filter Internet Address Range dip dmask

1 0.0.0.0 - 127.255.255.255 0.0.0.0 128.0.0.0

2 128.0.0.0 - 255.255.255.255 128.0.0.0 128.0.0.0

Filter LogsTo provide enhanced troubleshooting and session inspection capability,packet source and destination IP addresses are included in filter logmessages. Filter log messages are generated when a Layer 3/Layer 4




.


filter is triggered and has logging enabled. The messages are output tothe console port, system host log (syslog), and the Web-based interfacemessage window.

Example: A network administrator has noticed a significant number of ICMPframes on one portion of the network and wants to determine the specificsources of the ICMP messages. The administrator uses the Command LineInterface (CLI) to create and apply the following filter:

>> # /cfg/slb/filt 15(Select filter 15)

>> Filter 15# sip any (From any source IP address)

>> Filter 15# dip any (To any destination IP address)

>> Filter 15# action allow (Allows matching traffic topass)

>> Filter 15# name allow matchingtraffic

(Provide a descriptive name forthe filter)

>> Filter 15# proto icmp (For the ICMP protocol)


>> Filter 15# adv/log enable (Log matching traffic to syslog)

>> Filter 15 Advanced# /cfg/slb/port 7

(Select a switch port to filter)

>> SLB port 7# add 15 (Add the filter to the switchport)

>> SLB port 7# filt ena (Enable filtering on the switchport)

>> SLB port 7# apply (Apply the configurationchanges)

>> SLB port 7# save (Save the configurationchanges)

When applied to one or more switch ports, this simple filter rule produceslog messages that show when the filter is triggered, and what the IP sourceand destination addresses were for the ICMP frames traversing those ports.

Example: Filter log message output is shown below, displaying the filternumber, port, source IP address, and destination IP address:

slb: filter 15 fired on port 7, 206.118.93.110 ->20.10.1.10




.

Filtering 371

Cached versus Non-cached FiltersTo improve efficiency, by default, the Nortel Application Switch performsfilter processing only on the first frame in each session. Subsequent framesin the session are assumed to match the same criteria and are automaticallytreated in the same way as the initial frame. These filters create a sessionentry in the application switch and are known as cached.

Some types of filtering (TCP flag and ICMP message type filtering) requireeach frame in the session to be filtered separately. These filters are knownas non-cached. A Layer 2 filter, which specifies only smac and dmaccriteria, is a non-cached filter.

All filters are cached by default. To change the status of a filter, use thefollowing commands:

>> # /cfg/slb/filt <filter number>/adv

(Select the advanced filtermenu)

>> Filter 1 Advanced # cacheena|dis

(Enable or disable filtercaching)

Note: Cache-enabled filters should not be applied to the same portsas cache-disabled filters. Otherwise, the cache-disabled filters couldpotentially be bypassed for frames matching the cache-enabled criteria.

Logging Non-Cached Filter HitsA non-cached filter hit occurs when a session entry is not cached.Cache-disabled filters are used when a session is either very short-lived orcontains minimal data.

In order to log cache-disabled filters without generating an excess amountof syslog messages, the log message displays only a single NC filtermessage within a given window of time, which includes the number of timesthe cache-disabled filter has fired.

Step Action

1 To enable logging of both cached and cache-disabled filters,use the existing command:

>> # /cfg/slb/filt <#> /adv/log enable





.


>> Filter <#> Advanced# apply>> Filter <#> Advanced# save

An example of a Non-Cached Filter log message is as follows:

Jun 28 3:57:57 WARNING slb: NON-cached filter 1fired on port 1repeated 4 times.

—End—

MAC-Based Filters for Layer 2 TrafficIn the Nortel Application Switch Operating System, filters can be configuredbased on MAC addresses to capture non-IP frames. The benefits of aMAC-based filtering solution is that now a filter can be applied to allow ordeny non-IP traffic such as ARP, AppleTalk. While filtering has alwaysallowed MAC address criteria, only IP traffic was supported.

To configure a filter for non-IP traffic, specify only the source MAC (smac)and destination MAC (dmac) addresses. Do not enter source or destinationIP addresses on a MAC-based filter. MAC-based filtering of non-IP framesis supported for non-cached filters only. Even if caching is enabled on thistype of filter, it does not create a session entry.

To configure a MAC-based filter, specify only smac and dmac criteriawithout any IP-related parameters. The only filtering actions supported forMAC-based filters are allow and deny.

MAC-based filters are supported for VLAN-based filters("VLAN-basedFiltering" (page 373)), and 802.1p bit filtering ("Filtering on 802.1p PriorityBit in a VLAN Header" (page 376)).

For example:

>> # /cfg/slb/filt 23(Select the menu for Filter23)>>

Filter 23# smac any (From any source MACaddress)

>> Filter 23# dmac 00:60:cf:40:56:00

(To this MAC destinationaddress)


>> Filter 23# ena (Enable this filter)




.

Filtering 373

VLAN-based FilteringFilters are applied per switch, per port, or per VLAN. VLAN-based filteringallows a single application switch to provide differentiated services formultiple customers, groups, or departments. For example, you can defineseparate filters for Customers A and B on the same application switch on twodifferent VLANs. If VLANs are assigned based on data traffic, for example,ingress traffic on VLAN 1, egress traffic on VLAN 2, and management trafficon VLAN 3, filters can be applied accordingly to the different VLANs.

In the following example shown in "VLAN-based Filtering" (page 373), Filter2 is configured to allow local clients on VLAN 20 to browse the Web, andFilter 3 is configured to allow local clients on VLAN 30 to Telnet anywhereoutside the local intranet. Filter 2048 is configured to deny ingress trafficfrom VLAN 70.

VLAN-based Filtering

Note: While the following example is based on IP traffic, VLAN-basedfiltering can also be used for non-IP traffic by specifying smac and dmaccriteria instead of sip and dip.

Configuring VLAN-based Filtering

Step Action

1 Configure filter 2 to allow local clients to browse the Web andthen assign VLAN 20 to the filter.




.


The filter must recognize and allow TCP traffic from VLAN 20 toreach the local client destination IP addresses if originating from anyHTTP source port:

>> # /cfg/slb/filt 2(Select the menu for Filter2)


>> Filter 2# dip 205.177.15.0 (To base local network dest.address)

>> Filter 2# dmask 255.255.255.0

(For entire subnet range)

>> Filter 2# proto tcp (For TCP protocol traffic)

>> Filter 2# sport http (From any source HTTPport)

>> Filter 2# dport any (To any destination port)


>> Filter 2# vlan 20 (Assign VLAN 20 to Filter 2)


All clients from other VLANs are ignored.

2 Configure filter 3 to allow local clients to Telnet anywhereoutside the local intranet and then assign VLAN 30 to the filter.

The filter must recognize and allow TCP traffic to reach the localclient destination IP addresses if originating from a Telnet sourceport:




>> Filter 3# dmask 255.255.255.0



>> Filter 3# sport telnet (From a Telnet port)





.

Filtering 375


>> Filter 3# name allow clientsto telnet

(Provide a descriptive namefor the filter)

>> Filter 3# vlan 30 (Assign VLAN 30 to Filter 3)


3 Configure Filter 2048 to deny traffic and then assign VLAN 70to the filter.

As a result, ingress traffic from VLAN 70 is denied entry to the switch.



>> Filter 2048# dip 205.177.15.0

(To base local network dest.address)

>> Filter 2048# dmask255.255.255.0



>> Filter 2048# sport http (From a Telnet port)


>> Filter 2048# action deny (Allow matching traffic topass)

>> Filter 2048# vlan 70 (Assign VLAN 70 to Filter2048)


4 Assign VLAN-based filters to an SLB port.

Before the filters can be used, they must be assigned to an SLB port.

>> # /cfg/slb/port 10 (Select the menu for theport in use)

>> SLB Port 10# add 2 (Add Filter 2 to SLB Port 10)

>> SLB Port 10# add 3 (Add Filter 3 to SLB Port 10)

>> SLB Port 10# add 2048 (Add Filter 2048 to SLB Port10)

—End—




.


Filtering on 802.1p Priority Bit in a VLAN HeaderNortel Application Switch Operating System allows you to filter based onthe priority bits in a packet’s VLAN header. (The priority bits are defined bythe 802.1p standard within the IEEE 802.1Q VLAN header.) The 802.1pbits, if present in the packet, specify the priority that should be given topackets during forwarding. Packets with a higher (non-zero) priority bitsshould be given forwarding preference over packets with numerically lowerpriority bit value.

802.1p PrioritiesThe IEEE 802.1p standard uses eight levels of priority, 0-7, with priority7 being assigned to highest priority network traffic such as OSPF or RIProuting table updates, priorities 5-6 being for delay-sensitive applicationssuch as voice and video, and lower priorities for standard applications. Avalue of zero indicates a "best effort" traffic prioritization, and this is thedefault when traffic priority has not been configured on your network. TheNortel Application Switch can only filter packets based on the 802.1p valuesalready present in the packets. It does not assign or overwrite the 802.1pvalues in the packet.

Classifying Packets Based on 802.1p Priority BitsTraffic is easily classified based on their 802.1p priority by applying a filterbased on the priority bit value. The filtering advanced menu in NortelApplication Switch Operating System provides the option to filter based onthe priority bit value. The filter matches if it finds the corresponding 802.1pbit value in the packet. If the packet does not have the 802.1p bits thefilter will not match.

Configuring a Filter to Classify TrafficTo match on the 802.1p priority bit, go to the Filtering Advanced Menu.Then choose the 802.1p priority bit value (0-7).

Step Action

1 Configure a filter and an action.

>> # /cfg/slb/filt <x> /ena(Enable the filter)

>> Filter 1 # action allow (Set filter action)

2 Go to the filtering advanced menu and select the 802.1p priorityvalue.




.

Filtering 377

>> # /cfg/slb/filt <x>

>> 802.1p Advanced# adv/8021p/ (Select the 802.1pAdvanced Menu)

>> 802.1p Advanced# match ena (Enable matching of 802.1pvalue)

>> # 802.1p Advanced# value 1 (Set the 802.1p priorityvalue to match)

3 Apply a BWM Contract to the Prioritized Filter.

You can apply an 802.1p-prioritized filter to a BandwidthManagement contract to establish the rule for how the traffic thatmatches the defined 802.1p priority value.

>> # /cfg/slb/filt <x> /adv/cont1

(Apply BWM contract 1 tothis filter)

For more information on configuring a Bandwidth Managementcontract, see "Contracts" (page 770).

—End—

Tunable Hash for Filter RedirectionNortel Application Switch Operating System allows you to choose a numberof options when using the hash parameter for filter redirection. Hashing canbe based on source IP address, destination IP address, both, or source IPaddress and source port. For example:

Step Action

1 Configure hashing based on source IP address:

>> # /cfg/slb/filt 10/ena(Enable the filter)

>> Filter 10 # action redir (Specify the redir action)

>> Filter 10 # proto tcp (Specify the protocol)

>> Filter 10 # group 1 (Specify the group of realservers)

>> Filter 10 # rport 3128 (Specify the redirectionport)

>> Filter 10 # vlan any (Specify the VLAN)




.


>> Filter 10 # adv (Select the advanced filtermenu)

>> TCP advanced menu # thashsip

(Select source IP addressfor hashing)

Hashing on the 24-bit source IP address ensures that client requestsaccess the same cache.

2 Set the metric for the real server group to minmisses or hash .

The source IP address is passed to the real server group for eitherof the two metrics.

>> # /cfg/slb/group 1(Select the group of realservers)

>> Real server group 1 # metricminmiss

(Set the metric to minmissor hash)

Note: If firewall load balancing is enabled on the switch, thefirewall load balancing filter which hashes on source anddestination IP addresses will override the tunable hash filter.

—End—

Filter-based SecurityThis section provides an example of configuring filters for providing thebest security. It is recommended that you configure filters to deny all trafficexcept for those services that you specifically wish to allow. Consider thefollowing sample network:

Security Topology Example




.

Filtering 379

In this example, the network is made of local clients on a collector switch, aWeb server, a mail server, a domain name server, and a connection to theInternet. All the local devices are on the same subnet.

In this example, the administrator wishes to install basic security filters toallow only the following traffic:

• External HTTP access to the local Web server

• External SMTP (mail) access to the local mail server

• Local clients browsing the World Wide Web

• Local clients using Telnet to access sites outside the intranet

• DNS traffic

All other traffic is denied and logged by the default filter.

Note: Since IP address and port information can be manipulatedby external sources, filtering does not replace the necessity for awell-constructed network firewall.

Configuring a Filter-Based Security SolutionBefore you begin, you must be connected to the switch CLI as theadministrator.

In this example, all filters are applied only to the switch port that connectsto the Internet. If intranet restrictions are required, filters can be placed onswitch ports connecting to local devices.

Also, filtering is not limited to the few protocols and TCP or UDP applicationsshown in this example. See "Well-Known Application Ports" (page 199) for alist of well-known applications ports and "Well-Known Protocol Types" (page366) for a list of supported protocols.

Step Action

1 Assign an IP address to each of the network devices.

For this example, the network devices have the following IPaddresses on the same IP subnet:

Web Cache Example: Real Server IP Addresses

Network Device IP address

Local Subnet 205.177.15.0 - 205.177.15.255

Web Server 205.177.15.2

Mail Server 205.177.15.3

Domain Name Server 205.177.15.4




.


2 At the Application Switch, create a default filter to deny and logunwanted traffic.

The default filter is defined as Filter 2048 in order to give it the lowestorder of precedence:

>> # /cfg/slb/filt 2048(Select the default filter)





>> Filter 2048# name denyunwanted traffic



>> Filter 2048# adv/log enable (Log matching traffic tosyslog)

Note: Because the proto parameter is not tcp or udp, the sourceport ( sport) and destination port ( dport) values are ignored andmay be excluded from the filter configuration.

3 Create a filter that will allow external HTTP requests to reachthe Web server.

The filter must recognize and allow TCP traffic with the Web server’sdestination IP address and HTTP destination port:

>> Filter 2048# /cfg/slb/filt 1(Select the menu for filter 1)


>> Filter 1# dip 205.177.15.2 (To Web server dest. IPaddress)

>> Filter 1# dmask 255.255.255.255

(Set mask for exact dest.address)


>> Filter 1# sport any (From any source port)

>> Filter 1# dport http (To an HTTP destinationport)




.

Filtering 381


>> Filter 1# name allowmatching traffic



4 Create a pair of filters to allow incoming and outgoing mail toand from the mail server.

Filter 2 allows incoming mail to reach the mail server, and Filter 3allows outgoing mail to reach the Internet:

>> Filter 1# /cfg/slb/filt 2(Select the menu for filter 2)


>> Filter 2# dip 205.177.15.3 (To mail server dest. IPaddress)

>> Filter 2# dmask 255.255.255.255




>> Filter 2# dport smtp (To a SMTP destinationport)



>> Filter 2# /cfg/slb/filt 3 (Select the menu for filter 3)

>> Filter 3# sip 205.177.15.3 (From mail server source IPaddress)

>> Filter 3# smask 255.255.255.255

(Set mask for exact sourceaddress)



>> Filter 3# sport smtp (From a SMTP port)







.


5 Create a filter that will allow local clients to browse the Web.

The filter must recognize and allow TCP traffic to reach the localclient destination IP addresses if traffic originates from any HTTPsource port:

>> Filter 3# /cfg/slb/filt 4 (Select the menu for Filter4)



>> Filter 4# dmask 255.255.255.0



>> Filter 4# sport http (From any source HTTPport)



>> Filter 4# name allow clientsWeb browse



6 Create a filter that will allow local clients to Telnet anywhereoutside the local intranet.

The filter must recognize and allow TCP traffic to reach the localclient destination IP addresses if originating from a Telnet sourceport:

>> Filter 4# /cfg/slb/filt 5(Select the menu for Filter5)



>> Filter 5# dmask 255.255.255.0



>> Filter 5# sport telnet (From a Telnet port)





.

Filtering 383



7 Create a series of filters to allow Domain Name System (DNS)traffic.

DNS traffic requires four filters; one pair is needed for UDP traffic(incoming and outgoing) and another pair for TCP traffic (incomingand outgoing).

For UDP:



>> Filter 6# dip 205.177.15.4 (To local DNS Server)

>> Filter 6# dmask 255.255.255.255


>> Filter 6# proto udp (For UDP protocol traffic)


>> Filter 6# dport domain (To any DNS destinationport)




>> Filter 7# sip 205.177.15.4 (From local DNS Server)

>> Filter 7# smask 255.255.255.255



>> Filter 7# proto udp (For UDP protocol traffic)

>> Filter 7# sport domain (From a DNS source port)




Similarly, for TCP:




.




>> Filter 8# dip 205.177.15.4 (To local DNS Server)

>> Filter 8# dmask 255.255.255.255




>> Filter 8# dport domain (To any DNS destinationport)




>> Filter 9# sip 205.177.15.4 (From local DNS Server)

>> Filter 9# smask 255.255.255.255




>> Filter 9# sport domain (From a DNS source port)




8 Assign the filters to the switch port that connects to the Internet.

>> Filter 9# /cfg/slb/port 5(Select the SLB port 5 tothe Internet)

>> SLB Port 5# add 1-9 (Add filters 1-9 to port 5)

>> SLB Port 5# add 2048 (Add the default filter to port5)

>> SLB Port 5# filt enable (Enable filtering for port 5)

Nortel Application Switch Operating System allows you to add andremove a contiguous block of filters with a single command.




.

Filtering 385


>> SLB Port 5# apply(Make your changes active)

>> SLB Port 5# cur (View current settings)

Examine the resulting information. If any settings are incorrect,make appropriate changes.


>> SLB Port 5# save(Save for restore afterreboot)

11 Check the server load balancing information.

>> SLB Port 5# /info/slb/dump(View SLB information)


Note: Changes to filters on a given port do not take effect untilthe port’s session information is updated (every two minutes orso). To make filter changes take effect immediately, clear thesession binding table for the port (see the /oper/slb/clearcommand in the Nortel Application Switch Operating SystemCommand Reference).

—End—

Network Address TranslationNetwork Address Translation (NAT) is an Internet standard that enablesan Nortel Application Switch to use one set of IP addresses for internaltraffic and a second set of addresses for external traffic. Nortel ApplicationSwitches use filters to implement NAT.

NAT serves two main purposes:

• Provides a type of firewall by hiding internal IP addresses and increasesnetwork security.

• Enables a company to use more internal IP addresses. Since they’reused internally only, there’s no possibility of conflict with public IPaddresses used by other companies and organizations.




.


In the following NAT examples, a company has configured its internalnetwork with private IP addresses. A private network is one that is isolatedfrom the global Internet and is, therefore, free from the usual restrictionsrequiring the use of registered, globally unique IP addresses.

With NAT, private networks are not required to remain isolated. NATcapabilities within the switch allow internal, private network IP addressesto be translated to valid, publicly advertised IP addresses and back again.NAT can be configured in one of the following two ways:

• Static NAT provides a method for direct mapping of one predefined IPaddress (such as a publicly available IP address) to another (such as aprivate IP address)

• Dynamic NAT provides a method for mapping multiple IP addresses(such as a group of internal clients) to a single IP address (to conservepublicly advertised IP addresses)

Static NATThe static NAT (non-proxy) example requires two filters: one for the externalclient-side switch port, and one for the internal, server-side switch port. Theclient-side filter translates incoming requests for the publicly advertisedserver IP address to the server’s internal private network address. The filterfor the server-side switch port reverses the process, translating the server’sprivate address information to a valid public address.

In this example, clients on the Internet require access to servers on theprivate network:

Static Network Address Translation

Configuring Static NAT

>> # /cfg/slb/filt 10 (Select the menu for outboundfilter)

>> Filter 10# action nat (Perform NAT on matchingtraffic)




.

Filtering 387

>> Filter 10# nat source (Translate source information)

>> Filter 10# sip 10.10.10.0 (From the clients private IPaddress)

>> Filter 10# smask 255.255.255.0 (For the entire private subnetrange)

>> Filter 10# dip 205.178.13.0 (To the public network address)

>> Filter 10# dmask 255.255.255.0 (For the same subnet range)


>> Filter 10# adv/proxy disable (Override any proxy IP settings)

>> Filter 10 Advanced# /cfg/slb/filt 11

(Select the menu for inboundfilter)

>> Filter 11# action nat (Use the same settings asoutbound)

>> Filter 11# nat dest (Reverse the translationdirection)

>> Filter 11# sip 10.10.10.0 (Use the same settings asoutbound)

>> Filter 11# smask 255.255.255.0 (Use the same settings asoutbound)

>> Filter 11# dip 205.178.13.0 (Use the same settings asoutbound)

>> Filter 11# dmask 255.255.255.0 (Use the same settings asoutbound)


>> Filter 11# adv/proxy disable (Override any proxy IP settings)


(Select server-side port)

>> SLB port 1# add 10 (Add the outbound filter)

>> SLB port 1# filt enable (Enable filtering on port 1)

>> SLB port 1# /cfg/slb/port 2 (Select the client-side port)

>> SLB port 2# add 11 (Add the inbound filter)


>> SLB port 2# apply (Apply configuration changes)

>> SLB port 2# save (Save configuration changes)

Note the following important points about this configuration:

• Within each filter, the smask and dmask values are identical.




.


• All parameters for both filters are identical except for the NAT direction.For Filter 10, nat source is used. For Filter 11, nat dest is used.

• Filters for static (non-proxy) NAT should take precedence over dynamicNAT filters (following example). Static filters should be given lowerfilter numbers.

Dynamic NATDynamic NAT is a many-to-one solution: multiple clients on the privatesubnet take advantage of a single external IP address, thus conservingvalid IP addresses. In this example, clients on the internal private networkrequire TCP/UDP access to the Internet:

Dynamic Network Address Translation

You may directly connect the clients to the application switch if the totalnumber of clients is less than or equal to the switch ports.

Note: Dynamic NAT can also be used to support ICMP traffic for PING.

This example requires a NAT filter to be configured on the switch port thatis connected to the internal clients. When the NAT filter is triggered byoutbound client traffic, the internal private IP address information on theoutbound packets is translated to a valid, publicly advertised IP addresson the switch. In addition, the public IP address must be configured as aproxy IP address on the switch port that is connected to the internal clients.The proxy performs the reverse translation, restoring the private networkaddresses on inbound packets.

Configuring Dynamic NAT

>> # /cfg/slb/filt 14 (Select the menu for clientfilter)

>> Filter 14# invert ena (Invert the filter logic)

>> Filter 14# dip 10.10.10.0 (If the destination is not private)




.

Filtering 389

>> Filter 14# dmask 255.255.255.0 (For the entire private subnetrange)



>> Filter 14# nat source (Translate source information)


>> Filter 14# adv/proxy enable (Enable client proxy on thisfilter)

>> Filter 14 Advanced# proxyip 205.178.17.12 (Set the filter’s proxyIP address)


(Select SLB port 1)

>> SLB port 1# add 14 (Add the filter 14 to port 1)


>> SLB port 1# proxy ena (Enable proxies on this port)



For more information on proxy IP address, see "Proxy IP Addresses" (page228).

Note 1: The invert option in this example filter makes this specificconfiguration easier, but is not a requirement for dynamic NAT.

Note 2: Filters for dynamic NAT should be given a higher numbers thanany static NAT filters (see "Static NAT" (page 386)).

FTP Client NATNortel Application Switches provide NAT services to many clients withprivate IP addresses. In Nortel Application Switch Operating System, anFTP enhancement provides the capability to perform true FTP NAT fordynamic NAT.

Because of the way FTP works in active mode, a client sends informationon the control channel, information that reveals their private IP address, outto the Internet. However, the switch filter only performs NAT translation onthe TCP/IP header portion of the frame, preventing a client with a privateIP address from doing active FTP.




.


The switch can monitor the control channel and replace the client ’s privateIP address with a proxy IP address defined on the switch. When a client inactive FTP mode sends a port command to a remote FTP server, the switchwill look into the data part of the frame and modify the port command asfollows:

• The real server (client) IP address will be replaced by a public proxyIP address.

• The real server (client) port will be replaced with a proxy port.

Active FTP for Dynamic NAT

You may directly connect the real servers to the application switch if the totalnumber of servers is less than or equal to the switch ports.

Configuring Active FTP Client NAT

Note: The passive mode does not need this feature.

Step Action

1 Make sure that a proxy IP address is enabled on the filter port.

2 Make sure that a source NAT filter is set up for the port.:

>> # /cfg/slb/filt 14 (Select the menu for clientfilter)

>> Filter 14# invert ena (Invert the filter logic)

>> Filter 14# dip 10.10.10.0 (If the destination is notprivate)

>> Filter 14# dmask 255.255.255.0

(For the entire privatesubnet range)





.

Filtering 391


>> Filter 14# nat source (Translate sourceinformation)


>> Filter 14# adv/proxy enable (Allow proxy IP translation)

>> Filter 14 Advanced# proxyip 205.178.17.12 (Set thefilter’s proxy IP address)

>> Proxy IP Address# /cfg/slb/port 1

(Select SLB port 1)

>> SLB port 1# add 14 (Add the filter to port 1)


>> SLB port 1# proxy ena (Enable proxies on this port)

>> SLB port 1# apply (Apply configurationchanges)

>> SLB port 1# save (Save configurationchanges)

For more information on proxy IP address, see "Proxy IP Addresses"(page 228).

3 Enable active FTP NAT using the following command:

>> # /cfg/slb/filt <filter number> /adv/layer7/ftpaena

4 Apply and save the switch configuration.

—End—

Overlapping NATThe Nortel Application Switch Operating System supports the presenceof overlapping or duplicate source IP addresses on different VLANs in asource NAT filter. This is accomplished by extending the session tablelookup algorithm to include the session VLAN.

In instances where an overlapping source IP address is present for differentVLANs, the switch will create different sessions. For the source NAT, theswitch substitutes the source IP address with the configured proxy IPaddress. A proxy IP address for the VLAN must be configured for this tofunction properly.




.


In instances where an overlapping NAT is present the switch will notuse the routing table to route the packet back to the sender, due to theoverlapping source address, in Layer 3 mode. Instead, the switch will usethe VLAN gateway to forward the packet back to the sender. VLAN gatewayconfiguration is necessary to make this feature function properly. Layer 2mode is supported however.

Configuring Overlapping NAT

Step Action

1 Configure Gateway per VLAN

Default Gateway 5 or above must be used for the VLAN gateway asgateways 1 through 4 are reserved for default gateways.

>> Main# /cfg/l3/gw 5>> Default Gateway 5# addr <IP address>>> Default Gateway 5# vlan 100

2 Configure source NAT filter

Select the appropriate filter for usage. In this example, filter 2 is used.

>> Main# /cfg/slb/filt 2/action na

3 Enable Overlapping NAT

>> Main# /cfg/slb/adv/pvlantag enable

—End—

SIP NAT and Gleaning SupportThe IP end points on a network are typically assigned private addresses.Voice calls from and to the public network need to reach end points onthe private network. As a result, NAT is required to allow proper routing ofmedia to end points with private addresses.

The SIP carries the identification of the IP end point (IP address/Port) withinthe body of the message. The voice media which gets directed to theprivate IP address identified in the signaling message cannot be routed andresults in a one way path. Therefore, Nortel Application Switch OperatingSystem 24.0 allows you to NAT the SDP and create sessions for the mediacommunication.




.

Filtering 393

How SIP NAT WorksAll occurrences of the internal client’s private IP address and port in theoutgoing SIP message is replaced with the translated address. Thisprocedure is reversed when the SIP messages come from the outside, inwhich case the public IP is replaced with the private client’s IP and port.Nortel Application Switch Operating System 24.0 translates the IP addressand port.

Setting Up SIP NATTo set up SIP NAT, configure a NAT filter and enable SIP parsing. The SIPNAT modifies the signaling to reflect the public IP addresses and ports.These pinholes and NAT bindings are assigned dynamically based onstateful inspection. The SIP NAT performs the necessary translation ofthe IP addresses embedded in the SIP messages and updates the SIPmessage before sending the packet out.

To support SIP NAT and gleaning, you must configure the following:

Step Action

1 Enable VMA.

2 Configure a NAT filter.

Dynamic NAT is supported only.

>> Main# /cfg/slb/filt 14>> Filter 14# action nat>> Filter 14# nat source

3 Enable SIP parsing.

>> Main# /cfg/slb/filt 14>> Filter 14# adv>> Filter 14 Advanced# Layer7>> Layer 7 Advanced# sip>> Layer 7 SIP# sipp ena

4 Set bandwidth contract for the SIP RTP sessions.

>> Layer 7 SIP# rtpcont <contract #>


>> Layer 7 SIP# apply>> Layer 7 SIP# save




.


Note: When MCS proxy authentication is enabled, the MCSPC client will create message digests using the client’s privateaddress. These digests are sent back to the MCS server forauthentication during the invite stage. Call setup will fail withMCS proxy authentication enabled as the switch does notregenerate these message digests with the public address.

—End—

Matching TCP FlagsNortel Application Switch Operating System supports packet filtering basedon any of the following TCP flags.

Flag Description

URG Urgent

ACK Acknowledgement

PSH Push

RST Reset

SYN Synchronize

FIN Finish

Any filter may be set to match against more than one TCP flag at the sametime. If there is more than one flag enabled, the flags are applied with alogical AND operator. For example, by setting the switch to filter SYN andACK, the switch filters all SYN-ACK frames.

Note: TCP flag filters must be cache-disabled. Exercise caution whenapplying cache-enabled and cache-disabled filters to the same switchport. For more information, see "Cached versus Non-cached Filters"(page 371).

Configuring the TCP Flag Filter

Note: By default, all TCP filter options are disabled. TCP flags will notbe inspected unless one or more TCP options are enabled.

Consider the following network:




.

Filtering 395

TCP ACK Matching Network

In this network, the Web servers inside the LAN must be able to transfermail to any SMTP-based mail server out on the Internet. At the same time,you want to prevent access to the LAN from the Internet, except for HTTP.

SMTP traffic uses well-known TCP Port 25. The Web servers will originateTCP sessions to the SMTP server using TCP destination Port 25, and theSMTP server will acknowledge each TCP session and data transfer usingTCP source Port 25.

Creating a filter with the ACK flag closes one potential security hole. Withoutthe filter, the switch would permit a TCP SYN connection request to reachany listening TCP destination port on the Web servers inside the LAN, aslong as it originated from TCP source Port 25. The server would listen to theTCP SYN, allocate buffer space for the connection, and reply to the connectrequest. In some SYN attack scenarios, this could cause the server’s bufferspace to fill, crashing the server or at least making it unavailable.

A filter with the ACK flag enabled prevents external devices from beginninga TCP connection (with a TCP SYN) from TCP source Port 25. The switchdrops any frames that have the ACK flag turned off.

The following filters are required:

Step Action

1 An allow filter for TCP traffic from LAN that allows the Webservers to pass SMTP requests to the Internet.

>> # /cfg/slb/filt 10 (Select a filter for trustedSMTP requests)

>> Filter 10# sip 203.122.186.0 (From the Web servers’source IP address)

>> Filter 10# smask 255.255.255.0

(For the entire subnetrange)


>> Filter 10# proto tcp (For TCP traffic)





.


>> Filter 10# dport smtp (To well-known destinationSMTP port)



2 A filter that allows SMTP traffic from the Internet to pass throughthe switch only if the destination is one of the Web servers, andthe frame is an acknowledgment (SYN-ACK) of a TCP session.

>> Filter 10# /cfg/slb/filt 15 (Select a filter for InternetSMTP ACKs)


>> Filter 15# sport smtp (From well-known sourceSMTP port)


>> Filter 15# dip 203.122.186.0 (To the Web servers’ IPaddress)

>> Filter 15# dmask 255.255.255.0

(To the entire subnet range)




>> Filter 15# adv/tcp (Select the advanced TCPmenu)

>> Filter 15 Advanced# ack ena (Match acknowledgmentsonly)

>> Filter 15 Advanced# syn ena (Match acknowledgmentsonly)

3 A filter that allows SMTP traffic from the Internet to pass throughthe switch only if the destination is one of the Web servers, andthe frame is an acknowledgment (ACK-PSH) of a TCP session.

>> Filter 15# /cfg/slb/filt 16 (Select a filter for InternetSMTP ACKs)


>> Filter 16# sport smtp (From well-known sourceSMTP port)




.

Filtering 397



>> Filter 16# dmask 255.255.255.0





>> Filter 16# adv/tcp (Select the advanced TCPmenu)

>> Filter 16 Advanced# ack ena (Match acknowledgmentsonly)

>> Filter 16 Advanced# psh ena (Match acknowledgmentsonly)

4 A filter that allows trusted HTTP traffic from the Internet to passthrough the switch to the Web servers.

>> Filter 16 Advanced#/cfg/slb/filt 17

(Select a filter for incomingHTTP traffic)


>> Filter 17# sport http (From well-known sourceHTTP port)



>> Filter 17# dmask 255.255.255.0


>> Filter 17# dport http (To well-known destinationHTTP port)



5 A filter that allows HTTP responses from the Web servers topass through the switch to the Internet.




.


>> Filter 17# /cfg/slb/filt 18 (Select a filter for outgoingHTTP traffic)

>> Filter 18# sip 203.122.186.0 (From the Web servers’source IP address)

>> Filter 18# smask 255.255.255.0

(From the entire subnetrange)

>> Filter 18# sport http (From well-known sourceHTTP port)



>> Filter 18# dport http (To well-known destinationHTTP port)



6 A default filter is required to deny all other traffic.

>> Filter 18# /cfg/slb/filt2048

(Select a default filter)



>> Filter 2048# action deny (Block matching traffic)

>> Filter 2048# name deny matching traffic (Provide adescriptive name for the filter)


7 Apply the filters to the appropriate switch ports.

>> Filter 2048# /cfg/slb/port 1 (Select the Internet-sideport)

>> SLB port 1# add 15 (Add the SMTP ACK filterto the port)

>> SLB port 1# add 16 (Add the incoming HTTPfilter)

>> SLB port 1# add 17 (Add the incoming HTTPfilter)




.

Filtering 399

>> SLB port 1# add 2048 (Add the default filter to theport)

>> SLB port 1# filt ena (Enable filtering on the port)

>> SLB port 1# /cfg/slb/port 2 (Select the first Web serverport)

>> SLB port 2# add 10 (Add the outgoing SMTPfilter to the port)

>> SLB port 2# add 18 (Add the outgoing HTTPfilter to the port)



>> SLB port 2# /cfg/slb/port 3 (Select the other Webserver port)

>> SLB port 3# add 10 (Add the outgoing SMTPfilter to the port)

>> SLB port 3# add 18 (Add the outgoing HTTPfilter to the port)



>> SLB port 3# apply (Apply the configurationchanges)

>> SLB port 3# save (Save the configurationchanges)

—End—

Matching ICMP Message TypesInternet Control Message Protocol (ICMP) is used for reporting TCP/IPprocessing errors. There are numerous types of ICMP messages, asshown in "ICMP Message Types" (page 400). Although ICMP packets canbe filtered using the proto icmp option, by default, the application switchignores the ICMP message type when matching a packet to a filter. Toperform filtering based on specific ICMP message types, ICMP messagetype filtering must be enabled.

Nortel Application Switch Operating System software supports filtering onthe following ICMP message types:




.


ICMP Message Types

Type # Message Type Description

0 echorep ICMP echo reply

3 destun ICMP destination unreachable

4 quench ICMP source quench

5 redir ICMP redirect

8 echoreq ICMP echo request

9 rtradv ICMP router advertisement

10 rtrsol ICMP router solicitation

11 timex ICMP time exceeded

12 param ICMP parameter problem

13 timereq ICMP timestamp request

14 timerep ICMP timestamp reply

15 inforeq ICMP information request

16 inforep ICMP information reply

17 maskreq ICMP address mask request

18 maskrep ICMP address mask reply

The command to enable or disable ICMP message type filtering is enteredfrom the Advanced Filtering menu as follows:

>> # /cfg/slb/filt <filter number> /adv>> Filter 1 Advanced# icmp <message type|number|any|list>

For any given filter, only one ICMP message type can be set at any onetime. The any option disables ICMP message type filtering. The list optiondisplays a list of the available ICMP message types that can be entered.

Note: ICMP message type filters must be cache-disabled. Exercisecaution when applying cache-enabled and cache-disabled filters tothe same switch port. For more information, see "Cached versusNon-cached Filters" (page 371).

Deny Filter Based on Layer 7 Content LookupNortel Application Switch Operating System allows you to secure yourswitch from virus attacks or invalid data requests by configuring the switchwith filters containing potential offending string patterns. Examples of suchstrings include those embedded in an HTTP URL request, SOAPActionrequest bound to an HTTP header, or certain strings contained in the dataportion of UDP traffic. The switch examines theHTTP or UDP content of




.

Filtering 401

the incoming client request for the matching string pattern. If the matchingvirus pattern is found, then the packet is dropped and a reset frame is sentto the offending client. SYSLOG messages and SNMP traps are generatedwarning operators of a possible attack.

A layer string 7 deny filter works just like a basic deny filter, except thatthe deny action is delayed until the string content is examined to see if thepacket should be denied.

"Configuring a Deny Filter with Layer 7 Lookup for HTTP URL, HTTPHeader, or UDP Strings" (page 401) shows an incoming client requests withoffending content. The application switch is configured with a deny filtercombined with the Layer 7 lookup feature. The filter blocks the incomingpacket with the offending string or pattern, and prevents it from enteringthe network.

Configuring a Deny Filter with Layer 7 Lookup for HTTP URL, HTTP Header, orUDP Strings

Denying HTTP URL Requests

Step Action

1 Before creating a deny filter with Layer 7 lookup, ensure that theswitch has already been configured for basic switch functions:



For information on how to configure your network for the abovetasks, see "Server Load Balancing" (page 188)."




.


2 Define the virus string patterns or offending HTTP URL requestto be blocked.

>> # /cfg/slb/layer7/slb/addstrida

(Define the code red virusstring)

>> Server Loadbalance Resource#add %c1%9c

(Define the code blue virusstring)

>> Server Loadbalance Resource#add %c0%af

(Define the code blue virusstring)

>> Server Loadbalance Resource# add playdog.com (Defineoffending URL request)

3 Identify the IDs of the defined strings.

>> Server Loadbalance resource# cur

Number of entries: 4

ID SLB String

1 ida

2 %c1%9c

3 %c0%af

4 playdog.com

4 Assign the URL string IDs from step 2 to the filter.

>> /cfg/slb/filt 1/adv/layer7 (Select the Filt. 1 L7Advanced menu)

>> Layer 7 Advanced# addstr 1 (Add the code red virusstring)

>> Layer 7 Advanced# addstr 2 (Add the code blue virusstring)

>> Layer 7 Advanced# addstr 3 (Add the code blue virusstring)

>> Layer 7 Advanced# addstr 4 (Add the offending URLrequest)

5 Enable Layer 7 lookup. This feature, when combined with thefilter deny action, will match and deny any traffic containing thestrings you just added in step 4 .




.

Filtering 403

>> /cfg/slb/filt 1/adv/layer7/l7lkup ena

(Enable the Layer 7 lookupfeature)

6 Select the filter and enable the filter action to deny.


>> Filter 1 # action deny (Set the filter action to deny)


>> Filter 1 Advanced# apply (Apply the filter)

>> Filter 1 Advanced# save (Save the configuration)

—End—

Denying HTTP HeadersLayer 7 deny filters can be configured to match and deny on any HTTPheaders. Examples of HTTP headers include:

• HTTPHDR:Host: www.playdog.com

• HTTPHDR:Host:www.yahoo.com:/image/hello.gif

• /default.asp (the URL by itself)

• HTTPHDR:User-Agent:Netscape*

• HTTPHDR:SoapAction=*

Configure a filter as described in "Denying HTTP URL Requests" (page401).

Step Action

1 Define the HTTP header strings to be blocked.

>> /cfg/slb/layer7/slb/ (Select the ServerloadbalanceResource menu)

>> Server Loadbalance Resource# add

Enter type of string [l7lkup|pattern]: l7lkup

Configure HTTP header string? [y/n] y




.

http://www.playdog.com/

http://images.search.yahoo.com/search/images?p=hello.gif


Enter HTTP header name:Host

(Define HTTP header name Host)

Enter SLB header value string: www.playdog.com (Defineoffending header content)

Configure URL string? [y/n] y

Enter URL string: www.playdog.com




Enter HTTP header name:SoapAction=*

(Define SOAPAction header)

Enter SLB header value string:

Configure URL string? [y/n] n



The strings in bold are used in this example.


ID SLB String

1 ida

2 %c1%9c

3 %c0%af

4 playdog.com

6 HTTPHDR:Host:www.playdog.com

7 HTTPHDR:SoapAction=*

3 Assign the HTTP host header string IDs from step 1 to the filter.




.




Filtering 405

>> /cfg/slb/filt 1/adv/layer7 (Select the Filt. 1 L7Advanced menu)

>> Layer 7 Advanced# addstr 6 (Add the HTTP header hoststring)

>> Layer 7 Advanced# addstr 7 (Add the HTTP headerSoapAction string)

4 Enable Layer 7 lookup. This feature, when combined with thefilter deny action, will match and deny any traffic containing thestrings you just added in step 3.

/cfg/slb/filt 1/adv/layer7/l7lkup ena

(Enable the Layer 7 lookupfeature)

5 Set the filter action to deny.




>> Filter 1 Advanced# apply (Apply the filter)

>> Filter 1 Advanced# save (Save the configuration)

—End—

Multicast Filter RedirectionMulticast Filter Redirection is used to redirect multicast packets based onfiltering criteria. Before packets get redirected to the filter specified server,the switch substitutes the destination MAC address with the server MACaddress. The modified packets are then sent to the port where the specifiedserver is connected. Multicast packets are redirected without substitutingthe destination MAC address.

Since the destination MAC address and destination IP address need tobe in same cast category, the redirected multicast or broadcast packetsshould keep the multicast type destination MAC address. In redirection filterprocessing, the switch checks cast type of destination MAC address in thereceived packet. If the received packet is a unicast packet, the destinationMAC address is substituted to the specified server’s MAC address. Thenthe redirected unicast packet is sent to the port where the server connected




.


to. If the received packet is a multicast packet, the destination MAC addressis not substituted. Then the redirected multicast packet is sent to the portthat the server connected to.

IPv6 FilteringIPv6 support in Nortel Application Switch Operating System includessupport for ALLOW and DENY filters only; IPv6 filtering does not supportREDIR, NAT, or GOTO filters. IPv6 filtering operates in a similar fashionto IPv4 filtering with the exception that IPv6 filtering is only supported inbridging mode. Routed packets will be passed through without being filtered.

Connectivity is maintained in IPv6 through the regular exchange ofNeighbors Solicitation (NSol) packets. These packets are sent to find thelink layer address of a neighbor in the link and to find the reachability of aneighboring node. It is usually necessary to configure an additional ALLOWfilter for these multicast packets so that link neighbors can be learnt. If this isnot done no packets will be allowed because link neighbors cannot be learnt.Filter inversion will also have to take these NSol packets into consideration.

Not all commands available for the configuration of IPv4 filters are availablefor the configuration of IPv6 filters. The commands outlined in "IPv6 FilterConfiguration Commands" (page 406) are used to configure IPv6 filters.

IPv6 Filter Configuration Commands

Command Menu Supported Commands

/cfg/slb/filt <filter number> sip <IPv6 Address>dip <IPv6 Address>smask <IPv6 Prefix Length>dmask <IPv6 Prefix Length>proto <Protocol Name |Number | any>sport <Port>dport <Port>

/cfg/slb/filt <filternumber> /adv/ip

length <IP packet length (inbytes), 64-65535 | any>

/cfg/slb/filt <filternumber> /adv/tcp

urg <enable | disable>ack <enable | disable>psh <enable | disable>syn <enable | disable>rst <enable | disable>fin <enable | disable>ackrst <enable | disable>cur

The following example creates two IPv6 filters for Port 1. Filter 1 will allowthe exchange Neighbors Solicitation packets and Filter 2 will allow themovement of bridged HTTP traffic.




.

Filtering 407

Step Action

1 Globally enable Layer 4 load balancing.

Layer 4 load balancing must be enabled to allow filter processingto take place.


2 Create Filter 1 to allow the passage of Neighbors Solicitationpackets.

>> Main# /cfg/slb/filt 1/ena (Enable Filter 1)

>> Filter 1# action allow (Specify an ALLOW filter)

>> Filter 1# ipver v6 (Specify an IPv6 filter)

>> Filter 1# sip 2001:0:0:0:0:0:0:0

(Specify Source IP)

>> Filter 1# smask 64 (Specify IPv6 Source Prefix)

>> Filter 1# dip ff00:0:0:0:0:0:0:0

(Specify Destination IP)

>> Filter 1# dmask 8 (Specify IPv6 DestinationPrefix)

>> Filter 1# vlan any (Specify VLAN Settings)

3 Create Filter 2 to allow the movement of bridged HTTP traffic.

>> Main# /cfg/slb/filt 2/ena (Enable Filter 2)

>> Filter 2# action allow (Specify an ALLOW filter)

>> Filter 2# ipver v6 (Specify an IPv6 filter)

>> Filter 2# sip 2001:0:0:0:0:0:0:1

(Specify Source IP)

>> Filter 2# smask 128 (Specify IPv6 Source Prefix)

>> Filter 2# dip 2001:0:0:0:0:0:0:8

(Specify Destination IP)

>> Filter 2# dmask 128 (Specify IPv6 DestinationPrefix)

>> Filter 2# proto tcp (Specify filter protocol)

>> Filter 2# sport any (Specify Source Port)

>> Filter 2# dport http (Specify Destination Port)

>> Filter 2# vlan any (Specify VLAN Settings)




.


4 Add the two filters to Port 1.

>> Main# /cfg/slb/port 1 (Select Port 1)

>> Port 1# filt ena (Enable port filtering)

>> Port 1# add 1-2 (Add Filters 1 and 2 to Port1)

—End—




.

Application Redirection 409

Application Redirection

Application Redirection improves network bandwidth and provides uniquenetwork solutions. Filters can be created to redirect traffic to cache andapplication servers improving speed of access to repeated client access tocommon Web or application content and free valuable network bandwidth.


• "Overview" (page 409). Application redirection helps reduce the trafficcongestion during peak loads by accessing locally cached information.This section also discusses how performance is improved by balancingcached requests across multiple servers.

• "Cache Redirection Configuration Example" (page 411). This sectionprovides a step-by-step procedure on how to intercept all Internet boundHTTP requests (on default TCP port 80) and redirect them to the cacheservers.

• "RTSP Cache Redirection" (page 417). This section explains how toconfigure the switch to redirect data (multimedia presentations) to thecache servers, and how to balance the load among the cache servers.

• "IP Proxy Addresses for NAT" (page 421). This section discusses thebenefits of transparent proxies when used with application redirection.

• "Excluding Noncacheable Sites" (page 423). This section describes howto filter out applications that prevent real-time session information frombeing redirected to cache servers.

• "Content Intelligent Cache Redirection" (page 423). This sectiondescribes how to redirect cache requests based on different Layer 7content.

• "HTTP Redirection" (page 444). This section describes how use filtersto redirect HTTP requests to different gateways or servers.

• "Peer-to-Peer Cache Load Balancing" (page 461)

Note: To access Application Redirection functionality, the optional Layer4 software must be enabled on the application switch (see "Filtering andLayer 4" in the Nortel Application Switch Operating System CommandReference).

OverviewMost of the information downloaded from the Internet is not unique, asclients will often access the Web page many times for additional informationor to explore other links. Duplicate information also gets requested as thecomponents that make up Internet data at a particular Web site (pictures,buttons, frames, text, and so on) are reloaded from page to page. When you




.


consider this scenario in the context of many clients, it becomes apparentthat redundant requests can consume a considerable amount of youravailable bandwidth to the Internet.

Application redirection can help reduce the traffic congestion during peakloads. When Application redirection filters are properly configured for theNortel Application Switch Operating System-powered switch, outboundclient requests for Internet data are intercepted and redirected to a group ofapplication or cache servers on your network. The servers duplicate andstore inbound Internet data that has been requested by your clients. If theservers recognize a client’s outbound request as one that can be filled withcached information, the servers supply the information rather than send therequest across the Internet.

In addition to increasing the efficiency of your network, accessinglocally cached information can be much faster than requesting the sameinformation across the Internet.

Cache Redirection EnvironmentConsider a network where client HTTP requests begin to regularly overloadthe Internet router.

Traditional Network Without Cache Redirection

The network needs a solution that addresses the following key concerns:

• The solution must be readily scalable

• The administrator should not need to reconfigure all the clients’ browsersto use proxy servers.




.


Network with Cache Redirection

If you have more clients than application switch ports, then connect theclients to a layer 2 switch.

Adding an Nortel Application Switch with optional Layer 4 softwareaddresses these issues:

• Cache servers can be added or removed dynamically withoutinterrupting services.

• Performance is improved by balancing the cached request load acrossmultiple servers. More servers can be added at any time to increaseprocessing power.

• The proxy is transparent to the client.

• Frames that are not associated with HTTP requests are normallypassed to the router.

Additional Application Redirection OptionsApplication redirection can be used in combination with other Layer 4options, such as load balancing metrics, health checks, real server groupbackups, and more. See "Additional Server Load Balancing Options" (page199) for details.

Cache Redirection Configuration ExampleThe following is required prior to configuration:

• You must connect to the application switch Command Line Interface(CLI) as the administrator.

• Layer 4 (SLB) software must be enabled.

Note: For details about the procedures above, and about any of themenu commands described in this example, see the Nortel ApplicationSwitch Operating System Command Reference.




.


In this example, an Nortel Application Switch is placed between the clientsand the border gateway to the Internet. The application switch will beconfigured to intercept all Internet bound HTTP requests (on default TCPport 80), and redirect them to the cache servers. The application switchwill distribute HTTP requests equally to the cache servers based on thedestination IP address of the requests. If the cache servers do not have therequested information, then the cache servers behave like the client andforwards the request out to the internet.

Also, filters are not limited to the few protocols and TCP or UDP applicationsshown in this example. See "Well-Known Application Ports" (page 199) for alist of well-known applications ports and "Well-Known Protocol Types" (page366) for a list of supported protocols.

Step Action

1 Assign an IP address to each of the cache servers.

Similar to server load balancing, the cache real servers are assignedan IP address and placed into a real server group. The real serversmust be in the same VLAN and must have an IP route to theapplication switch that will perform the cache redirection. In addition,the path from the application switch to the real servers must notcontain a router. The router would stop HTTP requests from reachingthe cache servers and, instead, direct them back out to the Internet.

More complex network topologies can be used if configuring IP proxyaddresses (see "IP Proxy Addresses for NAT" (page 421)).

For this example, the three cache real servers have the following IPaddresses on the same IP subnet:

Cache Redirection Example: Real Server IP Addresses

Cache Server IP address

Server A 200.200.200.2

Server B 200.200.200.3

Server C 200.200.200.4

2 Install transparent cache software on all three cache servers.

3 Define an IP interface on the application switch.

The application switch must have an IP interface on the same subnetas the three cache servers because, by default, the applicationswitch only remaps destination MAC addresses.

To configure an IP interface for this example, enter this commandfrom the CLI:




.






Note: The IP interface and the real servers must be in the samesubnet. This example assumes that all ports and IP interfacesuse default VLAN 1, requiring no special VLAN configuration forthe ports or IP interface.

4 Define each real server on the switch.

For each cache real server, you must assign a real server number,specify its actual IP address, and enable the real server. Forexample:

>> # /cfg/slb/real 1 (Server A is real server 1)

>> Real server 1# rip200.200.200.2

(Assign Server A IPaddress)


>> Real server 1# /cfg/slb/real2

(Server B is real server 2)

>> Real server 2# rip200.200.200.3

(Assign Server B IPaddress)




>> Real server 3# rip200.200.200.4

(Assign Server C IPaddress)


5 Define a real server group.

This places the three cache real servers into one service group:

>> Real server 3# /cfg/slb/group 1


>> Real server group 1# add 1 (Add real server 1 to group1)






.


6 Set the real server group metric to minmisses.

This setting helps minimize cache misses in the event real serversfail or are taken out of service:

>> Real server group 1# metricminmisses

(Metric for minimum cachemisses.)

7 Verify that server processing is disabled on the portssupporting application redirection.

Note: Do not use the "server" setting on a port with ApplicationRedirection enabled. Server processing is used only with serverload balancing. To disable server processing on the port, usethe commands on the /cfg/slb/port menu, as describedin the Nortel Application Switch Operating System CommandReference.

8 Create a filter that will intercept and redirect all client HTTPrequests.

The filter must be able to intercept all TCP traffic for the HTTPdestination port and must redirect it to the proper port on the realserver group:

>> SLB port 6# /cfg/slb/filt 2 (Select the menu for Filter2)





>> Filter 2# dport http (To an HTTP destinationport)

>> Filter 2# action redir (Set the action forredirection)

>> Filter 2# rport http (Set the redirection port)

>> Filter 2# group 1 (Select real server group 1)





.


The rport (redirection) parameter must be configured wheneverTCP/UDP protocol traffic is redirected. The rport parameter definesthe real server TCP or UDP port to which redirected traffic willbe sent. The port defined by the rport parameter is used whenperforming Layer 4 health checks of TCP services.

Also, if NAT and proxy addresses are used on the application switch(see Step 3 on step 3), the rport parameter must be configured forall application redirection filters. Take care to use the proper portdesignation with rport: if the transparent proxy operation resideson the host, the well-known port 80 (or HTTP) is probably required.If the transparent proxy occurs on the application switch, make sureto use the service port required by the specific software package.

See "IP Proxy Addresses for NAT" (page 421) for more informationon IP proxy addresses.

9 Create a default filter.

In this case, the default filter will allow all noncached traffic toproceed normally:

>> Filter 2# /cfg/slb/filt 2048 (Select the default filter)




>> Filter 2048# action allow (Set the action to allowtraffic)


Note: When the proto parameter is not TCP or UDP, then sportand dport are ignored.

10 Assign the filters to the client ports.

Assuming that the redirected clients are connected to physicalswitch ports 5 and 6, both ports are configured to use the previouslycreated filters as follows:

>> Filter 2048# /cfg/slb/port 5 (Select the client port 5)







.


>> SLB Port 5# /cfg/slb/port 6 (Select the client port 6)




11 Activate layer 4 services. Apply, and verify the configuration.

>> SLB Port 6# /cfg/slb (Select Server LoadBalancing Menu)

>> Layer 4# on (Activate Layer 4 softwareservices)



Note: SLB must be turned on in order for application redirectionto work properly. The on command is valid only if the optionalLayer 4 software is enabled on your application switch (see"Activating Optional Software" in the Nortel Application SwitchOperating System Command Reference).

12 Examine the resulting information from the cur command. Ifany settings are incorrect, make appropriate changes.



14 Check the SLB information.

>> Layer 4# /info/slb (View SLB information)


Note: Changes to filters on a given port only effect new sessions.To make filter changes take effect immediately, clear the sessionbinding table for the port (see the /oper/slb/clear commandin the Nortel Application Switch Operating System CommandReference).

—End—




.


Delayed Binding for Cache RedirectionTo configure delayed binding on your application switch for cache redirectiononly, use the following command:

>> # /cfg/slb/filt <filter number> /adv/layer7/l7lkup ena

For more conceptual information on delayed binding, see "Delayed Binding"(page 242).

RTSP Cache RedirectionNortel Application Switch Operating System supports cache redirection forReal Time Streaming Protocol (RTSP). RTSP cache redirection is similarto HTTP cache redirection in configuration and in concept. Multimediapresentations consume a lot of Internet bandwidth. The quality of thesepresentations depends upon the real time delivery of the data. To ensurethe high quality of multimedia presentations, several caching servers areneeded to cache the multimedia data locally. This data is then madeavailable quickly from the cache memory as required.

RTSP cache redirection redirects cached data transparently and balancesthe load among the cache servers. If there is no cache server, the requestis directed to the origin server. Internet Service Providers use this feature tocache the multimedia data of a customer site locally. Since the requests forthis data are directed to the local cache, they are served faster.

This section explains Layer 4 support for RTSP Streaming CacheRedirection. For detailed information on two prominent commercial RTSPservers—Real Player and QuickTime—see "Real Time Streaming ProtocolSLB" (page 268).

You can also configure the application switch to redirect client requestbased on URL content. For information on layer 7 RTSP Streaming CacheRedirection, see "RTSP Streaming Cache Redirection" (page 439).




.


RTSP Cache Redirection

Follow this procedure to configure to load balance RTSP cache servers forthe topology illustrated in "RTSP Cache Redirection" (page 418):

Step Action

1 Before configuring RTSP, do the following:

• Connect each cache server to the application switch



2 At the application switch, configure RTSP cache servers andthe IP addresses


>> Real server 1# rip 1.1.1.1 (Configure RTSP cacheserver 1)

>> Real server 1# ena (Enable RTSP cache server1)

>> Real server 1# /cfg/slb/real 2





.









3 Define a group to load balance the RTSP cache servers.

>> # /cfg/slb/group 1

>> Real Server Group 1# add 1 (Add RTSP cache server 1to group 1)




4 Define the group metric for the RTSP cache servers.

RTSP supports all the standard load balancing metrics.

>>Real Server Group 1# metricleastconn

(Set the metric to leastconn)

5 Configure an RTSP redirection filter to cache data and balancethe load among the cache servers.

>> # /cfg/slb/filt 1 (Select the menu for filter 1)


>> Filter 1# proto tcp (Enter TCP protocol)

>> Filter 1# dport rtsp (Enter service port forRTSP)




.


>> Filter 1# rport rtsp (Enter redirection port forRTSP)

>> Filter 1# group 1 (Select RTSP cache servergroup 1)

>> Filter 1# adv (Select advanced menu forfilter 1)

>> Filter 1# Advanced# proxydisable

(Disable proxy)

6 Configure a default allow filter to facilitate traffic.

>> # /cfg/slb/filt 2048 (Select a default allow filter2048)



>> Filter 2048# ena (Enable a default allowfilter)

>> Filter 2048# action allow (Set the action to allownormal traffic)

7 Add and enable the redirection filter on the port to supportbasic cache redirection.

>> # /cfg/slb/port 25 (Select the menu for port25)

>> SLB Port 25# add 1 (Add RTSP filter 1 to port25)

>> SLB Port 25# add 2048 (Add default filter 2048 toport 25)

>> SLB Port 25# filt ena (Enable filtering on port 25)



—End—




.


IP Proxy Addresses for NATTransparent proxies provide the benefits listed below when used withapplication redirection. Application redirection is automatically enabledwhen a filter with the redir action is applied on a port.

• With proxy IP addresses configured on ports that use redirection filters,the application switch can redirect client requests to servers locatedon any subnet.

• The application switch can perform transparent substitution for allsource and destination addresses, including destination port remapping.This provides support for comprehensive, fully-transparent proxies. Noadditional client configuration is needed.

The following procedure can be used for configuring proxy IP addresses:

Step Action

1 Configure proxy IP addresses and enable proxy for theredirection ports.

Each of the ports using redirection filters require proxy IP addresses.For more information on proxy IP addresses, see "Proxy IPAddresses" (page 228).

In this example, proxy IP addresses are configured:

>> SLB port 3# /cfg/slb/pip (Select proxy IP addressmenu)

>> Proxy IP address# type port (Use port-based proxy IP)

>> Proxy IP Address# add200.200.200.68

(Set proxy IP address)







>> Proxy IP Address# /cfg/slb/port 1

(Select port 1)

>> SLB port 1# proxy ena (Enable proxy port 1)

>> SLB port 1# /cfg/slb/port 2 (Select port 2)







.








2 Configure the application redirection filters.

Once proxy IP addresses are established, configure each applicationredirection filter (Filter 2 in our example) with the real server TCPor UDP port to which redirected traffic will be sent. In this case, therequests are mapped to a different destination port (8080). You mustalso enable proxies on the real servers:


>> Filter 2# rport 8080 (Set proxy redirection port)

>> Filter 2# /cfg/slb/real1/proxy enable

(Enable proxy on realservers)

>> Real server 1# /cfg/slb/real 2/proxy enable (Enableproxy on real servers)

>> Real server 2# /cfg/slb/real 3/proxy enable (Enableproxy on real servers)

Note: This configuration is not limited to HTTP (Web) service.Other TCP/IP services can be configured in a similar fashion.For example, if this had been a DNS redirect, rport would be sentto well-known port 53 (or the service port you want to remapto). For a list of other well-known services and ports, see the"Well-Known Application Ports" (page 199).


4 Check server statistics to verify that traffic has been redirectedbased on filtering criteria:

>> # /info/slb/group <group number> /filter <filternumber>

—End—




.


Excluding Noncacheable SitesSome sites provide content that is not well suited for redirection to cacheservers. Such sites might provide browser-based games or applications thatkeep real-time session information or authenticate by client IP address.

To prevent such sites from being redirected to cache servers, create a filterthat allows this specific traffic to pass normally through the applicationswitch. This filter must have a higher precedence (a lower filter number)than the application redirection filter.

For example, if you want to prevent a popular Web-based game site onsubnet 200.10.10.* from being redirected, you could add the following tothe previous example configuration:

>> # /cfg/slb/filt 1 (Select the menu for filter 1)

>> Filter 1# dip 200.10.10.0 (To the site’s destination IPaddress)

>> Filter 1# dmask 255.255.255.0 (For entire subnet range)



>> Filter 1# dport http (To an HTTP destination port)


>> Filter 1# action allow (Allow matching traffic to pass)


>> Filter 1# /cfg/slb/port 5 (Select SLB port 5)


>> SLB port 5# /cfg/slb/port 6 (Select SLB port 6)




Content Intelligent Cache RedirectionNortel Application Switch Operating System allows you to redirect cacherequests based on different Layer 7 content such as HTTP headerinformation, such as "Host:" header or "User-Agent" for browser-smartload balancing.

The No Cache/Cache Control for cache redirection feature in NortelApplication Switch Operating System allows you to off load the processingof non-cacheable content from cache servers by sending only appropriaterequests to the cache server farm. When a Cache-Control header is presentin a HTTP 1.1 request, it indicates a client’s special request with respect




.


to caching, such as to guarantee up-to-date data from the origin server. Ifthis feature (Cache-Control: no cache directive) is enabled, HTTP 1.1 GETrequests are forwarded directly to the origin servers.

Note: The term origin server refers to the server originally specifiedin the request.

The HTTP 1.0 Pragma: no-cache header is equivalent to the HTTP 1.1Cache-Control header. By enabling the Pragma: no-cache header,requests are forwarded to the origin server.

Note: For cache redirection, at any given time one HTTP header issupported globally for the entire switch.

This section discusses the following types of cache redirection:

• "URL-Based Cache Redirection" (page 424)

• "HTTP Header-Based Cache Redirection" (page 433)

• "Browser-Based Cache Redirection" (page 434)

• "URL Hashing for Cache Redirection" (page 436)

• "RTSP Streaming Cache Redirection" (page 439)

URL-Based Cache RedirectionURL parsing for cache redirection operates in a manner similar toURL-based server load balancing—except that in cache redirection, avirtual server on the switch is the target of all IP/HTTP requests. Forinformation on URL-based server load balancing, see "URL-Based ServerLoad Balancing" (page 211).

By separating static and dynamic content requests via URL parsing, NortelApplication Switch Operating System enables you to send requests withspecific URLs or URL strings to designated cache servers. The URL-basedcache redirection option allows you to off load overhead processing fromthe cache servers by only sending appropriate requests to the cache serverfarm.

Note: Both HTTP 1.0 and HTTP 1.1 requests are supported.

Each request is examined and handled as described below:

• If the request is a non-GET request such as HEAD, POST, PUT, orHTTP with cookies, it is not sent to the cache.

• If the request is an ASP or CGI request or a dynamically generatedpage, it is not sent to the cache.

• If the request contains a Cookie, it can optionally bypass the cache.




.


Examples of matching string expressions are:

• /product

Any URL that starts with "/product," including any information in the"/product" directory

• product

Any URL that has the string "product"

Some of the common noncacheable items that you can configure the switchto add to, delete, or modify are:

• Dynamic content files:

— Common gateway interface files (.cgi)

— cold fusion files (.cfm), ASP files (.asp)

— BIN directory

— CGI-BIN directory

— SHTML (scripted html)

— Microsoft HTML extension files (.htx)

— executable files (.exe)

• Dynamic URL parameters: +, !, %, =, &




.


URL-Based Cache Redirection

Requests matching the URL are load balanced among the multiple servers,depending on the metric specified for the real server group (leastconns isthe default).

Network Address Translation OptionsURL-based cache redirection supports three types of Network AddressTranslation (NAT): No NAT, Half NAT, and Full NAT.

• No NAT

In this NAT method, the traffic is redirected to the cache with thedestination MAC address of the virtual server replaced by the MACaddress of the cache. The destination IP address remains unchanged,and no modifications are made to the IP address or the MAC addressof the source or origin server. This works well for transparent cacheservers, which process traffic destined to their MAC address but use theIP address of some other device.

• Half NAT

In this most commonly used NAT method, the destination IP addressis replaced by the IP address of the cache, and the destination MAC




.


address is replaced by the MAC address of the cache. Both the IPaddress and the MAC address of the source remain unchanged.

• Full NAT

In this NAT method, the source IP address and the source MAC addressare replaced by the IP address and MAC address of the cache. Thismethod works well for proxy cache servers.

Configuring URL-Based Cache RedirectionTo configure URL-based cache redirection, perform the following steps:

Step Action

1 Before you can configure URL-based cache redirection,configure the switch for basic Server Load Balancing (SLB)with the following tasks:





2 Configure the switch to support basic cache redirection.

For information on cache redirection, refer to "ApplicationRedirection" (page 409).

3 Configure the parameters and file extensions that bypass cacheredirection.

a. Add or remove string IDs that should not be cacheable.

>> # /cfg/slb/filt 1/adv/addstr|remstr <ID>>> # /cfg/slb/layer7/slb/addstr|remstr <strings>

b. Enable/disable ALLOW for non-GETS (such as HEAD, POST,and PUT) to the origin server, as described below.

>> # /cfg/slb/layer7/redir/urlal {ena|dis}

• Ena: The switch allows all non-GET requests to the originserver.




.


• Dis: The switch compares all requests against the expressiontable to determine whether the request should be redirectedto a cache server or the origin server.

c. Enable/disable cache redirection of requests that contain "cookie: " in the HTTP header.

>> # /cfg/slb/layer7/redir/cookie {ena|dis}

• Ena: The switch redirects all requests that contain "cookie:"in the HTTP header to the origin server.

• Dis: The switch compares the URL against the expressiontable to determine whether the request should be redirectedto a cache server or the origin server.

d. Enable/disable cache redirection of requests that contain "Cache-control:no cache " in the HTTP 1.1 header or "Pragma:no cache " in the HTTP 1.0 header to the originserver.

>> # /cfg/slb/layer7/redir/nocache {ena|dis}

• Ena: The switch redirects all requests that containCache-control: no cache in the HTTP 1.1 header orPragma:no cache in the HTTP 1.0 header to the originserver.

• Dis: The switch compares the URL against the expressiontable to determine whether the request should be redirectedto a cache server or the origin server.

4 Define the string(s) to be used for cache SLB. Refer to theparameters listed below:

>> # /cfg/slb/layer7/slb/{addstr|remstr} <string>

• addstr: Add a string or a path.

• remstr: Remove string or a path.

A default string any indicates that the particular server can handle allURL or cache requests. Refer to the following examples:

Example 1: String Starting with the Forward slash (/)




.


A string that starts with a forward slash ( / ), such as "/images,"indicates that the server will process requests that start out withthe "/images" string only.

For example, with the "/images" string, the server will handle theserequests:

/images/product/b.gif/images/company/a.gif/images/testing/c.jpg

The server will not handle these requests:

/company/images/b.gif/product/images/c.gif/testing/images/a.gif

Example 2: String without the Forward slash (/)

A string that does not start out with a forward slash ( / ) indicatesthat the server will process any requests that contain the definedstring. For example, with the "images" string, the server will processthese requests:

/images/product/b.gif/images/company/a.gif/images/testing/c.jpg/company/images/b.gif/product/images/c.gif/testing/images/a.gif

Example 3: String with the Forward slash (/) Only

If a server is configured with the load balance string ( / ) only, it willonly handle requests to the root directory. For example, the serverwill handle any files in the ROOT directory:

//index.htm/default.asp

/index.shtm




For easy configuration and identification, each defined string has anID attached, as shown in "SLB Strings" (page 430).




.


SLB Strings

ID SLB String

1 any

2 .gif

3 /sales

4 /xitami

5 /manual

6 .jpg

7 Configure the real server(s) to support cache redirection.


Add the defined string(s) to the real servers:


where ID is the identification number of the defined string.

The server can have multiple defined strings. For example:"/images", "/sales", ".gif"

With these defined strings, the server can handle requests that beginwith "/images" or "/sales" and any requests that contain ".gif".

8 Define a real server group and add real servers to the group.

The following configuration combines three real servers into a group:





9 Configure a filter to support basic cache redirection.

The filter must be able to intercept all TCP traffic for the HTTPdestination port and must redirect it to the proper port in the realserver group:




.


>> # /cfg/slb/filt <filternumber>

(Select the menu for Filter#x)

>> Filter <filter number> # sipany

(From any source IPaddresses)

>> Filter <filter number> # dipany

(To any destination IPaddresses)

>> Filter <filter number> #proto tcp

(For TCP protocol traffic)

>> Filter <filter number> #sport any

(From any source port)

>> Filter <filter number> #dport http

(To an HTTP destinationport)

>> Filter <filter number> #action redir

(Set the action forredirection)

>> Filter <filter number> #rport http

(Set the redirection port)

>> Filter <filter number> #group 1


>> Filter <filter number> # ena (Enable the filter)

10 Enable URL-based cache redirection on the same filter.

>> # /cfg/slb/filt <filter number> /adv/layer7/l7lkupena

11 Select the appropriate NAT option.

The three NAT options are listed below. For more information abouteach option, see "Network Address Translation Options" (page 426).

• No NAT option:

>> # /cfg/slb/filter <filter number> /adv/proxy dis

• Half NAT option:

>> # /cfg/slb/filter <filter number> /adv/proxy ena

• Full NAT option:

>> # /cfg/slb/pip


(Configure proxy IPaddress)




.


>> # /cfg/slb/filt <filter number>

>> Filter <filter number> #rport 3128

(Specify redirection port)

>> Filter <filter number> # adv (Select the advancemenu)

>> Filter <filter number>Advanced# proxy ena

(Enable proxy IP address)


12 Create a default filter for noncached traffic on the switch.

>> # /cfg/slb/filt <filternumber>

(Select the default filter)

>> Filter <filter number> # sipany

(From any source IPaddresses)

>> Filter <filter number> # dipany

(To any destination IPaddresses)

>> Filter <filter number> #proto any

(For any protocol traffic)

>> Filter <filter number> #action allow

(Set the action to allowtraffic)

>> Filter <filter number> # ena (Enable the default filter)

>> Filter <filter number> # port<port number>

(Assign the default filter toa port)

Note: When the proto parameter is not tcp or udp, then sportand dport are ignored.

13 Turn on filtering for the port.

>> SLB <port number> # filt ena

14 Add the filters to the client port.

>> SLB <port number> # add <filter number>

15 Enable Direct Access Mode (DAM) on the switch.

>> SLB <port number> # /cfg/slb/adv>> Layer 4 Advanced# direct ena




.



>> # /cfg/slb (Select the SLB Menu)

>> # on (Turn SLB on)

>> # apply (Make your changes active)

>> # cur (View current settings)

—End—

Viewing Statistics for URL-Based Cache RedirectionTo show the number of hits to the cache server or origin server, use thiscommand:

>> # /stats/slb/layer7/redirTotal URL based Web cache redirection stats:Total cache server hits: 73942Total origin server hits: 2244Total none-GETs hits: 53467Total ’Cookie: ’ hits: 729Total no-cache hits: 43

HTTP Header-Based Cache RedirectionTo configure the switch for cache direction based on the "Host:" header,use the following procedure:

Step Action

1 Configure basic SLB.

Before you can configure header-based cache redirection, ensurethat the switch has already been configured for basic SLB (see"Server Load Balancing" (page 188)) with the following tasks:






2 Turn on Layer 7 lookup for the filter.

>> # /cfg/slb/filt 1/adv/layer7/l7lkup ena




.


3 Enable header load balancing for the Host: header.

>> # /cfg/slb/layer7/redir/header ena host

4 Define the host names

>> # /cfg/slb/layer7/slb/addstr ".com">> Server Load Balance Resource# add ".org">> Server Load Balance Resource# add ".net"


6 Identify the string ID numbers with this command.


Each defined string has an associated ID number.

SLB Strings

ID SLB String

1 any

2 .com

3 .org

4 .net

7 Configure the real server(s) to handle the appropriate loadbalance string(s).

Add the defined string IDs to the real servers:



Note: If you don’t add a defined string (or add ID=1), the serverwill handle any request.

—End—

Browser-Based Cache RedirectionBrowser-based cache redirection uses the User-agent: header. To configurebrowser-based cache redirection, perform the following procedure.




.


Step Action

1 Before you can configure header-based cache redirection,ensure that the switch is already configured for basic SLB withthe following tasks:







>> # /cfg/slb/filt 1/adv/layer7/l7lkup enable

3 Enable header load balancing for "User-Agent:" header.

>> # /cfg/slb/layer7/redir/header ena useragent


>> # /cfg/slb/layer7/slb/addstr "Mozilla">> Server Load Balance Resource# add "InternetExplorer">> Server Load Balance Resource# add "Netscape"


6 Identify the string ID numbers with this command.


Each defined string has an ID number.

Number of entries: four

SLB Strings

ID SLB String

1 any

2 Mozilla




.


ID SLB String

3 Internet Explorer

4 Netscape

7 Add the defined string IDs to configure the real server(s) tohandle the appropriate load balance string(s).



Note: If you don’t add a defined string (or add the ID 1), theserver will handle any request.

—End—

URL Hashing for Cache RedirectionBy default, hashing algorithms use the source IP address and/or destinationIP address (depending on the application area) to determine contentlocation. For example, firewall load balancing uses both source anddestination IP addresses, cache redirection uses only the destination IPaddress, and SLB uses only the source IP address.

Hashing is based on the URL, including the HTTP Host header (if present),up to a maximum of 255 bytes. You can optimize "cache hits" by using thehashing algorithm to redirect client requests going to the same page of anorigin server to a specific cache server.

For example the switch could use the string "nortelnetworks.com/prod-ucts/2424/" for hashing the following request:

GET http://products/2424/ HTTP/1.0HOST:www.nortel.com

To configure the switch for cache redirection based on a hash key, use thefollowing procedure:

Step Action

1 Configure basic SLB.

Before you can configure header-based cache redirection, ensurethat the switch has already been configured for basic SLB (see"Server Load Balancing" (page 188)) with the following tasks:





.







• Configure the load-balancing algorithm to hash or minmiss.


>> # /cfg/slb/filt 1/adv/layer7/l7lkup enable

3 Enable hash to direct a cacheable URL request to a specificcache server.

By default, the host header field is used to calculate the hash keyand URL hashing is disabled.

• hash ena: Enables hashing based on the URL and the hostheader if it is present. Specify the length of the URL to hash intothe cache server.

>> # /cfg/slb/layer7/redir/hash enaEnter new hash length [1-255]: 24

• hash disable: Disables hashing based on the URL. Instead, thehost header field to calculate the hash key.

If the host header field does not exist in the HTTP header, thenthe switch uses the source IP address as the hash key.

—End—

Example 1: Hashing on the URLIn this example, URL hashing is enabled. If the Host field does not exist,the specified length of the URL is used to hash into the cache server asshown in "URL Hashing for Application Redirection" (page 438). If the Hostfield exists, the specified length of both the Host field and the URL is usedto hash into the cache server. The same URL request goes to the samecache server as shown below:

• Client 1 request http://www.nortelnetworks.com/sales/index.htm isdirected to cache server 1.





.

http://www.nortelnetworks.com/sales/index.htm




URL Hashing for Application Redirection

Example 2: Hashing on the Host Header Field OnlyIn this example, URL hashing is disabled. If you use the Host header fieldto calculate the hash key, the same URL request goes to the same cacheserver:

• Client 1 request http://www.nortelnetworks.com is directed to cacheserver 1.



Example 3: Hashing on the Source IP addressIn this example, URL hashing is disabled. Because the host header fielddoes not exist in the HTTP header, the source IP address is used as thehash key and requests from clients 1, 2, and 3 are directed to three differentcache servers as shown below.







.









RTSP Streaming Cache RedirectionRTSP load balancing with the URL hash metric can be used to load balancecache servers that cache multimedia presentations. Since multimediapresentations consume a large amount of Internet bandwidth, and theircorrect presentation depends upon the real time delivery of the data overthe Internet, several caching servers cache the multimedia data.

As a result, the data is available quickly from the cache, when required.The Layer 7 metric of URL hashing directs all requests with the same URLto the same cache server, ensuring that no data is duplicated across thecache servers. All the stream connections and the control connectionsare switched to the same cache server to facilitate caching of entirepresentations.

This section explains Layer 7 support for RTSP Streaming CacheRedirection. For conceptual information on RTSP Streaming CacheRedirection, see "RTSP Cache Redirection" (page 417). For detailedinformation on two prominent commercial RTSP servers—Real Player andQuickTime—see "Real Time Streaming Protocol SLB" (page 268).

In the scenario illustrated in "Load Balancing RTSP Cache Servers" (page439), the cache servers are configured for forward proxy mode. The cacheservers process the client request even though the destination IP address isnot destined for the cache servers.

Load Balancing RTSP Cache Servers




.


Follow this procedure to configure to load balance RTSP cache servers forthe topology illustrated in "Load Balancing RTSP Cache Servers" (page439):

Step Action

1 Before you start configuring the application switch do thefollowing:

• Connect each cache server to the application switch



2 At the application switch, configure RTSP cache servers andthe IP addresses.













3 Define a group to load balance the RTSP cache servers.




.







4 Configure a redirection filter.

>> # /cfg/slb/filter 100(Select the menu for filter100)


>> Filter 100# proto tcp (Enter TCP protocol)

>> Filter 100# dport rtsp (Enter service port forRTSP)

>> Filter 100# rport rtsp (Enter redirection port forRTSP)

>> Filter 100# group 1 (Select RTSP cache servergroup 1)

>> Filter 100# adv (Select advanced menu forfilter 100)

>> Filter 100# Advanced# proxydisable

(Disable proxy)

5 Enable Layer 7 lookup for the redirection filter 100.

>> Filter 100 Advanced#layer7/l7lkup ena

(Enable Layer 7 lookup)

6 Configure a default allow filter to facilitate traffic.

>> # /cfg/slb/filt 2048(Select a default allow filter2048)





.



>> Filter 2048# ena (Enable a default allowfilter)

>> Filter 2048# action allow (Set the action to allownormal traffic)

7 Add and enable the redirection filter to the port.

>> # /cfg/slb/port 25(Select the menu for port25)

>> SLB Port 25# add 100 (Add RTSP filter 100 to port25)

>> SLB Port 25# add 2048 (Add default filter 2048 toport 25)

>> SLB Port 25# filt ena (Enable filtering on port 25)

8 Configure the parameters and file extensions that will bypassRTSP streaming cache redirection. This is for user-definednon-cacheable content.

For example, QuickTime files are non-cacheable—RTSP files withthe extension *.mov must bypass the streaming cache redirection.Similarly, you can add other RTSP file extensions (such as *.smil,*.rm, *.ram, and so forth) to bypass the redirection.

>> # /cfg/slb/layer7/slb(Select the SLB resourcemenu)

>> # addstr *.mov (Add non-cacheable RTSPstrings)

A client request of the form RTSP://*.mov bypasses the cacheservers and instead is routed directly to the original servers.

9 Under the filter menu, add the string IDs that need to beexcluded.

>> /cfg/slb/filt 20/adv/layer7(Select the Filtering L7 Adv.menu)

>> Layer 7 Advanced# addstr 2 (Add the string ID for *.mov)

10 Define the RTSP file extensions to load balance among thecache servers.




.


>> # /cfg/slb/layer7/slb/addstr condor.rm>> Server Load Balance Resource# addstr tiger.rm


12 Identify the associated ID number for each of the defined RTSPfile extension.


SLB Strings

ID SLB String

1 any

2 *.mov

3 condor.rm

4 tiger.rm

13 Assign the URL string ID to the cache servers.

>> # /cfg/slb/real 1(Select the real server 1)

>> Real Server 1# Layer 7/addlb3

(Add the URL string ID 3)

>> Real Server 1 Layer 7 Commands# cfg/slb/real 2









Note: If no string is assigned to the server, the server will handleall requests.





.


>> Real Server 4 Layer 7 Commands# apply>> Real Server 4 Layer 7 Commands# save

Client requests condor.rm or tiger.rm are retrieved from the localcache servers 1 or 2 and 3 or 4 respectively; however, a clientrequest cheetah.mov bypasses the local cache servers and isforwarded to the original server.

—End—

HTTP RedirectionFilters can be used to redirect HTTP requests to different gateways orservers. The following HTTP redirection types are supported:

• IP redirection—The application switch redirects client requests todifferent service gateways based on the address range of the clientdevice and requested URL. For details, see "IP based HTTP redirection"(page 447).

• Port redirection—The application switch examines traffic entering ona TCP service port (such as HTTP port 80) and sends that traffic to auser-specified IP address on a different service port (such as 9090). Fordetails, see "TCP Service Port Based HTTP Redirection" (page 450).

• MIME type redirection—The application switch examines the HTTPheader or URL of an incoming request for a specific MultipurposeInternet Mail Extensions (MIME) type, and replaces the URL withanother URL. For details, see "MIME Type Header-Based Redirection"(page 452).

• URL redirection—The application switch examines a URL and redirectsit to a preconfigured IP address or URL. For details, see "URL-BasedRedirection" (page 454).

Note: The HTTP header redirection feature is not limited to the types ofHTTP headers listed below.

Configure SLB Strings for HTTP RedirectionAll of the following HTTP filtering redirection examples require the followingserver load balancing (SLB) strings to be configured. Each defined stringhas an associated ID number. A filter is then configured to redirect fromone configured string ID to another.

"Example HTTP Redirection Strings" (page 445) shows the ID numbers andSLB string content for the strings used in the following examples. Not allstrings are used in each example.




.


Example HTTP Redirection Strings

ID SLB String

1 any, cont 256

2 HTTPHDR=Host:wap.example.com

3 HTTPHDR=Host:wap.yahoo.com

4 HTTPHDR=Host:wap.google.com

5 HTTPHDR=Host:wap.p-example.com

6 HTTPHDR=Host:10.168.224.227=/top

7 jad, cont 256

8 jar, cont 256

9 HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor

10 HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL

11 HTTPHDR=Host:any

12 HTTPHDR=Host:any:90

13 HTTPHDR=Host:any:8080

14 HTTPHDR=X-Foo-ipaddress:10.168.100.*

15 HTTPHDR=Host:www.abc.com, cont 256

16 HTTPHDR=Host:any:443, cont 256

17 HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST/nava/toggle.jad, nre, cont 1024

18 HTTPHDR=Host:mobile.example.com=/4g/w?url=dev.example.com/$URL, nre, cont 1024

Step Action

1 Configure the switch with the basic Server Load Balancingrequirements as described in "HTTP Header-Based CacheRedirection" (page 433).

2 Configure the filter strings.

>> # /cfg/slb/layer7/slb/

>> Server Loadbalance Resource#addstr

(Add the first SLB string)


Configure HTTP header string? (y/n) [n] y

Enter HTTP header name: Host

Enter SLB header value string: wap.example.com




.


Configure URL string? (y/n) [n] n

>> # /cfg/slb/layer7/slb/ (Select the Serverloadbalance Resource menu)

>> Server Loadbalance Resource#add

(Add the second SLB string)


Enter HTTP header name:Host

(Define HTTP headername Host)

Enter SLB header value string: wap.yahoo.com

3 Use the same commands as step 2 to configure the rest of thefilter strings shown in "Example HTTP Redirection Strings" (page445).

4 Identify the ID numbers of the defined strings.


Number of entries: 141: any, cont 2562: HTTPHDR=Host:wap.example.com, cont 2563: HTTPHDR=Host:wap.yahoo.com, cont 2564: HTTPHDR=Host:wap.google.com, cont 2565: HTTPHDR=Host:wap.p-example.com, cont 2566: HTTPHDR=Host:10.168.224.227=/top, cont 2567: jad, cont 2568: jar, cont 2569: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor,cont 25610: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL, cont 25611: HTTPHDR=Host:any, cont 25612: HTTPHDR=Host:any:90, cont 25613: HTTPHDR=Host:any:8080, cont 25614: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 25615: HTTPHDR=Host:www.abc.com, cont 25616: HTTPHDR=Host:any:443, cont 25617: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST/nava/toggle.jad, nre, cont 102418: HTTPHDR=Host:mobile.example.com=/4g/w?url=dev.example.com/$URL, nre, cont 1024

5 Configure a port for client traffic. This configuration assumesclient traffic enters the application switch on port 1. Enabledfiltering on the client port.




.


>> /cfg/slb/port 1(Select the SLB port 1menu)

>> SLB port 1# filt en (Enable filtering on the port)

Current port 1 filtering: disabled

New port 1 filtering: enabled

The basic HTTP redirection configuration is now complete and canbe used for each of the redirection options described in the followingsections.

—End—

IP based HTTP redirectionIn this example, the application switch will redirect Web pages requestedfrom a mobile phone, to a specific gateway based on the client’s IP address.A mobile phone is set to access its home page via the default devicegateway.

Example client phone configuration:

Device Gateway IP address 10.168.107.101Home page: http://wap.example.comWAP port 9001, CSD number as 18881234567username: john

Configuration rulesThe following filter rules on the Application switch to filter client requestsfrom different WAP gateways:

• Filter 1: If the client IP address is between 10.168.43.0-255 and therequested URL is http://wap.example.com, then redirect the clientrequest to http://wap.yahoo.com.

• Filter 2: If the Client IP address is between 10.46.6.0.0-255 and therequested URL is http://wap.example.com then redirect the clientrequest to http://wap.google.com.

• Filter 3: If the client IP address is between 10.23.43.0- 255 and therequested URL is http://wap.p-example.com, then redirect the clientrequest to http://10.168.224.227/top.

Assuming that each client is in a different subnet, configure the switchwith three filters to redirect client requests from each subnet, to theURLs specified above. Use the string index numbers in "Example HTTPRedirection Strings" (page 445) to configure a redirection map for each filter.




.


Step Action

1 Identify the ID numbers of the defined strings. The strings inbold are used in this example.



2 Configure filter 1.

>> /cfg/slb/filt 1

>> Filter 1 # sip 10.168.43.0 (From this source IPaddress range)

Current source address: any

New pending source address: 10.168.43.0

>> Filter 1 # smask 255.255.255.0

Current source mask: 0.0.0.0

New pending source mask: 255.255.255.0

>> Filter 1 # proto tcp (For TCP protocol traffic)




.


Current protocol: any

Pending new protocol: tcp

>> Filter 1 # dport http (To destination port HTTP)

Current destination port or range: any

Pending new destination port or range: http

>> Filter 1 # action redir (Redirect the traffic)

Current action: allow

Pending new action: redir

>> Filter 1 # /cfg/slb/filt/adv/layer7

(Access advanced Layer 7menu)

>> Layer 7 Advanced# addrd

Enter filtering string ID(1-1024) to redirect from:

2(Redirect string 2 ..)

Enter filtering string ID(2-1024) to redirect to:

3(to string 3)


>> /cfg/slb/filt 2>> Filter 2 # sip 10.46.6.0.0Current source address: anyNew pending source address: 10.46.6.0.0>> Filter 2 # smask 255.255.255.0Current source mask: 0.0.0.0New pending source mask: 255.255.255.0>> Filter 2 # proto tcpCurrent protocol: anyPending new protocol: tcp>> Filter 2 # dport httpCurrent destination port or range: anyPending new destination port or range: http>> Filter 2 # action redirCurrent action: allowPending new action: redir>> Filter 2 # /cfg/slb/filt/adv/layer7>> Layer 7 Advanced# addrdEnter filtering string ID (1-1024) toredirect from: 2Enter filtering string ID (2-1024) toredirect to: 4

4 Configure Filter 3.




.


>> /cfg/slb/filt 3>> Filter 3 # sip 10.23.43.0Current source address: anyNew pending source address: 10.23.43.0>> Filter 3 # smask 255.255.255.0Current source mask: 0.0.0.0New pending source mask: 255.255.255.0>> Filter 3 # proto tcpCurrent protocol: anyPending new protocol: tcp>> Filter 3 # dport httpCurrent destination port or range: anyPending new destination port or range: http>> Filter 3 # action redirCurrent action: allowPending new action: redir>> Filter 3 # /cfg/slb/filt/adv/layer7>> Layer 7 Advanced# addrdEnter filtering string ID (1-1024) toredirect from: 5Enter filtering string ID (2-1024) toredirect to: 6


—End—

TCP Service Port Based HTTP RedirectionIn this example, the switch will redirect traffic entering the switch on oneTCP service port, and redirect it through another service port. Use thestring index numbers in "Example HTTP Redirection Strings" (page 445) toconfigure a redirection map for each filter.

• Filter 4: Configure a filter on the switch to examine the URL requesthttp://10.46.6.231:80/Connect1.jad on TCP service port 80, and redirectthat URL to TCP service port 90.

• Filter 5: Configure a filter on the switch that intercepts all traffic enteringon TCP service port 80, and send it to 10.168.120.129 on TCP serviceport 8080.

Step Action





.



Number of entries: 141: any, cont 2562: HTTPHDR=Host:wap.example.com, cont 2563: HTTPHDR=Host:wap.yahoo.com, cont 2564: HTTPHDR=Host:wap.google.com, cont 2565: HTTPHDR=Host:wap.p-example.com, cont 2566: HTTPHDR=Host:10.168.224.227=/top, cont 2567: jad, cont 2568: jar, cont 2569: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor ,cont 25610: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL, cont 25611: HTTPHDR=Host:any, cont 25612: HTTPHDR=Host:any:90, cont 25613: HTTPHDR=Host:any:8080, cont 25614: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 25615: HTTPHDR=Host:www.abc.com, cont 25616: HTTPHDR=Host:any:443, cont 25617: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST/nava/toggle.jad, nre, cont 102418: HTTPHDR=Host:mobile.example.com=/4g/w?url=dev.example.com/$URL, nre, cont 1024


>> /cfg/slb/filt 4>> Filter 4 # sip 10.46.6.231Current source address: anyNew pending source address: 10.46.6.231>> Filter 4 # smask 255.255.255.255Current source mask: 0.0.0.0New pending source mask: 255.255.255.255>> Filter 4 # proto tcpCurrent protocol: anyPending new protocol: tcp>> Filter 4 # dport httpCurrent destination port or range: anyPending new destination port or range: http>> Filter 4 # action redirCurrent action: allowPending new action: redir>> Filter 4 # /cfg/slb/filt/adv/layer7>> Layer 7 Advanced# addrdEnter filtering string ID (1-1024) toredirect from: 11




.


Enter filtering string ID (2-1024) toredirect to: 12


>> /cfg/slb/filt 5>> Filter 5 # sip 10.46.6.231Current source address: anyNew pending source address: 10.46.6.231>> Filter 5 # smask 255.255.255.255Current source mask: 0.0.0.0New pending source mask: 255.255.255.255>> Filter 5 # proto tcpCurrent protocol: anyPending new protocol: tcp>> Filter 5 # dport httpCurrent destination port or range: anyPending new destination port or range: http>> Filter 5 # action redirCurrent action: allowPending new action: redir>> Filter 5 # /cfg/slb/filt/adv/layer7>> Layer 7 Advanced# addrdEnter filtering string ID (1-1024) toredirect from: 11Enter filtering string ID (2-1024) toredirect to: 13


—End—

MIME Type Header-Based RedirectionIn this example, the switch receives a URL request from a mobile client andexamines the Multipurpose Internet Mail Extensions ( MIME) type header inthe URL. If the URL contains a pre-defined MIME type, text, or URL, theswitch will replace the URL. Use the string index numbers in "Example HTTPRedirection Strings" (page 445) to configure a redirection map for the filter.

• Filter 6: The mobile client executes a request for a URLhttp://dev.example.com/java/ toggle.jad. If the MIME typeis text/vnd.foo.j2me.app-descriptor, or if the URL containsjad or jar as an extension, it will replace the URL with:http://mobile.example.com/4g/w?url=dev.example.com/nava/toggle.jad.




.


Step Action



Number of entries: 141: any, cont 2562: HTTPHDR=Host:wap.example.com, cont 2563: HTTPHDR=Host:wap.yahoo.com, cont 2564: HTTPHDR=Host:wap.google.com, cont 2565: HTTPHDR=Host:wap.p-example.com, cont 2566: HTTPHDR=Host:10.168.224.227=/top, cont 2567: jad, cont 2568: jar, cont 2569: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor, cont 25610:HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL,cont 25611: HTTPHDR=Host:any, cont 25612: HTTPHDR=Host:any:90, cont 25613: HTTPHDR=Host:any:8080, cont 25614: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 25615: HTTPHDR=Host:www.abc.com, cont 25616: HTTPHDR=Host:any:443, cont 25617:HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST/nava/toggle.jad,nre, cont 102418:HTTPHDR=Host:mobile.example.com=/4g/w?url=dev.example.com/$URL,nre, cont 1024

2 Configure filter 6.The filter intercepts string 7, 8, and 9 and then redirects thembased on strings 10, 17, and 18 information. The $HOST_URL isreplaced with the incoming request from HOST and URL string.The $HOST is replaced with the incoming request from HOSTstring. The $URL is replaced with the incoming request fromthe URL string.




.


>> /cfg/slb/filt 6>> Filter 6 # sip 10.46.6.231Current source address: anyNew pending source address: 10.46.6.231>> Filter 6 # smask 255.255.255.255Current source mask: 0.0.0.0New pending source mask: 255.255.255.255>> Filter 6 # proto tcpCurrent protocol: anyPending new protocol: tcp>> Filter 6 # dport httpCurrent destination port or range: anyPending new destination port or range: http>> Filter 6 # action redirCurrent action: allowPending new action: redir>> Filter 6 # /cfg/slb/filt/adv/layer7>> Layer 7 Advanced# addrdEnter filtering string ID (1-1024) toredirect from: 7Enter filtering string ID (2-1024) toredirect to: 10>> Layer 7 Advanced# addrdEnter filtering string ID (1-1024) toredirect from: 8Enter filtering string ID (2-1024) toredirect to: 17>> Layer 7 Advanced# addrdEnter filtering string ID (1-1024) toredirect from: 9Enter filtering string ID (2-1024) toredirect to: 18>> Layer 7 Advanced# apply>> Layer 7 Advanced# save


—End—

URL-Based RedirectionA request for a URL can be redirected to another URL as follows:

• Filter 7: URL http://wap.example.com is redirected tohttp://10.168.224.227/top.




.


Step Action




2 Configure filter 7 to redirect the URL as described above.

>> /cfg/slb/filt 7>> Filter 7 # sip 10.46.6.231Current source address: anyNew pending source address: 10.46.6.231>> Filter 7 # smask 255.255.255.255Current source mask: 0.0.0.0New pending source mask: 255.255.255.255>> Filter 7 # proto tcpCurrent protocol: anyPending new protocol: tcp>> Filter 7 # dport httpCurrent destination port or range: anyPending new destination port or range: http>> Filter 7 # action redirCurrent action: allow




.


Pending new action: redir>> Filter 7 # /cfg/slb/filt/adv/layer7>> Layer 7 Advanced# addrdEnter filtering string ID (1-1024) toredirect from: 2Enter filtering string ID (2-1024) toredirect to: 6>> Layer 7 Advanced# apply>> Layer 7 Advanced# save


—End—

Source IP from HTTP header and Host Header-Based RedirectionIn this example, a filter is configured as follows:

• Filter 8: If X-Foo-ipaddress: 10.168.100.* and the request is tohttp://wap.example.com, then redirect the request to wap.yahoo.com.

Step Action



Number of entries: 141: any, cont 2562: HTTPHDR=Host:wap.example.com, cont 2563: HTTPHDR=Host:wap.yahoo.com, cont 2564: HTTPHDR=Host:wap.google.com, cont 2565: HTTPHDR=Host:wap.p-example.com, cont 2566: HTTPHDR=Host:10.168.224.227=/top, cont 2567: jad, cont 2568: jar, cont 2569: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor ,cont 25610: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL, cont 25611: HTTPHDR=Host:any, cont 25612: HTTPHDR=Host:any:90, cont 25613: HTTPHDR=Host:any:8080, cont 25614: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 25615: HTTPHDR=Host:www.abc.com, cont 25616: HTTPHDR=Host:any:443, cont 256




.


17: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST/nava/toggle.jad, nre, cont 102418: HTTPHDR=Host:mobile.example.com=/4g/w?url=dev.example.com/$URL, nre, cont 1024

—End—

Step Action

1 Configure filter 8 redirect URL as described above.

>> /cfg/slb/filt 8>> Filter 8 # sip 10.46.6.231Current source address: anyNew pending source address: 10.46.6.231>> Filter 8 # smask 255.255.255.255Current source mask: 0.0.0.0New pending source mask: 255.255.255.255>> Filter 8 # proto tcpCurrent protocol: anyPending new protocol: tcp>> Filter 8 # dport httpCurrent destination port or range: anyPending new destination port or range: http>> Filter 8 # action redirCurrent action: allowPending new action: redir>> Filter 8 # /cfg/slb/filt/adv/layer7>> Layer 7 Advanced# addrdEnter filtering string ID (1-1024) toredirect from: 2Enter filtering string ID (2-1024) toredirect to: 14>> Layer 7 Advanced# apply>> Layer 7 Advanced# save


—End—




.


HTTP to HTTPS RedirectionIn this example, a filter is configured to redirect any HTTP requests to anHTTP connection as follows:

• Filter 9: Configure a filter on the switch that intercepts HTTP traffic tohttp://www.abc.com and redirects it to https://www.abc.com.

Step Action


>> # /cfg/slb/layer7/slb/curNumber of entries: 141: any, cont 2562: HTTPHDR=Host:wap.foo.com, cont 2563: HTTPHDR=Host:wap.yahoo.com, cont 2564: HTTPHDR=Host:wap.google.com, cont 2565: HTTPHDR=Host:wap.p-foo.com, cont 2566: HTTPHDR=Host:10.168.224.227=/top, cont 2567: jad, cont 2568: jar, cont 2569: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor ,cont 25610: HTTPHDR=Host:mobile.foo.com=/4g/w?url=$HOST_URL,cont 25611: HTTPHDR=Host:any, cont 25612: HTTPHDR=Host:any:90, cont 25613: HTTPHDR=Host:any:8080, cont 25614: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 25615: HTTPHDR=Host:www.abc.com, cont 25616: HTTPHDR=Host:any:443, cont 25617: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST/nava/toggle.jad, nre, cont 102418: HTTPHDR=Host:mobile.example.com=/4g/w?url=dev.example.com/$URL, nre, cont 1024


>> /cfg/slb/filt 9>> Filter 9 # proto tcpCurrent protocol: anyPending new protocol: tcp>> Filter 9 # dport httpCurrent destination port or range: anyPending new destination port or range: http>> Filter 9 # action redirCurrent action: allowPending new action: redir>> Filter 9 # /cfg/slb/filt/adv/layer7




.


>> Layer 7 Advanced# addrd>> Layer 7 Advanced# l7lkup enCurrent layer 7 lookup: disabledNew layer 7 lookup: enabledEnter filtering string ID (1-1024) toredirect from: 15Enter filtering string ID (2-1024) to redirect to: 16


—End—

IPv6 Redirection FilterThe following configuration example demonstrates an IPv6 redirection filter.The following illustration shows the topology for this example.

IPv6 Redirection Filter Configuration Example

Take the following steps to replicate the configuration illustrated above:

Step Action

1 Configure the client VLAN.

>> Main# /cfg/l2/vlan 2/en/name "Client_VLAN"/add 1

2 Configure the client interface.




.


>> Main# /cfg/l3/if 2/en/vlan 2/ipv v6/add2001::1/mask 64

3 Configure the cache server VLAN.

>> Main# /cfg/l2/vlan 3/en/name "Cache_VLAN"/add10/add 20

4 Configure the cache server interface.


5 Configure the original server VLAN (VLAN to Internet).

>> Main# /cfg/l2/vlan 4/en/name "Internet_VLAN"/add24

6 Configure the interface to the Internet.




8 Configure cache server 1.

>> Main# /cfg/slb/re 1/en/ipv v6/rip 2002::11

9 Configure cache server 2.

>> Main# /cfg/slb/re 2/en/ipv v6/rip 2002::12

10 Add the 2 cache servers to the real group.




.


>> Main# /cfg/slb/gr 1/ipv v6/add 11/add 12

11 Configure the IPv6 redirection filter to redirect all HTTP trafficto the cache servers.

>> Main# /cfg/slb/fi 1/en/name"IPv6_HTTP_Redir_Filter"/ipv v6/actredir/proto tcp/dport http/group 1/

12 Configure IPv6 default filter to allow other traffic.

>> Main# /cfg/slb/fi 2048/en/name"IPv6_Allow_Filter"/ipv v6/act allow

13 Enable filter processing on client ports and add the 2 filtersto the client ports.

>> Main# /cfg/slb/po 1/fi en/add 1/add 2048

14 Apply the configuration.

>> Main# apply>> Main# save

—End—

Peer-to-Peer Cache Load BalancingThe pattern matching filter redirection feature load balances peer-to-peercaches. Previously the Nortel Application Switch Operating System had apattern matching filter that only supported ALLOW and DENY actions forthe filter. The Nortel Application Switch Operating System now enhancesthis pattern matching support by including a REDIR action. For moreinformation on this topic, refer to "Filtering" (page 364) ".

There are two instances where a packet will be redirected because of apattern matching filter:




.


Step Action

1 The packet matches a configured filter.

The packet matches a previously configured filter with a REDIRaction.

2 A packet earlier in the session was matched.

A packet earlier in the session was matched against a filterconfigured with a REDIR action and the session has been convertedto a redirect session. In this instance, subsequent packets after theinitial match are not subjected to pattern matching.

Packet redirection is accomplished by substituting the originaldestination MAC address with the real server MAC address. Someapplications, however, require that all of the Layer 2 informationremain unmodified in the redirected packet. To support instanceswhere this is the case, an option has been added to disabledestination MAC address substitution on a real server by real serverbasis. With this option enabled, all packets will be transparentlyredirected and no destination MAC address substitution will takeplace.

Note: Disabling destination MAC address substitution is onlyavailable for filter redirection.

To disable destination MAC address substitution, issue the followingcommand:

>> Main# /cfg/slb/real <real server number>/adv/subdmac disable

—End—




.

Health Checking 463

Health Checking

Health checking allows you to verify content accessibility in large Web sites.As content grows and information is distributed across different serverfarms, flexible, customizable content health checks are critical to ensureend-to-end availability.

The following Nortel Application Switch Operating System health-checkingtopics are described in this chapter.

• "Real Server Health Checks" (page 465). This section explains theswitch’s default health check, which checks the status of each serviceon each real server every two seconds.

• "DSR Health Checks" (page 467). This section describes the servers’ability to respond to the client queries made to the Virtual server IPaddress when the server is in Direct Server Return (DSR) mode.

• "Link Health Checks" (page 468). This section describes how to performLayer 1 health checking on an Intrusion Detection Server (IDS).

• "TCP Health Checks" (page 469). TCP health checks help verify theTCP applications that cannot be scripted.

• "ICMP Health Checks" (page 470). This section explains how ICMPhealth checks are used for UDP services.

• "Script-Based Health Checks" (page 470). This section describes howto configure the switch to send a series of health-check requests toreal servers or real server groups and monitor the responses. Healthchecks are supported for TCP and UDP protocols, using either Binary orASCII content.

• Application-based health checks:

— "HTTP Health Checks" (page 479). This section provides examplesof HTTP-based health checks using hostnames.

— "UDP-Based DNS Health Checks" (page 481). This section explainsthe functionality of the DNS Health Checks using UDP packets.

— "TFTP Health Check" (page 482). This section explains how tohealth check a real server using the TFTP protocol.

— "SNMP Health Check" (page 483). This section explains how toperform SNMP health checks to real servers running SNMP Agents.

— "FTP Server Health Checks" (page 485). This section describeshow the File Transfer Protocol (FTP) server is used to perform healthchecks and explains how to configure the switch to perform FTPhealth checks.




.


— "POP3 Server Health Checks" (page 486). This section explainshow to use Post Office Protocol Version 3 (POP3) mail server toperform health checks between a client system and a mail serverand how to configure the switch for POP3 health checks.

— "SMTP Server Health Checks" (page 487). This section explainshow to use Simple Mail Transfer Protocol (SMTP) mail server toperform health checks between a client system and a mail serverand how to configure the switch for SMTP health checks.

— "IMAP Server Health Checks" (page 488). This section describeshow the mail server Internet Message Access Protocol (IMAP)protocol is used to perform health checks between a client systemand a mail server.

— "NNTP Server Health Checks" (page 488). This section explainshow to use Network News Transfer Protocol (NNTP) server toperform health checks between a client system and a mail serverand how to configure the switch for NNTP health checks

— "RADIUS Server Health Checks" (page 489). This section explainshow the RADIUS protocol is used to authenticate dial-up users toRemote Access Servers (RASs).

— "HTTPS/SSL Server Health Checks" (page 492). This sectionexplains how the switch queries the health of the SSL servers bysending an SSL client "Hello" packet and then verifies the contentsof the server’s "Hello" response.

— "WAP Gateway Health Checks" (page 492). This sectiondiscusses how the application switch provides connectionless andconnection-oriented WSP health check for WAP gateways.

— "LDAP Health Checks" (page 499). This section describes howto configure the switch to perform Lightweight Directory AccessProtocol (LDAP) health checks for the switch to determine whetheror not the LDAP server is running.

• "ARP Health Checks" (page 501). This section describes how to performhealth checks on Intrusion Detection Servers (IDS) that do not havefull TCP/IP stack support.

• "Buddy Server Health Checks" (page 503). This section describes howto configure buddy server health checking.

• "Failure Types" (page 506). This section explains the service failed andserver failed states.

Note: IPv6 health checking currently supports ICMP, TCP, HTTP, andscript-based health checks.




.

Health Checking 465

Real Server Health ChecksNortel Application Switches running Server Load Balancing (SLB) monitorthe servers in the real server group and the load-balanced application(s)running on them. If a switch detects that a server or application has failed, itwill not direct any new connection requests to that server. When a servicefails, an Nortel Application Switch can remove the individual service fromthe load-balancing algorithm without affecting other services provided bythat server.

By default, the application switch checks the status of each service on eachreal server every two seconds. Sometimes, the real server may be too busyprocessing connections to respond to health checks. If a service does notrespond to four consecutive health checks, the switch, by default, declaresthe service unavailable. You can modify both the health check interval andthe number of retries.

>> # /cfg/slb/real <real servernumber>


>> Real server# inter 4 (Check real server every 4seconds)

>> Real server# retry 6 (If 6 consecutive health checksfail, declare real server down)

Note: Health checks are performed sequentially when used inconjunction with a virtual server configured with multiple servicesand groups. As a result, the actual health-check interval could varysignificantly from the value set for it using the inter parameter.

Select a health check based on the application running on the real servers.For example, with IDS servers, you could use any of the three healthchecking methods: link, advanced SNMP, or ARP. You may use the LDAPhealth check method to health check LDAP servers.

Advanced Group Health CheckNortel Application Switch Operating System allows you to configure anexpression to fine tune the selected health check for a real server group.For example, you have configured a real server group with four real servers.Two of the real servers are handling the contents of the Web site and theother two real servers are handling audio files. If the two content serversfail due to traffic distribution, then you want the two audio servers to failautomatically. However, you want the audio servers up if at least one of thecontent servers is up.




.


The advanced group health check feature allows you to create a booleanexpression to health check the real server group based on the state of thevirtual services. This feature supports two boolean operators, AND and OR.The two boolean operators are used to manipulate TRUE/FALSE values asfollows:

OR operator (|): A boolean operator that returns a value of TRUE if either(or both) of its operands is TRUE. This is called an inclusive OR operator.

AND operator (&): A boolean operator that returns a value of TRUE ifboth of its operands is TRUE.

Using parenthesis with the boolean operators, you can create a booleanexpression to state the health of the server group. The following twoboolean expressions show two examples with real servers 1, 2, 3, and 4 intwo different groups:

• (1|2)&(3|4)

Real servers 1, 2, 3, and 4 are configured in group 1 and assigned tovirtual service x in virtual server 1. The boolean expression is usedto calculate the status of a virtual service using group 1 based on thestatus of the real servers.

Virtual service x of virtual server 1 is marked UP if real servers 1 or 2and real servers 3 or 4 are health checked successfully.

>> # /cfg/slb/group 1 (Select the real server group1)

>> Real server group 1# advhlth

(1|2)&(3|4)(Configure a boolean expression for health check)

>> # /cfg/slb/virt 1/servicex/group 1

(Assign the real server group1)

>> Virtual Server 1 Service#apply

(Apply the changes)

>> Virtual Server 1 Service# save (Save the changes)

• (1&2)|(2&3)|(1&3)

Real servers 1, 2, and 3 are configured in group 2 and assigned tovirtual service x in virtual server 1. The boolean expression is used tocalculate the status of the virtual service using group 2 based on thestatus of the real servers.

Virtual service x of virtual server 1 is marked UP only if at least two ofthe real servers are health checked successfully.




.

Health Checking 467

>> # /cfg/slb/group 2 (Select the real server group2)

>> Real server group 2# advhlth (1&2)|(2&3)|(1&3)

(Configure a booleanexpression for health check)

>> # /cfg/slb/virt 1/servicex/group 2

(Assign the real server group2)

>> Virtual Server 1 Service#apply

(Apply the changes)

>> Virtual Server 1 Service# save (Save the changes)

Disabling the Fast Link Health CheckBy default, the Nortel Application Switch sets the real server as operationallydown as soon as the physical connection to it is down—without waitingfor the health check to fail. This behavior may not be advantageous incertain configurations in which a link may go down and then be quicklyrestored—such as in VPN load balancing. By disabling this "fast healthcheck" behavior, the real server will be marked as "down" only after theconfigured health check interval, thus allowing the possibility of the serverre-establishing itself before the next health check. To enable or disable fastlink health checks, enter the following command:

>> # /cfg/slb/real <real-server-#> /fasthc ena|dis

DSR Health ChecksDirect Server Return (DSR) health checks are used to verify the existenceof a server-provided service where the server replies directly back to theclient without responding through the virtual server IP address. In thisconfiguration, the server will be configured with a real server IP address andvirtual server IP address. The virtual server IP address is configured to bethe same address as the user’s virtual server IP address. When DSR healthchecks are selected, the specified health check is sent originating from oneof the switch’s configured IP interfaces, and is destined to the virtual serverIP address with the MAC address that was acquired from the real server IPaddress’s Address Resolution Protocol (ARP) entry.

Nortel Application Switch Operating System allows you to perform healthchecks for DSR configurations. For more information, see "Direct ServerReturn" (page 238). The switch is able to verify that the server correctlyresponds to requests made to the virtual server IP address as required inDSR configurations. To perform this function, the real server IP addressis replaced with the virtual server IP address in the health check packets




.


that are forwarded to the real servers for health checking. With this featureenabled, the health check will fail if the real server is not properly configuredwith the virtual server IP address.

Note: viphlth is enabled by default. This has no effect on the healthcheck unless the real server is configured with DSR.

Configuring the Switch for DSR Health Checks

Step Action

1 Select the health check menu for a real server group.

>> # /cfg/slb/group 1 (Select the Real ServerGroup 1 menu)

2 Enable DSR VIP health checks for a real server group.

For more information on DSR, see "Direct Server Return" (page238).

>> Real server group 1# viphlth enable|disable


>> DSR VIP Health Check# apply

—End—

Link Health ChecksLink health checks are performed at the Layer 1 (physical) level, and areused on servers that do not respond to any other type of health check.Intrusion Detection Servers (IDSs) fall into this category.

The server is considered to be up when the link (connection) is present, anddown when the link is absent. Many IDSs have two physical interfaces. Oneis used to detect intrusions, and the other is used to generate logging. Thefirst interface detects intrusions but it does not have TCP/IP stack. So it isnot possible to perform any health check other than Layer 1 health checkingon the IDS. As long as the physical link between the switch and the IDSis up, it indicates the IDS is alive.




.

Health Checking 469

To perform this health check, a link option has been added to the real servergroup health command. The real server number is used to determine whichport the server is connected to. For example, real server 1 is assumedto be connected to port 1. The valid IDS real server numbers are from 1to 26 when health check is in use.

Configuring Link Health ChecksConfigure the switch to verify if the IDS server is alive by performing thefollowing tasks:

Step Action

1 Select the health check menu for real server group 1.


2 Set the health check type to link for real server group 1.

>> # Real server group 1# healthCurrent health check type: tcpEnter health check type: link


>> # Real server group 1# apply>> # Real server group 1# save

—End—

TCP Health ChecksTCP health checks are useful in verifying user-specific TCP applicationsthat cannot be scripted.

Session switches monitor the health of servers and applications by sendingLayer 4 connection requests (TCP SYN packets) for each load-balancedTCP service to each server in the server group on a regular basis. Therate at which these connection requests are sent is a user-configurableparameter. These connection requests identify both failed servers andfailed services on a healthy server. When a connection request succeeds,the session switch quickly closes the connection by sending a TCP FIN(finished) packet.

Note: TCP health check is a default health check after you haveconfigured the switch for a particular service.




.


ICMP Health ChecksConfigure the switch with ICMP health check to verify if the real server isalive. The Layer 3 echo-echo reply health check is used for UDP services orwhen ICMP health checks are configured.

Step Action

1 Select the health check menu for group 1.


2 Set the health check type to ICMP for group 1.

>> # Real server group 1# health icmp


>> # Real server group 1# apply

—End—

Script-Based Health ChecksHealth check scripts dynamically verify application and content availabilityby executing a sequence of tests based on send and expect commands.

Configuring Script-Based Health ChecksYou can configure the switch to send a series of health check requests toreal servers or real server groups and monitor the responses. Both ASCIIand Binary-based scripts, for TCP and UDP protocols, can be used to verifyapplication and content availability.

The benefits of using script-based health checks are listed below:

• Ability to send multiple commands

• Check for any return ASCII string or Binary pattern

• Test availability of different applications

• Test availability of multiple domains or Web sites

Nortel Application Switch Operating System supports the following capacityfor a single switch:

• 6K bytes per script

• 64 scripts per switch




.

Health Checking 471

A simple command line interface controls the addition and deletion ofcommands to each script. New commands are added and removed from theend of the script. Commands exist to open a connection to a specific TCPor UDP port, send a request to the server, expect an ASCII string or Binarypattern, and, for TCP-based health checks only, to close a connection.The string or pattern configured with an expect (or in the case of binary,bexpect) command is searched for in each response packet. If it is notseen anywhere in any response packet before the real server health checkinterval expires, the server does not pass the expect (or bexpect) step andfails the health check. A script can contain any number of these commands,up to the allowable number of characters that a script supports.

Note: Health check scripts can only be set up via the command lineinterface, but once entered, can be assigned as the health-checkmethod using SNMP or the Browser-Based Interface (BBI).

Script FormatsHealth check script formats use different commands based on whether thecontent to be sent is ASCII-based or Binary-based. And, remember, theclose command is used only to close a TCP connection, and is not requiredif health checking a UDP-based protocol.

Each script should start with the command open <protocol portnumber>,<protocol-name>. The next line can be either a send orexpect (for ASCII-based), or bsend or bexpect (Binary-based).

ASCII-based Health CheckThe general format for ASCII-based health-check scripts is shown below:

open application_port, protocol-name (e.g. 80, TCP)send request 1 (ascii string)expect response 1send request 2expect response 2send request 3expect response 3close (used in TCP-based health checks only)

Binary Based Health CheckThe general format for Binary-based health check scripts is shown below.Specify the binary content in Hexadecimal format.




.


open application_port, protocol-name (e.g. 80, TCP)bsend request 1 (binary pattern in hex format)nsend request 1-continuedbexpect response 1nexpect response 1-continuedexpect response 3offset offset countdepth number of packets from offset to countclose (used in TCP-based health checks only)

A Binary-based TCP Health CheckThe bsend and bexpect commands are used to specify binary content. Theoffset and depth commands are used to specify where in the packet to startlooking for the binary content. For example, if your script is configured tolook for an HTTP 200 (ok) response, this typically appears starting from the7th byte in the packet, so an offset value of 7 can be specified.

open "80,tcp"bsend " <binary content for request 1> "nsend " <continuing binary content for request 1> "bexpect " <binary content for response 1> "nexpect " <binary content> "offset " <byte count from the start of the IP header> "depth "10"wait "100"close (used in TCP-based health checks only)

Notes on UDP-Based Health Checks

• UDP-based health check scripts can use either ASCII strings or Binarypatterns.

• The close command shown above is not required for a health check onUDP protocol.

Notes on TCP-based Health Checks for HTTP Protocol

• If you are doing HTTP 1.1 pipelining, you need to individually open andclose each response in the script.

• For HTTP-based health checks, the first word is the method. Themethod is usually the get command. However, HTTP also supportsseveral other commands, including put and head. The second wordindicates the content desired, or request-URI, and the third wordrepresents the version of the protocol used by the client.

If you supplied HTTP/1.1 for the protocol version, you would also haveto add in the following line: Host: www.hostname.com




.

Health Checking 473

Example: GET /index.html HTTP/1.1 (press Enter key)

Host: www.hostname.com (press Enter key twice)

This is known as a host header. It is important to include because mostWeb sites now require it for proper processing. Host headers wereoptional in HTTP/1.0 but are required when you use HTTP/1.1+.

• In order to tell the application server you have finished entering headerinformation, a blank line of input is needed after all headers. At thispoint, the URL will be processed and the results returned to you.

Note: If you make an error, enter rem to remove the last typed scriptline entered. If you need to remove more than one line, enter rem foreach line that needs to be removed.

• The switch provides the "\" prompt, which is one enter key stroke. Whenusing the send command, note what happens when you type the sendcommand with the command string. When you type send, press enterand allow the switch to format the command string (that is, \ versus \\).

Scripting CommandsListed below are the currently available commands for building ascript-based health check:

• OPEN: specify which destination real server UDP port to be used; forexample, OPEN 9201. After entering the destination port, you will beprompted to specify a protocol; choose udp.

• CLOSE (for TCP-based health checks only): This command is used toclose a TCP connection. It is not necessary to use this command forUDP services.

• SEND: specify the send content in raw hexadecimal format.

• BSEND (for binary content only): This command is used to specify binarycontent (in hex format) for the request packet.

• NSEND (for binary content only): can be used to specify an additionalbinary send value (in hexadecimal format) at the end of a UDP basedhealth check script. The NSEND command allows the user to appendadditional content to the packet generated by the BSEND command.Since the current CLI limit allows a maximum of 256 bytes to be entered,using one or more NSEND commands will allow binary content of morethan 256 bytes in length to be generated.

• EXPECT: specify the expected content in raw hexadecimal format.




.


• BEXPECT (for binary content only): This command is used to specify thebinary content (in hex format) to be expected from the server responsepacket.

• NEXPECT (for binary content only): Similar to NSEND, this commandallows the user to specify additional binary content to be appended tothe original content specified by the BEXPECT command.

• OFFSET (for binary content only): can be used to specify the offset fromthe beginning of the binary data area to start matching the contentspecified in the EXPECT command. The OFFSET command is supportedfor both UDP and TCP-based health checks. Specify the OFFSETcommand after an EXPECT command if an offset is desired. If thiscommand is not present, an offset of zero is assumed.

• DEPTH (for binary content only): can be used to specify the number ofbytes in the IP packet that should be examined. If no OFFSET valueis specified, Depth is specified from the beginning of the packet. Ifan OFFSET value is specified, the Depth counts the number of bytesstarting from the offset value.

• WAIT: can be used to specify a wait interval before the expectedresponse is returned. The wait window begins when the SEND string issent from the switch. If the expected response is received within thewindow, the WAIT step passes. Otherwise, the health check fails. TheWAIT command should come after an EXPECT command in the script,or the OFFSET command if one exists after an EXPECT command. Thewait window is in units of milliseconds.

• Wildcard character (*): can be used to trigger a match as longas a response is received from the server. The wildcard character isallowed with the BEXPECT command, as in BEXPECT *. Any NEXPECT,OFFSET, or DEPTH commands that follow a wildcard character will beignored.

Scripting Guidelines

• Use generic result codes that are standard and defined by the RFC, asapplicable. This helps ensure that if the server software changes, theservers won’t start failing unexpectedly.

• Avoid tasks that may take a long time to perform or the health check willfail. For example, avoid tasks that exceed the interval for load balancing.

Script Configuration ExamplesScript Example 1: A Basic ASCII TCP-Based Health CheckConfigure the switch to check a series of Web pages (HTML or dynamicCGI scripts) before it declares a real server is available to receive requests.




.

Health Checking 475

Note: If you are using the CLI to create a health check script, you mustuse quotes (") to indicate the beginning and end of each commandstring.

>> /cfg/slb/group x/health script1/content none>> /cfg/slb/advhc/script 1

open 80send "GET /index.html HTTP/1.1\\r\\nHOST:www.hostname.com\\r\\n\\r\\n"expect "HTTP/1.1 200"closeopen 80send "GET /script.cgi HTTP/1.1\\r\\nHOST:www.hostname.com\\r\\n\\r\\n"expect "HTTP/1.1 200"closeopen 443...close

Note: When you are using the command line interface to enter the sendstring as an argument to the send command, you must type two "\"sbefore an "n" or "r." If you are instead prompted for the line, that is, thetext string is entered after hitting <return>, then only one "\" is neededbefore the "n" or "r."

Script Example 2: GSLB URL Health CheckIn earlier Nortel Application Switch Operating System releases, each remoteGlobal Server Load Balancing site’s virtual server IP address was requiredto be a real server of the local switch. Each switch sends a health checkrequest to the other switch’s virtual servers that are configured on the localswitch. The health check is successful if there is at least one real serveron the remote switch that is up. If all real servers on the remote switchare down, the remote real server (a virtual server of a remote switch) willrespond with an HTTP Redirect message to the health check.

Using the scriptable health check feature, you can set up health checkstatements to check all the substrings involved in all the real servers.

Site 1 with Virtual Server 1 and the following real servers:

• Real Server 1 and Real Server 2: "images"

• Real Server 3 and Real Server 4: "html"

• Real Server 5 and Real Server 6: "cgi" and "bin"

• Real Server 7 (which is Virtual Server 2): "any"




.


Site 2 with Virtual Server 2 and the following real servers:

• Real Server 1 and Real Server 2: "images"

• Real Server 3 and Real Server 4: "html"

• Real Server 5 and Real Server 6: "cgi" and "bin"

• Real Server 7 (which is Virtual Server 2): "any"

A sample script is shown below:

>> /cfg/slb/group x/health script2/content none>> /cfg/slb/advhc/script 2

open 80send "GET /images/default.asp HTTP/1.1\\r\\nHOST:192.192.1.2\\r\\n\\r\\n"expect "HTTP/1.1 200"close

open 80send "GET /install/default.html HTTP/1.1\\r\\nHOST:192.192.1.2\\r\\n\\r\\n"expect "HTTP/1.1 200"close

open 80send "GET /script.cgi HTTP/1.1\\r\\nHOST: www.myurl.com\\r\\n\\r\\n"expect "HTTP/1.1 200"close

Script-based health checking is intelligent in that it will only send theappropriate requests to the relevant servers. In the example above, the firstGET statement will only be sent to Real Server 1 and Real Server 2. Goingthrough the health-check statements serially will ensure that all content isavailable by at least one real server on the remote site.

Configure the remote real server IP address (the virtual server IP addressof the remote site) to accept "any" URL requests. The purpose of the firstGET is to check if Real Server 1 or Real Server 2 is up—that is, to check ifthe remote site has at least one server for "images" content. Either RealServer 1 or Real Server 2 will respond to the first GET health check.




.

Health Checking 477

If all the real server IP addresses are down, Real Server 7 (the virtualserver IP address of the remote site) will respond with an HTTP Redirect(respond code 302) to the health check. Thus, the health check will failas the expected response code is 200, ensuring that the HTTP Redirectmessages will not cause a loop.

Script Example 3: A UDP-Based Health Check using BinaryContentHealth checks scripts can be designed to be sent over the UDP protocolwith a few minor differences from a TCP-based health check script. Dueto the stateless nature of the UDP protocol, the CLOSE command is notsupported.

A sample UDP-based script that uses Binary content to health check theUDP port on a real server is shown below.

>> /cfg/slb/group <x> /health script3/content none>> /cfg/slb/advhc/script 3open "53,udp"bsend "53 53 01 00 00 01 00 00"nsend "00 00 00 00 03 77 77 77"nsend "04 74 65 73 74 03 63 6f"nsend "6d 00 00 01 00 01"bexpect "00 01 00 01"offset "1"depth "32"wait "1024"

Note: A maximum of 255 bytes of input are allowed on the switchcommand line. If your send or expect content is lengthy, you mayremove spaces in between the numbers to save space on the commandline. For example, type 000101 instead of 00 01 01. Or, continue thecontent using the nsend and nexpect commands.

Script Example 4: A TCP-Based Health Check using BinaryContentHealth check scripts can also be sent over the TCP protocol using Binarycontent.

A sample of a TCP-based script that uses Binary content to send an HTTPGET request, and expect an HTTP 200 response, is shown below.




.


>> /cfg/slb/group <x> /health script 4/content none>> /cfg/slb/advhc/script4open "80,tcp"bsend "474554202F746573742E68746D20"nsend "485454502F312E300D0A0D0A"bexpect "203230"nexpect "3020"offset "7"depth "10"wait "100"close

Verifying Script-Based Health ChecksIf a script fails, the expect line in the script that is not succeeding is displayedunder the /info/slb/real <real server number> command:

>> # /info/slb/real 11: 205.178.13.225, 00:00:00:00:00:00, vlan 1,

port 0, health 4, FAILEDreal ports:script 2, DOWN, current

send GET / HTTP/1.0\r\n\r\nexpect HTTP/1.0 200

The server is not responding to the get with the expect string.

When the script succeeds in determining the health of a real server, thefollowing information is displayed:

>> # /info/slb/real 11: 205.178.13.223, 00:00:5e:00:01:24, vlan 1,

port 2, health 4, upreal ports:script 2, up, current

Application-Specific Health ChecksApplication-specific health checks include the following applications:

• "HTTP Health Checks" (page 479)

• "UDP-Based DNS Health Checks" (page 481)

• "FTP Server Health Checks" (page 485)

• "POP3 Server Health Checks" (page 486)

• "SMTP Server Health Checks" (page 487)

• "IMAP Server Health Checks" (page 488)




.

Health Checking 479

• "NNTP Server Health Checks" (page 488)

• "RADIUS Server Health Checks" (page 489)

• "HTTPS/SSL Server Health Checks" (page 492)

• "WAP Gateway Health Checks" (page 492)

— "Configuring WSP Health Checks" (page 494)

— "Configuring WTP Health Checks" (page 496)

— "Configuring WTLS Health Checks" (page 498)

• "LDAP Health Checks" (page 499)

HTTP Health ChecksHTTP-based health checks can include the hostname for HOST: headers.The HOST: header and health check URL are constructed from the followingcomponents:

Item Option Configured Under Max. Length

Virtual serverhostname

hname /cfg/slb/virt/service 9 characters

Domain name dname /cfg/slb/virt 35 characters

Server group healthcheck field

content

/cfg/slb/group 34 characters

If the HOST: header is required, an HTTP/1.1 GET will occur. Otherwise,an HTTP/1.0 GET will occur. HTTP health check is successful if you geta return code of 200.

Example 1:hname= everestdname= alteonwebsystems.comcontent= index.html

Health check is performed using:GET /index.html HTTP/1.1Host: everest.alteonwebsystems.com

Note: If the content is not specified, the health check will revert back toTCP on the port that is being load balanced.

Example 2:hname= (none)dname= raleighduram.cityguru.comcontent= /page/gen/?_template=alteon




.


Health check is performed using:GET /page/gen/?_template=alteon HTTP/1.1Host: raleighduram.cityguru.com

Example 3:hname= (none)dname= jansuscontent= index.html

Health check is performed using:GET /index.html HTTP/1.1 Host: jansus

Example 4:hname= (none)dname= (none)content= index.html

Health check is performed using:GET /index.html HTTP/1.0 (since no HTTP HOST: header isrequired)

Example 5:hname= (none)dname= (none)content= //everest/index.html

Health check is performed using:GET /index.html HTTP/1.1Host: everest

Configuring the Switch for HTTP Health ChecksPerform the following on the switch to configure the switch for HTTP healthchecks:

Step Action

1 Select the real server group.

>> # /cfg/slb/group 1 (Select a real server group)

2 Set the health check type to FTP for the real server group.

>> # /cfg/slb/group 1/health http

3 Configure the health check content.

>> # /cfg/slb/group 1/content <filename>




.

Health Checking 481



—End—

UDP-Based DNS Health ChecksNortel Application Switch Operating System supports UDP-based healthchecks along with TCP health checks, and performs load-balancing basedon TCP and UDP protocols.

DNS servers can be based on both TCP and UDP protocols. WithUDP-based DNS health checks enabled, you can send TCP-based queriesto one real server group and UDP-based queries to another real servergroup.

The health check may be performed by sending a UDP-based query (forexample, for http://www.nortel.com/), and watching for the server’s reply.The domain name to be queried may be modified by specifying the contentcommand if you need to change the domain name.

Configuring the Switch for UDP-based Health ChecksConfigure the switch to verify if the DNS server is alive.

Step Action



2 Set the health check type to UDP for the real server group.

>> # Real server group 1# health udpdns

3 Set the content to domain name.

>> # Real server group 1# content <filename> |//<host><filename> |none






.



Note: If no host name is configured, the health check isperformed by sending a UDP-based query from a dummy hostand watching for the server’s reply. The reply, even thoughnegative (for example, "Server not found" since the query isfrom a dummy host), serves the purpose of a health check,nonetheless.

—End—

TFTP Health CheckNortel Application Switch Operating System supports the Trivial FileTransfer Protocol (TFTP) health check which utilizes the TFTP protocol torequest a file from the server. At regular intervals, the switch transmitsTFTP read requests (RRQ) to all the servers in the group. The health checkis successful if the server successfully responds to the RRQ. The healthcheck fails if the switch receives an error packet from the real server.

To configure TFTP health check, do the following:

Step Action



2 Set the health check type to TFTP for the real server group.

>> # Real server group 1# health tftp

3 Specify the file name that the switch requests from the realservers.

Make sure the file is less than 512 bytes, so you don’t incuradditional traffic between the server and the switch. Depending onthe implementation of the TFTP daemon on the real servers beinghealth-checked, you may have to specify the full pathname of the file(/tftpboot/<filename>) on some systems and on others a filenameis sufficient. By default, the switch checks the /tftpboot folder.

>> # Real server group 1# content test

If full pathname is specified, add quotation marks for example,"/tftpboot/test".





.

Health Checking 483


—End—

SNMP Health CheckNortel Application Switch Operating System supports SNMP healthchecks by sending an SNMP GET request to the real server running anSNMP-based agent. SNMP health checks can be used on any real servers,provided they have an SNMP agent. The SNMP health check is performedby polling a single variable within the MIB. For each SNMP health check, youconfigure the Object Identifier (OID) and community string to be queried.These values are obtained by using a MIB Browser and a MIB compiler tofind the OID of the desired variable.

If the OID and community string are assigned per real server(/cfg/slb/real/ids), then it will override the group configuration. TheSNMP health check per real server is used to health check IDS servers only.Nortel Application Switch Operating System also allows you to configurethe real server weights to dynamically readjust, based on the SNMPhealth check response. To adjust the server weights based on the SNMPhealth check response, use the command /cfg/slb/advhc/snmphc<x> /weight ena. The switch will then use the value sent in the SNMPhealth check response packet to dynamically adjust the real server weight.If the value in the response packet is greater than 63, then 63 is used asthe weight.

To configure SNMP health check for a real server group, do the following:

Step Action

1 Select the SNMP health check menu and enter an index number.

You can configure up to five SNMP health checks and assign it to agroup or per real server.

>> # /cfg/slb/advhc/snmphc 1 (Specify an index number)

2 Specify the object identifier (OID).

The OID is obtained from the MIB file of the switch. For example,you may enter the OID for checking the status of a physical port onthe switch port that is connected to the group of IDS servers.

>> SNMP Health Check 1# oid 1.3.6.1.2.1.2.2.1.8.257




.


3 Set the community string on the switch which notifies theSNMP agent on the real server to accept the SNMP packet fromthe switch.

This community string must match the community string specifiedon the real server.

>> SNMP Health Check 1# comm real1

4 Configure an integer value for the switch to accept the healthcheck.

If the value returned by the real server for the MIB variable does notmatch the expected value configured in the rcvcnt field, then theserver is marked down; the server is marked back up when it returnsthe expected value.

In this Step, the server is marked up if the switch receives a value 0;any other value that is returned from the real server is considered ashealth check failed

>> SNMP Health Check 1# rcvcnt 0

5 Enable the real server weights to dynamically change based onthe SNMP health check response

>> SNMP Health Check 1# weightena

(Update weights for the realservers)

6 Enable the invert field if you want the switch to invert the healthcheck.

By enabling the invert field, it is possible to reverse your configurationin Step 4. Then, the server is marked down if the switch receives theexpected value in Step 4. In this example, the real server is markedup if the switch receives any value other than 0.

>> SNMP Health Check 1# invert ena

7 Add the SNMP health check to a real server group.

When you assign a group to use the SNMP health check, all the realservers in the group must use the same OID and community string.

>> # /cfg/slb/group 10 (Select the real servergroup)

>> Real Server Group 10# healthsnmp1




.

Health Checking 485

—End—

FTP Server Health ChecksThe Internet File Transfer Protocol (FTP) provides facilities for transferringfiles to and from remote computer systems. Usually the user transferring afile needs authority to login and access files on the remote system. Thisprotocol is documented in RFC 1123.

In normal Internet operation, the FTP server listens on the well-known portnumber 21 for control connection requests. The client sends a controlmessage which indicates the port number on which the client is preparedto accept an incoming data connection request.

When a transfer is being set up, it is always initiated by the client. However,either the client or the server may be the sender of data. Along withtransferring user requested files, the data transfer mechanism is also usedfor transferring directory listings from server to client.

Note: To configure the switch for FTP health checks, the FTP servermust accept anonymous user login.

Configuring the Switch for FTP Health ChecksCreate any file name from an FTP server under FTP server directory, forexample, .txt, .exe, .bin.

To configure the switch for FTP health checks:

Step Action



2 Set the health check type to FTP for the real server group.

>> # /cfg/slb/group 1/health ftp


>> # /cfg/slb/group 1/content<filename>





.



—End—

POP3 Server Health ChecksThe Post Office Protocol - Version 3 (POP3) is intended to permit aworkstation to dynamically access a maildrop on a server host. The POP3protocol is used to allow a workstation to retrieve mail that the server isholding for it. This protocol is documented in RFC 1939.

When the user on a client host wants to enter a message into the transportsystem, it establishes an SMTP connection to its relay host and sends allmail to it.

Initially, the server host starts the POP3 service by listening on TCP port110. When a client host wants to make use of the service, it establishes aTCP connection with the server host.

Configuring the Switch for POP3 Health ChecksTo support health checking on the UNIX POP3 server, the networkadministrator must configure a username:password value in theswitch, using the content option on the SLB real server group menu(/cfg/slb/group)

To configure the switch for POP3 health checks:

Step Action



2 Set the health check type to POP3 for the real server group.

>> # /cfg/slb/group 1/health pop3

3 Configure the health check content

>> # /cfg/slb/group 1/content <username>:<password>





.

Health Checking 487


—End—

SMTP Server Health ChecksSimple Mail Transfer Protocol is a protocol to transfer e-mail messagesbetween servers reliably and efficiently. This protocol traditionally operatesover TCP, port 25 and is documented in RFC 821. Most e-mail systems thatsend mail over the Internet use SMTP to send messages from one serverto another; the messages can then be retrieved with an e-mail client usingeither POP or IMAP.

Configuring the Switch for SMTP Health ChecksTo support SMTP health checking, the network administrator must configurea username:password value in the switch, using the content option on theSLB real server group menu (/cfg/slb/group).

To configure the switch for SMTP health checks:

Step Action

1 Select the health check menu for the real server group.


2 Set the health check type to SMTP for the real server group.

>> # /cfg/slb/group 1/health smtp


>> # /cfg/slb/group 1/content <username>



—End—




.


IMAP Server Health ChecksInternet Message Access Protocol (IMAP) is a mail server protocol usedbetween a client system and a mail server that allows a user to retrieve andmanipulate mail messages. IMAP is not used for mail transfers betweenmail servers. IMAP servers listen to TCP port 143.

Configuring the Switch for IMAP Health CheckTo support IMAP health checking, the network administrator must configurea username:password value in the switch, using the content option on theSLB Real Server Group Menu (/cfg/slb/group).

To configure the switch for IMAP health checks:

Step Action



2 Set the health check type to IMAP for the real server group.

>> # /cfg/slb/group 1/health imap


>> # /cfg/slb/group 1/content <username>:<password>

The content option specifies the username:passwordvalue that theserver tries to match in its user database. In addition to verifying theuser name and password, the database may specify the client(s) orport(s) the user is allowed to access.



—End—

NNTP Server Health ChecksNet News Transfer Protocol (NNTP) is a TCP/IP protocol based upon textstrings sent bidirectionally over 7 bit ASCII TCP channels, and listens to port119. It is used to transfer articles between servers as well as to read andpost articles. NNTP specifies a protocol for the distribution, inquiry, retrieval,and posting of news articles using a reliable stream-based transmission of




.

Health Checking 489

news among the ARPA-Internet community. NNTP is designed so that newsarticles are stored in a central database allowing a subscriber to selectonly those items he wishes to read.

NNTP is documented in RFC977. Articles are transmitted in the formspecified by RFC1036.

Configuring the Switch for NNTP Health ChecksTo configure the switch for NNTP health checks:

Step Action



2 Set the health check type to NNTP for the real server group.

>> # /cfg/slb/group 1/health nntp


>> # /cfg/slb/group 1/content <nntp newsgroup name>

Create nntp directory from MS Windows Option Pack4.



—End—

RADIUS Server Health ChecksNortel Application Switch Operating System allows you to use the RemoteAuthentication Dial-In User Service (RADIUS) protocol to health checkthe RADIUS accounting and authentication services on RADIUS servers.RADIUS is stateless and uses UDP as its transport protocol. Before youstart configuring RADIUS health checks, make sure of the following:

• Configure the Network-attached storage (NAS) IP parameter on theRADIUS server

This parameter is the IP address of the switch interface connected to theRADIUS server. The Nortel Application Switch will provide the NAS IP




.


parameter while performing RADIUS content health checks. The switchuses the IP address of the IP interface that is on the same subnet as theRADIUS server or the default gateway as the NAS IP.

• Configure the real server port (rport) on the switch

The RADIUS health check is performed using the real server port(rport). Make sure that the rport is the same port the server is listeningon for RADIUS authentication (1812) or RADIUS accounting (1813). Toconfigure the rport, use the /cfg/slb/virt <#> / service menu.

Configuring RADIUS Authentication Health ChecksFollow this procedure to health check RADIUS authentication service.

Step Action



2 Set the health check type for the real server group.

>> Real server group 1# health radius-auth


The content option specifies the username:password value thatthe server tries to match in its user database. In addition to verifyingthe user name and password, the database may specify the client(s)or port(s) the user is allowed to access.

>> Real server group 1# content <username>:<password>

4 Configure the RADIUS code value.

The secret value is a field of up to 32 alphanumeric charactersused by the switch to encrypt a password during the RSA MessageDigest Algorithm (MD5) and by the RADIUS server to decrypt thepassword during verification. This value must be identical to thevalue specified on the RADIUS server.

>> # /cfg/slb/advhc/secret <RADIUS-coded value>






.

Health Checking 491

—End—

Configuring RADIUS Accounting Health ChecksRADIUS accounting packets are sent over UDP to port 1813 or 1646 on theserver. Follow this procedure to health check RADIUS accounting service.

Step Action




>> Real server group 1# health radius-acc

Note: Nortel Application Switch Operating System allowsyou to couple the Radius Accounting Health check with theWAP health checks. If you enable the couple command(/cfg/slb/advhc/waphc/couple) and one of the WAPhealth checks fail, then the Radius Accounting service isdisabled.

—End—

Configuring Combined RADIUS Health ChecksInstead of configuring separate RADIUS authentication and accountinghealth checks, the Nortel Application Switch Operating System provides theability to create a combined RADIUS health check capability.

This is accomplished through the use of the radius_aa health check type.When a server group uses this health check type, the health check taskqueries the service port. If the service port is detemined to be representinga RADIUS Authentication service, then a RADIUS Authentication healthcheck is performed. If a RADIUS Accounting service is detected, a RADIUSAccounting health check is performed. If the service cannot be determined,a TCP health check is performed.

In using this health check type, a single group can be used to health checkboth types of service. If one service should fail, the other will go into ablocking state.

To configure a combined RADIUS health check, perform the followingprocedure:




.


Step Action




>> Real server group 1# healthradius-aa

(Set the health check type)

3 Configure the content of the group so that it contains theRADIUS user name and password separated by a colon.

>> Real server group 1# content radadmin:radpassword

—End—

HTTPS/SSL Server Health ChecksThe sslh health check option on the Real Server Group Menu(/cfg/slb/group <#>) allows the switch to query the health of the SSLservers by sending an SSL client "Hello" packet and then verify the contentsof the server’s "Hello" response. SSL health check is performed using thereal server port configured, that is, the rport.

The SSL enhanced health check behavior is summarized below:

• The switch sends a SSL "Hello" packet to the SSL server.

• If it is up and running, the SSL server responds with the "Server Hello"message.

• The switch verifies fields in the response and marks the service "Up"if the fields are OK.

During the handshake, the user and server exchange security certificates,negotiate an encryption and compression method, and establish a sessionID for each session.

WAP Gateway Health ChecksWireless Application Protocol or WAP is a specification for wireless devicesthat uses TCP/IP and HTTP as part of a standards-based implementation.The translation from HTTP/HTML to WAP/WML (Wireless MarkupLanguage) is implemented by servers known as WAP gateways on theland-based part of the network.




.

Health Checking 493

Wireless Session Protocol (WSP) is used within the WAP suite to managesessions between wireless devices and WAP content servers or WAPgateways. Nortel Application Switch Operating System provides acontent-based health check mechanism where customized WSP packetsare sent to the WAP gateways, and the switch verifies the expectedresponse, in a manner similar to scriptable health checks.

WSP content health checks can be configured in two modes: connectionlessand connection-oriented. Connectionless WSP runs on UDP/IP protocol,ports 9200/9202. Connection-oriented traffic runs on ports 9201 and 9203.Nortel Application Switches can be used to load balance the gatewaysin both modes of operation.

Nortel Application Switch Operating System allows you to configure threeWAP gateway health check types for all four WAP services (default ports9200, 9201, 9202, and 9203) deployed on WAP gateway/servers.

WAP Gateway Health Checks

Health CheckType

Type of TrafficHealth Check Mode

WAP Service To configure, see

WSP connectionless WSP 9200 "Configuring WSPHealth Checks"(page 494)

WTPa connection-orientedWTP + WSP

9201 "Configuring WTPHealth Checks"(page 496)

WTLSb encryptedconnectionlessWTLS + WSP

9202 "Configuring WTLSHealth Checks"(page 498)

WTLS encryptedconnection-orientedWTLS + WTP + WSP

9203 "Configuring WTLSHealth Checks"(page 498)

a. Wireless Transaction Protocol

b. Wireless Transport Layer Security

Note: In the Nortel Application Switch Operating System, all four WAPservices are grouped together. If a health check to one of the servicesfail, then all four WAP services (9200, 9201, 9202, or 9203) are disabled.

What is WTLS?Wireless Transport Layer Security or WTLS is the security layer of the WAP,providing privacy, data integrity and authentication for WAP services. WTLS,designed specifically for the wireless environment, is needed because theclient and the server must be authenticated in order for wireless transactions




.


to remain secure and because the connection needs to be encrypted. Forexample, a user making a transaction with a bank over a wireless deviceneeds to know that the connection is secure and private and not subject to asecurity breach during transfer. WTLS is needed because mobile networksdo not provide complete end-to-end security.

How WAP Health Check WorksThe content of the WSP/UDP packet that is sent to the gateway is configuredas a hexadecimal string, which is encapsulated in a UDP packet andshipped to the server. Hence, this byte string should include all applicableWSP headers.

The content that the switch expects to receive from the gateway is alsospecified in the form of hexadecimal byte string. The switch matches eachbyte of this string with the received content.

If there is a mismatch of even a single byte on the received content, thegateway fails the health check. You can also configure an offset for thereceived WSP packet: a byte index to the WSP response content fromwhere the byte match can be performed. Offset value (WSP or WTP) is forthe receiving content only, and is the number of bytes from the beginningof the UDP Data Area, at which the comparison begins to match with theexpected receive content.

Coupling with Radius Accounting Health CheckNortel Application Switch Operating System allows you to couple the WAPhealth checks with the Radius Accounting health check. If you enable thecouple command (/cfg/slb/advhc/waphc/couple) and the RadiusAccounting health check fails, then all four of the WAP services are broughtdown. Similarly, if one of the WAP health checks fail, then all the WAPservices and the Radius Accounting service fails.

Configuring WSP Health ChecksFollow this procedure to configure the health check for connectionless andunencrypted WAP traffic.

Step Action

1 Select the WAP Health Check Menu.

>> # /cfg/slb/advhc/waphc

2 Enter the WSP port.

By default, the health check is sent to the UDP port 9200.

>> WAP Health Check# wspport 9200




.

Health Checking 495


>> WAP Health Check# wspcnt

4 Use the sndcnt command to enter the content to be sent tothe WSP gateway.

>> WSP Health Check Content# sndcntCurrent Send content:Enter new Send content: 01 42 15 68 74 74 703a 2f 77 77 77 2e 6e 6f6b 61 6d 00 .

5 Enter the content that the switch expects to receive from theWSP gateway.

>> WSP Health Check Content# rcvcntCurrent Receive content:Enter new Receive content: 01 04 60 0e 03 94

Note: A maximum of 255 bytes of input are allowed on theswitch command line. You may remove spaces in between thenumbers to save space on the command line. For example, type010203040506 instead of 01 02 03 04 05 06.

6 Set the offset value.

The offset value is the number of bytes from the beginning of theUDP Data Area, at which the comparison begins to match with theexpected receive content. For 9200 service, the UDP data areais the WSP response content.

>> WSP Health Check Content# offset 0

7 Because WAP gateways are UDP-based and operate on a UDPport, configure UDP service in the virtual server menu.

>> # /cfg/slb/virt 1

>> Virtual Server 1# service (Configure virtual service 1)

Enter virtual port: 9200 (On the default WSP port)

>> Virtual Server 1 9200Service# group 1

(Set the real server groupnumber)




.


>> Virtual Server 1 9200Service# udp ena

(Enable UDP loadbalancing)

>> Virtual Server 1 9200Service# apply

(Apply the configuration)

8 Enable WSP health checks for group 1.


>> Real server group 1# healthwsp



>> Real server group 1# apply

—End—

Configuring WTP Health ChecksFollow this procedure to configure the health check for connection-oriented,unencrypted WAP traffic.

Step Action



2 Enter the WTP port.

By default, the health check is sent to the UDP port 9201.

>> WAP Health Check# wtpport 9201

3 Select the WTP Health Check Menu.

>> WAP Health Check# wtpcnt

4 Create a WSP session by sending the connect message.

Use the connect command to enter the content for the firstswitch-generated WSP session packet. This command allows you tocustomize the headers in the connect message.




.

Health Checking 497

>> WTP+WSP Health Check Content# connectCurrent Connect content:Enter new Connect content: 01 10 00 00


This send content can be used to get a dummy Web page from theserver.

>> WTP+WSP Health Check Content# sndcntCurrent Send content:Enter new Send content: 01 42 15 68 74 74 703a 2f 77 77 77 2e 6e 6f6b 61 6d 00 .

6 Enter the content that the switch expects to receive from theWSP gateway.

>> WTP+WSP Health Check Content# rcvcntCurrent Receive content:Enter new Receive content: 01 04 60 0e 03 94

7 Set the offset value.

The offset value is the number of bytes from the beginning of theUDP Data Area, at which the comparison begins to match with theexpected receive content. For 9201 service, the UDP data areaincludes the WTP content as well as the WSP content.

>> WTP+WSP Health Check Content# offset 0

8 Because WAP gateways are UDP-based and operate on a UDPport, configure UDP service in the virtual server menu.

>> # /cfg/slb/virt 1

>> Virtual Server 1# service (Configure virtual service 1)

Enter virtual port: 9201 (On the default WTP port)

>> Virtual Server 1 9200Service# group 1

(Set the real server groupnumber)

>> Virtual Server 1 9200Service# udp ena

(Enable UDP loadbalancing)

>> Virtual Server 1 9200Service# apply





.


9 Enable WSP health checks for group 1.


>> Real server group 1# healthwtp




—End—

Configuring WTLS Health ChecksWireless Transport Layer Security (WTLS) is used to health checkencrypted WAP traffic. The encrypted WAP traffic can be connectionless(WTLS+WSP) or connection-oriented (WTLS+WTP+WSP). Theconnectionless encrypted WTLS traffic uses default port 9202 and theconnection-oriented encrypted WTLS traffic uses port 9203. The applicationswitch sends a new WTLS Client Hello to the WAP gateway, and checks tosee if it receives a valid WTLS Server Hello back from the WAP Gateway.

The contents for WTLS health check are not configurable and is generatedby the switch automatically.

Step Action

1 Select the group with the WAP gateway.

>> Main# /cfg/slb/group 1 (Select the Real ServerGroup 1 menu)


>> Real server group 1# health wtls



4 Select a port number on which your gateway is listening toWTLS traffic.




.

Health Checking 499

By default, the health check is sent to the UDP port 9202 for connec-tionless traffic (/cfg/slb/adv/waphc/wtlswsp) and to port 9203for connection-oriented traffic (/cfg/slb/adv/waphc/wtlsprt).

>> WAP Health Check# wtlsprt 9203


>> WAP Health Check# apply

—End—

LDAP Health ChecksLightweight Directory Access Protocol (LDAP) health checks enable theswitch to determine whether the LDAP server is alive or not. LDAP versions2 and 3 are described in RFC 1777 and RFC 2251.

The LDAP health check process consists of three LDAP messages overone TCP connection:

• Bind request: The switch first creates a TCP connection to the LDAPserver on port 339, which is the default port. After the connection isestablished, the switch initiates an LDAP protocol session by sending ananonymous bind request to the server.

• Bind response: On receiving the bind request, the server sends a bindresponse to the switch. If the result code indicates that the server isalive, the switch marks the server as up. Otherwise, the switch marksthe server as down even if the switch did this because the server did notrespond within the timeout window.

• Unbind request: If the server is alive, the switch sends a request tounbind the server. This request does not require a response. It isnecessary to send an unbind request as the LDAP server may crash iftoo many protocol sessions are active.

If the server is up, the switch closes the TCP connection after sending theunbind request. If the server is down, the connection is torn down after thebind response, if one arrives. The connection will also be torn down if itcrosses the timeout limit, irrespective of the server’s condition.

Configuring the Switch for LDAP Health ChecksConfigure the switch to verify if the LDAP server is alive.




.


Step Action



2 Add the desired real servers to the group.

>> Real server group 1# add 2>> Real server group 1# add 3

3 Set the backup server.

>> Real server group 1# backupr1

(Set real server 1 asbackup)

4 Set the health check type to LDAP for the real server group.

>> # Real server group 1# health ldap

5 Configure the LDAP health check to verify the domain namein the content field. For example, to verify the domain nameldap.example.com , enter the following with the customer name =Admin and password =test :

>> # content "cn=Admin,dc=ldap,dc=example,dc=com:test"

6 (Optional) Name the real server group.

>> Real server group 1# name LDAP



—End—




.

Health Checking 501

Determining the Version of LDAP

Step Action

1 Select the Advanced Menu.

>> # Real server group 1# /cfg/slb/advhc

2 Set the version of LDAP. The default version is 2.

>> Layer 4 Advanced HealthCheck# ldapver <2 | 3>

(Select the desired LDAPversion)


>> Layer 4 Advanced Health Check# apply>> Layer 4 Advanced Health Check# save

—End—

Windows Terminal Server Health ChecksApplication health checking can be performed on Windows TerminalServers similar to LDAP health checking. The WTS protocol (RDP) is abinary protocol so scripted health checks cannot be used in this instance.Therefore, this health check only entails the checking of server availabilityon TCP port 3389.

To enable WTS health checking on a real server group, use the followingcommand:

>> Main# /cfg/slb/group <Group Number> /health wts

ARP Health ChecksAddress Resolution Protocol (ARP) is the TCP/IP protocol that resideswithin the Internet layer. ARP resolves a physical address from an IPaddress. ARP queries machines on the local network for their physicaladdresses. ARP also maintains IP to physical address pairs in its cachememory. In any IP communication, the ARP cache is consulted to see if theIP address of the computer or the router is present in the ARP cache. Thenthe corresponding physical address is used to send a packet.

In the switch, this features allows the user to health check the IntrusionDetection Server (IDS) by sending an ARP query. The health check consistsof the following sequence of actions:




.


Step Action

1 Accessing the ARP table.

2 Looking for the session entry in the ARP table. If the entryexists in the table, that means the real server is up, otherwisethe health check has failed.

3 If the entry is present, then check the timestamp to find out ifthe last used time is greater than the ARP health check interval.If it is, then delete the query, as this means that the healthcheck has failed.

4 Send another ARP request and repeat the above process untilthe timestamp shows the last used time smaller than the ARPhealth check interval.

—End—

Configuring the Switch for ARP Health Checks

Step Action

1 Select the SLB group from the health check menu.

>> /cfg/slb/group 1

2 Select the type of health check to use.

>> Real server group 1# health arp

3 Enable ARP health checks for group 1.

>> Real server group 1# arp



—End—




.

Health Checking 503

Buddy Server Health ChecksBuddy server health checking gives the administrator the ability to tie thehealth of a real server to another real server. This real server can be inthe same real server group but can be in a separate group as well. In thisconfiguration, a real server will only be considered healthy if the buddy it isassociated with is healthy as well.

The following illustration is a sample network topology:

Sample Buddy Server Health Check Network Topology

Note: This is not the same as Buddy Groups as this marks individualservers and not server groups.

To add a real server as a buddy server for another real server, use thefollowing command:

>> Main# /cfg/slb/real <real server number> /adv/buddyhc/addbd <real server number> <real server group> <service>

To remove a real server as a buddy server, use the following command:

>> Main# /cfg/slb/real <real server number> /adv/buddyhc/delbd <real server number> <real server group> <service>

To view the current buddy server settings for a real server, use the followingcommand:

>> Main# /cfg/slb/real <real server number> /adv/buddyhc/cur




.


Buddy Server Health Check Sample ConfigurationThe following example outlines the steps necessary for Buddy Server HealthCheck configuration:

Step Action

1 Configure an interface.

>> Main# /cfg/l3/if 1/addr 10.1.11.1/mask255.255.255.0/ena



3 Enable ports for SLB.

>> Main# /cfg/slb/port 2/server en>> Main# /cfg/slb/port 3/server en>> Main# /cfg/slb/port 4/server en>> Main# /cfg/slb/port 5/server en>> Main# /cfg/slb/port 6/server en

4 Configure and enable real servers.

>> Main# /cfg/slb/real 1/rip 10.1.11.30/ena>> Main# /cfg/slb/real 2/rip 10.1.11.31/ena>> Main# /cfg/slb/real 3/rip 10.1.11.32/ena>> Main# /cfg/slb/real 4/rip 10.1.11.33/ena>> Main# /cfg/slb/real 5/rip 10.1.11.34/ena

5 Configure real server groups and assign real servers to them.

>> Main# /cfg/slb/group 1/add 1>> Main# /cfg/slb/group 1/health tcp

>> Main# /cfg/slb/group 2/add 2>> Main# /cfg/slb/group 2/add 3>> Main# /cfg/slb/group 2/add 4>> Main# /cfg/slb/group 2/add 5>> Main# /cfg/slb/group 2/health tcp

6 Apply and save the configuration

>> Main# Apply>> Main# Save




.

Health Checking 505

7 Configure virtual servers and enable HTTP service.

>> Main # /cfg/slb/virt 1/vip 120.10.10.10/ena>> Main # /cfg/slb/virt 1/service http>> Main # /cfg/slb/virt 1/service http/group 1

>> Main # /cfg/slb/virt 2/vip 120.10.10.11/ena>> Main # /cfg/slb/virt 2/service http>> Main # /cfg/slb/virt 2/service http/group 2

8 Add real servers 2 to 5, in group 2, to real server 1 as buddyservers.

>> Main# /cfg/slb/real 1/adv/buddyhc/addbd 2 2 80>> Main# /cfg/slb/real 1/adv/buddyhc/addbd 3 2 80>> Main# /cfg/slb/real 1/adv/buddyhc/addbd 4 2 80>> Main# /cfg/slb/real 1/adv/buddyhc/addbd 5 2 80

9 Apply and save configuration.

>> Main# Apply>> Main# Save

Note: It is not mandatory for a Buddy Server Group to be part ofany virtual service.

—End—

DHCP Health ChecksA DHCP health check works by sending a DHCPINFORM packet to thereal server. The DHCPINFORM is sent from a random switch port to port67 on the real server.

The group health content can contain one of the following types when usingthis health check type:

• request - use DHCP request instead of inform packet

• srequest - use DHCP request with a source port of 68

• strict - use DHCP inform but with a source port of 68

• none - usage of a DHCP inform with the UDP offset source port

Note: Enable DAM while using this Health Check type.




.


Configuring the Switch for DHCP Health ChecksThe following is the procedure to configure the switch for DHCP healthchecks:

Step Action

1 Select the SLB group from the health check menu.

>> /cfg/slb/group 1

2 Select the type of health check to use.

>> Real server group 1# health dhcp

3 (Optional) Set the group health content.

>> Real server group 1# content strict



>> Real server group 1# save

—End—

Failure TypesService Failure

If a certain number of connection requests for a particular service fail,the Nortel Application Switch places the service into the service failedstate. While in this state, no new connection requests are sent to theserver for this service; however, if graceful real server failure is enabled(/cfg/slb/adv/grace ena), state information about existing sessionsis maintained and traffic associated with existing sessions continues to besent to the server. Connection requests to, and traffic associated with, otherload-balanced services continue to be processed by the server.

Example: A real server is configured to support HTTP and FTP within tworeal server groups. If a session switch detects an HTTP service failure onthe real server, it removes that real server group from the load-balancingalgorithm for HTTP, but keeps the real server in the mix for FTP. Removingonly the failed service from load balancing allows users access to all healthyservers supporting a given service.




.

Health Checking 507

When a service on a server is in the service failed state, the NortelApplication Switch sends Layer 4 connection requests for the failed serviceto the server. When the session switch has successfully established aconnection to the failed service, the service is restored to the load-balancingalgorithm.

Server FailureIf all load-balanced services supported on a server fail to respond toswitch connection requests within the specified number of attempts, thenthe server is placed in the server failed state. While in this state, no newconnection requests are sent to the server; however, if graceful real serverfailure is enabled (/cfg/slb/adv/grace ena), state information aboutexisting sessions is maintained and traffic associated with existing sessionscontinues to be sent to the server.

Note: All load-balanced services on a server must fail before the switchplaces the server in the server failed state.

The server is brought back into service as soon as the first service isproven to be healthy. Additional services are brought online as they aresubsequently proven to be healthy.




.


High Availability

Nortel Application Switches support high-availability network topologiesthrough an enhanced implementation of the Virtual Router RedundancyProtocol (VRRP).


• "VRRP Overview" (page 509). This section discusses VRRPoperation and Nortel Application Switch Operating System redundancyconfigurations.

• "Nortel Application Switch Operating System Extensions to VRRP"(page 512). This section describes VRRP enhancements implementedin Nortel Application Switch Operating System.

• "IPv6 VRRP Support" (page 521). This section describes VRRP supportfor IPv6 in the Nortel Application Switch Operating System.

• "Failover Methods and Configurations" (page 524). This sectiondiscusses a few of the more useful and easily deployed redundantconfigurations.

— "Active-Standby VSR Configuration in a Non-Shared Environment"(page 526)

— "Active-Active VIR and VSR Configuration" (page 529)

— "Active-Active Server Load Balancing Configuration" (page 531)

— "Hot-Standby Configuration" (page 541)

— "Service-Based Virtual Router Groups" (page 550)

• "IPv6 VRRP Configuration Examples" (page 555). This sectionillustrates examples for IPv6 VRRP configuration.

— "Hot Standby Configuration Example" (page 555)

— "Active-Standby Configuration Example" (page 562)

— "Active-Active Configuration Example" (page 569)

• "Virtual Router Deployment Considerations" (page 576). This sectiondescribes issues to consider when deploying virtual routers.

• "Stateful Failover of Persistent Sessions" (page 580). This sectiondescribes how to enable stateful failover by mirroring Layer 7 and Layer4 persistent transactional states on the peer switch.

• "Service-based Session Failover" (page 584). This section describesthe Nortel Application Switch Operating System 24.0 support for thefailover of a session based on a service.




.

High Availability 509

• "Peer Synchronization" (page 586)

VRRP OverviewIn a high-availability network topology, no device can create a singlepoint-of-failure for the network or force a single point-of-failure to any otherpart of the network. This means that your network will remain in servicedespite the failure of any single device. To achieve this usually requiresredundancy for all vital network components.

VRRP enables redundant router configurations within a LAN, providingalternate router paths for a host to eliminate single points-of-failure withina network. Each participating VRRP-capable routing device is configuredwith the same virtual router IP address and ID number. One of the virtualrouters is elected as the master, based on a number of priority criteria, andassumes control of the shared virtual router IP address. If the master fails,one of the backup virtual routers will take control of the virtual router IPaddress and actively process traffic addressed to it.

Because the router associated with a given alternate path supported byVRRP uses the same IP address and MAC address as the routers for otherpaths, the host’s gateway information does not change, no matter whatpath is used. A VRRP-based redundancy schema reduces administrativeoverhead because hosts need not be configured with multiple defaultgateways.

Note: The IP address of a VRRP virtual interface router (VIR) andvirtual server router (VSR) must be in the same IP subnet as theinterface to which it is assigned.

Standard VRRP ComponentsEach physical router running VRRP is known as a VRRP router.

Virtual RouterTwo or more VRRP routers can be configured to form a virtual router(RFC 2338). Each VRRP router may participate in one or more virtualrouters.Each virtual router consists of a user-configured virtual routeridentifier (VRID) and an IP address.

Virtual Router MAC AddressThe VRID is used to build the virtual router MAC Address. The fivehighest-order octets of the virtual router MAC Address are the standardMAC prefix (00-00-5E-00-01) defined in RFC 2338. The VRID is used toform the lowest-order octet.




.


Owners and RentersOnly one of the VRRP routers in a virtual interface router may be configuredas the IP address owner. The owner is the virtual router (Nortel ApplicationSwitch) whose virtual interface router’s IP address is equal to the realinterface address. This router responds to packets addressed to the virtualinterface router’s IP address for ICMP pings, TCP connections, and so on.

If the owner is not available, the backup becomes the master and takesover responsibility for packet forwarding and responding to ARP requests.However, because this switch is not the owner, it does not have a realinterface configured with the virtual interface router’s IP address.

There is no requirement for any VRRP router to be the IP address owner.Most VRRP installations choose not to implement an IP address owner. Forthe purposes of this chapter, VRRP routers that are not the IP addressowner are called renters.

Virtual Router StatesWithin each virtual router, one VRRP router is selected to be the virtualrouter master. See "How VRRP Priority Decides Which Switch is theMaster" (page 511) for an explanation of the selection process.

Note: If the IP address owner is available, it will always become thevirtual router master.

Master The virtual router master forwards packets sent to the virtualinterface router. It also responds to Address Resolution Protocol (ARP)requests sent to the virtual interface router’s IP address. Finally, the virtualrouter master sends out periodic advertisements to let other VRRP routersknow it is alive and its priority.

Backup Within a virtual router, the VRRP routers not selected to be themaster are known as virtual router backups. Should the virtual router masterfail, one of the virtual router backups becomes the master and assumes itsresponsibilities.

Init If there is no port in the virtual router’s VLAN with an active link, theinterface for the VLAN fails, thus placing the virtual router into the INIT state.

The INIT state identifies that the virtual router is waiting for a startup event.If it receives a startup event, it will either transition to master if its priorityis 255, (the IP address owner) or transition to the backup state if it is notthe IP address owner.




.


How VRRP Priority Decides Which Switch is the MasterEach VRRP router that is not an owner is configured with a priority between1–254. According to the VRRP standard, an owner has a priority of 255.A bidding process determines which VRRP router is or becomes themaster—the VRRP router with the highest priority. Owners have a higherpriority than the range permitted for non-owners. If there is an IP addressowner, it is always the master for the virtual interface router, as long as itis available.

The master periodically sends advertisements to an IP multicast address.As long as the backups receive these advertisements, they remain in thebackup state. If a backup does not receive an advertisement for threeadvertisement intervals, it initiates a bidding process to determine whichVRRP router has the highest priority and takes over as master.

If, at any time, a backup determines that it has higher priority than thecurrent master does, it can preempt the master and become the masteritself, unless configured not to do so. In preemption, the backup assumesthe role of master and begins to send its own advertisements. The currentmaster sees that the backup has higher priority and will stop functioning asthe master.

A backup router can stop receiving advertisements for one of tworeasons—the master can be down, or all communications links between themaster and the backup can be down. If the master has failed, it is clearlydesirable for the backup (or one of the backups, if there is more than one) tobecome the master.

Note: If the master is healthy but communication between the masterand the backup has failed, there will then be two masters within thevirtual router. To prevent this from happening, configure redundant linksto be used between the switches that form a virtual router.

Determining How to Configure PriorityThink of a virtual router’s priority as a starting value that increases ordecreases depending on the parameters that are tracked. For example,if you configure the virtual router to track link state of the physical ports,one port losing link would cause the virtual router’s priority to decrease by2 priority points. In order to ensure that this decrease in priority causesfailover from the current master to the backup virtual router, you shouldmake sure to set the "base" priority of the Master switch to be only 1 pointhigher than the backup; for example priority 101 for master, 100 for backup.If the master and backup switches were set to priorities 110 and 100respectively, a single port failure would only decrease the master switch’spriority to 108. As 108 is still higher than backup’s priority 100, the masterswitch would not fail over due to the loss of one ports’ link.




.


Nortel Application Switch Operating System Extensions to VRRPThis section describes the following VRRP enhancements that areimplemented in the Nortel Application Switch Operating System:

• "Virtual Interface Routers" (page 512)

• "Virtual Server Routers" (page 512)

• "Sharing Interfaces for Active-Active Failover" (page 514)

• "Service-Based Virtual Router Groups" (page 515)

• "Switch-Based VRRP Groups" (page 517)

• "Tracking VRRP Router Parameters" (page 518)

• "Tracking Service-Based Virtual Router Groups" (page 520)

• "VRRP Holdoff Timer" (page 521)

Virtual Interface RoutersAt Layer 3, a Virtual Interface Router (VIR) allows two VRRP routers toshare an IP interface across the routers.VIRs provide a single DestinationIP (DIP) for upstream routers to reach various destination networks, andprovide a virtual default Gateway.

A VIR must be assigned an IP interface, and every IP interface must beassigned to a VLAN. If the IP interface of a VIR is down, then the VIR willbe in the INIT state.

Virtual Server RoutersSupport for 1024 VSRs Nortel Application Switch Operating Systemsupports up to 1024 virtual server routers, which extend the benefits ofVRRP to virtual server IP addresses that are used to perform server loadbalancing.

In Nortel Application Switch Operating System 24.0, all VSRs with a VirtualRouter ID (VRID) greater than 255 use a new packet format, which differs insize and location of the VRID field. When sending advertisements using aVSR with a VRID greater than 255, the Type should be set to 15. Switchesthat do not support the new packet format will automatically discard thesepackets because VRRP currently only supports one defined packet type(type=1).

What is a VSR? Virtual server routers operate for virtual server IP (vip)addresses in much the same manner as Virtual Interface Routers operatefor IP interfaces. A master is negotiated via a bidding process, duringwhich information about each VRRP router’s priority is exchanged. Onlythe master can process packets that are destined for the virtual server IPaddress and respond to ARP requests.




.


One difference between virtual server routers and virtual interface routersis that a virtual server router cannot be an IP address owner. All virtualserver routers are renters.

All virtual routers, whether virtual server routers or virtual interface routers,operate independently of one another; that is, their priority assignments,advertisements, and master negotiations are separate. For example, whenyou configure a VRRP router’s priority in a virtual server router, you arenot affecting that VRRP router’s priority in any virtual interface router orany other virtual server router of which it is a part. However, because ofthe requirement that MAC addresses be unique on a LAN, VRIDs mustbe unique among all virtual routers, whether virtual interface routers orvirtual server routers.

The Nortel Application Switches in "Virtual Interface Router" (page513) have been configured as VRRP routers. Together, they form a virtualinterface router (VIR).

Virtual Interface Router

Application Switch 1 in "Virtual Interface Router" (page 513) has its realinterface configured with the IP address of the virtual interface router,making it the IP address owner. As IP address owner, it receives a priorityof 255, and is the virtual router master.

Application Switch 2 is a virtual router backup. Its real interface is configuredwith an IP address that is on the same subnet as the virtual interface router,but is not the IP address of the virtual interface router.

The virtual interface router has been assigned a VRID = 1. Both of theVRRP routers have a virtual router MAC address = 00-00-5E-00-01-01.




.


Sharing Interfaces for Active-Active FailoverNortel Application Switch Operating System supports sharing of interfacesat both Layer 3 and Layer 4, as shown in "Active-Active Failover with SharedInterfaces" (page 514).

Active-Active Failover with Shared Interfaces

With sharing enabled, an IP interface or a VIP address can be activesimultaneously on multiple switches, enabling active-active operation asshown in "Active-Active Failover with Shared Interfaces" (page 514), and"Active-Active Failover with Shared Interfaces" (page 514) below.

Active-Active Failover with Shared Interfaces

Virtual Router 1 Virtual Router 2 Virtual Router 3

Application Switch 1

Master-ActiveVRID 2VIP: 205.178.13.226Virtual Rtr.MAC address:00-00-5E-00-01-02

Backup-ActiveVRID 4VIP: 205.178.13.240Virtual Rtr.MAC address:00-00-5E-00-01-04

Master-ActiveVRID 6VIP: 205.178.13.110Virtual Rtr.MAC address:00-00-5E-00-01-06

Application Switch 2

Backup-Active VR 1VRID 2VIP: 205.178.13.226Virtual Rtr.MAC address:00-00-5E-00-01-02

Master-Active VR 2VRID 4VIP: 205.178.13.240Virtual Rtr.MAC address:00-00-5E-00-01-04

Backup-Active VR 3VRID 6VIP: 205.178.13.110Virtual Rtr.MAC address:00-00-5E-00-01-06




.


When sharing is used, incoming packets are processed by the switch onwhich they enter the virtual router. The ingress switch is determined byexternal factors, such as routing and Spanning Tree configuration.

Sharing cannot be used in configurations where incoming packets havemore than one entry point into the virtual router—for example, where ahub is used to connect the switches.

When sharing is enabled, the master election process still occurs. Althoughthe process does not affect which switch processes packets that mustbe routed or that are destined for the virtual server IP address, it doesdetermine which switch sends advertisements and responds to ARPrequests sent to the virtual router’s IP address.

Nortel strongly recommends that sharing, rather than active-standbyconfigurations, be used whenever possible. Sharing offers both betterperformance and fewer service interruptions in the face of fault conditionsthan active-standby configurations.

See "Active-Active Redundancy" (page 529) for a configuration example.

Service-Based Virtual Router GroupsA service-based virtual router group (vrgroup) consists of one or morevirtual routers on a switch. Virtual routers can be grouped together andbehave as a single VRRP entity. Service based virtual router groups allowfor efficient tracking and failover based on each group’s tracking parameterswhile leaving other groups unaffected. For example, an administrator wishesto provide high availability for Customer A and Customer B’s servers andservices across the same two switches, without one affecting the other:

• Customer A’s traffic load-balances across real servers in real servergroup 1.

• Customer B’s traffic load balances across real servers in real servergroup 2.

Each switch is configured with vrgroup 1 for customer A, and vrgroup 2for Customer B.

Because each vrgroup is tracked independently of the other, vrgroup 1 canfailover to its equivalent vrgroup 1 on the other switch while not affectingthe VRRP state of vrgroup 2.




.


Service-based Virtual Router Groups

Characteristics of Service-Based Virtual Router Groups(vrgroups) The following are characteristics of Virtual Router Groups:

• Switch-based VRRP groups must be disabled (/cfg/l3/vrrp/groupdis)

• Up to 16 vrgroups can be configured on a single application switch.Each vrgroup can contain up to 64 virtual routers assigned with a virtualrouter number from 1-1024. Each virtual router can be configured as avirtual interface router or a virtual service router.

• Virtual routers that become members of a vrgroup, assume the prioritytracking parameters configured for that vrgroup.

• When one member of a Master vrgroup fails, the priority of thevrgroup decreases, and all the members of that vrgroup change fromMaster to Backup. This is accomplished by configuring tracking on theservice-based virtual router group.

Commands

• To access the vrgroup menu, enter the following command:

>> Main# /cfg/l3/vrrp/vrgroup <vrgroup # 1-16>

• To add virtual routers to a service-based virtual router group use thescenario as an example:

>> Main# /cfg/l3/vrrp/vrgroup 1 (Select vrgroup 1)

>> VRRP Virtual Router Vrgroup 1#add 1

(Add virtual router 1 tovrgroup 1)






.


>> Main# /cfg/l3/vrrp/vrgroup 2 (Select vrgroup 2)





See "Tracking Service-Based Virtual Router Groups" (page 520) for aconfiguration example.

Switch-Based VRRP GroupsA switch-based virtual router group aggregates all virtual routers on theswitch as a single entity for non-shared environments. All virtual routerswill failover as a group, and cannot failover individually. As members of agroup, all virtual routers on the switch (and therefore the switch itself), willbe in either a master or backup state.

Characteristics of a Switch-Based VRRP Group The following arecharacteristics of a switch-based VRRP group:

• When enabled, all virtual routers behave as one entity, and all groupsettings override any individual virtual router settings or service-basedvrgroup settings.

• All individual virtual routers, once the switch-based VRRP group isenabled, assume the group’s tracking and priority.

• When one member of a switch-based VRRP group fails, the priority ofthe group decreases, and the state of the entire switch changes fromMaster to Backup.

• If a switch is in the backup state, Layer 4 processing is still enabled.If a virtual server is not a virtual router, the backup switch can stillprocess traffic addressed to that virtual server IP address. Filtering isalso still functional. Only traffic addressed to virtual server routers isnot processed.

• Each VRRP advertisement can include up to 1024 addresses. All virtualrouters are advertised within the same packet, conserving processingand buffering resources.

Note: The switch-based virtual router group cannot be used foractive-active configurations or any other configuration that requiresshared interfaces.

Command The switch-based VRRP group is configured by using thefollowing command:

>> Main# /cfg/l3/vrrp/group ena




.


Note: For more information on using switch-based VRRP groups withhot-standby, see "Hot-Standby Configuration" (page 541).

Tracking VRRP Router ParametersNortel Application Switch Operating System supports a tracking functionthat dynamically modifies the priority of a VRRP router based on its currentstate. The objective of tracking is to have, whenever possible, the masterbidding processes for various virtual routers in a LAN converge on the sameswitch. Tracking ensures that the selected switch is the one that offersoptimal network performance. For tracking to have any effect on virtualrouter operation, preemption must be enabled.

Note: Tracking only affects hot standby and active-standbyconfigurations. It does not have any effect on active-active sharingconfigurations.

Nortel Application Switch Operating System can track the parametersoutlined in "VRRP Tracking Parameters" (page 518).

VRRP Tracking Parameters

Parameters and Commands Description

Number of virtual routers in mastermode on the switch.

• To enable tracking on vrs:/cfg/l3/vrrp/vr <#>/track/vrs/ena

• To change the virtual router increment: /cfg/l3/vrrp/track/vrs<[0-254]>

Useful for ensuring that traffic forany particular client/server pair ishandled by the same switch, increasingrouting and load-balancing efficiency.This parameter influences the VRRProuter’s priority in both virtual interfacerouters and virtual server routers.

Note: The vrs parameter is not availablefor tracking for a service based virtualrouter group (vrgroup).

Number of IP interfaces active onthe switch.

• To enable tracking on IP interfaces:/cfg/l3/vrrp/vr /track/ifs<#> /ena

• To change the interfaces trackingincrement: /cfg/l3/vrrp/track/ifs <[0-254]>

Helps elect the virtual routers with themost available routes as the master.(An IP interface is considered activewhen there is at least one active porton the same VLAN.) This parameterinfluences the VRRP router’s priority inboth virtual interface routers and virtualserver routers.




.


Parameters and Commands Description

Number of active ports on the sameVLAN.

• To enable tracking on ports on thesame VLAN: /cfg/l3/vrrp/vr/track/port <#> /ena

• To change the ports trackingincrement: /cfg/l3/vrrp/track/ports <[0-254]>

Helps elect the virtual routers with themost available ports as the master.This parameter influences the VRRProuter’s priority in both virtual interfacerouters and virtual server routers.

Number of physical switch ports thathave active Layer 4 processing onthe switch.

• To enable tracking on Layer 4ports: /cfg/l3/vrrp/vr/track/l4pts/ena

• To change the Layer 4ports tracking increment:/cfg/l3/vrrp/track/l4pts<[0-254]>

Helps elect the main Layer 4 switch asthe master. This parameter influencesthe VRRP router’s priority in both virtualinterface routers and virtual serverrouters.

Number of healthy real serversbehind the virtual server IP addressthat is the same as the IP addressof the virtual server router on theswitch.

/cfg/l3/vrrp/track/reals

Helps elect the switch with the largestserver pool as the master, increasingLayer 4 efficiency. This parameterinfluences the VRRP router’s priority invirtual server routers only.

In networks where the Hot StandbyRouter Protocol (HSRP) is usedfor establishing router failover, thenumber of Layer 4 client-only portsthat receive HSRP advertisements.

/cfg/l3/vrrp/track/hsrp

Helps elect the switch closest to themaster HSRP router as the master,optimizing routing efficiency. Thisparameter influences the VRRProuter’s priority in both virtual interfacerouters and virtual server routers.

Tracking HSRP on VLAN.

/cfg/l3/vrrp/track/hsrv

Hot Standby Router on VLAN (HSRV)is used in VLAN-tagged environments.Enable this option to increment onlythat VRRP instance that is on the sameVLAN as the tagged HSRP masterflagged packet. This command isdisabled by default.




.


Each tracked parameter is associated with a user-configurable weight. Asthe count associated with each tracked item increases (or decreases), sodoes the VRRP router’s priority, subject to the weighting associated witheach tracked item. If the priority level of a backup is greater than that of thecurrent master, then the backup can assume the role of the master.

See "Tracking Virtual Routers" (page 548) for an example on how toconfigure the switch for tracking VRRP priority.

Tracking Service-Based Virtual Router GroupsNortel Application Switch Operating System also supports a trackingfunction that dynamically modifies the priority of a service-based virtualrouter group (vrgroup), which contains one or more virtual routers. Oncea VRRP router is added to a vrgroup, the group’s tracking configurationoverrides an individual VRRP router’s tracking.

Nortel Application Switch Operating System allows the independent failoverof individual virtual router groups on the same switch. When Web hosting isshared between two or more customers on a single VRRP switch, severalvirtual routers can be grouped to serve the high availability needs of aspecific customer.

Each vrgroup is treated as a single entity regardless of how many virtualrouters belong to the vrgroup. When switch tracks a vrgroup, it measuresthe resources contained in this group, and updates all members of thevrgroup with the same priority. When any of the tracked parameterschanges the priority for one of the virtual routers belonging to the vrgroup,then the entire vrgroup will failover.

Tracking can be configured for each vrgroup, with the same resourcestracked on individual virtual routers ("VRRP Tracking Parameters" (page518)). The only resource that cannot be tracked on a vrgroup basis is thenumber of virtual routers (vrs).

If failover occurs on a customer link, only the group of virtual routersassociated with that customer’s vrgroup will failover to the backup switch.Other vrgroups configured for other customers do not failover. For example,if a vrgroup is configured to track on ports, a port failure will decrease thepriority of the vrgroup. The lowered priority will cause this vrgroup to failoverto its equivalent vrgroup on the other switch.

See "Service-Based Virtual Router Groups" (page 550) for an example onhow to configure the switch for tracking VRRP priority.




.


VRRP Holdoff TimerWhen an application switch becomes the VRRP master at power up or aftera failover operation, it may begin to forward data traffic before the connectedgateways or real servers are operational. The application switch may createempty session entries for the coming data packets and the traffic cannot beforwarded to any gateway or real server.

Nortel Application Switch Operating System supports a VRRP holdoff timer,which pauses VRRP instances from starting or changing to master stateduring the initialization.The VRRP holdoff timer can be set from 0 to 255seconds. The VRRP master will wait the specified number of secondsbefore forwarding traffic to the default gateway and real servers. The VRRPholdoff timer is set with the following command:

>> Main# /cfg/l3/vrrp/holdoff <0-255 seconds>

IPv6 VRRP SupportNortel Application Switch Operating System 24.0 supports the usageof IPv6 with VRRP. This section describes this support. For conceptualinformation about IPv6, refer to "IPv6" (page 123).

IPv6 hosts on a VLAN usually learn about other routers by receivingIPv6 Routing Advertisements. The Routing Advertisements are multicastperiodically at a rate such that the hosts usually learn about the otherrouters within a few minutes. They are not sent frequently enough for thehosts to rely on to detect router failures.

IPv6 hosts can also use the Neighbor Discovery mechanism to detect routerfailure by sending unicast Neighbor Solicitation messages to the otherrouters. By using the default setting, it will take a host about 38 seconds tolearn that a router is unreachable before it switches to another router.

IPv6 VRRP support provides a much faster mechanism for the switch overto a backup router than can be obtained using standard Neighbor Discoveryprocedures. Using IPv6 VRRP support, a backup router can take over theresponsibility of virtual router master within seconds. This is done withoutany interaction with the hosts and a minimum amount of traffic in the subnet.

To accomplish this, two types of addresses are used in IPv6 that faciliateVRRP support:

Step Action

1 Unicast address

• The Global Unicast address is an address that is accessible andidentifiable globally.




.


• The Link-local Unicast address is an address used tocommunicate with neighbors on the same link. The sourceaddress of an IPv6 VRRP packet is set to the IPv6 Link-localaddress of the transmission interface.

2 Multicast address

• The IPv6 Multicast address is an identifier for a group interface.IPv6 VRRP support has an IPv6 link-local scope multicastaddress assigned by IANA. This multicast address follows theformat FF02:0:0:0:0:0:XXXX:XXXX. The destination address ofthe IPv6 packet is set to this link-local scope multicast address.Routers must not forward a datagram with this destinationaddress regardless of its Hop Limit setting.

—End—

IPv6 VRRP packetsIPv6 VRRP packets differ in some aspects to VRRP implemented in an IPv4network. The key differences are as follows:

• The Version field specifies the VRRP protocol version. In IPv4 packetsthis value is 2 and in IPv6 packets this value is 3.

• The Authentication Type field is not present in IPv6 packets. This field isused in IPv4 to identify the authentication method in use.

• The Advertisement Interval field is a 12-bit field that indicates theadvertisement interval in centiseconds (1/100 second). This is an 8-bitfield in IPv4 that specifies this interval in seconds.

Note: It is recommended that the default of 100 (1 second) or aboveis used to avoid a high load on the switch management CPU.

• The Hop Limit field is used to track how many nodes have forwarded thepacket. The field value is decremented by one for each that forwards thepacket. VRRP routers are instructed to discard IPv6 VRRP packets thatdo not have a Hop Limit value of 255.

• The Next Header field is used to identify the type of protocol immediatelyfollowing the IPv6 header. The IPv6 Next Header assigned by IANAfor VRRP is 112.

• The Neighbor Discovery protocol replaces IPv4 ARP, ICMP RouterDiscovery, and ICMP Redirection. Neighbor Discovery enables nodes(hosts and routers) to determine the link-layer address of a neighbor onthe same network and to detect any changes in these addresses. It also




.


enables a router to advertise its presence and address prefix to informhosts of a better next hop address to forward packets.

IPv6 VRRP configurationTo enable IPv6 VRRP support perform the following two tasks:

Note: The VRRP3 VRID for IPv6 VRRP configuration has a range of 1to 255.

Step Action

1 Enable IPv6 support on the virtual router.

Before VRRP will support IPv6, it must be enabled on the virtualrouter. This is accomplished by doing the following:

• Change the IP version supported by the virtual router.

Use the command /cfg/l3/vrrp/vr <virtual routernumber> /ipver v6 to configure the virtual router for IPv6support.

• Assign an IPv6 address to the vitural router.

Use the command address <IPv6_address> to assign anIPv6 address to the virtual router.

2 Enable IPv6 support on the virtual router group.

After IPv6 support has been enabled on the virtual router, enableit on the virtual router group. This is accomplished by using the/cfg/l3/vrrp/group/ipver v6 command.

—End—

IPv6 VRRP informationConfiguration and statistical information can be obtained from the switchabout IPv6 VRRP support. The command /info/l3/vrrp displaysinformation about both IPv4 and IPv6 VRRP configuration. The output forthis command is illustrated below.




.


>> Main# /info/l3/vrrpVRRP information:

9: vrid 9, 2005:0:0:0:0:0:10:9if 9, renter,

prio 101, master10: vrid 10, 10.10.10.50, if 1, renter,

prio 101, master20: vrid 20, 2005:0:0:0:0:0:20:20

if 20, renter,prio 105, master, server

The command /stat/l3/vrrp6 displays statistical information about thecurrent IPv6 VRRP configuration. The output for this command is illustratedbelow.

>> Main# /stat/l3/vrrp6------------------------------------------------------------VRRP6 statistics:vrrp6InAdvers: 7vrrp6BadAdvers: 0vrrp6OutAdvers: 86801vrrp6BadVersion: 0vrrp6BadVrid: 0vrrp6BadAddress: 0vrrp6BadData: 0vrrp6BadInterval: 0

Failover Methods and ConfigurationsNortel Application Switches offer flexibility in implementing redundantconfigurations. This section discusses a few of the more useful and easilydeployed configurations:

• "Active-Standby Redundancy" (page 525)

— "Active-Standby VSR Configuration in a Non-Shared Environment"(page 526)

• "Active-Active Redundancy" (page 529)

— "Active-Active VIR and VSR Configuration" (page 529)

— "Active-Active Server Load Balancing Configuration" (page 531)

• "Hot-Standby Redundancy" (page 539)

— "Hot-Standby Configuration" (page 541)

• "Tracking Virtual Routers" (page 548)

• "Service-Based Virtual Router Groups" (page 550)




.


Nortel Application Switch Operating System high availability configurationsare based on VRRP. TheNortel Application Switch Operating Systemimplementation of VRRP includes proprietary extensions to accommodateLayer 4 though Layer 7 application switching features.

The Nortel Application Switch Operating System implementation of VRRPsupports three modes of high availability:

• Active-Standby

• Active-Active

• Hot-Standby

The first mode, active-standby, is based on standard VRRP, as defined inRFC 2338. The second and third modes, active-active and hot-standby, arebased on proprietary Nortel Application Switch Operating System extensionsto VRRP. Each mode is described in detail in the following sections.

Active-Standby RedundancyIn an active-standby configuration, shown in "Active-Standby VRRPRouters" (page 525), two application switches are used. Both switchessupport active traffic but are configured so that they do not simultaneouslysupport the same service. Each switch is active for its own set of services,such as IP routing interfaces or load-balancing virtual server IP addresses,and acts as a standby for other services on the other switch. If either switchfails, the remaining switch takes over processing for all services. Thebackup switch may forward Layer 2 and Layer 3 traffic, as appropriate.

Note: In an active-standby configuration, the same service cannot beactive simultaneously on both switches.

Active-Standby VRRP Routers




.


In the example shown in "Active-Standby VRRP Routers" (page 525),Application Switch 1 is the master for the virtual interface router with VRID =1, and its backup for the virtual interface router with VRID = 2. ApplicationSwitch 2 is master for the virtual interface router with VRID = 2 and backupfor the virtual interface router with VRID = 1. In this manner, both routerscan actively forward traffic at the same time but not for the same interface.

Active-Standby Configuration

VRID = 1 VRID = 2

ApplicationSwitch 1

Router #1 = Master ActiveVR IP address =205.178.13.226MAC address =00.00.5E.00.01.01Priority = 255IP interface = 205.178.13.226

Router #1 = Backup StandbyVR IP address =205.178.13.240MAC address =00.00.5E.00.01.02Priority = 100IP interface = 205.178.13.239

ApplicationSwitch 2

Router #2 = Backup StandbyVR IP address =205.178.13.226MAC address =00.00.5E.00.01.01Priority = 100IP interface = 205.178.13.225

Router #1 = Master ActiveVR IP address =205.178.13.240MAC address =00.00.5E.00.01.02Priority = 255IP interface = 205.178.13.240

Active-Standby VSR Configuration in a Non-Shared Environment"Non-Shared Active-Standby High Availability Configuration" (page527) shows an example configuration where two Nortel Application Switchesare used as VRRP routers in an active-standby configuration, implementinga virtual server router. In this configuration, when both switches are healthy,only the master responds to packets sent to the virtual server IP address.

Active-standby redundancy should be used in configurations that cannotsupport sharing of interfaces at Layer 3 and Layer 4. This includesconfigurations where incoming packets will be seen by more than oneswitch, such as instances where a hub is used to connect the switches.




.


Non-Shared Active-Standby High Availability Configuration

Although this example shows only two switches, there is no limit on thenumber of switches that can be used in a redundant configuration. Itis possible to implement an active-standby configuration across all theVRRP-capable switches in a LAN.

Each VRRP-capable switch in an active-standby configuration isautonomous. Switches in a virtual router need not be identically configured.

To implement the active-standby example, perform the following switchconfiguration:

Step Action

1 Configure the appropriate Layer 2 and Layer 3 parameters onboth switches.

This includes any required VLANs, IP interfaces, default gateways,and so on. If IP interfaces are configured, none of them should usethe virtual server IP address described in Step 3.

2 Define all filters required for your network configuration.

Filters may be configured on one switch and synchronized withsettings on the other switch (see Step 5 below).

3 Configure all required SLB parameters on application switch 1.

For the purposes of this example, assume that application switch1 in "Non-Shared Active-Standby High Availability Configuration"(page 527) is configured in this step. Required Layer 4 parametersinclude a VIP = 205.178.13.226 and one real server group withfour real servers, RIP = 10.10.10.101, RIP = 10.10.10.102, RIP =10.10.10.103, and RIP = 10.10.10.104.

4 Configure the VRRP parameters on application switch 1.




.


This configuration includes VRID = 2, VIP = 205.178.13.226 and thepriority. Enable tracking on the virtual router, and set the parametersappropriately (refer to "Tracking Virtual Routers" (page 548)). Makesure to disable sharing.

5 Synchronize the SLB and VRRP configurations bysynchronizing the configuration from application switch 1 toapplication switch 2.

Use the /oper/slb/sync command (see "Configuring VRRPPeers for Synchronization" (page 578)).

6 Change the real servers in the application switch 2 configurationto RIP = 10.10.11.101, RIP = 10.10.11.102, RIP =10.10.11.103,and RIP = 10.10.11.104.

Adjust application switch 2’s priority (see "Tracking Virtual Routers"(page 548)).

In this example, with application switch 1 as the master, if a linkbetween application switch 1 and a server fails, the server will failhealth checks and be taken out of the load-balancing algorithm.If tracking is enabled and is configured to take into account thenumber of healthy real servers for the Virtual Router’s VIP address,application switch 1’s priority will be reduced. If it is reduced toa value lower than application switch 2’s priority, then applicationswitch 2 will assume the role of master. In this case, all activeconnections serviced by application switch 1’s virtual server IPaddress are severed.

If the link between application switch 1 and its Internet routerfails, the protocol used to distribute traffic between the routers, forexample, Open Shortest Path First (OSPF), will reroute traffic tothe other router. application switch 2 (backup) will act as a Layer2/3 switch and forward all traffic destined to the virtual server IPaddress to application switch 1.

If the entire application switch 1 (master) fails, the protocol used todistribute traffic between the routers, such as OSPF, will reroute trafficto application switch 2. Application switch 2 (backup) detects thatthe master has failed because it will stop receiving advertisements.The backup then assumes the master’s responsibility of respondingto ARP requests and issuing advertisements.

—End—




.


Active-Active RedundancyNortel Application Switch Operating System has extended VRRP to includevirtual servers, allowing full active/active redundancy between its Layer 4switches. In an active-active configuration, shown in "Active-Active HighAvailability Configuration" (page 529), both switches can process traffic forthe same service at the same time. Both switches share interfaces at Layer3 and Layer 4, meaning that both switches can be active simultaneously fora given IP routing interface or load-balancing virtual server (VIP).

Active-Active VIR and VSR ConfigurationIn "Active-Active High Availability Configuration" (page 529), two NortelApplication Switches are used as VRRP routers in an active-activeconfiguration implementing a virtual server router. As noted earlier, this isthe preferred redundant configuration.

Active-Active High Availability Configuration

Although this example shows only two switches, there is no limit on thenumber of switches used in a high availability configuration. It is possible toimplement an active-active configuration and perform load sharing betweenall of the VRRP-capable switches in a LAN.

In this configuration, when both switches are healthy, the load balancedpackets are sent to the virtual server IP address, resulting in higher capacityand performance than when the switches are used in an active-standbyconfiguration.

The switch on which a frame enters the virtual server router is the one thatprocesses that frame. The ingress switch is determined by external factors,such as routing and STP settings.

Note: Each VRRP-capable switch is autonomous. There is norequirement that the switches in a virtual router be identically configured.Different switch models with different numbers of ports and differentenabled services may be used in a virtual router.




.


To implement this example, configure the switches as follows:

Step Action

1 Configure the appropriate Layer 2 and Layer 3 parameters onboth switches.

This configuration includes any required VLANs, IP interfaces,default gateways, and so on. If IP interfaces are configured, none ofthem should use the VIP address described in Step 3.


Filters may be configured on one switch and synchronized with thesettings on the other switch (see Step 6, below).

3 Configure all required SLB parameters on one of the switches.

For the purposes of this example, assume that application switch 1(see "Active-Active High Availability Configuration" (page 529)) isconfigured in this step. Configure a VIP = 205.178.13.226 and onereal server group with two real servers:

RIP = 10.10.10.103 should be configured as a backup server toRIP = 10.10.10.101.


Note: In this configuration, each server’s backup is attached tothe other switch. This ensures that operation will continue if all ofthe servers attached to a switch fail.

4 Configure the VRRP parameters on the switch.

Configure VRID = 2, VIP address = 205.178.13.226, and priority.Be sure to enable sharing.

5 Disable synchronization of VRRP priority to switch 2.

Use the /cfg/slb/synch/prios dis command. This will leaveswitch 2 with its default priority of 100.

6 Synchronize the SLB and VRRP configurations by pushing theconfiguration from application switch 1 to application switch 2.

Use the /oper/slb/sync command.

7 Reverse the roles of the real servers and their backups inapplication switch 2’s configuration.





.



In this configuration, if a link between a switch and a server fails,the server will fail health checks and its backup (attached to theother switch) will be brought online. If a link between a switch and itsInternet router fails, the protocol used to distribute traffic between therouters (for example, OSPF) will reroute traffic to the other router.Since all traffic now enters the virtual server router on one switch,that switch will process all incoming connections.

If an entire master switch fails, the backup will detect this failurebecause it will stop receiving advertisements. The backup willassume the master’s responsibility of responding to ARP requestsand issuing advertisements.

Be cautious before setting the maximum connections (maxconn)metric in this configuration. The maxcon number is not sharedbetween switches. Therefore, if a server is used for normal operationby one switch and is activated simultaneously as a backup by theother switch, the total number of possible connections to that serverwill be the sum of the maximum connection limits defined for it onboth switches.

—End—

Active-Active Server Load Balancing ConfigurationIn this example, you set up four virtual servers each load balancing twoservers providing one service (for example, HTTP) per virtual server.

You are load balancing HTTP, HTTPS, POP3, SMTP, and FTP. Eachprotocol is load balanced via a different virtual server. You could loadbalance all of these services on one VIP, but in this example, four distinctvirtual servers are used to illustrate the benefits of active/active failover. Setup one switch, dump out the configuration script (also called a text dump),edit it, and dump the edited configuration into the peer switch.

Note: Configuring the switch for active-active failover should take nolonger than 15 minutes to complete. You can use either theNortelApplication Switch Operating System Browser-Based Interface (BBI) orthe Command Line Interface (CLI) for configuration.

Task 1: Background Configuration

Step Action





.


The switch will need an IP interface for each subnet to which it willbe connected so it can communicate with devices attached to it.Each interface will need to be placed in the appropriate VLAN. In ourexample, Interfaces 1, 2, 3, and 4 will be in VLAN 2 and Interface 5will be in VLAN 3.

Note: On Nortel Application Switches, you may configure morethan one subnet per VLAN.

To configure the IP interfaces for this example, enter the followingcommands from the CLI:

>> Main# /cfg/l3/if 1 (Select IP interface 1)



>> IP Interface 1 # vlan 2 (Assign VLAN for theinterface)


Repeat the commands for each interface listed below:

• IF 2—20.10.10.10

• IF 3—30.10.10.10

• IF 4—40.10.10.10

• IF 5—200.1.1.10

2 Define the VLANs.

In this configuration, set up two VLANs: One for the outside world(the ports connected to the upstream switches, toward the routers)and one for the inside (the ports connected to the downstreamswitches, toward the servers).

>> Main# /cfg/l2/vlan <VLANnumber>

(Select VLAN 3)

>> vlan 3 # add <port number> (Add a port to the VLANmembership)

>> vlan 3 # ena (Enable VLAN 3)

Repeat this command for the second VLAN.

• VLAN 3 - IF 5—physical ports connected to upstream switches.

• VLAN 2 - IFs 1,2,3,4—physical ports connected to downstreamswitches.




.


3 Disable Spanning Tree.

>> Main# /cfg/l2/stg 1 (Select the STP Groupnumber)

>> Main# /cfg/l2/stg 1/off (Disable STP)

>> Main# /cfg/l2/stg 1/apply (Make your changes active)

4 Enable IP forwarding.

IP forwarding is enabled by default. Make sure IP forwardingis enabled if the virtual server IP addresses and real server IPaddresses are on different subnets, or if the switch is connected todifferent subnets and those subnets need to communicate throughthe switch. If you are in doubt as to whether or not to enable IPforwarding, enable it. In this example, the virtual server IP addressesand real server IP addresses are on different subnets, so enable thisfeature using the following command:

>> Main# /cfg/l3/frwd/on

(Enable IP forwarding)

—End—

Task 2: SLB Configuration

Step Action

1 Define the Real Servers.

The real server IP addresses are defined and put into four groups,depending on the service they are running. Notice that RIPs 7 and 8are on routable subnets in order to support passive FTP. For eachreal server, you must assign a real server number, specify its actualIP address, and enable the real server.

For example:

>> Main# /cfg/slb/real 1 (Server A is real server 1)

>> Real server 1 # rip10.10.10.5

(Assign Server A IPaddress)


Repeat this sequence of commands for the following real servers:

• RIP 2—10.10.10.6/24




.


• RIP 3—20.10.10.5/24

• RIP 4—20.10.10.6/24

• RIP 5—30.10.10.5/24

• RIP 6—30.10.10.6/24

• RIP 7—200.1.1.5/24

• RIP 8—200.1.1.6/24

2 Define the real server groups, adding the appropriate realservers.

This combines the three real servers into one service group:





Repeat this sequence of commands for the following real servergroups:

• Group 2—Add RIP 3 and 4



3 Define the virtual servers.

After defining the virtual server IP addresses and associating themwith a real server group number, you must tell the switch which IPports/services/sockets you want to load balance on each VIP. Youcan specify the service by either the port number, service name,or socket number.

>> Real server group 4 #/cfg/slb/virt 1





(Assign HTTP service port80)

>> Virtual server 1 httpService # group 1


>> Virtual server 1 # ena (Enable the virtual server)




.


Repeat this sequence of commands for the following virtual servers:

• VIP 2—200.200.200.101 will load balance HTTPS (Port 443)to Group 2

• VIP 3—200.200.200.102 will load balance POP/SMTP (Ports110/25) to Group 3

• VIP 4—200.200.200.104 will load balance FTP (Ports 20/21)to Group 4

4 Define the client and server port states.

Defining a client port state tells that port to watch for any framesdestined for the VIP and to load balance them if they are destined fora load-balanced service. Defining a server port state tells the port tothe do the remapping (NAT) of the real server IP address back to thevirtual server IP address. Note the following:

• The ports connected to the upstream switches (the onesconnected to the routers) will need to be in the client port state.

• The ports connected to the downstream switches (the onesproviding fan out for the servers) will need to be in the serverport state.

Configure the ports, using the following sequence of commands:

>> Virtual server 4# /cfg/slb/port 1

(Select physical switch port1)

>> SLB port A1 # client ena (Enable client processingon port 1)

>> SLB port A1 # /cfg/slb/port2


>> SLB port A2 # server ena (Enable server processingon port 2)

—End—

Task 3: Virtual Router Redundancy Configuration

Step Action

1 Configure virtual routers 2, 4, 6, and 8.




.


These virtual routers will have the same IP addresses as the virtualserver IP address. This is what tells the switch that these are virtualservice routers (VSRs). In this example, Layer 3 bindings are left intheir default configuration, which is disabled.

Configure a virtual router using the following sequence of commands:

>> Virtual server 4 #/cfg/l3/vrrp/vr 2

(Select virtual router 2)

>> Virtual router 2 # vrid 2 (Set virtual router ID)

>> Virtual router 2 # addr200.200.200.100

(Assign virtual router IPaddress)

>> Virtual router 2 # if 5 (Assign virtual routerinterface)

>> Virtual router 2 # ena (Enable virtual router 2)

Repeat this sequence of commands for the following virtual routers:

• VR 4 - VRID 4 - IF 5 (associate with IP interface #5)—Address200.200.200.101



2 Configure virtual routers 1, 3, 5, and 7.

These virtual routers will act as the default gateways for the serverson each respective subnet. Because these virtual routers aresurvivable next hop/default gateways, they are called virtual interfacerouters (VIRs).

Configure each virtual router listed below, using the sequence ofcommands in Step 1.

• VR 1 - VRID 1 - IF 1 (associate with IP interface 1)—Address10.10.10.1




3 Set the renter priority for each virtual router.




.


Since you want Switch 1 to be the master router, you need to bumpthe default virtual router priorities (which are 100 to 101 on virtualrouters 1-4) to force switch 1 to be the master for these virtualrouters.

Use the following sequence of commands:

>> Virtual server 4 #/cfg/l3/vrrp/vr 1

(Select virtual router 1)

>> Virtual router 1 # prio 101 (Set virtual router priority)

Apply this sequence of commands to the following virtual routers,assigning each a priority of 101:

• VR 2—Priority 101



4 Configure priority tracking parameters for each virtual router.

For this example, the best parameter to track is Layer 4 ports (l4pts).

Use the following command:

>> Virtual server 4# /cfg/l3/vrrp/vr 1/track l4pts

This command sets the priority tracking parameter for virtual router1, electing the virtual router with the most available ports as themaster router. Repeat this command for the following virtual routers:

• n VR 2 - Track l4ptsVR 6 - Track l4pts



Switch 1 configuration is complete.

—End—

Task 4: Configuring Switch 2 Use the following procedure to configureSwitch 2:

Step Action

1 Dump the configuration script (text dump) of Switch 1 usingeither of the following tools:




.


• The Browser Based Interface (BBI)

— You need a serial cable that is a DB-9 Male to DB-9 Female,straight-through (not a null modem) cable.

— Connect the cable from a COM port on your computer tothe console port on switch 1.

— Open HyperTerminal (or the terminal program of your choice)and connect to the switch using the following parameters:Baud: 9600, Data Bits: 8, Parity: None, Stop Bits:1, FlowControl: None.

• HyperTerminal

— Only the Baud Rate and Flow Control options need to bechanged from the default settings.

— Once you connect to the switch, start logging your session inHyperTerminal (transfer/capture text).

— Save the file as "Customer Name" Switch 1, then type thefollowing command in the switch command line interface:

/cfg/dump

A script will be dumped out.

— Stop logging your session (transfer/capture text/stop).

2 Modify the script created in Step 1 as follows:

• Open the text file that was created and change the following:

— Delete anything above Script Start.

— Delete the two lines directly below Script Start. These twolines identify the switch from which the dump was taken andthe date and time. If these two lines are left in, it will confuseApplication Switch 2 when you dump in the file.

— Change the last octet in all the IP interfaces from .10 to .11.Find this line in the file:

/cfg/l3/if 1/addr 10.10.10.10

Simply delete the 0 and put in a 1. Be sure to do this for allthe IP interfaces or duplicate IP addresses will be present inthe network.

— Change the virtual router priorities. Virtual routers 1–4 needto have their priority set to 100 from 101, and virtual routers5-7 need to have their priorities set to 101 from 100. Youcan find this in the line /cfg/l3/vrrp/vr 1/vrid 1/if1/prio 101.




.


— Scroll to the bottom of the text file and delete anything pastScript End.

— Save the changes to the text file as <Customer Name>Switch 2.

3 Move your serial cable to the console port on the secondswitch. Any configuration on it needs to be deleted by resettingit to factory settings, using the following command:

>> Main# /boot/conf factory/reset

You can tell if the switch is at factory default when you log on becausethe switch will prompt you if you want to use the step-by-stepconfiguration process. When it does, respond: No.

Note: After completing the setup you cannot proceed furtherwithout configuring the ports.To configure ports enter y or enter n to ignore.

4 In HyperTerminal, go to transfer/send text file and send theSwitch 2 text file created in Step 2. The configuration will dumpinto the switch. Simply type apply , then save. When you cantype characters in the terminal session again, reboot the switch( /boot/reset ).

—End—

Hot-Standby RedundancyIn a hot-standby configuration, Spanning Tree Protocol (STP) is not neededto eliminate bridge loops. This speeds up failover when a switch fails. Thestandby switch blocks all ports configured as standby ports, whereas themaster switch enables these same ports. Consequently, on a given switch,all virtual routers are either master or backup; they cannot change stateindividually.

In a hot-standby configuration, two or more switches provide redundancyfor each other. One switch is elected master and actively processes Layer4 traffic. The other switches (the backups) assume the master role shouldthe master fail. The backups may forward Layer 2 and Layer 3 traffic asappropriate.

Switch-Centric Virtual Router GroupHot-standby requires that all virtual routers on a switch failover together as agroup. For more information about the switch-based virtual router groups,see"Switch-Based VRRP Groups" (page 517).




.


When enabled, the switch-centric virtual router group (/cfg/l3/vrrp/group)aggregates all virtual routers on the switch as a single entity. All virtualrouters will failover as a group, and cannot failover individually. As membersof a group, all virtual routers on the switch (and therefore the switch itself),will be in either a master or backup state.

Enable the switch-based virtual router group using the following command:

>> Main# /cfg/l3/vrrp/group ena

Layer 4 Port StatesWhen a switch changes from master to backup, it does not process anytraffic destined to the virtual server routers configured on that switch.However, Layer 4 processing is still enabled. A switch that has become thebackup can still process traffic addressed to its virtual server IP address.Filtering is also still functional.

Each VRRP advertisement can include up to 1024 addresses, and istherefore is not limited to a single virtual router IP address. A VRRPadvertisement packet contains all virtual routers are advertised in the samepacket, thus conserving processing and buffering resources.

Hot-Standby and Inter-Switch Port StatesThe second part of the solution involves introducing two additional Layer 4port states, hot-standby and inter-switch:

• Links that attach to the standby switch must be configured as hotstandby using:

>> Main# /cfg/slb/port x/hotstan

Note: All ports with hot standby enabled must be connected toanother device.

• Links that are used by VRRP to deliver updates are configured asintersw, or Inter-switch links (not to be confused with Cisco’s ISL). Thecommand to configure one or more ports as interswitch links is:

>> Main# /cfg/slb/port <port number> /intersw

Note: A port cannot be configured to support both hot-standby andinterswitch link.

The hot-standby switch listens to the master’s VRRP updates. After aninterval period has expired without receiving a update, the backup switchwill take over. The forwarding states of hot-standby ports are controlled




.


much like the forwarding states of the old hot-standby approach. Enablinghot-standby on a switch port allows the hot-standby algorithm to control theforwarding state of the port. If a switch is master, the forwarding states ofthe hot-standby ports are enabled. If a switch is backup, the hot-standbyports are blocked from forwarding or receiving traffic.

When the hotstan option (/cfg/slb/port x/hotstan) is enabled and allhot-standby ports have link, the virtual router group’s priority is automaticallyincremented by the track other virtual routers value.

This action allows the switches to failover when a hot-standby port loseslink. Other enabled tracking features only have effect when all hot-standbyports on a switch have link. The default virtual routers tracking value istwo seconds. Keep in mind that this is an automatic process that cannotbe turned off.

Note: The VRRP hot-standby approach does not support single-linkfailover. If one hot-standby port loses link, the entire switch mustbecome master to eliminate loss of connectivity.

The forwarding states of non-hot-standby ports are not controlled via thehot-standby algorithm, allowing the additional ports on the switches toprovide added port density. The client ports on both switches should be ableto process or forward traffic to the master switch.

The inter-switch port state is only a place holder. Its presence forces theuser to configure an inter-switch link when hot-standby is globally enabledand prohibits the inter-switch link from also being a hot-standby link forVRRP advertisements. These advertisements must be able to reach thebackup switch.

Hot-Standby ConfigurationA hot-standby configuration allows all processes to failover to a backupswitch if any type of failure should occur. The primary application forhot-standby redundancy is to avoid bridging loops when using the SpanningTree Protocol (STP), IEEE 802.1d. VRRP-based hot-standby supports thedefault Spanning Tree only. It does not support multiple Spanning Trees.

"Hot-Standby Configuration" (page 542) shows a classic network topology,designed with redundancy in mind. This topology contains bridging loopsthat would require the use of STP. In the typical network, STP failover time is45-50 seconds, much longer than the typical failover rate using VRRP only.

Note: To use hot-standby redundancy, peer switches must have anequal number of ports.




.


Hot-Standby Configuration

The key to hot-standby is that the interswitch link (the link betweenswitches), does not participate in STP, so there are no loops in the topology(see"Hot-Standby Configuration" (page 542)). User has to disable STPglobally to use VRRR Hot-Standby Scenario. The switch will have failovertimes similar to what would be the case with VRRP.

Note: While the port usage in this example assumes use of a NortelApplication Switch 2424, you may adapt this example according theports available on your particular Nortel Application Switch model.

Task 1: Configure Layer 2 and Layer 3 Parameters on Switch 1 Thisexample assumes you have already configured SLB parameters.

Perform the following procedure to configure Layer 2 and 3 parameterson Switch 1:

Step Action

1 On Switch 1, configure the external ports into their respectiveVLANs as shown in "Hot-Standby Configuration" (page 542) .

>> Main# /cfg/l2/vlan 1>> VLAN 1# ena

>> VLAN 1# name servers (Name VLAN 1 for servertraffic)

>> VLAN 1# /cfg/l2/vlan 192 (VLAN 192 is for clienttraffic)

>> VLAN 192# ena (Enable the VLAN)

>> VLAN 192# name clients (Name VLAN 192 for clienttraffic)

>> VLAN 192# def 25 26 (Add the ports 25, 26 toclient VLAN)




.


>> VLAN 192# /cfg/l2/vlan 172 (VLAN 172 is for theInterswitch Link)

>> VLAN 172# ena (Enable the VLAN)

>> VLAN 172# name ISL (Name VLAN 172 for ISL)

>> VLAN 172# def 3 (Add port 3 to ISL VLAN)

2 Trunk the ports you configured for the client VLAN.

>> Main # /cfg/l2/trunk 1 (Select Trunk Group 1)

>> Trunk group 1# ena (Enable the Trunk Group)

>> Trunk group 1# add 25 26 (Add the external ports tothe trunk)

3 Turn off Spanning Tree.

>> Main # /cfg/l2/stg 1/off (Disable STG group)

>> Spanning Tree Group 1# apply (Make your changes active)

>> Spanning Tree Group 1# save (Save for restore afterreboot)

4 Configure the IP addresses for each VLAN.

>> Main # /cfg/l3/if 1 (IP Interface 1: Servers)

>> IP Interface 1# ena (Enable this interface)

>> IP Interface 1# addr 10.0.1.251>> IP Interface 1# mask 255.255.255.0>> IP Interface 1# broad 10.0.1.255

>> IP Interface 1# /cfg/l3/if 2 (IP Interface 2: Client traffic)

>> IP Interface 2# ena>> IP Interface 2# addr 192.168.1.251>> IP Interface 2# vlan 192

>> IP Interface 2# /cfg/l3/if 3 (IP Interface 3: InterswitchLink)

>> IP Interface 3# ena>> IP Interface 3# addr 172.16.2.251>> IP Interface 3# vlan 172

—End—




.


Task 2:Configure Virtual Router Redundancy Perform the followingtasks to configure Virtual Router redundancy:

Step Action

1 Configure virtual routers for the server, client, and InterswitchLink traffic.

>> Main# /cfg/l3/vrrp/vr 1 (Virtual router for server)

>> VRRP Virtual Router 1# ena>> VRRP Virtual Router 1# vrid 1>> VRRP Virtual Router 1# if 1>> VRRP Virtual Router 1# addr 10.0.1.250

>> Main #/cfg/l3/vrrp/vr 2 (Virtual router for client)


>> Main # /cfg/l3/vrrp/vr 3 (Virtual router for InterswitchLink)


2 From the VRRP menu, enable VRRP group mode andhot-standby on all connected ports except the interswitch link.

>> Main # /cfg/l3/vrrp/on (Enable VRRP)

>> Virtual Router Redundancy Protocol# hotstan ena(Enable hot-standby)

>> Virtual Router Redundancy Protocol# group ena(Enable VR group)

>> VRRP Virtual Router Group#apply

(Make your changes active)

>> VRRP Virtual Router Group#save

(Save for restore afterreboot)

3 Set VRRP tracking for the ports.

If a link on any of the connected ports goes down, the switch willdecrease in VRRP priority and the backup switch will take over asthe master.




.


>> Main # /cfg/l3/vrrp>> VRRP Virtual Router Group# vrid 254

>> VRRP Virtual Router Group#prio 101

(Set priority at 101 forMaster switch)

>> VRRP Virtual Router Group# track/ports ena

4 Setup the peer switch to receive synchronization.

Make sure to disable synchronization of VRRP priorities; the peerswitch will assume its own priority based on the VRRP electionprocess and should not acquire the VRRP priority from the Masterswitch’s configuration. If you will be configuring real servers forVRRP hotstandby, make sure to enable synchronization of realserver configuration as well.

>> Main # /cfg/slb/sync/prios d (Do not synchronize VRRPpriorities to the peer switch)

>> Config Synchronization# peer1/ena

(Enable the synch. peerswitch)

>> Peer Switch 1# addr172.16.2.252

(Set IP address of switch 1)

5 From the SLB menu, enable a hot-standby link on the Layer 4ports; then enable interswitch link on the crosslink.

>> Main # /cfg/slb/port 2>> SLB port 2# hotstan ena>> SLB port 2# /cfg/slb/port 3>> SLB port 3# intersw ena

6 Apply and save changes to the configuration.


—End—

Task 3: Prepare a Configuration Script for Switch 2 Use the followingprocedure to dump the configuration script (text dump) from Switch 1. Thisconfiguration will be modified and loaded onto Switch 2.




.


Step Action

1 Dump the switch configuration using the following command:

>> Main # /cfg/dump

A script will be dumped out.

2 Copy and paste the entire contents of the script to a text file.

The first and last lines of the file should show the following:

script start "Nortel Application Switch 2424" 4/**** DO NOT EDIT

THIS LINE! (File must begin with thisline)

/* Configuration dump taken 1:52:02 Fri Feb 6, 2004/* Version 0.0.0, Base MAC address 00:0e:40:32:7c:00::script end /**** DO NOT EDIT THIS LINE!

>> Configuration#

3 Edit the text file that you just created as follows:

• Change all the IP interface addresses for switch 2; otherwise, youwill have duplicate IP addresses in the network. In this example,change the last octet in all the IP interfaces from .251 to .252.

(Example from configuration script)/c/l3/if 1addr 10.0.1.252

• Change the synchronization peer switch to use the IP addressof Switch 1. In this example, change the last octet from .252(denoting switch 2), to .251 (switch 1).

(Example from configuration script)/c/slb/sync/peer 1enaaddr 172.16.2.251

• Change the virtual router priority from 100 to 101—this willindicate that switch 2 is the backup for now.




.


/c/l3/vrrp/group:prio 101

4 Save the changes to the text file as <Customer-Name>_backup_config and load it onto a TFTP server.

5 Begin a Telnet session for the second switch. Delete anyexisting configuration on it by resetting it to factory settings,using the following command:

>> Main # /boot/conf factory/reset

Confirmation message appears. Enter y to save changes and restartenter n to ignore changes and cancel restart.

You can tell if the switch is at factory default when you logon, because the switch will prompt you if you want to use thestep-by-step configuration process. When it does, respond: No.

6 From the CLI, download the configuration script into the switchfrom the TFTP server using the following command:

>> Main # /cfg/gtcfg <tftp-server-addr> <cfg-filename>

—End—

Task 4: Synchronize Layer 4 Parameters form Switch 1 to Switch2 Synchronize Layer 4 parameters from Switch 1 to 2 using the followingprocedure:

Step Action

1 On Switch 1, synchronize the VRRP, SLB, real server, and filtersettings to the other switch (same ports).

Switches peering with each other should have an equal numberof ports.




.


>> Main# /oper/slb/syncNOTE: Use the "/c/slb/sync" menu to configureomitting sections ofthe configuration.Synchronizing VRRP, FILT, PORT, REAL and SLBconfigurationto 172.16.2.252Confirm synchronizing the configuration to172.16.2.252 [y/n]:y

2 On switch 2, apply and save the configuration changes.

—End—

Tracking Virtual RoutersTracking configuration largely depends on user preferences and networkenvironment. Consider the configuration shown in "Non-SharedActive-Standby High Availability Configuration" (page 527). Assume thefollowing behavior on the network:

• Application switch 1 is the master router upon initialization.

• If application switch 1 is the master and it has one fewer active serversthan application switch 2, then application switch 1 remains the master.

This behavior is preferred because running one server down is lessdisruptive than bringing a new master online and severing all activeconnections in the process.

• If application switch 1 is the master and it has two or more active serversfewer than application switch 2, then application switch 2 becomes themaster.

• If application switch 2 is the master, it remains the master even if serversare restored on application switch 1 such that it has one fewer or anequal number of servers.

• If application switch 2 is the master and it has one active server fewerthan application switch 1, then application switch 1 becomes the master.

The user can implement this behavior by configuring the switch for trackingas follows:

Step Action

1 Set the priority for application switch 1 to the default value of100.

2 Set the priority for application switch 2 to 96.




.


3 On both switches, enable tracking based on the number ofvirtual routers in master mode on the switch and set the value= 5.

4 On both switches, enable tracking based on the number ofhealthy real servers behind the VIP address. The VIP addressis the same as the IP address of the virtual server router onthe switch. Set the value = 6.

Initially, application switch 1 ("Non-Shared Active-Standby HighAvailability Configuration" (page 527)) will have a priority of 100(base value) + 5 (initially it is the master) + 24 (4 active real servers *6 per real server) = 129.

Application Switch 2 will have a priority of 96 (base value) + 24 (4active real servers * 6 per real server) = 120.

If a server attached to application switch 1 fails, then applicationswitch 1’s priority will be reduced by 6 to 123. Since 123 is greaterthan 120 (application switch 2’s priority), application switch 1 willremain the master.

If a second server attached to application switch 1 fails, thenapplication switch 1’s priority will be reduced by 6 more to 117.Since 117 is less than 120 (application switch 2’s priority), thenapplication switch 2 will become the Master. At this point, applicationswitch 1’s priority will fall by 5 more and application switch 2’s willrise by 5 because the switches are tracking how many masters theyare running. So, application switch 1’s priority will settle out at 112and application switch 2’s priority at 125.

When both servers are restored to application switch 1, that switch’spriority will rise by 12 (2 healthy real servers * 6 per healthy server)to 124. Since 124 is less than 125, application switch 2 will remainthe master.

If, at this point, a server fails on application switch 2, its priority willfall by 6 to 119. Since 119 is less than 124, application switch 1will become the Master. Its priority will settle out at 129 (since it’snow the master) while application switch 2’s priority will drop by 5more to 114.

You can see from this example that the user’s goals were met by theconfigured tracking parameters.

Note: There is no shortcut to setting tracking parameters. Thegoals must first be set and the outcomes of various configurationsand scenarios analyzed to find settings that meet the goals.

—End—




.


Service-Based Virtual Router GroupsService-based virtual router groups can be used for failover in either anactive-active or active-standby configuration.

In "Service-based Virtual Router Groups - Active-Standby Configuration"(page 550), two customers are sharing the same VRRP switches configuredin Active-Standby configuration for VIP 1 and 2. Virtual routers 1, 2, 3, and 4are defined on both switches as follows:

• Virtual routers 1 and 3 are virtual interface routers—they use the IPinterface addresses.

• Virtual routers 2 and 4 are virtual service routers—they use the virtualserver IP addresses.

Virtual router 1 on the master forwards the packets sent to the IP addressesassociated with the virtual router and answers ARP requests for these IPaddresses. The virtual router backup assumes forwarding responsibility fora virtual router should the current master fail.

Virtual routers 1 and 2 are members of vrgroup 1 and virtual routers 3 and 4are members of vrgroup 2.

Service-based Virtual Router Groups - Active-Standby Configuration




.


Configuration ExampleIn this example, if the interface or link to the real server fails for the vrgroup1 on Application Switch 1, then all the VRs in vrgroup 1 change to thebackup state. At the same time, all VR’s in vrgroup 1 on Application Switch2 change to the master state. Meanwhile, the VRs in vrgroup 2 continueto operate via Application switch 1.

The separate real server groups provide segregation of services for eachcustomer., so neither customer’s traffic interferes with the others. Toimplement the active-standby example with tracking of service-based virtualrouter groups, perform the following switch configuration.

Step Action


The switch will need an IP interface for each subnet to which it willbe connected so it can communicate with devices attached to it.To configure the IP interfaces for this example, enter the followingcommands from the CLI:

>> Main# /cfg/l3/if 1 (Select IP interface 1)




Repeat the commands for the following interfaces:

• IF 2: 205.178.13.2

• IF 3: 200.200.200.3

• IF 4: 205.178.13.4


Filters may be configured on one switch and synchronized withsettings on the other switch.

3 Configure all required SLB parameters on application switch 1.

Required Layer 4 parameters include 2 virtual server IP addresses,two groups and four real servers.

>> Main# /cfg/slb/real 1/ (Configure real servers)

>> Real server 1# rip 10.10.10.101>> Real server 1# /cfg/slb/real 2/rip 10.10.10.102>> Real server 2# /cfg/slb/real 3/rip 10.10.10.103>> Real server 3# /cfg/slb/real 4/rip 10.10.10.104




.






>> Main # /cfg/slb/virt 1/vip 205.178.13.226 (Configurevirtual server IP 1)



(Select the HTTP serviceport menu)



>> Main # /cfg/slb/group 2



>> Main # /cfg/slb/virt 1/vip 205.178.13.300






4 Configure virtual interface routers 1 and 3, make sure to disablesharing.

These virtual routers are assigned the same IP address as the IPinterfaces configured in Step 1, thus telling the switch that these arevirtual interface routers (VIRs). In this example, Layer 3 bindingsare left in their default configuration, which is disabled. For anactive-standby configuration, sharing is disabled.

>> Main # /cfg/l3/vrrp/vr 1 (Select virtual router 1)

>> VRRP Virtual Router 1# vrid1

(Set virtual router ID)

>> VRRP Virtual Router 1# addr 200.200.200.100 (AssignVR IP address)

>> VRRP Virtual Router 1# if 1 (Assign virtual routerinterface)




.


>> VRRP Virtual Router 1# sharedis

(Disable sharing ofinterfaces)

>> VRRP Virtual Router 1# ena (Enable virtual router 1)




>> VRRP Virtual Router 3# addr 200.200.200.103 (Assign VR IPaddress)





5 Configure virtual server routers 2 and 4.

These virtual routers will have the same IP addresses as the virtualserver IP address. This is what tells the switch that these are virtualservice routers (VSRs).

For an active-standby configuration, sharing is disabled.




















.


6 Add virtual routers 1 and 2 to the vrgroup 1.

>> Main# /cfg/l3/vrrp/vrgroup 1

>> VRRP Virtual Router Vrgroup1# add 1

(Add virtual router 1: theVIR)


(Add virtual router 2: theVSR)

>> VRRP Virtual Router Vrgroup 1# ena

>> VRRP Virtual Router Vrgroup1# track

(Select the Priority TrackingMenu)

>> VRRP Vrgroup 1 Priority Tracking# ports ena (Track onphysical ports)

7 Add virtual routers 3 and 4 to switch-based vrgroup 2.

>> Main# /cfg/l3/vrrp/vrgroup 2


(Add virtual router 1)


(Add virtual router 2)

>> VRRP Virtual Router Vrgroup 2# ena

>> VRRP Virtual Router Vrgroup2# track

(Select the Priority TrackingMenu)

>> VRRP Vrgroup 2 Priority Tracking# l4ports ena (Trackon layer 4 ports)

8 Disable synchronizing of priority on Application Switch 1.

The priorities should not be synchronized between the twoswitches. Priority for each vrgroup will change based on the trackingparameters configured in Step 6 and Step 7.

>> Main # /cfg/slb/synch prios disable

9 Synchronize the SLB and VRRP configurations from applicationswitch 1 to application switch 2.

Use the /oper/slb/sync command (see "Configuring VRRPPeers for Synchronization" (page 578)).

—End—




.


IPv6 VRRP Configuration ExamplesThe following section contains three IPv6 VRRP configuration examplescovering Hot Standby, Active Standby, and Active Active configurations. Forconceptual information on these VRRP configuration types, refer to "FailoverMethods and Configurations" (page 524).

Hot Standby Configuration ExampleThis configuration example demonstrates a Hot Standby configurationbetween two Nortel Application Switch 2424 units. The following conceptsshould be taken into account in IPv6 Hot Standby configurations:

Step Action

1 Layer 2 (Port and VLAN) configuration

• Each VLAN must be configured per interface.

• Client-side and server-side VLANs must also be a member inan inter-switch-link (ISL) port.

2 Spanning Tree Group configuration

• The Spanning Tree Protocol must be turned off.

3 Layer 3 interface and VRRP configuration

• In this example, tracking is performed by Layer 2 ports so thatany failures on the Master switch results in a successful switch tothe Backup switch.

4 Server Load Balancing

• Ports connected to the peer switch directly, or via a Layer 2switch, must have Hot Standby (/cfg/slb/port hot) enabled.ISL and other ports should not have Hot Standby enabled.

—End—

The following illustration demonstrates the Hot Standby configurationpresented in this example




.


IPv6 Hot Standby configuration example

Take the following steps to replicate the configuration demonstrated above:

Step Action

1 2424-A Switch Configuration

• Layer 2 (Port and VLAN) and Layer 3 (Interface) configuration

/cfg/port 1pvid 3

/cfg/port 2pvid 2

/cfg/port 3tagged enapvid 911


/cfg/l2/vlan 2enaname "server"learn enadef 2,3,4

/cfg/l2/vlan 3enaname "client"learn ena




.


def 1,3,4/cfg/l2/vlan 911

enaname "intersw"learn enadef 3,4

cfg/l2/trunk 1enaadd 3add 4

• Spanning Tree Group configuration

/cfg/l2/stg 1/off/cfg/l2/stg 1/add 1 2 3 911

• Interface configuration

/cfg/l3/if 2enaipver v6addr 2000:2:2:0:0:0:0:amask 96vlan 2


/cfg/l3/if 254enaipver v4addr 192.168.0.1mask 255.255.255.0broad 192.168.0.255vlan 911

• Default Gateway configuration

/cfg/l3/gw 1enaipver v6addr 3000:3:3:0:0:0:0:c

• VRRP configuration




.


/cfg/l3/vrrp/on/cfg/l3/vrrp/vr 2

enaipver v6vrid 2if 2addr 2000:2:2:0:0:0:0:fff0share dis

/cfg/l3/vrrp/vr 3enaipver v6vrid 3if 3addr 3000:3:3:0:0:0:0:ffffshare dis

/cfg/l3/vrrp/groupenaipver v6vrid 254if 2share distrack ports

• General SLB configuration

/cfg/slbon

/cfg/slb/advdirect ena

• IPv6 Real Server configuration

/cfg/slb/real 1enaipver v6rip 2000:2:2:0:0:0:0:1001


• IPv6 Real Server Group 1 configuration

/cfg/slb/group 1ipver v6add 1add 2




.


• IPv6 VIP 1 HTTP Service configuration

/cfg/slb/virt 1enaipver v6vip 3000:3:3:0:0:0:0:ffffvname "v6http"

/cfg/slb/virt 1/service httpgroup 1

• Layer 4 port configuration

/cfg/slb/port 1client enahotstan en

/cfg/slb/port 2server enahotstan en

/cfg/slb/port 3intersw ena


• Synchronization configuration

/cfg/slb/syncprios d

/cfg/slb/sync/peer 1enaaddr 192.168.0.2

2 2424-B Switch Configuration


/cfg/port 1pvid 3

/cfg/port 2pvid 2



/cfg/l2/vlan 2enaname "server"learn ena




.


def 2,3,4/cfg/l2/vlan 3

enaname "client"learn enadef 1,3,4

/cfg/l2/vlan 911enaname "intersw"learn enadef 3,4

/cfg/l2/trunk 1enaadd 3add 4

• Spanning Tree Group configuration

/cfg/l2/stg 1/off/cfg/l2/stg 1/add 1 2 3 911


/cfg/l3/if 2enaipver v6addr 2000:2:2:0:0:0:0:bmask 96vlan 2







.





enaipver v6vrid 2if 2addr 2000:2:2:0:0:0:0:fff0share dis

/cfg/l3/vrrp/vr 3enaipver v6vrid 3if 3addr 3000:3:3:0:0:0:0:ffffshare dis

/cfg/l3/vrrp/groupenaipver v6vrid 254if 2share distrack ports


/cfg/slbon








.







• Layer 4 Ports configuration








—End—

Active-Standby Configuration ExampleThis configuration example demonstrates an Active-Standby configurationbetween two Nortel Application Switch 2424 units. The following conceptsshould be taken into account in IPv6 Active-Standby configurations:




.


Step Action




• In this example, tracking is performed by Layer 4 ports so thatthe two virtual routers will switch over when one of the Mastervirtual routers declare as Backup.

The following illustration demonstrates the Active-Standbyconfiguration presented in this example

IPv6 Active-Standby configuration example

Take the following steps to replicate the configuration demonstratedabove:

—End—




.


Step Action



/cfg/port 1pvid 3

/cfg/port 2pvid 2

/cfg/port 3pvid 911

/cfg/l2/vlan 2enaname "server"learn enadef 2

/cfg/l2/vlan 3enaname "client"learn enadef 1

/cfg/l2/vlan 911enaname "intersw"learn enadef 3








.






enaipver v6vrid 2if 2addr 2000:2:2:0:0:0:0:fff0share distrack

l4pts ena/cfg/l3/vrrp/vr 3

enaipver v6vrid 3if 3addr 3000:3:3:0:0:0:0:ffffshare distrack

l4pts ena


/cfg/slbon









.







/cfg/slb/port 1client ena

/cfg/slb/port 2server ena






/cfg/port 1pvid 3

/cfg/port 2pvid 2

/cfg/port 3pvid 911


/cfg/l2/vlan 3enaname "client"




.


learn enadef 1

/cfg/l2/vlan 911enaname "intersw"learn enadef 3











.



enaipver v6vrid 2if 2addr 2000:2:2:0:0:0:0:fff0share distrack


enaipver v6vrid 3if 3addr 3000:3:3:0:0:0:0:ffffshare distrack

l4pts ena


/cfg/slbon











.





/cfg/slb/port 1client ena

/cfg/slb/port 2server ena




—End—

Active-Active Configuration ExampleThis configuration example demonstrates an Active-Active configurationbetween two Nortel Application Switch 2424 units. The following conceptsshould be taken into account in IPv6 Active-Active configurations:

Step Action




• In this example, tracking is performed by Layer 4 ports so thatthe two virtual routers will switch over when one of the Mastervirtual routers declare as Backup.

—End—




.


The following illustration demonstrates the Active-Active configurationpresented in this example

IPv6 Active-Active configuration example

Take the following steps to replicate the configuration demonstrated above:

Step Action



/cfg/port 1pvid 3

/cfg/port 2pvid 2

/cfg/port 3pvid 911


/cfg/l2/vlan 3




.


enaname "client"learn enadef 1

/cfg/l2/vlan 911enaname "intersw"

learn enadef 3




/cfg/l3/if 254enaipver v4addr 192.168.0.1mask 255.255.255.0

broad 192.168.0.255vlan 911







.



enaipver v6vrid 2if 2addr 2000:2:2:0:0:0:0:fff0share entrack


enaipver v6vrid 3if 3addr 3000:3:3:0:0:0:0:ffffshare entrack

l4pts ena


/cfg/slbon










.














/cfg/port 1pvid 3

/cfg/port 2pvid 2

/cfg/port 3pvid 911


/cfg/l2/vlan 3




.


enaname "client"learn enadef 1

/cfg/l2/vlan 911enaname "intersw"

learn enadef 3




/cfg/l3/if 255enaipver v4addr 192.168.0.2mask 255.255.255.0

broad 192.168.0.255vlan 911







.



enaipver v6vrid 2if 2addr 2000:2:2:0:0:0:0:fff0share entrack

l4pts en/cfg/l3/vrrp/vr 3

enaipver v6vrid 3if 3addr 3000:3:3:0:0:0:0:ffffshare entrack

l4pts en


/cfg/slbon










.












—End—

Virtual Router Deployment ConsiderationsReview the following issues described in this section to prevent networkproblems when deploying virtual routers:

• "Mixing Active-Standby and Active-Active Virtual Routers" (page 577)

• "Eliminating Loops with STP and VLANs" (page 577)

• "Assigning VRRP Virtual Router ID" (page 578)

• "Configuring VRRP Peers for Synchronization" (page 578)

• "Synchronizing Active/Active Failover" (page 580)




.


Mixing Active-Standby and Active-Active Virtual RoutersIf the network environment can support sharing, enable it for all virtualrouters in the LAN. If not, use active-standby for all virtual routers. Donot mix active-active and active-standby virtual routers in a LAN. Mixedconfigurations may result in unexpected operational characteristics, andare not recommended.

Eliminating Loops with STP and VLANsVRRP active/active failover is significantly different from the hot-standbyfailover method supported in previous releases. As shown in "Loops inActive-Active Configuration" (page 577), active-active configurations canintroduce loops into complex LAN topologies.

Loops in Active-Active Configuration

Using Spanning Tree Protocol to Eliminate LoopsVRRP generally requires Spanning Tree Protocol (STP) to be enabledin order to resolve bridge loops that usually occur in cross-redundanttopologies, as shown in "Cross-Redundancy Creates Loops but STPResolves Them." (page 577). In this example, a number of loops are wiredinto the topology. STP resolves loops by blocking ports where looping isdetected.

Cross-Redundancy Creates Loops but STP Resolves Them




.


One drawback to using STP with VRRP is the failover response time. STPcould take as long as 45 seconds to re-establish alternate routes after aswitch or link failure.

Using VLANs to Eliminate LoopsWhen using VRRP, you can decrease failover response time by usingVLANs instead of STP to separate traffic into non-looping broadcastdomains. An example is shown in "Using VLANs to Create Non-LoopingTopologies" (page 578):

Using VLANs to Create Non-Looping Topologies

This topology allows STP to be disabled. On the Nortel ApplicationSwitches, IP routing allows traffic to cross VLAN boundaries. The serversuse the Nortel Application Switches as default gateways. For port failure,traffic is rerouted to the alternate path within one health check interval(configurable between 1 and 60 seconds, with a default of 2 seconds).

Assigning VRRP Virtual Router IDDuring the software upgrade process, VRRP virtual router IDs will beautomatically assigned if failover is enabled on the switch. When configuringvirtual routers at any point after upgrade, virtual router ID numbers(/cfg/l3/vrrp/vr #/vrid) must be assigned. The virtual router ID maybe configured as any number between 1 and 255.

Configuring VRRP Peers for SynchronizationThe final piece in configuring a high-availability solution includes theaddition of synchronization options to simplify the manual configuration.Configuration options have been added to refine what is synchronized, towhom, and to disable synchronizing certain configurations. These optionsinclude proxy IP addresses, Layer 4 port configuration, filter configuration,and virtual router priorities.

Also, a peer menu (cfg/slb/sync/peer) has been added to allowthe user to configure the IP addresses of the switches that should besynchronized. This provides added synchronization validation but does notrequire the users to enter the IP address of the redundant switch for eachsynchronization.




.


Each VRRP-capable switch is autonomous. Switches in a virtual routerneed not be identically configured. As a result, configurations cannot besynchronized automatically.

For user convenience, it is possible to synchronize a configuration from oneVRRP-capable switch to another using the /oper/slb/sync command.However, care must be taken when using this command to avoid unexpectedresults. All server load balancing, port configurations, filter configurations,and VRRP parameters can be synchronized using the /oper/slb/synchcommand.

Note: Before you synchronize the configuration between two switches,a peer must be configured on each switch. Switches being synchronizedmust use the same administrator password.Sessions created in 33-64 auxiliary table are not synced to backup.

Configure the two switches as peers to each other. From Switch 1, configureSwitch 2 as a peer and specify its IP address as follows:

>> Main # /cfg/slb/sync (Select the synchronizationmenu)

>> Config Synchronization # peer 1 (Select a peer)

>> Peer Switch 1 # addr <IPaddress>

(Assign switch 2 IP address)

>> Peer Switch 1 # enable (Enable peer switch)

Similarly, from Switch 2, configure Switch 1 as a peer and specify its IPaddress as follows:

>> Main # /cfg/slb/sync (Select the synchronizationmenu)

>> Config Synchronization # peer 2 (Select a peer)

>> Peer Switch 2 # addr <IPaddress>

(Assign switch 1 IP address)


Port specific parameters, such as what filters are applied and enabledon what ports, are part of what is pushed by the /oper/slb/synchcommand. Thus, if the /oper/slb/synch command is used, it is highlyrecommended that the hardware configurations and network connectionsof all switches in the virtual router be identical; that is, each switchshould be the same model, have the same line cards in the same slots(if modular) and have the same ports connected to the same external




.


network devices. Otherwise, unexpected results may occur when the/oper/slb/synch command attempts to configure a non-existent port orapplies an inappropriate configuration to a port.

Synchronizing Active/Active FailoverWith VRRP and active/active failover, the primary and secondary switchesdo not require identical configurations and port topology. Each switch canbe configured individually with different port topology, SLB, and filters. If youwould rather force two active/active switches to use identical settings, youcan synchronize their configuration using the following command:

>> Main # /oper/slb/sync

The sync command copies the following settings to the switch at thespecified IP interface address:

• VRRP settings (including priority)

• SLB settings (including port settings)

• Filter settings (including filter port settings)

• Proxy IP settings

If you perform the sync command, you should check the configuration onthe target switch to ensure that the settings are correct.

Note: When using both VRRP and GSLB, you must change the/cfg/sys/access/wport (Browser-Based Interface port) value of thetarget switch (the switch that is being synchronized to) to a port otherthan port 80 before VRRP synchronization begins.

Stateful Failover of Persistent SessionsNortel Application Switch Operating System provides stateful failover ofpersistent session state. See Chapter 19, "Persistence" for more informationabout the types of persistence supported.

• Client IP

• SSL session state

• HTTP cookie state

• Layer 4 persistent

• FTP session state

• WAP session state

Stateful failover enables network administrators to mirror their Layer 7 andLayer 4 persistent transactional state on the peer switch.




.


Note: Stateful failover is only supported in active-standby modewith VMA enabled. Also, Stateful failover does not synchronize allsessions, except persistent sessions (SSL session ID persistenceand cookie-based persistence). If a service fails in the middle of aconnection, the current session is discarded, but the new connectionbinds the session request correctly to the same real server.

To provide stateful failover, the state of the connection and session tablemust be shared between the switches in high-availability configurations. IfVirtual Matrix Architecture (VMA) is enabled, all URL and cookie-parsinginformation is stored in the session table on the last port number on theswitch. Sharing this information between switches is necessary to ensurethe persistent session goes back to the same server.

Stateful failover only ensures that the client’s request returns to the sameserver based on the persistent session entries being shared by the masterand the slave switch. The TCP session information, however, is not shared.

What Happens When a Switch FailsAssume that the user performing an e-commerce transaction has selecteda number of items and placed them in the shopping cart. The user hasalready established a persistent session on the top server in "StatefulFailover Example when the Master Switch Fails" (page 582). The user thenclicks the Submit button to purchase the items. At this time, the activeswitch fails. With stateful failover, the following sequence of events occurs:

Step Action

1 The backup switch becomes active.

2 The incoming request is redirected to the backup switch.

3 When the user clicks Submit again, the request is forwarded tothe correct server.

Even though the master switch has failed, the stateful failover featureprevents the client from having to re-establish a secure session. Theserver that stores the secure session now returns a response tothe client via the backup switch.




.


Stateful Failover Example when the Master Switch Fails

—End—

Stateful Failover Configuration ExampleAfter the VRRP setup, perform the following additional steps to enablestateful failover on the switches.

On the Master Switch

Step Action

1 Enable stateful failover.

>> Main # /cfg/slb/sync/state ena

2 Set the update interval.

>> Main # /cfg/slb/sync/update10

(The default is 30)

3 Configure the backup switch as a peer and specify its IPaddress.

>> Main # /cfg/slb/sync

>> Config Synchronization #peer 1

(Select a peer)

>> Peer Switch 1 # addr10.1.1.2

(Assign backup switch IPaddress)





.


—End—

On the Backup Switch

Step Action

1 Enable stateful failover.

>> Main # /cfg/slb/sync/state ena

2 Set the update interval.

>> Main # /cfg/slb/sync/update10

(The default is 30)

Note: The update does not have to be the same for bothswitches. Stateful failover supports up to two peer switches.Repeat the steps mentioned above to enable stateful failoveron all the peer switches.

3 Configure the master switch as a peer and specify its IPaddress.

>> Main # /cfg/slb/sync

>> Config Synchronization #peer 2

(Select a peer)

>> Peer Switch 2 # addr10.1.1.1

(Assign master switch IPaddress)


—End—

Viewing Statistics on Persistent Port SessionsYou can view statistics on persistent port sessions using the/stats/slb/ssl command. To determine which switch is the master andwhich is the backup, use the /info/l3/vrrp command. The column onthe far right displays the switch status.

If the switch is a master:




.


>> Main # /info/l3/vrrp (View VRRP Information)

VRRP information:1: vrid 1, 172.21.16.187,if 4, renter, prio

109, master, server3: vrid 3, 192.168.1.30, if 2, renter,

prio 109, master5: vrid 5, 172.21.16.10, if 4, renter,

prio 109, master

If the switch is a backup:

>> Main # /info/l3/vrrp (View VRRP Information)

VRRP information:1: vrid 1, 172.21.16.187,if 1, renter, prio

104, backup, server3: vrid 3, 192.168.1.30, if 3, renter,

prio 104, backup5: vrid 5, 172.21.16.10, if 1, renter,

prio 104, backup

Service-based Session FailoverNortel Application Switch Operating System 24.0 supports the failoverof a session based on a service. The NAAP protocol is used as thecommunication mechanism between the master and backup switches.Since NAAP is a Layer 2 protocol, the switches need to be connecteddirectly over the interswitch link.

"Service-based Session Failover Network Topology" (page 585) illustrates aService-based Session Failover network topology.




.


Service-based Session Failover Network Topology

When a new session is created on the master, the session entry will besent to the backup switch using NAAP. The backup switch will create thesession and set the age to a maximum age. This prevents the session fromaging out on the backup switch and prevents frequent updates between themaster and backup. When the session is updated or deleted on the master,the session on the backup will also be updated or deleted.

This feature can only be supported for group-based VRRP in hot and activestandby configurations.

To support this feature, the following new commands have been added:

Step Action

1 Enable and disable mirroring for a service.

>> Main # /cfg/slb/virt <Virtual Server> /service<Service Number> / mirror {enable|disable}

2 Enable and disable mirroring for a filter.

>> Main # /cfg/slb/filt <Filter Number> /adv/mirror{enable|disable}




.


3 Mirroring statistics.

>> Main # /stats/slb/mirror

—End—

Peer SynchronizationIn situations where a peer device has been created for a switch, thesoftware will prompt for configuration synchronization with that peer beforeany reboot.




.

587

Part 4: Advanced Switching

Nortel Application Switch Operating System can parse requests andclassify flows using URLs, host tags, and cookies so that each request canbe isolated and treated intelligently. This section describes the followingadvanced switching applications:

• "Persistence" (page 588)

• "Advanced Denial of Service Protection" (page 611)

• "Symantec Intelligent Network Protection" (page 651)

• "Firewall Load Balancing" (page 667)

• "Virtual Private Network Load Balancing" (page 708)

• "Global Server Load Balancing" (page 727)

• "Bandwidth Management" (page 769)

• "XML Switch Configuration API" (page 814)




.

588 Part 4: Advanced Switching

Persistence

The Nortel Application Switch Operating Systempersistence feature ensuresthat all connections from a specific client session reach the same realserver, even when Server Load Balancing (SLB) is used.


• "Overview of Persistence" (page 588). This section gives an overview ofpersistence and the different types of persistence methods implementedin Nortel Application Switch Operating System.

• "Cookie-BasedPersistence" (page 591). The use of cookie persistenceprovides a mechanism for inserting a unique key for each client of avirtual server. This feature is only used in non-Secure Sockets Layer(SSL) connections. This section discusses in detail how persistenceis maintained between a client and a real server using different typesof cookies.

• "HTTP and HTTPS Persistence Based on Client IP" (page 590). Thissection explains how both HTTP and HTTPS traffic map to the sameserver based on client IP.

• "Server-Side Multi-Response Cookie Search" (page 604). This sectionexplains how to configure the switch to look through multiple HTTPresponses from the server to achieve cookie-based persistence.

• "SSL Session ID-Based Persistence" (page 605). This section explainshow an application server and client communicate over an encryptedHTTP session.

• "Windows Terminal Server Load Balancing and Persistence" (page 607).This section explains how to configure load balancing and persistencefor Windows Terminal Services.

Overview of PersistenceIn a typical SLB environment, traffic comes from various client networksacross the Internet to the virtual server IP address on the Nortel ApplicationSwitch. The switch then load balances this traffic among the available realservers.

In any authenticated Web-based application, it is necessary to provide apersistent connection between a client and the content server to whichit is connected. Because HTTP does not carry any state information forthese applications, it is important for the browser to be mapped to the samereal server for each HTTP request until the transaction is complete. Thisensures that the client traffic is not load balanced mid-session to a differentreal server, forcing the user to restart the entire transaction.




.

Persistence 589

Persistence-based SLB enables the network administrator to configurethe network to redirect requests from a client to the same real server thatinitially handled the request. Persistenceis an important consideration foradministrators of e-commerce Web sites, wherea server may have dataassociated with a specific user that is not dynamically shared with otherservers at the site.

In Nortel Application Switch Operating System, persistence can be basedon the following characteristics: source IP address, cookies, and SecureSockets Layer (SSL) session ID.

Using Source IP AddressUntil recently, the only way to achieve TCP/IP session persistence wasto use the source IP address as the key identifier. There are two majorconditions which cause problems when session persistence is based on apacket’s IP source address:

• Many clients sharing the same source IP address (proxied clients):Proxied clients appear to the switch as a single source IP address anddo not take advantage of SLB on the switch. When many individualclients behind a firewall use the same proxied source IP address,requests are directed to the same server, without the benefit of loadbalancing the traffic across multiple servers. Persistence is supportedwithout the capability of effectively distributing traffic load.

Also, persistence is broken if you have multiple proxy servers behind theapplication switch performing SLB. The application switch changes theclient’s address to different proxy addresses as attempts are made toload balance client requests.

• Single client sharing a pool of source IP addresses: When individualclients share a pool of source IP addresses, persistence for any givenrequest cannot be assured. Although each source IP address is directedto a specific server, the source IP address itself is randomly selected,thereby making it impossible to predict which server will receive therequest. SLB is supported, but without persistence for any given client.

Using CookiesCookies are strings passed via HTTP from servers to browsers. Based onthe mode of operation, cookies are inserted by either the application switchor the server. After a client receives a cookie, a server can poll that cookiewith a GET command, which allows the querying server to positively identifythe client as the one that received the cookie earlier.

The cookie-based persistence feature solves the proxy server problem andgives better load distribution at the server site. In the application switch,cookies are used to route client traffic back to the same physical server tomaintain session persistence.




.


Using SSL Session IDThe SSL session ID is effective only when the server is running SSLtransactions. Because of the heavy processing load required to maintainSSL connections most network configurations use SSL only when it isnecessary. Persistence based on SSL Session ID ensures completion ofcomplex transactions in proxy server environments. However, this typeof persistence does not scale on servers because of their computationalrequirements.

HTTP and HTTPS Persistence Based on Client IPNortel Application Switch Operating System allows you to use the clientIP address to maintain persistence for both HTTP and HTTPS sessionsonly. The pbind clientip command maintains persistence for thesame service across multiple sessions from the same client, or maintainspersistence between different services (for HTTP and HTTPS traffic only)from the same client to map to the same server, as long as the same groupis configured for both services. In the Nortel Application Switch OperatingSystem, when the metric configured is hash, phash, or minmisses,persistence may also be maintained to the real server port (rport), inaddition to the real server.

When to disable persistence to the RPORTIn cases where two different services, such as TCP and UDP must bothmaintain persistence to the same real server.

Client IP-based persistence is not dependent on the load balancing metric.

Configuring Client IP Address-Based PersistenceTo configure client IP Address-based persistence for a real server, performthe following steps:

Step Action

1 Configure real servers and services for basic SLB, as indicatedbelow:

• Define each real server and assign an IP address to each realserver in the server pool.


• Define a virtual server on the virtual port for HTTP (port 80) andHTTPS (port 443) and assign both services to the same realserver group. HTTP and HTTPS are supported only on theirdefault service port numbers.


• Enable client processing on the port connected to the client.




.

Persistence 591

For information on how to configure your network for SLB, see"Server Load Balancing" (page 188)

2 If a proxy IP address is not configured on the client port, enableDAM for real servers.


3 Select Client IP-based persistence as the persistent bindingoption for the virtual port.

If multiple real server ports are configured for this service, you maychoose whether to maintain persistence to the rport on the realserver.

>> # /cfg/slb/virt 1/service <virtual port> pbindclientIPCurrent persistent binding mode: disabledEnter clientip|cookie|sslid|disable persistencemode: clientIPUse Rport? (y/n) [y]y

4 Enable client processing on the client port.

>> # /cfg/slb/port <port number> /client ena

—End—

Cookie-Based PersistenceCookies are a mechanism for maintaining state between clients andservers. When the server receives a client request, the server issuesa cookie, or token, to the client, which the client then sends to theserver on all subsequent requests. Using cookies, the server does notrequire authentication, the client IP address, or any other time-consumingmechanism to determine that the user is the same user that sent theoriginal request.

In the simplest case, the cookie may be just a "customer ID" assigned tothe user. It may be a token of trust, allowing the user to skip authenticationwhile his or her cookie is valid. It may also be a key that associates the userwith additional state data that is kept on the server, such as a shoppingcart and its contents. In a more complex application, the cookie may beencoded so that it actually contains more data than just a single key or anidentification number. The cookie may contain the user’s preferences fora site that allows their pages to be customized.




.


Cookie-Based Persistence: How It Works

The following topics discussing cookie-based persistence are detailed inthis section:

• "Permanent and Temporary Cookies" (page 592)

• "Cookie Formats" (page 593)

• "Cookie Properties" (page 593)

• "Client Browsers that Do Not Accept Cookies" (page 594)

• "Cookie Modes of Operation" (page 594)

• "Configuring Cookie-Based Persistence" (page 598)

Permanent and Temporary CookiesCookies can either be permanent or temporary. A permanent cookie isstored on the client’s browser, as part of the response from a Web site’sserver. It will be sent by the browser when the client makes subsequentrequests to the same site, even after the browser has been shut down. Atemporary cookie is only valid for the current browser session. Similar to aSSL Session-based ID, the temporary cookie expires when you shut downthe browser. Based on RFC 2109, any cookie without an expiration date isa temporary cookie.




.

Persistence 593

Cookie FormatsA cookie can be defined in the HTTP header (the recommended method) orplaced in the URL for hashing. The cookie is defined as a "Name=Value"pair and can appear along with other parameters and cookies. For example,the cookie "SessionID=1234" can be represented in one of the followingways:

• In the HTTP Header

Cookie: SesssionID=1234Cookie: ASP_SESSIONID=POIUHKJHLKHDCookie: name=john_smith

The second cookie represents an Active Server Page (ASP) session ID.The third cookie represents an application-specific cookie that recordsthe name of the client.

• Within the URL

http://www.mysite.com/reservations/SessionID=1234

Cookie PropertiesCookies are configured on the application switch by defining the followingproperties:

• Cookie names of up to 20 bytes

• The offset of the cookie value within the cookie string

For security, the real cookie value can be embedded somewhere withina longer string. The offset directs the application switch to the startingpoint of the real cookie value within the longer cookie string.

• Length of the cookie value

This defines the number of bytes to extract for the cookie value within alonger cookie string.

• Whether to find the cookie value in the HTTP header (the default) orthe URL

• Cookie values of up to 64 bytes for hashing

Hashing on cookie values is used only with the passive cookie mode("Passive Cookie Mode" (page 596)), using a temporary cookie.The switch mathematically calculates the cookie value using a hashalgorithm to determine which real server should receive the request.

• An asterisk (*) in cookie names for wildcards

For example, Cookie name = ASPsession*




.


Client Browsers that Do Not Accept CookiesUnder normal conditions, most browsers are configured to accept cookies.However, if a client browser is not configured to accept cookies, youmust use hash or pbind clientip (for client IP persistence) as theload-balancing metric to maintain session persistence.

With cookie-based persistence enabled, session persistence for browsersthat do not accept cookies will be based on the source IP address. However,individual client requests coming from a proxy firewall will appear to becoming from the same source IP address. Therefore, the requests will bedirected to a single server, resulting in traffic being concentrated on a singlereal server instead of load balanced across the available real servers.

Cookie Modes of OperationNortel Application Switch Operating System supports the following modesof operation for cookie-based session persistence: insert, passive, andrewrite mode. The following table shows the differences among the modes:

Comparison Among the Three Cookie Modes

Cookie Mode Configuration Required Cookie Location Uses SwitchSession Entry

Insert Cookie Switch only HTTP Header No

Passive Cookie Server and Switch HTTP Header orURL

Yes

Rewrite Cookie Server and Switch HTTP Header No

Insert Cookie ModeIn the insert cookie mode, the application switch generates the cookie valueon behalf of the server. Because no cookies are configured at the server,the need to install cookie server software on each real server is eliminated.

An inserted cookie has a value of 20 bytes, containing an 8 byte VIP value,an 8 byte RIP value, and a 4 byte RPORT value.

In this mode, the client sends a request to visit the Web site. The applicationswitch performs load balancing and selects a real server. The real serverresponds without a cookie. The application switch inserts a cookie andforwards the new request with the cookie to the client.




.

Persistence 595

Insert Cookie Mode

Cookie Insert Mode EnhancementThis mode allows to configure new cookie values, path and secure flag.

Cookie Insert option Currently the configuration options provided are:

• Cookie name - This defaults to "AlteonP".

• Expiry date and time - If configured, client sends cookie only till theexpiration time. Otherwise cookie expires after the current session.

• Domain name

- If configured, cookies are sent only to the domain.

Currently domain can be configured under commands the followingcommands:

>> #/cfg/slb/virt x/dname

>> #/cfg/slb/virt x/service y/hname

Note: Domain name is taken as "<hname>.<dname>". It defaults toNULL string.

CLI Capture When this command is executed: /cfg/slb/virt<virtual#>/service <service#>/pbind , additional inputs takenfrom the user are listed in the table below.




.


>> Virtual Server 10 http Service# /c/sl/vi 10/ser http/pbindCurrent persistent binding mode: disabled

New persistent binding mode: cookie

Enter clientip|cookie|sslid|disable persistencemode: cookie

Enter passive|rewrite|insert cookie persistence mode[p/r/i]: i

Enter Cookie Name [AlteonP]:

Enter insert-cookie expiration as either:...a date <MM/dd/yy[@hh:mm]> (e.g. 12/31/01@23:59)...a duration <days[:hours[:minutes]]> (e.g 45:30:90)...or none <return>

Enter cookie expiration: 0:0:59

Insert cookie domain name? (y/n) [n]yes

Enter path: "/test/test.html" --------------- NEW

Is cookie secure[y/n] [n]yes --------------- NEW

Passive Cookie ModeIn Passive Cookie mode, when the client first makes a request, the switchselects the server based on the configured load-balancing metric. The realserver embeds a cookie in its response to the client. The switch records thecookie value and matches it in subsequent requests from the same client.

Note: The passive cookie mode is recommended for temporarycookies. However, you can use this mode for permanent cookies if theserver is embedding an IP address. In this case, a cookie has to be 8characters long and every 2 characters represent 1 byte of IP addressencoded in hexadecimal.

The following figure shows passive cookie mode operation:




.

Persistence 597

Passive Cookie Mode

Subsequent requests from Client 1 with the same cookie value will be sentto the same real server (RIP 1 in this example).

Proxy support for Passive Cookie When passive cookie persistencemode is enabled, switch creates persistent entries for server returnedresponses with new cookie values, within the same TCP connection.

Rewrite Cookie ModeIn rewrite cookie mode, the application switch generates the cookie valueon behalf of the server, eliminating the need for the server to generatecookies for each client.

Instead, the server is configured to return a special persistence cookiewhich the switch is configured to recognize. The switch then interceptsthis persistence cookie and rewrites the value to include server-specificinformation before sending it on to the client. Subsequent requests from thesame client with the same cookie value are sent to the same real server.

Rewrite cookie mode requires at least eight bytes in the cookie header.An additional eight bytes must be reserved if you are using cookie-basedpersistence with Global Server Load Balancing (GSLB).

Note: Rewrite cookie mode only works for cookies defined in the HTTPheader, not cookies defined in the URL.

Example: The following figure shows rewrite cookie mode operation:




.


Rewrite Cookie Mode

Note: When the application switch rewrites the value of the cookie, therewritten value represents the responding server; that is, the value canbe used for hashing into a real server ID or it can be the real server IPaddress. The rewritten cookie value is encoded.

Configuring Cookie-Based Persistence

Step Action

1 Before you can configure cookie-based persistence, youneed to configure the switch for basic SLB. This includes thefollowing tasks:



• Configure each real server with its IP address, name, weight,and so forth.



For information see "Server Load Balancing" (page 188).

2 Either enable Direct Access Mode (DAM), or disable DAM andspecify proxy IP address(es) on the client port(s).

• Enable DAM for the switch.

>> # /cfg/slb/adv/direct ena (Enable Direct AccessMode on switch)




.

Persistence 599

• Disable DAM and specify proxy IP address(es) on the clientport(s).

>> # /cfg/slb/adv/directdisable

(Disable DAM on the switch)

>> # /cfg/slb/port 1 (Select network port 1)

>> # pip 200.200.200.68 (Set proxy IP address for port1)

Note: If Virtual Matrix Architecture (VMA) is enabled on theswitch, you must configure a unique proxy IP address forevery port (except port 9).

3 If proxy IP addresses are used, make sure server processing isdisabled on the server port.

>> # /cfg/slb/port 1 (Select switch port 1)

>> # server dis (Disable server processing on port 1)

4 Select the appropriate load-balancing metric for the real servergroup.

>> # /cfg/slb/group 2/metrichash

(Select hash as servergroup metric)

• If embedding an IP address in the cookie, select roundrobin orleastconns as the metric.

• If you are not embedding the IP address in the cookie, selecthash as the metric in conjunction with a cookie assignmentserver.

While you may experience traffic concentration using thehash metric with a cookie assignment server, using a hashmetric without a cookie assignment server will cause trafficconcentration on your real servers.

5 Enable cookie-based persistence on the virtual server service.

In this example, cookie-based persistence is enabled for service80 (HTTP).

>> # /cfg/slb/virt 1/service 80/pbindCurrent persistent binding mode: disabledEnter clientip|cookie|sslid|disable persistence mode:cookie




.


Once you specify cookie as the mode of persistence, you will beprompted for the following parameters:

Enter insert|passive|rewrite cookie persistence mode[i/p/r]: pEnter cookie name: CookieSession1Enter starting point of cookie value [1-64]: 1Enter number of bytes to extract [0-64]: 8Look for cookie in URI [e|d]: d

• Cookie-based persistence mode: insert, passive orrewrite

• Cookie name

• Starting point of the cookie value

• Number of bytes to be extracted

• Look for cookie in the URI [e | d]

If you want to look for cookie name/value pair in the URI, enter eto enable this option. To look for the cookie in the HTTP header,enter d to disable this option.

—End—

Setting Expiration Timer for Insert CookieIf you configure for insert cookie persistence mode, then you will beprompted for cookie expiration timer. The expiration timer specifies a datestring that defines the valid life time of that cookie. The expiration timer forinsert cookie can be of the following types:

• Absolute timer

The syntax for the absolute timer is MM/dd/yy[@hh:mm]. The date andtime is based on RFC 822, RFC 850, RFC 1036, and RFC 1123, withthe variations that the only legal time zone is GMT. Once the expirationdate is met, the cookie is not stored or given out. For example,

Enter cookie expiration: 12/31/04@11:59Current persistent binding for http: disabledNew persistent binding for http: cookieNew cookie persistence mode: insertInserted cookie expires on Mon 12/31/04 at 11:59

• Relative timer




.

Persistence 601

This timer defines the elapsed time from when the cookie was created.The syntax for the relative timer is days[:hours[:minutes]]. For example,

Enter cookie expiration: 32:25:61Current persistent binding for http: disabledNew persistent binding for http: cookieNew cookie persistence mode: insertInserted cookie expires after 33 days 2 hours 1 minutes

The switch adds or subtracts hours according to the time zone settingsin /cfg/sys/ntp/tzone. When relative expiration timer is used,make sure the tzone setting is set correctly. If NTP is disabled(/cfg/sys/ntp/off), the tzone setting will still apply to the cookiemode.

Note: If the cookie expiration timer is not specified, the cookie willexpire when the user’s session ends.

New Configuration options The new configuration options provided are:

• Cookie path

- If configured, cookie is sent only for URL requests which are subset ofthe path, path defaults to "/".

• Secure flag

- If secure flag is set, client is required to use secure connection toobtain content associated with the cookie.

Example 1: Setting the Cookie LocationIn this example, the client request has two different cookies labeled "UID."One exists in the HTTP header and the other appears in the URI:

GET /product/switch/UID=12345678;ck=1234...Host: http://www.nortel.com/Cookie: UID=87654321

• Look for the cookie in the HTTP header

>> # /cfg/slb/virt 1/service 80/pbind cookie passive UID1 8 dis

The last parameter in this command answers the "Look for cookiein URI?" prompt. If you set this parameter to disable, the applicationswitch will use UID=87654321 as the cookie.

• Look for the cookie in the URI

>> # /cfg/slb/virt 1/service 80/pbind cookie passive UID1 8 ena




.



The last "Look for cookie in URI?" parameter is set to enable. Thereforethe application switch will use UID=12345678 as the cookie.

Example 2: Parsing the CookieThis example shows three configurations where the switch uses the hashingkey or wild cards to determine which part of the cookie value should beused for determining the real server. For example, the value of the cookieis defined as follows:

Cookie: sid=0123456789abcdef; name1=value1;...

• Select the entire value of the sid cookie as a hashing key for selectingthe real server:

>> # /cfg/slb/virt 1/service 80/pbind cookie passive sid1 16 dis

This command directs the switch to use the sid cookie, starting with thefirst byte in the value and using the full 16 bytes.

• Select a specific portion of the sid cookie as a hashing key for selectingthe real server:


This command directs the switch to use the sid cookie, starting with theeight byte in the value and using only four bytes. This uses 789a asa hashing key.

• Using wildcards for selecting cookie names:

>> #/cfg/slb/virt 1/service 80/pbind cookie passiveASPSESSIONID* 1 16 dis

With this configuration, the switch will look for a cookie name that startswith ASPSESSIONID. ASPSESSIONID123, ASPSESSIONID456, andASPSESSIONID789 will all be seen by the switch as the same cookiename. If more than one cookie matches, only the first one will be used.

Example 3: Using Passive Cookie ModeIf you are using passive cookie mode, the application switch examines theserver’s Set-Cookie: value and directs all subsequent connections tothe server that assigned the cookie.

For example, if Server 1 sets the cookie as "Set-Cookie: sid=12345678,"then all traffic from a particular client with cookie sid=12345678 will bedirected to Server 1.




.

Persistence 603

The following command is used on the application switch:


Example 4: Using Rewrite Cookie Mode

• Rewrite server cookie with the encrypted real server IP address:

In cookie rewrite mode, if the cookie length parameter is configured tobe eight bytes, the switch will rewrite the placeholder cookie value withthe encrypted real server IP address.

>> # /cfg/slb/virt 1/service 80/pbind cookie rewrite sid1 8 dis

If the server is configured to include a placeholder cookie, such asfollows:

Set-Cookie: sid=alteonpersistence;

then the application switch will rewrite the first eight bytes of the cookieto include the server’s encrypted IP address:

Set-Cookie: sid=alteonpersistence;

All subsequent traffic from a specific client with this cookie will bedirected to the same real server.

• Rewrite server cookie with the encrypted real server IP address andvirtual server IP address:

If the cookie length is configured to be 16 bytes, the switch will rewritethe cookie value with the encrypted real server IP address and virtualserver IP address.

>> # /cfg/slb/virt 1/service 80/pbind cookie rewrite sid1 16 dis

If the server is configured to include a placeholder cookie, as follows:

Set-Cookie: sid=alteonwebcookies;

then the application switch will rewrite the first 16 bytes of the cookieto include the encrypted real server IP address and virtual server IPaddress:




.


Set-Cookie: sid=cdb20f04cdb20f0a;

All subsequent traffic from a specific client to the particular virtual serverIP address with this cookie will be directed to the same real server.

Server-Side Multi-Response Cookie SearchCookie-based persistence requires the switch to search the HTTP responsepacket from the server and, if a persistence cookie is found, sets up apersistence connection between the server and the client. The NortelApplication Switch looks through the first HTTP response from the server.While this approach works for most servers, some customers with complexserver configurations might send the persistence cookie a few responseslater. In order to achieve cookie-based persistence in such cases, NortelApplication Switch Operating System allows the network administrator toconfigure the switch to search through multiple HTTP responses from theserver.

In Nortel Application Switch Operating System, the network administratorcan modify a response counter to a value from 1-16. The switch will look forthe persistence cookie in this number of responses (each of them can bemulti-frame) from the server.

Configuring Server-Side Multi-Response Cookie SearchConfigure the server-side multi-response cookie search by using thefollowing command:

>> # /cfg/slb/virt <virtual server> /service <virtual portnumber> /rcountCurrent Cookie search response count:Enter new Cookie search response count [1-16]:

Proxy Support for Insert CookieWhen the insert cookie persistence mode is enabled, the switch will parsethrough every HTTP requests within the same TCP connection to look forthe configured cookie name to use for persistency. If the client requestarrives without a cookie, then the request will be forwarded to the existingbinded server. When cookie insert persistence mode is enabled, the switchneeds to insert a cookie in the server returned response for those clientrequests without a cookie.

If the client request arrives with a cookie, then the cookie is used to checkagainst the persistence binding table.




.

Persistence 605

SSL Session ID-Based PersistenceSSL is a set of protocols built on top of TCP/IP that allows an applicationserver and client to communicate over an encrypted HTTP session,providing authentication, non-repudiation, and security. The SSL protocolhandshake is performed using clear (unencrypted) text. The content datais then encrypted (using an algorithm exchanged during the handshake)prior to being transmitted.

Using the SSL session ID, the switch forwards the client request to thesame real server to which it was bound during the last session. BecauseSSL protocol allows many TCP connections to use the same session IDfrom the same client to a server, key exchange needs to be done onlywhen the session ID expires. This reduces server overhead and provides amechanism, even when the client IP address changes, to send all sessionsto the same real server.

Note: The SSL session ID can only be read by the switch after the TCPthree-way handshake. In order to make a forwarding decision, the switchmust terminate the TCP connection to examine the request.

Some versions of Web browsers allow the session ID to expire every 2minutes, thereby breaking the SSL ID persistence. To resolve this issue,use persistency with metric hash or pbind clientip.

Note: The destination port number to monitor for SSL traffic isuser-configurable.

How SSL Session ID-Based Persistence Works

• All SSL sessions that present the same session ID (32 random byteschosen by the SSL server) will be directed to the same real server.

• New sessions are sent to the real server based on the metric selected(hash, roundrobin, leastconns, minmisses, response, and bandwidth).

• If no session ID is presented by the client, the switch picks a real serverbased on the metric for the real server group and waits until a connectionis established with the real server and a session ID is received.

• The session ID is stored in a session hash table. Subsequentconnections with the same session ID are sent to the same real server.This binding is preserved even if the server changes the session IDmid-stream. A change of session ID in the SSL protocol will cause afull three-way handshake to occur.

• Session IDs are kept on the switch until an idle time equal to theconfigured server time-out (a default of 10 minutes) for the selected realserver has expired.




.


"SSL Session ID-Based Persistence" (page 606) illustrates persistencebased on SSL session ID as follows:

Step Action

1 An SSL Hello handshake occurs between Client 1 and Server1 via the application switch.

2 An SSL session ID is assigned to Client 1 by Server 1.

3 The application switch records the SSL session ID.

4 The application switch selects a real server based on theexisting SLB settings.

As a result, subsequent connections from Client 1 with the sameSSL session ID are directed to Server 1.

SSL Session ID-Based Persistence

5 Client 2 appears to the switch to have the same source IPaddress as Client 1 because they share the same proxy firewall.

However, the application switch does not automatically direct Client2 traffic to Server 1 based on the source IP address. Instead an SSLsession ID for the new traffic is assigned. Based on SLB settings,the connection from Client 2 is spliced to Server 3.

As a result, subsequent connections from Client 2 with the sameSSL session ID are directed to Server 3.

—End—




.

Persistence 607

Configuring SSL Session ID-Based PersistenceTo configure session ID-based persistence for a real server, perform thefollowing steps:

Step Action

1 Configure real servers and services for basic SLB, as indicatedbelow:

• Define each real server and assign an IP address to each realserver in the server pool.


• Define a virtual server on the virtual port for HTTPS (for example,port 443) and assign a real server group to service it.


• Enable client processing on the port connected to the client.


2 If a proxy IP address is not configured on the client port, enableDAM for real servers.


3 Select session ID-based persistence as the persistent bindingoption for the virtual port.

>> # /cfg/slb/virt <virtual server number> /service<virtual port> pbind sslid

4 Enable client processing on the client port.

>> # /cfg/slb/port <port number> /client ena

—End—

Windows Terminal Server Load Balancing and PersistenceWindows Terminal Services refer to a set of technologies that allowWindows users to run Windows-based applications remotely on a computerrunning as the Windows Terminal Server. The Nortel Application SwitchOperating System includes load balancing and persistence options aimedspecifically at Windows Terminal Services.




.


In a load-balanced environment, a group of terminal servers have incomingsession connections distributed in a balanced manner across the serversin the group. The Windows session director is used to keeping a list ofsessions indexed by user name. This allows a user to reconnect to adisconnected user session.

The session director provides functionality that allows a group of terminalservers to coordinate the reconnection of disconnected sessions. Thesession director is updated and queried by the terminal servers wheneverusers log on, log off, or disconnect their sessions while leaving theirapplications active.

Client can be reconnected to the terminal server where the user’sdisconnected session resides using the routing token information. Thesession director passes the routing token information to the client withthe correct server IP address embedded. The client presents this routingtoken to the load balancer when it reconnects to the virtual IP address.The load balancer will decipher the token and send the client to the correctterminal server.

In some instances a dedicated session director may not exist. If this isthe case, enable the userhash functionality to perform the terminal serverbinding operation based on user name hashing.

By default, Windows Terminal Server traffic uses TCP port 3389 but it canconfigured to work on any non-standard port.

For further information regarding Windows Terminal Services, refer to theMicrosoft website.

The following illustration demonstrates a sample Windows Terminal ServerLoad Balancing network topology.




.

Persistence 609

Windows Terminal Server Load Balancing Network Topology

Configuring Windows Terminal Server Load Balancing andPersistence

Note: When using Windows Terminal Server Load Balancing andPersistence, ensure that either DMA is enabled or a proxy IP addresshas been configured.

To configure this feature, follow this procedure:




.


Step Action

1 Access the Windows Terminal Server menu.

>> Main# /cfg/slb/virt <virtual server number>/service 3389/wts

2 Enable the Windows Terminal Server feature.

>> WTS Load Balancing# ena

3 (Optional) Enable the WTS userhash.

If the dedicated session director does not exist to relate users todisconnected sessions, it is advised that the userhash functionalitybe enabled to perform this task.

>> WTS Load Balancing# userhash enable

—End—




.

Advanced Denial of Service Protection 611

Advanced Denial of Service Protection

This chapter describes the Advanced Denial of Service protection featuresin Nortel Application Switch Operating System that can be used to prevent awide range of network attacks. The features described in this chapter arelocated within the new security menu commands, and are enabled via aseparately purchased license key.

Note: If you purchased the advanced Denial of Service protectionoption, make sure you enable it by typing /oper/swkey and enteringits software key.

• "Background" (page 611) describes the rationale for providing AdvancedDenial of Service protection and how the features can assist traditionalfirewalls in preventing malicious network attacks.

• "IP Address Access Control Lists" (page 612). Describes how to setupblocking of large ranges of IP addresses.

• "Protection Against Common Denial of Service Attacks" (page 615): Thissection explains how to prevent common denial of service (DOS) attacksfrom entering switch ports that are connected to unsafe networks.

• "Protocol-BasedRate Limiting" (page 628): This section explainshow to monitor and limit incoming UDP, ICMP or TCP traffic within aconfigurable time window.

• "Protection Against UDP Blast Attacks" (page 635). This sectiondescribes how to monitor and limit traffic on UDP ports to a maximumnumber of connections per second.

• "TCP or UDP Pattern Matching" (page 636). This section describeshow to match on binary or ascii patterns embedded in IP packets, andcombine them into pattern groups which can be applied to a filter todeny traffic containing those patterns.

BackgroundThe Advanced Denial of Service Protection feature set extendsthe functionality of the Nortel Application Switch to act as anapplication-intelligent firewall. An administrator can use the featuresdescribed in this chapter to configure the Nortel Application Switch toperform deep inspection and blocking of malicious content. For example,many newer viruses, worms, malicious code, buggy applications, andcyber-attacks have targeted application and protocol weaknesses bytunneling through the firewall over HTTP port 80, or by encapsulatingattacks into SSL tunnels. Such packets can pass undetected throughstandard network firewalls, which are configured only to open or close




.


access to HTTP port 80. Many of the attacks (such as nullscan, xmascan,scan SYNFIN) are created with purposely malformed packets that includeillegal fields in the IP headers.

Security Inspection WorkflowA typical workflow of the application switch to handle security inspection isdescribed below.

1. The Nortel Application Switch is configured with a predefined setof rules. To increase the performance of the inspection, complexpattern inspection rules can be defined with an offset value so that theinspection engine can go directly to the location to be inspected. A viruspattern often is a combination of multiple patterns within the IP payload.The application switch can be configured to inspect multiple patternsand locate them at different offsets within the payload.

2. Packets enter the Nortel Application Switch.

3. The Nortel Application Switch inspects the packet by comparing therules to the content of the packet.

4. When an attack pattern is matched, the application switch drops thispacket, and creates a session in the switch so that subsequent packetsof the same session (if it is TCP) will be also dropped without goingthrough additional rule inspection.

Other Types of Security InspectionThe Nortel Application Switch can use its inspection engine to provide ratelimiting capability to complex protocols such as those used in the Peer toPeer programs that use dynamic ports to establish communication betweenclients. Standard firewalls are unable to detect these programs, becausethe protocol signatures do not appear at the Layer 4 port level. Many ofthese protocols have signatures that are embedded in the HTTP header orin some cases, embedded in the data payload itself. Fore more information,see "TCP or UDP Pattern Matching" (page 636).

The Nortel Application Switch can also rate limit the amount of the totaltraffic generated by these programs. This is especially useful in Cable ISPand universities where Peer to Peer programs can reach as much as 70% ofthe total traffic. For more information, see "Protocol-BasedRate Limiting"(page 628).

IP Address Access Control ListsNortel Application Switch Operating System can be configured with IPaccess control lists (ACLs) composed of ranges of client IP addresses thatare to be denied access to the switch. When traffic ingresses the switch,the client source or destination IP address is checked against this pool ofaddresses. If a match is found, then the client traffic is blocked.




.


ACLs vs. FiltersAccess control lists (ACLs) are used to control which IP addresses areallowed access to a network. Unlike a filter, the ACL feature in NortelApplication Switch Operating System can only perform a deny action. Thedecision about whether to deny traffic is based solely on whether or not amatch is found between the client IP and the ACL. The IP access control list(ipacl) commands can be used to configure a pool of up to 8192 blockableIP addresses (5120 configured source IP addresses, 1024 configureddestination IP addresses, 1024 operationally added source IP addresses,and 1024 operationally added destination IP addresses).

While filters can perform the same function by blocking IP addressesranges, they contain more information besides source IP address whichalso must be matched on ingress traffic before determining whether toallow, deny, or redirect traffic.

How it worksThe IP ACL feature uses a hash table to effectively block a configured rangeof IP addresses. The access control list is a global list which is by defaultdisabled on the switch; and then enabled on a per-port basis.

When a packet ingresses a port that has been enabled with IP accesscontrol list processing, the switch compares the client source or destinationIP address with internal hash tables containing the IP addresses. If a matchis found, the packet is dropped. If no match on the address is found in anyof the hash tables, the packet is allowed to pass.

Configuring Blocking with IP Access Control Lists

Step Action

1 Add IP addresses that you wish to block.

• The following example will block source addresses192.168.40.0-255.

>> Main # /cfg/security/ipacl (Select the IP ACL menu)

>> IP ACL# add 192.168.40.0 (Enter a network address)

Enter IP subnet mask [default is 255.255.255.255]:255.255.255.0 (Enter the appropriate mask)

• The following example will block destination addresses192.180.11.0-255:




.


>> Main# /cfg/security/ipacl (Select the IP ACL menu)

>> IP ACL# dadd 192.180.11.0 (Enter a network address)

Enter IP subnet mask [default is 255.255.255.255]:255.255.255.0 (Enter the appropriate mask)

2 Repeat step 1 to configure any other IP addresses that shouldbe dropped.

3 Enable IP ACL processing on the ingress port.

>> Main# /cfg/security/port <x> /ipacl ena (Enable IP ACL)Current IP ACL processing: disabledNew IP ACL processing: enabled


—End—

Viewing IP ACL statisticsYou can view the accumulated blocked packets for each IP address /maskpair by entering the following command:

>> /stats/security/ipacl/dump (Dump IP ACL statistics)

Address---------------192.168.40.1192.168.40.12192.168.40.65

Blocked Packets---------------

30499702563

Bogon ListThe Nortel Application Switch Operating System supports the importationand use of a Bogon list. A bogon list specifies a listing of source IPaddresses that are not currently in use or valid and therefore should beblocked. This is a useful tool in filtering out packets that would otherwise notbe caught by other means.

Bogon lists will be imported through the Nortel Application Switch ElementManager 4.0 although usage statistics can be viewed through either theNortel ASEM application or the CLI. To view the number of bogon liststhrough the CLI, use the following command:

>> Main# /cfg/security/ipacl/bogon

To enable Bogon processing on an ingress port, use the following command:




.


>> Main# /cfg/security/port <port number> /bogon ena

Protection Against Common Denial of Service AttacksNortel Application Switch Operating System can protect switch portsagainst a variety ofDenial of Service (DOS) attacks including Port Smurf,LandAttack, Fraggle, Blat, Nullscan, Xmascan, PortZero, andScan SynFinamong many others. Enable DOS protection on any ports connected tounsafe networks.

Configuring Ports with DoS ProtectionEnable DoS protection on any switch port that is connected to an unsafenetwork. Once enabled, this feature will automatically detect and droppackets containing any of the supported types of DoS attack.

Step Action

1 Enable DoS protection on the ports.

>> Main# /cfg/security/port1/dos enable

(Enable DOS protection onthis port)

Current Protocol anomaly and DoS attackprevention: disabledNew Protocol anomaly and DoS attackprevention: enabled

2 Add a DoS attack type to guard against.

>> Main# /cfg/security/port 1/dos/add <DoS attacktype>

Note: To determine which DoS attack types a port is guardingagainst, view the current settings by using the command/cfg/security/port <port number>/cur.

3 (Optional) To remove a DoS attack type from a port, use thefollowing command.

>> Main# /cfg/security/port 1/dos/rem <DoS attacktype>

4 Repeat steps 1 and 2 to apply DoS protection to any other ports.


—End—




.


Viewing DOS statisticsYou can view the number of times packets were dropped when a DOSattack was detected on the switch or on a specific port.

When an attack is detected, the switch will generate a message such as:

Jun 18 22:33:32 ALERT security: DoS Attack:Fragglesip:192.115.106.200 dip:192.115.106.255 ingress port:1

The following command shows DOS statistics on all ports where DOSprotection is enabled:

>> /stats/security/dos/dump------------------------------------------------------------Protocol anomaly and DoS attack preventionstatistics for port 1:------------------------------------------------------------Protocol anomaly and DoS attack preventionstatistics for port 8:broadcast : 1loopback : 8land : 1ipttl : 1ipprot : 1fragmoredont: 1fragdata : 2fragboundary: 2fraglast : 1fragdontoff : 1fragoff : 1fragoversize: 1tcplen : 4tcpportzero : 2blat : 1nullscan : 1fullxmasscan: 1finscan : 1vecnascan : 5xmasscan : 1synfinscan : 1synfrag : 1ftpport : 1dnsport : 1seqzero : 1ackzero : 1udplen : 2udpportzero : 2




.


fraggle : 1snmpnull : 1icmplen : 2smurf : 1icmpdata : 1igmplen : 2igmpfrag : 1arpnbcast : 21------Totals : 77

Specific subtotals are given for only those ports that are seeing attack traffic.

Viewing DOS statistics per portThe following command displays DOS protection statistics only on thespecified port:

>> /stats/security/dos/port 8>> Main# /st/sec/dos/port 8------------------------------------------------------------Protocol anomaly and DoS attack preventionstatistics for port 8:broadcast : 1loopback : 8land : 1ipttl : 1ipprot : 1fragmoredont: 1fragdata : 2fragboundary: 2fraglast : 1fragdontoff : 1fragoff : 1fragoversize: 1tcplen : 4tcpportzero : 2blat : 1nullscan : 1fullxmasscan: 1finscan : 1vecnascan : 5xmasscan : 1synfinscan : 1synfrag : 1ftpport : 1dnsport : 1seqzero : 1ackzero : 1udplen : 2




.


udpportzero : 2fraggle : 1snmpnull : 1icmplen : 2smurf : 1icmpdata : 1igmplen : 2igmpfrag : 1arpnbcast : 21------Totals : 77

Understanding the types of DOS attacksYou can use the help command to obtain a brief explanation of each typeof DOS attack detected by the switch.

>> /stats/security/dos/help

Once DOS protection is enabled on the appropriate ports on the NortelApplication Switch, the switch performs the following checks on incomingpackets.

IPLen:

• Description: An IPv4 packet is sent with an invalid payload or IP headerlength.

• Switch action: The switch checks for malformed packets that have eitheran IP header length less than 20 bytes, an IP total packet length lessthan the IP header length, or an actual packet length less than the IPtotal length and drops any matching packets.

IPVersion:

• Description: An IPv4 packet is sent with an invalid IP version.

• Switch action: The switch checks for IPv4 packets marked with a versionother than 4 and drops any matching packets.

Broadcast:

• Description: An IPv4 packet with a broadcast source or destination IPaddress.

• Switch action: The switch checks for IPv4 packets with a broadcastsource or destination IP address (0.0.0.0,255.255.255.255) and dropsany matching packets.




.


LoopBack:

• Description: An IPv4 packet with a loopback source or destination IPaddress.

• Switch action: The switch checks for IPv4 packets with a loopbacksource or destination IP address (127.0.0.0/8) and drops any matchingpackets.

LandAttack:

• Description: Packets with source IP (sip) equal to destination IP (dip)address.

• Switch action: The switch checks for sip=dip in the packet and dropany matching packets.

IPReserved:

• Description: An IPv4 packet with the reserved IP bit set.

• Switch action: The switch checks for IPv4 packets with the reserved IPbit set and drops any matching packets.

IPTTL:

• Description: An IPv4 packet with a small IP TTL.

• Switch action: The switch checks for IPv4 packets with a small IP TTLand drops any matching packets.

IPProt:

• Description: An IPv4 packet with an unassigned or reserved IP protocol.

• Switch action: The switch checks for IPv4 packets with an unassignedor reserved IP protocol and drops any matching packets.

IPOptLen:

• Description: An IPv4 packet with an invalid IP options length.

• Switch action: The switch checks for IPv4 packets with an invalid IPoptions length set and drops any matching packets.

FragMoreDont:

• Description: An IPv4 packet with the more fragments and don’t fragmentbits set.

• Switch action: The switch checks for IPv4 packets with both the morefragments and don’t fragments bits set and drops any matching packets.




.


FragData:

• Description: An IPv4 packet with the more fragments bit set but a smallpayload.

• Switch action: The switch checks for IPv4 packets with the morefragments bit set but exhibiting a small payload and drops any matchingpackets.

FragBoundary:

• Description: An IPv4 packet with the more fragments bit set but apayload not at an 8-byte boundary.

• Switch action: The switch checks for IPv4 packets with the morefragments bit set but whose payload is not at an 8-byte boundary anddrops any matching packets.

FragLast:

• Description: An IPv4 packet that is the last fragment but no payload.

• Switch action: The switch checks for IPv4 packets with the last fragmentbit set but no payload and drops any matching packets.

FragDontOff:

• Description: An IPv4 packet with a non-zero fragment offset and thedon’t fragment bits set.

• Switch action: The switch checks for IPv4 packets with a non-zerofragment offset and the don’t fragment bits set and drops any matchingpackets.

FragOpt:

• Description: An IPv4 packet with a non-zero fragment offset and IPoptions bits set.

• Switch action: The switch checks for IPv4 packets with a non-zerofragment offset and the IP options bits set and drops any matchingpackets.

FragOff:

• Description: An IPv4 packet with a small non-zero fragment offset.

• Switch action: The switch checks for IPv4 packets with a small non-zerofragment offset and drops any matching packets.




.


FragOverSize:

• Description: An IPv4 packet with a non-zero fragment offset and anoversized payload.

• Switch action: The switch checks for IPv4 packets with a non-zerofragment offset and an oversized payload and drops any matchingpackets.

TCPLen:

• Description: A TCP packet with a TCP header length less than 20 bytesand an IP data length less than the TCP header length.

• Switch action: The switch checks for TCP packets with a TCP headerlength less than 20 bytes and an IP data length less than the TCPheader length and drops any matching packets.

TCPPortZero:

• Description: A TCP packet with a source or destination port of zero.

• Switch action: The switch checks for TCP packets with a source ordestination port of zero and drops any matching packets.

TCPReserved:

• Description: A TCP packet with the TCP reserved bit set.

• Switch action: The switch checks for TCP packets with the TCPreserved bit set and drops any matching packets.

NULLscan:

• Description: A TCP packet with a sequence number of zero or all of thecontrol bits are set to zero.

• Switch action: The switch checks for TCP packets with a sequencenumber or zero or with all control bits set to zero and drops any matchingpackets.

FullXmasScan:

• Description: A TCP packet with all control bits set.

• Switch action: The switch checks for TCP packets with all of the controlbits set and drops any matching packets.

FinScan:

• Description: A TCP packet with only the FIN bit set.

• Switch action: The switch checks for TCP packets with only the FIN bitset and drops any matching packets.




.


VecnaScan:

• Description: A TCP packet with only the URG, PUSH, URG|FIN,PSH|FIN, or URG|PSH bits set.

• Switch action: The switch checks for TCP packets with only the URG,PUSH, URG|FIN, PSH|FIN, or URG|PSH bits set and drops anymatching packets.

Xmascan:

• Description: Sequence number is zero and the FIN, URG, and PSHbits are set.

• Switch action: The switch checks for any TCP packets where thesequence number is zero and the FIN, URG, and PSH bits are set anddrops any matching packets.

SYNFIN Scan:

• Description: SYN and FIN bits set in the packet.

• Switch action: The switch checks for TCP packets with the SYN and FINbits set and drops any matching packets.

FlagAbnormal:

• Description: A TCP packet with an abnormal control bit combination set.

• Switch action: The switch checks for an abnormal control bit combinationand drops any matching packets.

SynData:

• Description: A TCP packet with the SYN bit set and that also has apayload.

• Switch action: The switch checks for TCP packets with the SYN bit setand that also has a payload and drops any matching packets.

SynFrag:

• Description: A TCP packet with the SYN and more fragments bits set.

• Switch action: The switch checks for TCP packets with the SYN andmore fragments bits set and drops any matching packets.

FTPPort:

• Description: A TCP packet with a source port of 20, a destination port ofless than 1024 and the SYN bit set.




.


• Switch action: The switch checks for TCP packets with a source port of20, a destination port of less than 1024 and the SYN bit set and dropsany matching packets.

DNSPort:

• Description: A TCP packet with a source port of 53, a destination port ofless than 1024 and the SYN bit set.

• Switch action: The switch checks for TCP packets with a source port of53, a destination port of less than 1024 and the SYN bit set and dropsany matching packets.

SeqZero:

• Description: A TCP packet with a sequence number of zero.

• Switch action: The switch checks for TCP packets with a sequencenumber of zero and drops any matching packets.

AckZero:

• Description: A TCP packet with an acknowledgement number of zeroand the ACK bit set.

• Switch action: The switch checks for TCP packets with anacknowledgement number of zero and the ACK bit set and drops anymatching packets.

TCPOptLen:

• Description: A TCP packet with a TCP options length of less than two orwhere the TCP options length is greater than the TCP header length.

• Switch action: The switch checks for TCP packets with a TCP optionslength of less than two or where the TCP options length is greater thanthe TCP header length and drops any matching packets.

UDPLen:

• Description: An UDP packet with a UDP header length of less than 8bytes or where the IP data length is less than the UDP header length.

• Switch action: The switch checks for UDP packets with a UDP headerlength of less than 8 bytes or where the IP data length is less than theUDP header length and drops any matching packets.

UDPPortZero:

• Description: An UDP packet with a source or destination port of zero.

• Switch action: The switch checks for UDP packets with a source ordestination port of zero and drops any matching packets.




.


Fraggle:

• Description: Similar to a smurf attack, attacks are directed to a broadcastaddress, except that the packets sent are UDP, not ICMP.

• Switch action: Deny all the UDP packets with destination address set toa broadcast address.

• User action: Configure "UDP and ICMP Rate Limiting" (page 629).

Pepsi:

• Description: An UDP packet with a source port of 19 and destinationport of 7 or vice versa.

• Switch action: The switch checks for UDP packets with a source portof 19 and destination port of 7 or vice versa and drops any matchingpackets.

RC8:

• Description: An UDP packet with a source and destination port of 7.

• Switch action: The switch checks for UDP packets with a source anddestination port of 7 and drops any matching packets.

SNMPNull:

• Description: An UDP packet with a destination port of 161 and nopayload.

• Switch action: The switch checks for UDP packets with a destinationport of 161 and no payload and drops any matching packets.

ICMPLen:

• Description: An ICMP packet with an improper ICMP header length.

• Switch action: The switch checks for ICMP packets with an improperICMP header length and drops any matching packets.

Smurf:

• Description: The attacker sends ICMP ping requests to multiplebroadcast destination IP (x.x.x.255). The packet contains spoofedsource IP of the victim.

• Switch action: Check every packet for destination IP set to a broadcastaddress in a filter, and drop any matching packet.

ICMPData:

• Description: An ICMP packet with a zero fragment offset and a largepayload.




.


• Switch action: The switch checks for ICMP packets with a zero fragmentoffset and a large payload and drops any matching packets.

ICMPOff:

• Description: An ICMP packet with a large fragment offset.

• Switch action: The switch checks for ICMP packets with a large fragmentoffset and drops any matching packets.

ICMPType:

• Description: An ICMP packet where the type is unassigned or reserved.

• Switch action: The switch checks for ICMP packets where the type isunassigned or reserved and drops any matching packets.

IGMPLen:

• Description: An IGMP packet with an improper IGMP header length.

• Switch action: The switch checks for IGMP packets with an improperIGMP header length and drops any matching packets.

IGMPFrag:

• Description: An IGMP packet with the more fragments bit set and anon-zero fragment offset.

• Switch action: The switch checks for IGMP packets with the morefragments bit set and a non-zero fragment offset and drops anymatching packets.

IGMPType:

• Description: An IGMP packet with the type of unassigned or reserved.

• Switch action: The switch checks for IGMP packets with the type ofunassigned or reserved and drops any matching packets.

ARPLen:

• Description: An ARP request or reply packet with an improper length.

• Switch action: The switch checks for ARP request or reply packets withan improper length and drops any matching packets.

ARPNBCast:

• Description: An ARP request packet with a non-broadcast destinationMAC address.




.


• Switch action: The switch checks for ARP request packets with anon-broadcast destination MAC address and drops any matchingpackets.

ARPNUCast:

• Description: An ARP reply packet with a non-unicast destination MACaddress.

• Switch action: The switch checks for ARP reply packets with anon-unicast destination MAC address and drops any matching packets.

ARPSpoof:

• Description: An ARP request or reply packet with a mismatched sourcewith sender MAC addresses or destination with target MAC addresses.

• Switch action: The switch checks for ARP request or reply packets witha mismatched source with sender MAC addresses or destination withtarget MAC addresses and drops any matching packets. It should benoted that VRRP enabled gateways can produce a false positive forarpspoof.

GARP:

• Description: An ARP request or reply packet with the same source anddestination IP.

• Switch action: The switch checks for ARP request or reply packets withthe same source and destination IP and drops any matching packets.

IP6Len:

• Description: An IPv6 packet with an improper header length.

• Switch action: The switch checks for IPv6 packets with an improperheader length and drops any matching packets.

IP6Version:

• Description: An IPv6 packet with the IP version set to a value otherthan 6.

• Switch action: The switch checks for IPv6 packets with the IP versionset to a value other than 6 and drops any matching packets.

Blat

• Description: TCP packets with a source IP (sip) not equal to a destinationIP (dip), but a source port (sport) equal to the destination port (dport).

• Switch action: The switch checks for sourceIP ≠ destinationIP, sport =dport and drops any matching packets.




.


DoS Attack Prevention ConfigurationMany of the DoS attacks guarded against by the switch have configurablevalues associated with them. These values allow the switch to make ajudgement about packets under inspection based on additional administratorinput.

"DoS Attack Prevention Commands" (page 627) outlines these DoS attacksand their associated commands.

DoS Attack Prevention Commands

DoS Attack Command

IPTTL /cfg/security/dos/ipttl <smallest allowable IPTTL>

IPProt /cfg/security/dos/ipprot <highest allowableprotocol>

FragData /cfg/security/dos/fragdata <smallest allowableIP fragment payload>

FragOff /cfg/security/dos/fragoff <smallest allowableIP fragment offset>

SynData /cfg/security/dos/syndata <largest allowable TCPSYN payload>

ICMPData /cfg/security/dos/icmpdata <largest allowableICMP payload>

ICMPOff /cfg/security/dos/icmpoff <largest allowableICMP offset>

To view the current values associated with these DoS attacks, use eitherof the following commands:

>> Main# /cfg/security/dos/cur>> Main# /info/security/dos

A brief explanation of any of the DoS attacks guarded against by the switchcan be acquired by using the following command:

>> Main# /cfg/security/dos/help

Preventing other types of DOS attackPing Flood:

• Description: Flood of ICMP packets intentionally sent to overwhelmservers. The server is removed from service while it attempts to reply toevery ping.




.


• User action: Configure "A Rate Limiting Filter to Thwart Ping Flooding"(page 634) to limit ICMP packets.

Ping of Death:

• Description: A ping of death attack sends fragmented ICMP echorequest packets. When these packets are reassembled, they are largerthan the 65536 byte packets allowed by the IP protocol. Oversizedpackets cause overflows in the server’s input buffer, and can cause asystem to crash, hang, or reboot.

• User action: Configure FragOversize or "Matching and Denying LargePackets - ICMP Ping of Death Example" (page 643).

Protocol-BasedRate LimitingNortel Application Switch Operating System allows you to detect and blockcertain kinds of protocol-based attacks. These attacks can flood serverswith enough traffic to severely affect their performance or bring them downaltogether. Protocol-based rate limiting is implemented via filters. NortelApplication Switch Operating System currently supports rate limiting onTCP, UDP and ICMP protocols. Each filter is configured with one of theabove protocols, and then rate limiting is enabled or disabled in the FilteringAdvanced menu.

• TCP Rate Limiting: limits new TCP connection requests, or SYNpackets. The switch monitors the rate of incoming TCP connectionrequests to a virtual IP address and limits the client requests with aknown set of IP addresses. See "TCP Rate Limiting" (page 629) formore information.

• UDP and ICMP Rate limiting: counts all received packets from a clientand compares against the configured maximum threshold. When themaximum configured threshold has been reached before the timewindow expires, the switch will drop until the configured hold-downperiod expires. See "UDP and ICMP Rate Limiting" (page 629) for moreinformation.

Time Windows and Rate LimitsA time window is a configured period of time (in seconds) during whichpackets are allowed to be received. A rate limit is defined as the maximumnumber of TCP connection requests (for TCP rate limiting), or the maximumnumber of UDP or ICMP packets that have been received from a particularclient within a configured time window.




.


When the fastage value is configured, the time window used by the switchis a multiple of the configured switch fastage and timewin values. Referto Chapter 6 of the Command Reference for information on these value.The total time window then is the outcome of the timewin value multipliedby the fastage value.

Hold Down PeriodsThe switch monitors the number of new TCP connections (for TCP ratelimiting) or UDP/ICMP packets received (for UDP/ICMP rate limiting). Whenthe number of new connections or packets exceeds the configured limit, anynew TCP connection requests or UDP/ICMP packets from the client areblocked. When blocking occurs, the client is said to be held down. Theclient is held down for a specified number of minutes, after which new TCPconnection requests or packets from the client are allowed once again topass through.

Note: The time window and hold duration can be configured individuallyon a per-filter basis.

The switch hold down period is a multiple of the slowage and holddurvalues. Refer to Chapter 6 of the Command Reference for information onthese values. The total hold down period is an outcome of the holddur valuemultipled by the slowage value.

UDP and ICMP Rate LimitingNortel Application Switch Operating System filters can be configured toperform rate limiting on UDP and ICMP traffic. Because UDP and ICMPare stateless protocols, the maximum threshold (the maxcon command)should be interpreted as the maximum number of packets received from aparticular client IP address.

When the maximum threshold has been reached before the time windowhas expired, all packets of the configured protocol will be dropped until theconfigured hold down (holddur) period has expired.

TCP Rate LimitingThe switch monitors new TCP connections by looking for incoming SYNpackets that match a specified TCP rate filter. The first SYN packet to matchthe filter creates a TCP Rate session in the session table. Subsequent SYNpackets from the same client that match the same filter increment the TCPRate session counter. If the counter reaches the threshold value before theTCP Rate session ages out, then a hold down period is reached. Duringthe hold down period no new TCP sessions from this client that match thisfilter are allowed. Once the hold down period ends, the next SYN packet isallowed, and a new TCP Rate session is created.




.


"Configuring Clients with Different Rates" (page 630) shows four clientsconfigured for TCP rate limits based on source IP address. Clients 1 and 4have the same TCP rate limit of 10 connections per second. Client 2 hasa TCP rate limit of 20 connections per second. Client 3 has a TCP ratelimit of 30 connections per second.

When the rate of new TCP connections from clients 1, 2, 3, and 4 reachthe configured threshold, any new connection request from the client isblocked for a pre-determined amount of time. If the client’s IP address andthe configured filter do not match, then the default filter is applied.

In "Configuring Clients with Different Rates" (page 630), the default filter2048 configured for Any is applied for all other connection requests.

Configuring Clients with Different Rates

Configuring Protocol-Based Rate Limiting FiltersRate limiting filters are supported on TCP, UDP or ICMP protocols only.Protocol-based rate limiting can be configured for all filter types (allow, deny,redir, SIP, and DIP) and parameters. Specify the source IP address andmask options in the filter configuration menu to monitor a client or a group ofclients. The destination IP address and mask options are used to monitorconnections to a virtual IP address or a group of virtual IP addresses.

The following examples work for any supported protocol-based rate limitingconfiguration. To specify a rate limiting filter for TCP, UDP, or ICMP, simplyset the protocol on the filter itself, then go into the Filtering Advanced menuto set the rate limiting parameters.




.


A Basic Rate Limiting FilterThe following example shows how to configure rate limiting for Filter 10 in"Configuring Clients with Different Rates" (page 630).

Step Action

1 Set the protocol used for the rate limiting filter.

Only UDP, ICMP, and TCP protocols are supported for rate limiting.

>> Main# /cfg/slb/filt 10 (Select the filter 10 menu)

>> Filter 10 # proto <any|<number>|<name>>

(Specify TCP, UDP or ICMPprotocol)

2 Enable rate limiting for the filter.

>> # /cfg/slb/filt 10/adv/security/ratelim/ena (Enablerate limiting)

3 Configure maximum number of connections.

>> Rate Limiting Advanced#maxconn 3

(Specify in units of 10)

The value of 1 indicates a total of 10 TCP connections (or sessions).

4 Set the time window in seconds.

>> Rate Limiting Advanced#timewin 3

(Denotes a 3-second timewindow)

Note: From step 3 and step 4 the rate limit defined as themaximum number of connections over a specified time window is30 TCP connections for every 3 seconds (or 10 TCP connectionsper second).

5 Set the holddur parameter in minutes.

>> Rate Limiting Advanced#holddur 4

(Set the hold duration)

If a client exceeds the rate limit, then the client is not allowedto make any new TCP connections or UDP/ICMP packets for 4minutes. The following two configuration examples illustrate how touse protocol-based rate limiting to limit user access based on sourceIP address and virtual IP address.




.


6 Repeat steps 1-5 to configure the other filters shown in"Configuring Clients with Different Rates" (page 630).


—End—

A Rate Limiting Filter Based on Source IP AddressThis example shows how to define a filter that limits clients with IP address30.30.30.x to a maximum of 150 TCP connections or 150 UDP or ICMPpackets per second.

Step Action

1 Configure the filter as follows.

>> # /cfg/slb/filt 100/ena (Enable the filter)

>> Filter 100 # sip 30.30.30.0 (Specify the source IPaddress)

>> Filter 100 # smask255.255.255.0

(Specify the source IPaddress mask)

>> Filter 100 # proto<any|<number>|<name>>


>> Filter 100 # adv/security/ratelim

(Select the Rate LimitingAdv. menu)

>> Rate Limiting # ena (Enable rate limiting onTCP)

>> Rate Limiting # maxconn 15 (Specify the maximumconnections in multiples of10)

>> Rate Limiting # timewin 1 (Set the time window inseconds)

>> Rate Limiting # holddur 10 (Set the hold duration inminutes)

• Time window = 1 second

• Hold duration = 10 minutes

• Max rate = maxconn/timewin = 150 connections/1 second =150 connections/second





.


Any client with source IP address equal to 30.30.30.x is allowed tomake 150 new TCP connections (or UDP/ICMP packets) per secondto any single destination. When the rate limit of 150 is met, the holdduration takes effect. The client is not allowed to transmit sessionsor connections to the same destination for 10 minutes.

—End—

A Rate Limiting Filter Based on Virtual Server IP AddressThis example defines a filter that limits clients to 100 TCP connections persecond or 100 UDP or ICMP sessions per second to a specific destination(VIP 10.10.10.100). Once a client exceeds that limit, the client is notallowed to initiate new TCP connection requests or send UDP or ICMPtraffic to that destination for 40 minutes. "Limiting User Access to Server"(page 633) shows how to use this feature to limit client access to a specificdestination.

Limiting User Access to Server

Step Action

1 Configure the following on the switch:

>> # /cfg/slb/filt 100/ena (Enable the filter)

>> Filter 100 # dip 10.10.10.100

>> Filter 100 # dmask 255.255.255.255

>> Filter 100 # proto<any|<number>|<name>>


>> Filter 100 # adv/security (Select the Security menu)

>> Security# ratelim ena (Enable rate limiting)




.


>> Security# maxconn 20 (Specify the maximumconnections in multiples of10)

>> Security# timewin 2 (Set the time window for thesession)

>> Security# holddur 40 (Set the hold duration forthe session)

• time window = 2 seconds

• hold down time = 40 minutes

• max rate = maxconn/time window = 100 connections/second

• 200 connections/2 seconds = 100 connections/second

This configuration limits all clients to 100 new TCP (or UDP/ICMPpackets) per second to the server. If a client exceeds this rate,then the client is not allowed transmit sessions or connections tothe virtual server for 40 minutes.

2 Add the filter to the ingress port on the switch.

>> Rate Limiting # /cfg/slb/port 2/filt ena/add 100


—End—

A Rate Limiting Filter to Thwart Ping FloodingThis example shows how to define a filter that limits the amount of ICMPpings to any destination behind the application switch. A ping flood attemptsto overwhelm servers with ping packets, thus removing it from service whileit attempts to reply to every ping.

Step Action

1 Configure the following filter on the switch.

>> # /cfg/slb/filt 30/ena

>> Filter 30 # proto icmp (Specify ICMP protocol)

>> Filter 30 # action allow (Allow ICMP traffic)

>> Filter 30 # adv/security (Select the Security menu)




.


>> Security# ratelim ena (Enable rate limiting)

>> Security# maxcon 10 (Specify the maximumconnections in multiples of10)

2 Add the filter to the ingress port on the switch.

>> Rate Limiting # /cfg/slb/port 2

(Select the appropriateingress port)


Current port 2 filtering: disabled

New port 2 filtering: enabled

>> SLB port 2# add 30 (Add the rate limit filter tothe port)

Filter 30 added to port 2.


—End—

Protection Against UDP Blast AttacksMalicious attacks over UDP protocol ports are becoming a common way tobring down real servers. Nortel Application Switch Operating System canbe configured to restrict the amount of traffic allowed on any UDP port, thusensuring that backend servers are not flooded with data.

In the CLI, specify a series of UDP port ranges and the allowed packet limitfor that range. When the maximum number of packets/second is reached,UDP traffic is shut down on those ports.

Configuring UDP Blast Protection

Step Action

1 Configure the UDP port numbers or ranges of UDP ports thatyou want to protect against UDP attacks.

For example, configure UDP ports 1001-2000 @ 1000pps, UDPports 2001-4000 @2000pps, and UDP ports 4001-6000 @5000pps.




.


>> /cfg/security/udpblast (Access the UDP BlastProtection Menu)

>> UDP Blast Protection# addEnter UDP port number (1 to 65535) or range(first-last): 1001-2000Enter max packet rate per second (1 to20000000): 1000



Nortel Application Switch Operating System supports up to 5000UDP port numbers, using any integer from 1 to 65535. For the entireport range, the difference between the highest port number and thelowest port number must be less than or equal to 5000.

2 Enable UDP blast protection on the ports on the switch that areconnected to unsafe networks

/cfg/security/port 1/udpblast ena


—End—

TCP or UDP Pattern MatchingThis feature provides the capability to scan ingressing packets for patternscontained in some well-known TCP or UDP attacks on backend servers.The switch can be configured with one or more filters that scan the first IPpacket, and drop if it finds one or all of the configured patterns. If no matchis found, the packets will be allowed through.

Pattern matching is constructed much in the same way as any other filterconfigured to examine Layer 7 content, such as "Deny Filter Based on Layer7 Content Lookup" (page 400).




.


Note: The ability to match and perform filter action on a pattern orgroup of patterns is available only when the Security Pack softwareis enabled on your switch.

Pattern CriteriaMany TCP or UDP attacks contain common signatures or patterns in the IPpacket data. The switch can be configured to examine an IP packet fromeither the beginning, from a specific offset value (starting point) within theIP packet, and/or from a specified depth (number of characters) into the IPpacket. It then performs a matching operation.

"IP Packet Format" (page 638) shows an IP packet format. The switch is ableto track from the beginning of the IP packet (at IP version number), throughIP packet payload of 1500 bytes. Each row in an IP packet is four bytes.

PatternA pattern can be a regular expression string pattern in ASCII characters,or a binary pattern in Hexadecimal notation. For more information onusing regular expressions to match pattern data, see "Regular ExpressionMatching" (page 827).

If the pattern is binary, specify the binary pattern in Hexadecimal notation.For example, to specify the binary pattern 1111 1100 0010 1101, enterFC2D.

OffsetAn offset value is the byte count from the start of the IP header, from whicha search or compare operation is performed. An offset value is alwaysrequired when the creating pattern strings, even if the desired value iszero (0).

For example, if an offset of 12 is specified, the switch will start examiningthe hexadecimal representation of a binary string, from the 13th byte. Inthe IP packet, the 13th byte starts at the Source IP Address portion of theIP payload.




.


IP Packet Format

DepthDepth is the number of bytes in the IP packet that should be examined fromeither the beginning of the packet or from the offset value. For example, ifan offset of 12 and a depth of 8 is specified, the search begin at the 13thbyte in the IP packet, and will match 8 bytes. As we can see from "IP PacketFormat" (page 638), an offset of 12 and depth of 8 encompasses the SourceIP Address and Destination IP Address fields in the IP payload.

If no depth is specified in ASCII matches, the exact pattern will be matchedfrom the offset value to the end of the pattern. A depth must be specified forBinary matches that is larger than the pattern length in bytes.

OperationAn operation tells the switch how to interpret the pattern, offset and depthcriteria.

• For a string pattern, use the operation eq (equals) in order to matchthe content of the string.

• Use the operations to find values lt (less than), gt (greater than) oreq (equals) to the specified binary value. If no operation is specified,the pattern is invalid. The lt and gt operations can be used for certainattack signatures, in which one or more bytes are less than or greaterthan a certain value.

Syntax:

>> /cfg/slb/layer7/slb/addstr




.


Matching Groups of PatternsWhen a virus or other attack contains multiple patterns or strings, it is usefulto combine them into one group and give the group a name that is easy toremember. When a pattern group is applied to a deny filter, the switch willmatch any of the strings or patterns within that group before denying anddropping the packet. Up to five patterns can be combined into a singlepattern group. Configure the binary or ascii pattern strings, group them intoa pattern group, name the pattern group, and then apply the group to a filter.

The filtering commands allow the administrator to define groups of patternsand place them into groups. By applying the patterns and groups to adeny filter, the packet content can be detected and thus denied accessto the network.

The Nortel Application Switch Operating System supports up to 1024pattern groups.

Note: The pattern group matching feature is available only if you havepurchased and enabled the Advanced Denial of Service Protectionsoftware key.

The Nortel Application Switch Operating System supports multi-packetinspection. This allows for the inspection of multiple patterns across multiplepackets in a session. Filtering actions will be taken only after matching allthe patterns in the same given sequence.

For example, assume a chain consisting of multiple patterns numbered 1through 4. The incoming packets of the session will be first searched forpattern 1. Once pattern 1 of the chain is matched, subsequent packets ofthe session will be searched for pattern 2 and if matched, pattern 3 will besearched for and so on, until all the patterns in the chain are matched. Thefilter action will be taken after patterns 1 through 4 are matched.

Note: A reset frame is sent to the destination device when a Layer 7deny filter is matched instead of waiting for a server side timeout. Thiswill release the TCP connection in the destination device. Similarly, anytime a TCP packet is denied by the switch a reset frame is sent.

Matching and Denying a UDP Pattern Group

Step Action

1 Configure a list of SLB strings containing binary patterns andoffset pairs.




.


The following example illustrates adding one binary pattern and oneASCII string pattern. The binary pattern is written in hexadecimalnotation.

>> /cfg/slb/layer7/slb/addstr

Enter type of string [l7lkup|pattern]: pattern (Addthe first pattern)Enter match pattern type [ascii|binary]: binary (Selectbinary matching)

Enter HEX string: 014F (For this Binary pattern)

Enter offset in bytes from start of IP frame(0-1500): 2 (Starting from 3rd byte)Enter depth in bytes to search from offset (0-1500):0 (Search length of the pattern)

Enter operation (eq|gt|lt): eq (For values equal to thisBinary pattern)

>> Server Loadbalance Resource# add (Add the second pattern)

Enter type of string [l7lkup|pattern]: pattern

Enter match pattern type [ascii|binary]: ascii (Selectascii matching)Enter ASCII string: /default.htm (Match this ascii string)Enter offset in bytes from start of IP frame(0-1500): 44 (Search from 45th byte)Enter depth in bytes to search from offset (0-1500):30 (through 30th byte)



The strings in bold are used in this example.


ID SLB String

1 ida

2 %c1%9c

3 %c0%af

4 playdog.com






.



ID SLB String

8 BINMATCH=014F, offset=2, depth=0, op=eq, cont256

9 STRMATCH=/default.htm offset=44, depth=30,op=eq, cont 256

3 In the security menu, configure a pattern group and name itsomething relevant and easy to remember.

>> /cfg/security/pgroup 1/name (Name pattern group 1)

Current pattern group name:

Enter new pattern group name:virus_x

(Name the group)

4 Add the new pattern/offset pairs to the pattern group usingtheir ID numbers.

Refer back to step 2, where you typed the cur command, if you needto recall the ID number associated with the SLB string.

>> Pattern Match Group 1# add 8 (Add the first binary pattern)

>> Pattern Match Group 1# add 9 (Add the ascii string pattern)

5 Configure a filter and its appropriate protocol in which thepatterns are found.

>> /cfg/slb/filt 90 (Go to the Filter 90 menu)

>> Filter 90 # proto tcp

6 Configure the filter source and destination ports.

>> Filter 90 # sport any (From any TCP source port)

>> Filter 90 # dport http (To HTTP destination port)

7 Configure the filter to deny.


Current action: nonePending new action: deny

8 Apply the pattern group you configured in step 3 and step 4 tothe filter.




.


>> Main# /cfg/slb/filt90/adv/security/addgrp 1

(Add pattern group 1 to thefilter)

Group ID 1 added.

9 Enable pattern matching on the filter.

This command will automatically enable Layer 7 lookup on the filter.

>> /cfg/slb/filt 90/adv/security/pmatch enableCurrent Pattern Match: disabledNew Pattern Match: enabled

10 Apply the filter to the client port.

If the incoming client requests enter the switch on port 3, then addthis filter to port 3.


>> SLB Port 3# filt ena (Enable filtering on theclient port)

>> SLB Port 3# add 90 (Add Filter #90 to the clientport)


—End—

Matching All Patterns in a GroupThe switch is capable of matching on all patterns in a pattern group beforethe filter denies a packet. Use the matchall command to instruct the filterto match all patterns in the group before performing the deny action.

Note: The matchall command is configurable only for binary or asciipatterns added to pattern groups (pgroup). It does not apply to l7lkupfilter strings configured with the /cfg/slb/layer7/slb/addstrcommand.

Step Action

1 Use the base configuration in "Matching and Denying a UDPPattern Group" (page 639).

2 In the Filter menu, enable the matching of all criteria.




.


>> /cfg/slb/filt 90/adv/security/matchall ena

(Enable matching all criteria)

Current Match-all Criteria: disabledNew Match-all Criteria: enabled

Now, both patterns configured in the above example must bematched before a packet is denied and dropped:




—End—

Matching and Denying Large Packets - ICMP Ping of DeathExampleA ping of death attack sends fragmented ICMP echo request packets.When these packets are reassembled, they are larger than the 65536 bytepackets allowed by the IP protocol. Oversized packets cause overflows inthe server’s input buffer, and can cause a system to crash, hang, or reboot.

Large ICMP packets, such as in an ICMP ping of death attack, can beblocked using a deny filter combined with binary patterns used to filternon-zero IP offsets or More-Fragment bits sent in the IP flags.

An IP packet is determined to be an IP fragment if:

(a) the 13-bit fragment offset field in the IP header is non-zero, or

(b) the More Fragments bit in the 3-bit flags field in the IP header is set.

The flags field begins at the 7th byte of the IP packet, and the fragmentoffset is right after this field. The two fields taken together occupy a totalof 2 bytes. By searching for values greater than 0000 and less than 4000,the switch searches for either (a) or (b) or both.

The following configuration is similar to the examples in "Matching andDenying a UDP Pattern Group" (page 639) and "Matching All Patterns ina Group" (page 642).

Step Action

1 Create an SLB string pattern that filters non-zero IP offsets.Enter the value in Hexadecimal notation.




.


>> /cfg/slb/layer7/slb/addstrEnter type of string [l7lkup|pattern]: pattern (Addthe pattern)Enter match pattern type [ascii|binary]: binary (Selectbinary matching)

Enter HEX string: 0000 (non-zero IP offset)

Enter offset in bytes from start of IP frame(0-1500): 6 (Search from 7th byte)Enter depth in bytes to search from offset (0-1500):0 (Through end of pattern)

Enter operation (eq|gt|lt): gt (For values greater than0000)

2 Create another SLB string pattern that filters More Fragments.


Enter type of string [l7lkup|pattern]: pattern (Addthe pattern)Enter match pattern type [ascii|binary]: binary (Selectbinary matching)

Enter HEX string: 4000 (More-Fragments bit set)

Enter offset in bytes from start of IP frame(0-1500): 6 (Search from 7th byte)Enter depth in bytes to search from offset (0-1500):0 (Through end of pattern)

Enter operation (eq|gt|lt): lt (For values less than 4000)

3 Apply the new configuration.

>> Server Loadbalance Resource# apply

4 Identify the IDs of the defined patterns.


The strings in bold are used in this example.Number of entries: 11

ID SLB String

1 ida

2 %c1%9c

3 %c0%af

4 playdog.com




.


ID SLB String





10 BINMATCH=0000, offset=6, depth=0, op=gt, cont256

11 BINMATCH=4000, offset=6, depth=0, op=lt, cont256

5 In the security menu, configure a pattern group and name itsomething relevant and easy to remember.

>> /cfg/security/pgroup 2/nameCurrent pattern group name:

Enter new pattern group name:pingofdeath

(Enter name for patterngroup 2)

6 Add the defined patterns to the pattern group.

>> Pattern Match Group 2# add 10>> Pattern Match Group 2# add 11

7 Configure a filter and its appropriate protocol in which thepatterns are found; in this case, icmp protocol should bespecified.

>> /cfg/slb/filt 190 (Go to the Filter 90 menu)

>> Filter 190 # proto icmp

8 Set the filter action to deny.


Current action: nonePending new action: deny

9 Set the ICMP message type.

Ping of Death uses the ICMP message type echoreq.




.



>> Filter 190 # adv/icmp>> Filter 190 Advanced# icmpCurrent ICMP message type: any

Enter ICMP message type or any:echoreq

(Set ICMP message type)

10 Apply the pattern group you configured in step 5 and step 6 tothe filter.

>> Filter 190 # security/addgrp 2 (Add pattern group 2 tothe filter)

Group ID 2 added.

11 Enable pattern matching on the filter.

>> /cfg/slb/filt 190/adv/security/pmatch enableCurrent Pattern Match: disabledNew Pattern Match: enabled

12 Enable matchall criteria so that the filter matches on all patternsin the pattern group.

>> Security# matchall enaCurrent Match-all Criteria: disabledNew Match-all Criteria: enabled

13 Apply the filter to the client port.

This example assumes a client connection on port 22.


>> SLB Port 22# filt ena (Enable filtering on theclient port)

>> SLB Port 22# add 190 (Add Filter #190 to the clientport)


—End—




.


Nortel Threat Protection System 4.1 Enforcement PointThe Nortel Application Switch Operating System gives the Nortel ApplicationSwitch the ability to be an enforcement point for the Nortel Threat ProtectionSystem version 4.0. In this capacity, the switch can enforce policies thathave been generated by the Threat Protection System.

Remediation SubsystemThe Remediation Subsystem is a component of the Nortel Threat ProtectionSystem that issues remediations directly to the Nortel Application Switchin response to detected threats on the network. These remediations, withthe exception of session deletion, take the form of Operations IP AccessControl Lists. Refer to "Operations IP Access Control List" (page 648) formore information on this topic.

The following remediations are issued directly to the Nortel ApplicationSwitch from the Remediation Subsystem of the Nortel TPS:

Step Action

1 Block Source IP

Blocks any traffic sent from the source IP in the event that triggeredthe remediation.

2 Block Destination IP

Blocks any traffic sent to the destination IP in the event that triggeredthe remediation.

3 Block Source Network

Block any traffic sent from source network in the event that triggeredthe remediation.

4 Block Destination Network

Block any traffic sent to destination network in the event thattriggered the remediation.

5 Delete Session

Deletes existing session based on five parameters of the event thattriggered the remediation. Refer to "Session Deletion" (page 649) forfurther information on this topic.

When an operations IP ACL is added remotely by the remediationsubsystem a syslog entry is generated.

—End—




.


Operations IP Access Control ListThe Operations IP Access Control List (ACL) feature allows up to 1024source IP ACLs and 1024 destination IP ACLs to be set for a user-specifiedtime duration in minutes without making configuration changes or manuallyremoving the IP ACL. As well, when the maximum number of source ordestination IP ACLs is reached, any new source or destination IP ACL setwill automatically remove the next source or destination IP ACL that willexpire. Any new source IP ACL will remove the next source IP ACL only andany new destination ACL will only replace the next destination IP ACL. Thiswill allow the new IP ACL to be set even though the maximum is reached.

Configuring Operations IP Access Control ListsThe following sections outline the commands necessary to configure andmaintain Operations IP ACLs.

Configuring Source IP Access Control Lists A switch administrator hasthe option of performing the following three actions with source IP accesscontrol lists:

Step Action

1 Add a new source IP access control list.

To add a new source IP access control list, use the followingcommand:

>> Main# /oper/sec/ipacl/add <IP Address> <SubnetMask> <Duration in Minutes (1—10080)>

2 Remove a source IP access control list.

A source IP access control list can be removed from the switchbefore its timeout threshold is reached. To remove a source IPaccess control list, use the following command:

>> Main# /oper/sec/ipacl/rem <IP Address> <SubnetMask>

3 Remove all source IP access control lists.

To remove all source IP access control lists from the switch, usethe following command:

>> Main# /oper/sec/ipacl/arem

—End—




.


Configuring Destination IP Access Control Lists A switch administratorhas the option of performing the following three actions with destination IPaccess control lists:

Step Action

1 Add a new destination IP access control list.

To add a new destination IP access control list, use the followingcommand:

>> Main# /oper/sec/ipacl/dadd <IP Address> <SubnetMask> <Duration in Minutes (1—10080)>

2 Remove a destination IP access control list.

A destination IP access control list can be removed from the switchbefore the timeout threshold is reached. To remove a destination IPaccess control list, use the following command:

>> Main# /oper/sec/ipacl/drem <IP Address> <SubnetMask>

3 Remove all destination IP access control lists.

To remove all destination IP access control lists from the switch, usethe following command:

>> Main# /oper/sec/ipacl/darem

When an operations IP ACL is removed automatically, a syslogentry is generated.

—End—

Session DeletionSessions can be deleted from the switch through the RemediationSubsystem when the switch is acting as a Nortel TPS enforcement pointor manually through the command line interface. Manual session deletionis based on the five parameters entered by the user when the commandis executed. Based on these parameters the operating system will find thecorresponding single session entry and delete it.

The five parameters are:

• Source IP Address

• Source Port




.


• Destination IP Address

• Destination Port

• TCP or UDP protocol

When the session deletion command is received by the switch, the MP willloop and send session deletion requests to all SPs but it will stop once thesession entry is found and deleted on any SP.

Session deletion is accomplished by the following command:

>> Main# /oper/slb/sessdel <Source IP Address> <Source Port><Destination IP Address> <Destination Port> {TCP | UDP}




.

Symantec Intelligent Network Protection 651

Symantec Intelligent Network Protection

This chapter describes the Symantec Intelligent Network Protection featuresin the Nortel Application Switch Operating System. These new features areused in conjunction with the Intelligent Traffic Management functionality tocreate a more robust and well-rounded security solution.

It should be noted that although this chapter provides an explanation of theSymantec Intelligent Network Protection feature and general configurationinformation, it does not provide specific and detailed information on theconfiguration, usage, and management of this feature. For detailedinformation on these topics, refer to the following documents in the NortelApplication Switch documentation suite:

• Nortel Intelligent Traffic Management 5.0 User’s Guide (NN47220-102)

• Nortel Application Switch Element Manager 5.0 User’s Guide(NN47220-101)

• Nortel Application Switch Element Manager 5.0 Help (NN47220-100)

Symantec Intelligent Network Protection is only available to switches thathave a valid Intelligent Traffic Management and Symantec license that arerunning the Nortel Application Switch Operating System 24.0 and higher.

Symantec Intelligent Network Protection is not meant to supplant theexisting security functionality of the Nortel Application Switch OperatingSystem but to enhance it. For the most secure solution possible, usethis functionality in conjunction with the existing security functionality.Information on this security functionality can be found in "Advanced Denialof Service Protection" (page 611)

This chapter contains the following topics:


• "Installing Software Keys" (page 653)

• "Intelligent Network Protection Components" (page 653)

• "Configuration Tasks" (page 654)

• "Tunable Resources" (page 656)

• "Monitoring Symantec Functionality" (page 657)

• "General Symantec Information" (page 657)

• "Signature Names" (page 658)

• "Configuration Example" (page 659)

• "Troubleshooting" (page 665)




.


OverviewIntelligent Network Protection provides enhanced security functionalityto the switch by providing a continually updated line of defense againstmoderate and severe network threats. Intelligent Network Protection isprovided as a subscription based service that is purchased on a yearlybasis for each switch it protects. This allows a user to provide up to dateprotection to the switch. Intelligent Network Protection is available to aNortel Application Switch with a valid Intelligent Traffic Management license.

Once this functionality is enabled on the switch, Symantec securitysignatures are downloaded to it through the Symantec LiveUpdatetechnology. Security signatures are continuously updated by Symantecand posted for immediate download by subscribers. Updated signaturescan be downloaded through Nortel ASEM automatically and applied eitherautomatically or manually.

Traffic flows are then steered through the Symantec security engine forinspection and the results are communicated to the Application Switch toenable the pre-determined course of action. Traffic that cleanly passessecurity interrogation is then processed for application classification andpolicy assignment.

"Security Layers in Nortel Application Switch Operating System" (page652) illustrates the multiple layers of security enabled by a Nortel ApplicationSwitch running Intelligent Traffic Management and Intelligent NetworkProtection.

Security Layers in Nortel Application Switch Operating System




.


Intelligent Network Protection ComponentsThe Intelligent Network Protection functionality is composed of severalcomponents that work together to provide the overall security solution. Thisoverall security solution is composed of the following items:

• Switch Software

The main component of the Intelligent Network Protection functionalityis the software included in the Nortel Application Switch OperatingSystem. The switch software contains the logic for filtering and denyingtraffic based on the Symantec signatures downloaded to the switch.

• Intelligent Traffic Management

The Intelligent Traffic Management component works in conjunctionwith the Intelligent Network Protection functionality to filter and monitortraffic. Intelligent Network Protection does not replace Intelligent TrafficManagement and Intelligent Traffic Management does not provide asubstitute to Intelligent Network Protection. Both provide complimentaryservices that aid in the overall security of the switch.

• Application Switch Element Manager

Configuration and management tasks are performed through theApplication Switch Element Manager (ASEM). The Application SwitchElement Manager provides screens for the configuration, monitoring,and scheduling of Intelligent Network Protection functionality.

Installing Software KeysSymantec Intelligent Network Protection requires the installation of one ormore software keys to enable the feature on the switch. To install thesesoftware keys and enable the feature, perform the following procedure:

Step Action

1 Log into the switch CLI.

2 Install software keys.

Symantec Intelligent Network Protection requires the previousinstallation of the Intelligent Traffic Management and Security Packfeatures before this feature can be installed. If these features havenot been previously installed they must be purchased and installed.

Once all software keys have been acquired, they must be installed inthe following order:

• Intelligent Traffic Management

• Security Pack

• Symantec Intelligent Network Protection




.


Use the following command to install all software keys:

>> Main# /oper/swkey <software key>

3 Globally enable Intelligent Network Protection functionality.

Globally enable the Intelligent Network Protection functionality usingthe following command:

>> Main# /boot/symantec ena

The switch will prompt for confirmation of the request. Answer yat the prompt.

The switch will then reset and load the Intelligent Network Protectionmemory management scheme.

Note: To disable the Intelligent Network Protection functionalityglobally, use the command /boot/symantec dis. The switchwill prompt for confirmation of the request and reset afteranswering y at the prompt.

—End—

Configuration TasksThe tasks listed in this section must be completed to successfullyenable Intelligent Network Protection on a switch. Before enablingIntelligent Network Protection, both an Intelligent Traffic Managementand Symantec license must be purchased for each switch on which thisfeature will run. For information on purchasing these licenses, refer tohttp://www.nortel.com/contactus.

The tasks outlined in this section refer to, and make use of, the ApplicationSwitch Element Manager. Use of the ASEM is the preferred mode ofconfiguration for Intelligent Network Protection functionality.

To enable Intelligent Network Protection, perform the following tasks:

Note: Although many of these tasks are represented individually, mostcan be performed together when running the Traffic ManagementWizard in the Application Switch Element Manager.

Step Action

1 Log into the switch using SNMPv3.




.

http://www.nortel.com/contactus


Symantec Intelligent Network Protection requires the use ofSNMPv3 for switch authentication. Using any other form of SNMPauthentication to log into the switch will cause the Intelligent NetworkProtection options to be unavailable.

2 Open the Traffic Management Wizard.

Open the Traffic Management Wizard by selecting Wizards > TrafficManagement Wizard from the ASEM menu.

3 Add inbound and outbound ports for protection.

Select the inbound and outbound ports that will be protected.

4 Add Symantec critical and severe threats to monitor.

Critical network threats are selected from a list presented on theThreats - Criticial and Threats-Severe tabs of the ApplicationSelection screen of the Traffic Management Wizard.

5 Schedule signature updates.

Symantec signatures can be configured to update automaticallyusing Symantec LiveUpdate functionality. Use the SymantecSchedule button found at the bottom of the Application Selectionscreen of the Traffic Management Wizard to schedule updates. Thisscreen is also used to determine if signatures will be automaticallyor manually applied to the switch.

6 Configure application actions.

Once threats have been identified and configured for monitoring,the action to take on these threats are configured in the ApplicationActions screen of the Traffic Management Wizard.

—End—

CLI Command AnalogsAlthough the primary configuration mechanism for Intelligent NetworkProtection is the Application Switch Element Manager, many of theprocedures performed in the ASEM can also be performed in the CLI.Extension of ASEM functionality into the CLI is primarily provided as atroubleshooting mechanism.

"Intelligent Network Protection CLI Commands" (page 656)outlines theIntelligent Network Protection CLI commands.




.


Intelligent Network Protection CLI Commands

Command Description

/cfg/bwm/cont <contractnumber> /maxsess <0 - 65534>

This command limits the number ofopen sessions per user or application.If Intelligent Traffic Management is inuse, this command should not be used.Configuration should take place in theTraffic Management Wizard.

/cfg/slb/port <port number>/symantec {enable | disable}

This command enables or disablesIntelligent Network Protection on a port.Since Intelligent Traffic Managementwill automatically enable or disableSymantec processing, this command isprovided for troubleshooting purposesonly.

/cfg/security/symsig <signature_id> <inbound_contract><outbound_contract>

This command manually adds aSymantec signature to bandwidthcontract mappings. This command isprovided for troubleshooting purposesonly. Where possible, this procedureshould be performed in the third screenof the Traffic Management Wizard.

/cfg/security/symdel<signature_id>

This command manually removesa Symantec signature to bandwidthcontract mappings. This command isprovided for troubleshooting purposesonly. Where possible, this procedureshould be performed in the third screenof the Traffic Management Wizard.

Tunable ResourcesAs features are added to the Nortel Application Switch Operating System,more and more memory is necessary to sufficiently support these newfeatures. Since the Nortel Application Switch hardware has not beenupgraded to provide this additional capacity, the Tunable Resource featurehas been created to provide variable memory profiles.

The Tunable Resources feature allows switch memory to be allocated basedon two types of configuration:

• Intelligent Traffic Management / Symantec

• Default

Switches running the Nortel Application Switch Operating Systemautomatically have their memory allocations tuned to the Defaultconfiguration. This memory allocation configuration maximizes switchresources to handle day to day operations.




.


The Intelligent Traffic Management / Symantec memory allocationconfiguration maximizes switch performance for the use of the IntelligentNetwork Protection feature. This memory allocation profile is automaticallyselected when the user enables the Symantec Intelligent Network Protectionfeature.

Memory allocation profiles are not configurable and are selectedautomatically by the switch. The switch will indicate the current memoryallocation configuration when logging into the CLI or by using the/info/sys/general command.

Monitoring Symantec FunctionalityOnce Intelligent Network Protection is configured, it can be monitored usingthe ASEM or CLI. Monitoring Intelligent Network Protection functionalitywill provide information about threat applications that have been filteredand monitored and what applications that are not currently configured butshould be.

"Intelligent Network Protection Monitoring Tasks" (page 657) outlines themonitoring tasks available in the ASEM and CLI.

Intelligent Network Protection Monitoring Tasks

Monitoring Task ASEM Location CLI Command

Symantec MatchStatistics

Monitor > Security(Several tabs)

/stat/security/symhits/stat/security/symclear

Symantec SP MatchStatistics

Monitor > Security(Several tabs)

/info/security/symantec

Symantec Maintenance Statistics

Monitor > Layer 4 > SLB> SP Maintenance

/stat/slb/sp<sp_number> /maint

Symantec EngineStatistics

Monitor > Layer 4 > SLB> SP Maintenance

/stat/slb/maint

General Symantec InformationThe ASEM application also provides general information about theSymantec configuration on the administered switch. "General SymantecInformation" (page 658) outlines the information provided by the application.




.


General Symantec Information

SymantecInformation

ASEM Location Description

License Expiration Configure > Security >General

The number of days lefton the current Symanteclicense. Licenses expirewithin 365 days after thefirst signature download.

LiveUpdate DefaultAction

Configure > Security >General

The default action theswitch applies to newlydownloaded signatures.The Traffic ManagementWizard is used to set thelong term signature policy.

ScanEngine Version


The version of theSymantec security enginecurrently running on theswitch.

Symantec PendingLicense Renewal


Indicates whether a licenserenewal is pending.

Signature NamesAll Symantec signatures used in Intelligent Network Protection functionalityfollow a specific naming scheme where file names are as follows:

YYYYMMDDNN

where:

Step Action

1 YYYY = The year the signature was issued.

2 MM = The month the signature was issued.

3 DD = The day the signature was issued.

4 NN = The iteration number of the signature issued on the datespecified by the previous three name components.

—End—




.


Configuration ExampleThis section contains a Nortel Symantec Intelligent Network Protectionexample configuration. This configuration example assumes that clientport 5 and server port 6 are Symantec enabled. Traffic in this example isbeing sent at 10 Mbps but rate limited to 5 Mbps as defined in the policyin the example.

Take the following steps to create the sample configuration:

Step Action

1 Configure the switch management port options.

/cfg/sys/mmgmtaddr 47.80.20.103mask 255.255.255.0broad 47.80.20.255gw 47.80.20.1tftp mgmtreport mgmtena

2 Configure the physical switch management port options.

/cfg/sys/mmgmt/portspeed anymode anyauto on

3 Associate action and bandwidth contracts with Symantecsignatures.

/cfg/sec/symsig 20595 1 2symsig 20596 1 2symsig 20267 1 2symsig 20268 1 2symsig 20269 1 2symsig 20270 1 2symsig 20271 1 2symsig 20272 1 2symsig 20273 1 2symsig 20274 1 2symsig 20294 1 2symsig 20295 1 2symsig 20296 1 2symsig 20275 1 2symsig 20293 1 2symsig 20297 1 2




.


symsig 20276 1 2symsig 20148 1 2symsig 20277 1 2symsig 20298 1 2symsig 20278 1 2symsig 20299 1 2symsig 20300 1 2symsig 20301 1 2symsig 20302 1 2symsig 20575 1 2symsig 20597 1 2symsig 20303 1 2symsig 20304 1 2symsig 20305 1 2symsig 20279 1 2symsig 20179 1 2symsig 20306 1 2symsig 20307 1 2symsig 20598 1 2symsig 20309 1 2symsig 20310 1 2symsig 20311 1 2symsig 20313 1 2symsig 20314 1 2symsig 20315 1 2symsig 20316 1 2symsig 20317 1 2symsig 20280 1 2symsig 20281 1 2symsig 20282 1 2symsig 20283 1 2symsig 20284 1 2symsig 20285 1 2symsig 20319 1 2symsig 20286 1 2symsig 20318 1 2symsig 20287 1 2symsig 20320 1 2symsig 20599 1 2symsig 20288 1 2symsig 20289 1 2symsig 20321 1 2symsig 20600 1 2symsig 20290 1 2symsig 20322 1 2symsig 20601 1 2symsig 20291 1 2symsig 20292 1 2symsig 20715 1 2symsig 20021 1 2




.


symsig 20076 1 2symsig 20958 1 2symsig 20359 1 2symsig 21298 1 2symsig 20716 1 2symsig 21744 1 2symsig 21732 1 2symsig 21320 1 2symsig 21750 1 2symsig 20704 1 2symsig 20726 1 2symsig 21265 1 2symsig 21297 1 2symsig 21319 1 2symsig 21256 1 2symsig 20727 1 2symsig 20094 1 2symsig 21391 1 2symsig 20706 1 2symsig 20633 1 2symsig 20634 1 2symsig 20097 7 8symsig 20098 7 8symsig 20088 7 8symsig 20077 7 8symsig 20767 7 8symsig 20086 7 8symsig 20087 7 8symsig 20074 7 8symsig 20326 7 8symsig 20765 7 8symsig 21701 7 8symsig 21702 7 8symsig 20022 7 8symsig 20023 7 8symsig 20024 7 8symsig 20637 7 8symsig 20763 7 8symsig 21266 7 8symsig 100101 11 11symsig 100102 12 12symsig 100103 13 13symsig 100104 14 14symsig 100105 15 15

4 Configure switch access.




.


/cfg/sys/accesssnmp whttp enatnet ena

5 Configure port options.

/cfg/port 5cont 3nonip 5

/cfg/port 6cont 4nonip 6

6 Configure general bandwidth management options.

/cfg/bwmonreport 47.80.20.88email dis

7 Configure bandwidth management contracts.

/cfg/bwm/cont 1enaname "Symantec-Severe_IN"pol 1prec 255

/cfg/bwm/cont 2enaname "Symantec-Severe_OUT"pol 2prec 255

/cfg/bwm/cont 3enaname "OTHER_IN"mononly ena

/cfg/bwm/cont 4enaname "OTHER_OUT"mononly ena

/cfg/bwm/cont 5enaname "NONIP_IN"mononly ena

/cfg/bwm/cont 6enaname "NONIP_OUT"




.


mononly ena/cfg/bwm/cont 7

enaname "Symantec-Critical_IN"pol 1prec 255

/cfg/bwm/cont 8enaname "Symantec-Critical_OUT"pol 2prec 255

/cfg/bwm/cont 11enapol 11





8 Configure bandwidth management policies.

/cfg/bwm/pol 1hard 5Msoft 0Kresv 0Kuserlim 5M

/cfg/bwm/pol 2hard 6Msoft 0Kresv 0Kuserlim 6M

/cfg/bwm/pol 11hard 10Msoft 9M



/cfg/bwm/pol 14hard 10M




.


soft 9M/cfg/bwm/pol 15

hard 10Msoft 9M


/cfg/slbon

10 Enable Nortel Symantec functionality.

/cfg/slb/port 5symantec ena

/cfg/slb/port 6symantec ena

11 Configure SLB filters.

/cfg/slb/filt 2043name "L7_INSPECT_IN"enaaction allowipver v4sip anysmask 0.0.0.0dip anydmask 0.0.0.0vlan any

/cfg/slb/filt 2043/advcont 3

/cfg/slb/filt 2044name "L7_INSPECT_OUT"enaaction allowipver v4sip anysmask 0.0.0.0dip anydmask 0.0.0.0vlan any

/cfg/slb/filt 2044/advcont 4

12 Enable SLB filters.




.


/cfg/slb/port 5filt enaadd 2043

/cfg/slb/port 6filt enaadd 2044

—End—

TroubleshootingThis section details known situations that may arise out of the operation ofthe Symantec Intelligent Network Protection functionality. Where possible,workarounds for these situations are provided.

Configuration Synchronization - Different Memory ProfilesThe situation may arise in a networked environment where two switchessynchronize their configurations but do not share the same memory profiles(see "Tunable Resources" (page 656)). In this instance, not all configurationchanges may be transferred successfully from one switch to another.Consider the following example.

Switch B synchronizes its configuration with Switch A. Switch A is currentlyrunning the Symantec memory profile and Switch B is running the defaultmemory profile. Additionally, Symantec processing is enabled on port 1 ofSwitch A and disabled on port 1 of Switch B.

Although the system messages from the switch will indicate success duringthe configuration synchronization, Symantec processing will never beenabled on port 1 of Switch B until Symantec processing is enabled on theswitch and Switch B is placed into the Symantec memory profile.

This is due in part to the fact that the Symantec Intelligent NetworkProtection functionality is licensed per switch and this license cannot beshared between switches. In the above example, Switch B would havefully accepted Switch A’s configuration if a Symantec license had beenpurchased for it and the switch placed into the Symantec memory profile.

Configuration Synchronization - Similar Memory ProfilesThe situation may arise in a networked environment where two switchesthat synchronize their configurations deviate from one another because ofadministrator intervention. Consider the following example.




.


Switch A synchronizes its configuration with Switch B. Both Switch A andSwitch B are currently running the Symantec memory profile (see "TunableResources" (page 656)). Additionally, Symantec processing is enabledon port 1 of Switch A and Switch B.

If an administrator disables Symantec processing on Switch A it will revertto the default memory profile, disable Symantec processing previouslyconfigured on port 1 and reboot. The configurations of Switch A and B willremain inconsistent until such time as the configurations are synchronized.




.

Firewall Load Balancing 667

Firewall Load Balancing

Firewall Load Balancing (FWLB) with Nortel Application Switches allowsmultiple active firewalls to operate in parallel. Parallel operation allows usersto maximize firewall productivity, scale firewall performance without forkliftupgrades, and eliminate the firewall as a single point-of-failure.

This chapter presents the following topics:

• "Firewall Overview" (page 667)

An overview of firewalls and the various FWLB solutions supported byNortel Application Switches.

• "Basic FWLB" (page 669)

Explanation and example configuration for FWLB in simple networks,using two parallel firewalls and two application switches. The basicFWLB method combines redirection filters and static routing for FWLB.

• "Four-Subnet FWLB" (page 682)

Explanation and example configuration for FWLB in a large-scale,high-availability network with redundant firewalls and applicationswitches. This method combines redirection filters, static routing, andVirtual Router Redundancy Protocol (VRRP).

• "Advanced FWLB Concepts" (page 701)

— "Free-Metric FWLB" (page 701). Using other load balancing metrics(besides hash) by enabling the Return to Sender (RTS) option.

— "Adding a Demilitarized Zone (DMZ)" (page 704). Adding a DMZ forservers that attach to the Nortel Application Switch between theInternet and the firewalls.

— "Firewall Health Checks" (page 706). Methods for fine-tuning thehealth checks performed for FWLB.

Firewall OverviewFirewall devices have become indispensable for protecting networkresources from unauthorized access. Prior to FWLB, however, firewallscould become critical bottlenecks or single points-of-failure for your network.

As an example, consider the following network:




.


Typical Firewall Configuration Before FWLB

One network interface card on the firewall is connected to the public sideof the network, often to an Internet router. This is known as the dirty oruntrusted side of the firewall. Another network interface card on the firewallis connected to the side of the network with the resources that must beprotected. This is known as the clean or trusted side of the firewall.

In this simple example, all traffic passing between the dirty, clean, andDMZ networks must traverse the firewall, which examines each individualpacket. The firewall is configured with a detailed set of rules that determinewhich types of traffic are allowed and which types are denied. Heavy trafficcan turn the firewall into a serious bottleneck. The firewall is also a singlepoint-of-failure device. If it goes out of service, external clients can no longerreach your services and internal clients can no longer reach the Internet.

Sometimes, a Demilitarized Zone (DMZ) is attached to the firewall orbetween the Internet and the firewall. Typically, a DMZ contains its ownservers that provide dirty-side clients with access to services, making itunnecessary for dirty-side traffic to use clean-side resources.

FWLB with Nortel Application Switches provides a variety of options thatenhance firewall performance and resolve typical firewall problems.

Nortel Application Switches support the following methods of FWLB:

• Basic FWLB for simple networks

This method uses a combination of static routes and redirection filtersand is usually employed in smaller networks.

A Nortel Application Switch filter on the dirty-side splits incoming trafficinto streams headed for different firewalls. To ensure persistence ofsession traffic through the same firewall, distribution is based on amathematical hash of the IP source and destination addresses.

For more information about basic FWLB, see "Basic FWLB" (page 669).

• Four-Subnet FWLB for larger networks




.


Although similar to basic FWLB, the four-subnet method is more oftendeployed in larger networks that require high-availability solutions.This method adds Virtual Router Redundancy Protocol (VRRP) to theconfiguration.

Just as with the basic method, four-subnet FWLB uses the hash metricto distribute firewall traffic and maintain persistence.

For more information, see "Four-Subnet FWLB" (page 682).

Each method is described in more detail in the following sections.

Basic FWLBThe basic FWLB method uses a combination of static routes and redirectionfilters to allow multiple active firewalls to operate in parallel.

"Basic FWLB Topology" (page 669) shows a basic FWLB topology:

Basic FWLB Topology

The firewalls being load balanced are in the middle of the network,separating the dirty side from the clean side. This configuration requires aminimum of two application switches: one on the dirty side of the firewallsand one on the clean side.

A redirection filter on the dirty-side application switch splits incoming clienttraffic into multiple streams. Each stream is routed through a differentfirewall. The same process is used for outbound server responses; aredirection filter on the clean-side application switch splits the traffic, andstatic routes forward each stream through a different firewall and then backto the client.

Although other metrics can be used in some configurations (see "Free-MetricFWLB" (page 701)), the distribution of traffic within each stream is normallybased on a mathematical hash of the source IP address and destination IPaddresses. This ensures that each client request and its related responses




.


will use the same firewall (a feature known as persistence) and that thetraffic will be equally distributed. The persistence is required for the firewallas it maintains state and processes traffic in both directions for a connection.

Although basic firewall load-balancing techniques can support more firewallsas well as multiple switches on the clean and dirty sides for redundancy,the configuration complexity increases dramatically. The four-subnet FWLBsolution is usually preferred in larger scale, high-availability topologies (see"Four-Subnet FWLB" (page 682)).

Basic FWLB ImplementationIn this example, traffic is load balanced among the available firewalls.

Basic FWLB Process

Step Action

1 The client requests data.

The external clients intend to connect to services at the publiclyadvertised IP address assigned to a virtual server on the clean-sideapplication switch.

2 A redirection filter balances incoming requests among differentIP addresses.

When the client request arrives at the dirty-side application switch,a filter redirects it to a real server group that consists of a numberof different IP addresses. This redirection filter splits the traffic intobalanced streams: one for each IP address in the real server group.For FWLB, each IP address in the real server group represents anIP Interface (IF) on a different subnet on the clean-side applicationswitch.

3 Requests are routed to the firewalls.




.


On the dirty-side switch, one static route is needed for each trafficstream. For instance, the first static route will lead to an IP interfaceon the clean-side application switch using the first firewall as thenext hop. A second static route will lead to a second clean-sideIP interface using the second firewall as the next hop, and so on.By combining the redirection filter and static routes, traffic is loadbalanced among all active firewalls.

All traffic between specific IP source/destination address pairs flowsthrough the same firewall, ensuring that sessions established by thefirewalls persist for their duration.

Note: More than one stream can be routed though a particularfirewall. You can weight the load to favor one firewall byincreasing the number of static routes that traverse it.

4 The firewalls decide if they should allow the packets and, if so,forwards them to a virtual server on the clean-side applicationswitch.

Client requests are forwarded or discarded according to rulesconfigured for each firewall.

Note: Rule sets must be consistent across all firewalls.

5 The clean-side application switch performs normal SLBfunctions.

Packets forwarded from the firewalls are sent to the originaldestination address, that is, the virtual server on the clean-sideapplication switch. There, they are load balanced to the real serversusing standard SLB configuration.

6 The real server responds to the client request.

7 Redirection filters on the clean-side application switch balanceresponses among different IP addresses.

Redirection filters are needed on all ports on the clean-sideapplication switch that attach to real servers or internal clients onthe clean-side of the network. Filters on these ports redirect theInternet-bound traffic to a real server group that consists of a numberof different IP addresses. Each IP address represents an IP interfaceon a different subnet on the dirty-side application switch.

8 Outbound traffic is routed to the firewalls.

Static routes are configured on the clean-side switch. One staticroute is needed for each stream that was configured on the dirty-sideapplication switch. For instance, the first static route would beconfigured to lead to the first dirty-side IP interface using the first




.


firewall as the next hop. The second static route would lead to thesecond dirty-side IP interface using the second firewall as the nexthop, and so on.

Since application switches intelligently maintain state information,all traffic between specific IP source/destination addresses flowsthrough the same firewall, maintaining session persistence.

Note: If Network Address Translation (NAT) software is usedon the firewalls, FWLB session persistence requires the RTSoption to be enabled on the application switch (see "Free-MetricFWLB" (page 701)).

9 The firewall decides if it should allow the packet and, if so,forwards it to the dirty-side application switch.

Each firewall forwards or discards the server responses according tothe rules that are configured for it. Forwarded packets are sent tothe dirty-side application switch and out to the Internet.

10 The client receives the server response.

—End—

Configuring Basic FWLBThe steps for configuring basic FWLB are provided below. While two orfour switches can be used, the following procedure assumes a simplenetwork topology with only two application switches (one on each side ofthe firewalls) as shown in "Basic FWLB Example Network" (page 672).

Basic FWLB Example Network




.


Configure the Dirty-Side Nortel Application Switch

Step Action

1 Configure VLANs.

Note: Alternately, if using hubs between the switches andfirewalls and you do not wish to configure VLANs, you mustenable Spanning Tree Protocol to prevent broadcast loops.

2 Define the dirty-side IP interface.

In addition to one IP interface for general switch management, theremust be one dirty-side IP interface for each firewall path being loadbalanced. Each must be on a different subnet.



(Set address for switchmanagement)


(Set subnet mask forinterface 1)


>> IP Interface 1# /cfg/l3/if 2 (Select IP interface 2)


(Set the IP address forinterface 2)










3 Configure the clean-side IP interface as if they were real serverson the dirty side.

Later in this procedure, you’ll configure one clean-side IP interfaceon a different subnet for each firewall path being load balanced. Onthe dirty-side application switch, create two real servers using the IPaddress of each clean-side IP interface used for FWLB.

Note: The real server index number must be the same on bothsides of the firewall. For example, if real server 1 is the dirty-side




.


IP interface for Firewall 1, then configure real server 1 on theclean side with the dirty-side IP interface. Configuring the samereal server number on both sides of the firewall ensures that thetraffic travels through the same firewall.

>> IP Interface 3# /cfg/slb/real 1

(Select real server 1)

>> Real server 1# rip 10.1.3.1 (Assign clean-side IF 2address)




>> Real server 2# rip 10.1.4.1 (Assign clean-side IF 3address)


Real servers in the server groups must be ordered the same onboth clean side and dirty side switch. For example, if real server 1IP interface connects to Firewall 1 for clean side server group, thenreal server 1 IP interface on the dirty side should be connected toFirewall 1. Selecting the same real server ensures that the traffictravels through the same firewall.

Note: Each of the four interfaces used for FWLB (two on eachapplication switch) in this example must be configured for adifferent IP subnet.

4 Place the IP interface real servers into a real server group.







5 Set the health check type for the real server group to ICMP.

>> Real server group 1#health icmp

(Select ICMP as health checktype)

6 Set the load-balancing metric for the real server group to hash.




.


>> Real server group 1# metrichash

(Select SLB hash metric forgroup 1)

Using the hash metric, all traffic between specific IPsource/destination address pairs flows through the same firewall.This ensures that sessions established by the firewalls aremaintained for their duration.

Note: Other load balancing metrics such as leastconns,roundrobin, minmiss, response, and bandwidth can be usedwhen enabling the Return to Sender (RTS) option. For moreinformation, see "Free-Metric FWLB" (page 701).

7 Enable SLB on the switch.

>> Real server group 1# /cfg/slb/on

8 Create a filter to allow local subnet traffic on the dirty side ofthe firewalls to reach the firewall interfaces.

>> Layer 4# /cfg/slb/filt 10 (Select filter 10)


>> Filter 10# dip 192.16.12.0 (Specify destination IPaddress)

>> Filter 10# dmask 255.255.255.0

(Specify destination mask)

>> Filter 10# action allow (Allow frames with this DIPaddress)

>> Filter 10# ena (Enable filter)

9 Create the FWLB redirection filter.

This filter will redirect inbound traffic, load balancing it among thedefined real servers in the group. In this network, the real serversrepresent IP interfaces on the clean-side application switch.

>> Filter 10# /cfg/slb/filt 15 (Select filter 15)



>> Filter 15# proto any (For any protocol)

>> Filter 15# action redir (Perform redirection)




.


>> Filter 15# group 1 (To real server group 1)


10 Enable firewall load balancing

>> Filter 15# adv/redir/fwlb ena

11 Add filters to the ingress port.


(Select the ingress port)

>> SLB Port 1# add 10 (Add the filter to the ingressport)


>> SLB Port 1# filt ena (Enable filtering on the port)

12 Define static routes to the clean-side IP interfaces, using thefirewalls as gateways.

One static route is required for each firewall path being loadbalanced. In this case, two paths are required: one that leads toclean-side IF 2 (10.1.3.1) through the first firewall (10.1.1.10) as itsgateway, and one that leads to clean-side IF 3 (10.1.4.1) through thesecond firewall (10.1.2.10) as its gateway.

>> SLB Port 5# /cfg/l3/route/ip4>> IP Static Route# add 10.1.3.1 255.255.255.25510.1.1.10>> IP Static Route# add 10.1.4.1 255.255.255.25510.1.2.10

13 Apply and save the configuration changes

>> # apply>> # save

—End—




.


Configure the Clean-Side Nortel Application Switch

Step Action

1 Define the clean-side IP interfaces.

Create one clean-side IP interface on a different subnet for eachfirewall being load balanced.

Note: An extra IP interface (IF 1) prevents server-to-servertraffic from being redirected.



















2 Configure the dirty-side IP interfaces as if they were realservers on the clean side.

You should already have configured a dirty-side IP interface on adifferent subnet for each firewall path being load balanced. Createtwo real servers on the clean-side switch, using the IP address ofeach dirty-side IP interface.

Note: The real server index number must be the same on bothsides of the firewall. For example, if real server 1 is the dirty-sideIP interface for Firewall 1, then configure real server 1 on theclean side with the dirty-side IP interface. Configuring the samereal server number on both sides of the firewall ensures that thetraffic travels through the same firewall.




.


>> IP Interface 5# /cfg/slb/real 1


>> Real server 1# rip 10.1.1.1 (Assign dirty-side IF 1address)




>> Real server 2# rip 10.1.2.1 (Assign dirty-side IF 2address)


Note: Each of the four IP interfaces (two on each applicationswitch) in this example must be configured for a different IPsubnet.

3 Place the real servers into a real server group.



>> Real server group 1# add 1 (Select real server 1 togroup 1)


4 Set the health check type for the real server group to ICMP.

>> Real server group 1# healthicmp

(Select ICMP as healthcheck type)

5 Set the load-balancing metric for the real server group to hash.



Note: The clean-side application switch must use the samemetric as defined on the dirty side.

6 Enable server load balancing on the switch.


7 Configure ports 2 and 3, which are connected to the clean-sideof the firewalls, for client processing.




.


>> Real server group 1# /cfg/slb/port 2/client ena(Enable client processing on port 2)

>> SLB port 2# /cfg/slb/port3/client ena

(Enable client processingon port 3)

>> SLB port 3# apply (Apply the configuration)

>> SLB port 3# save (Save the configuration)

8 Configure the virtual server that will load balance the realservers.

>> SLB port 3# /cfg/slb/virt100

(Configure virtual server100)

>> Virtual Server 100# vip20.1.1.10

(Assign virtual server 100IP address)


9 Configure the real servers to which traffic will be load-balanced.

These are the real servers on the network.

>> Real server group 1#/cfg/slb/real 3


>> Real server 2 # rip 20.1.1.2 (Assign real server 2 IPaddress)




>> Real server 3# ena 20.1.1.3 (Assign real server 3 IPaddress)

10 Place the real servers into a real server group.





11 Configure ports 4 and 5, which are connected to the realservers, for server processing.




.


>> Real server group 200# /cfg/slb/port 4/server ena>> SLB port 4# /cfg/slb/port 5/server ena

12 Enable server load balancing on the switch.


13 Create a filter to prevent server-to-server traffic from beingredirected.

>> Layer 4# /cfg/slb/filt 10 (Select filter 10)


>> Filter 10# dip 20.1.1.0 (To base IP address for IF 5)

>> Filter 10# dmask255.255.255.0

(For the range of addresses)


>> Filter 10# action allow (Allow traffic)


14 Create the redirection filter.

This filter will redirect outbound traffic, load balancing it among thedefined real servers in the group. In this case, the real serversrepresent IP interfaces on the dirty-side switch.





>> Filter 15# action redir (Perform redirection)

>> Filter 15# group 1 (To real server group 1)


15 Add the filters to the ingress ports for the outbound packets.

Redirection filters are needed on all the ingress ports on theclean-side application switch. Ingress ports are any that attach toreal servers or internal clients on the clean-side of the network. Inthis case, two real servers are attached to the clean-side applicationswitch on port 4 and port 5.




.



(Select ingress port 4)





(Select ingress port 5)




16 Define static routes to the dirty-side IP interfaces, using thefirewalls as gateways.

One static route is required for each firewall path being loadbalanced. In this case, two paths are required: one that leads todirty-side IF 2 (10.1.1.1) through the first firewall (10.1.3.10) as itsgateway, and one that leads to dirty-side IF 3 (10.1.2.1) through thesecond firewall (10.1.4.10) as its gateway.

>> SLB Port 5# /cfg/l3/route/ip4>> IP Static Route# add 10.1.1.1 255.255.255.25510.1.3.10>> IP Static Route# add 10.1.2.1 255.255.255.25510.1.4.10

Note: Configuring static routes for FWLB does not require IPforwarding to be turned on.

17 Apply and save the configuration changes

>> # apply>> # save

—End—




.


Four-Subnet FWLBThe four-subnet FWLB method is often deployed in large networks thatrequire high-availability solutions. This method uses filtering, static routing,and Virtual Router Redundancy Protocol (VRRP) to provide parallel firewalloperation between redundant application switches.

"Four-Subnet FWLB Topology" (page 682) shows one possible networktopology using the four-subnet method:

Four-Subnet FWLB Topology

This network is classified as a high-availability network because no singlecomponent or link failure could cause network resources to becomeunavailable. Simple switches and vertical block interswitch connections areused to provide multiple paths for network failover. However, the interswitchlinks may trunked together with multiple ports for additional protection fromfailure.

Note: Other topologies that use internal hubs, or diagonalcross-connections between the Nortel Application Switches andsimple switches are also possible. While such topologies may resolvenetworking issues in special circumstances, they can make configurationmore complex and can cause restrictions on the use of advancedfeatures such as Active-Active VRRP, free-metric FWLB, or ContentIntelligent Switching. Alternate topologies are explored in more detail inNortel Application Switch Operating System FWLB white papers, butare not within the scope of this manual.

As shown in "Four-Subnet FWLB Topology" (page 682), the network isdivided into four sections:

• Subnet 1 includes all equipment between the exterior routers anddirty-side application switches.

• Subnet 2 includes the dirty-side application switches with theirinterswitch link, and dirty-side firewall interfaces.




.


• Subnet 3 includes the clean-side firewall interfaces, and clean-sideapplication switches with their interswitch link.

• Subnet 4 includes all equipment between the clean-side applicationswitches and their servers.

In this network, external traffic arrives through both routers. Since VRRPis enabled, one of the dirty-side application switches acts as primary andreceives all traffic. The dirty-side primary application switch performs FWLBin a fashion similar to basic FWLB: a redirection filter splits traffic intomultiple streams which are routed through the available firewalls to theprimary clean-side application switch.

Just as with the basic method, four-subnet FWLB uses the hash metricto distribute firewall traffic and maintain persistence, though otherload-balancing metrics can be used by configuring an additional Return toSender (RTS) option (see "Free-Metric FWLB" (page 701)).

Four-Subnet FWLB ImplementationIn this example, traffic between the redundant Nortel Application Switchesis load balanced among the available firewalls.

Four-Subnet FWLB Process

Step Action

1 Incoming traffic converges on the primary dirty-side applicationswitch.

External traffic arrives through redundant routers. A set ofinterconnected switches ensures that both routers have a path toeach dirty-side application switch.




.


VRRP is configured on each dirty-side application switch so that oneacts as the primary routing switch. If the primary fails, the secondarytakes over.

2 FWLB is performed between primary application switches.

Just as with basic FWLB, filters on the ingress ports of the dirty-sideapplication switch redirect traffic to a real server group composedof multiple IP addresses. This configuration splits incoming trafficinto multiple streams. Each stream is then routed toward the primaryclean-side application switch through a different firewall.

Although other load balancing metrics can be used in someconfigurations (see "Free-Metric FWLB" (page 701)), the distributionof traffic within each stream is normally based on a mathematicalhash of the IP source and destination addresses. Hashing ensuresthat each request and its related responses will use the samefirewall (a feature known as persistence), and that the streams willbe statistically equal in traffic load.

3 The primary clean-side application switch forwards the trafficto its destination.

Once traffic arrives at the primary clean-side application switch, it isforwarded to its destination. In this example, the application switchuses regular server load balancing settings to select a real server onthe internal network for each incoming request.

The same process is used for outbound server responses; a filter onthe clean-side application switch splits the traffic, and static routesforward each response stream back through the same firewall thatforwarded the original request.

—End—

Configuring Four-Subnet FWLBAn example network for four-subnet FWLB is illustrated in "Four-SubnetFWLB Example Network" (page 685). While other complex topologies arepossible, this example assumes a high-availability network using block(rather than diagonal) interconnections between switches.




.


Four-Subnet FWLB Example Network

Note: The port designations of both dirty-side application switches areidentical, as are the port designations of both clean-side applicationswitches. This simplifies configuration by allowing you to synchronizeeach primary application switch’s configuration with the secondary.

Four-subnet FWLB configuration is summarized as follows:

• Configure routers and firewalls and test them for proper operation.

• Configure VLANs, IP interfaces, and static routes on all applicationswitches and test them.

• Configure secondary application switches with VRRP support settings.

• Configure FWLB groups and redirection filters on the primary dirty-sideapplication switch.

• Configure and synchronize VRRP on the primary dirty-side applicationswitch.

• Configure FWLB and SLB groups, and add FWLB redirection filters onthe primary clean-side application switch.

• Configure VRRP on the primary clean-side application switch andsynchronize the secondary.

These steps are explained in detail in the following sections.

Configure the RoutersThe routers must be configured with a static route to the destination servicesbeing accessed by the external clients.




.


In this example, the external clients intend to connect to services at apublicly advertised IP address on this network. Since the real servers areload balanced behind a virtual server on the clean-side application switchusing normal SLB settings, the routers require a static route to the virtualserver IP address. The next hop for this static route is the application switchVirtual Interface Router (VIR), which is in the same subnet as the routers:

Route Added: 10.10.4.100 (to clean-side virtual server) via195.1.1.9 (Subnet 1 VIR)

Configure the FirewallsBefore you configure theNortel Application Switches, the firewalls must beproperly configured. For incoming traffic, each firewall must be configuredwith a static route to the clean-side virtual server, using the VIR in itsclean-side subnet as the next hop. For outbound traffic, each firewall mustuse the VIR in its dirty-side subnet as the default gateway.

In this example, the firewalls are configured with the following IP addresses:

Four-Subnet Firewall IP Address Configuration

Item Address

Firewall 1

Dirty-side IP interface

Clean-side IP interface

Default Gateway

Route Added

10.10.2.3

10.10.3.3

10.10.2.9 (Subnet 2 VIR)

10.10.4.100 (virtual server) via 10.10.3.9 (Subnet3 VIR)

Firewall 2

Dirty-side IP interface

Clean-side IP interface

Default Gateway

Route Added

10.10.2.4

10.10.3.4

10.10.2.9 (dirty-side VIR)

10.10.4.100 (virtual server) via 10.10.3.9 (Subnet3 VIR)

The firewalls must also be configured with rules that determine which typesof traffic will be forwarded through the firewall and which will be dropped.All firewalls participating in FWLB must be configured with the same setof rules.




.


Note: It is important to test the behavior of the firewalls prior to addingFWLB.

Configure the Primary Dirty-Side Switch

Step Action

1 Configure VLANs on the primary dirty-side application switch.

Two VLANs are required. VLAN 1 includes port 25, for the Internetconnection. VLAN 2 includes port 26, for the firewall connection,and port 28, for the interswitch connection.

>> # /cfg/l2/vlan 2

>> # add 26 (Port 26 connects to the firewall)

>> # add 28 (Port 28 is the inter-switchconnection)

>> # ena

Note: Port 25 is part of VLAN 1 by default and does not requiremanual configuration.

2 Configure IP interfaces on the primary dirty-side applicationswitch.

Three IP interfaces (IF’s) are used. IF 1 is on placed on Subnet 1. IF2 will be used for routing traffic through the top firewall. IF 3 will beused for routing traffic through the lower firewall. To avoid confusion,IF 2 and IF 3 will be used in the same way on all application switches.

>> # /cfg/l3/if 1>> # mask 255.255.255.0>> # addr 195.1.1.10>> # ena>> # /cfg/l3/if 2>> # mask 255.255.255.0>> # addr 10.10.2.1>> # vlan 2>> # ena>> # /cfg/l3/if 3>> # mask 255.255.255.255>> # addr 10.10.2.2>> # vlan 2>> # ena

Note: By configuring the IP interface mask prior to the IPaddress, the broadcast address is automatically calculated. Also,




.


only the first IP interface in a given subnet is given the full subnetrange mask. Subsequent IP interfaces (such as IF 3) are givenindividual masks.

3 Turn Spanning Tree Protocol (STP) off for the primary dirty-sideapplication switch.

>> # /cfg/l2/stg #/off

4 Configure static routes on the primary dirty-side applicationswitch.

Four static routes are required:

• To primary clean-side IF 2 via Firewall 1 using dirty-side IF 2

• To primary clean-side IF 3 via Firewall 2 using dirty-side IF 3

• To secondary clean-side IF 2 via Firewall 1 using dirty-side IF 2

• To secondary clean-side IF 3 via Firewall 2 using dirty-side IF 3

Note: Remember, IF 2 is being used on all application switcheswhenever routing through the top firewall, and IF 3 is being usedon all application switches whenever routing through the lowerfirewall.

The static route add command uses the following format:

add <destination address> <dest. mask> <gatewayaddress> <source interface>

This example requires the following static route configuration:

>> # /cfg/l3/frwd/route>> # add 10.10.3.1 255.255.255.255 10.10.2.3 2>> # add 10.10.3.2 255.255.255.255 10.10.2.4 3>> # add 10.10.3.11 255.255.255.255 10.10.2.3 2>> # add 10.10.3.12 255.255.255.255 10.10.2.4 3

Note: When defining static routes for FWLB, it is important tospecify the source IP interface numbers.

5 When dynamic routing protocols are not used, configure agateway to the external routers.

>> # /cfg/l3/gw 1/addr 195.1.1.1>> # /cfg/l3/gw 2/addr 195.1.1.2

6 Make your changes take effect.




.


>> # apply>> # save>> # /boot/reset

—End—

Configure the Secondary Dirty-Side SwitchExcept for the IP interfaces, this configuration is identical to the primarydirty-side application switch.

Step Action

1 Configure VLANs on the secondary dirty-side applicationswitch.

>> # /cfg/l2/vlan 2>> # add 26>> # add 28>> # ena

2 Configure IP interfaces on the secondary dirty-side applicationswitch.

>> # /cfg/l3/if 1>> # mask 255.255.255.0>> # addr 195.1.1.11>> # ena>> # /cfg/l3/if 2>> # mask 255.255.255.0>> # addr 10.10.2.11>> # vlan 2>> # ena>> # /cfg/l3/if 3>> # mask 255.255.255.255>> # addr 10.10.2.12>> # vlan 2>> # ena

3 Turn STP off for the secondary dirty-side application switch.


4 Configure static routes on the secondary dirty-side applicationswitch.




.



5 When dynamic routing protocols are not used, configure agateway to the external routers on the secondary dirty-sideswitch.

>> # /cfg/l3/gw 1/addr 195.1.1.1>> # /cfg/l3/gw 2/addr 195.1.1.2



—End—

Configure the Primary Clean-Side Switch

Step Action

1 Configure VLANs on the primary clean-side application switch.

Two VLANs are required. VLAN 3 includes the firewall port andinterswitch connection port. VLAN 4 includes the port that attachesto the real servers.

>> # /cfg/l2/vlan 3>> # add 25>> # add 28>> # ena>> # /cfg/l2/vlan 4>> # add 26>> # ena

2 Configure IP interfaces on the primary clean-side applicationswitch.




.


>> # /cfg/l3/if 1>> # mask 255.255.255.0>> # addr 10.10.4.10>> # vlan 4>> # ena>> # /cfg/l3/if 2>> # mask 255.255.255.0>> # addr 10.10.3.1>> # vlan 3>> # ena>> # /cfg/l3/if 3>> # mask 255.255.255.255>> # addr 10.10.3.2>> # vlan 3>> # ena

3 Turn STP off for the primary clean-side application switch.

>> # /cfg/l2/stg/off

Spanning Tree Protocol is disabled because VLANs preventbroadcast loops.

4 Configure static routes on the primary clean-side applicationswitch.

Four static routes are needed:

• To primary dirty-side IF 2 via Firewall 1 using clean-side IF 2

• To primary dirty-side IF 3 via Firewall 2 using clean-side IF 3

• To secondary dirty-side IF 2 via Firewall 1 using clean-side IF 2

• To secondary dirty-side IF 3 via Firewall 2 using clean-side IF 3

The static route add command uses the following format:

add <destination address> <dest. mask> <gatewayaddress> <source interface>

This example requires the following static route configuration:






.



—End—

Configure the Secondary Clean-Side Switch

Step Action

1 Configure VLANs on the secondary clean-side applicationswitch.

>> # /cfg/l2/vlan 3>> # add 25>> # add 28>> # ena>> # /cfg/l2/vlan 4>> # add 26>> # ena

2 Configure IP interfaces on the secondary clean-side applicationswitch.

>> # /cfg/l3/if 1>> # mask 255.255.255.0>> # addr 10.10.4.11>> # vlan 4>> # ena>> # /cfg/l3/if 2>> # mask 255.255.255.0>> # addr 10.10.3.11>> # vlan 3>> # ena>> # /cfg/l3/if 3>> # mask 255.255.255.255>> # addr 10.10.3.12>> # vlan 3>> # ena

3 Turn STP off for the secondary clean-side application switch.





.


Spanning Tree Protocol is disabled because VLANs preventbroadcast loops.

4 Configure static routes on the secondary clean-side applicationswitch.




—End—

Verify Proper ConnectivityTo verify proper configuration up to this point, use the ping option to testnetwork connectivity. At each Nortel Application Switch, you should receivea valid response when pinging the destination addresses established inthe static routes.

For example, on the secondary clean-side application switch, the followingcommands should receive a valid response:

>> # ping 10.10.2.1Response; 10.10.2.1: #1 OK, RTT 1 msec.>> # ping 10.10.2.2Response; 10.10.2.2: #1 OK, RTT 1 msec.>> # ping 10.10.2.11Response; 10.10.2.11: #1 OK, RTT 1 msec.>> # ping 10.10.2.12Response; 10.10.2.12: #1 OK, RTT 1 msec.

Configure VRRP on the Secondary Dirty-Side SwitchThe secondary dirty-side application switch must be configured with theprimary as its peer. Once this is done, the secondary application switch willget the remainder of its configuration from the primary when synchronizedin a later step.




.


In this example, the secondary application switch is configured to useprimary dirty-side interface 1 as its peer.

>> # /cfg/l3/vrrp/on>> # /cfg/slb>> # on>> # sync/peer 1>> # addr 195.1.1.10>> # ena>> # apply>> # save

Configure VRRP on the Secondary Clean-Side SwitchIn this example, the secondary application switch uses primary clean-sideinterface 1 as its peer.

>> # /cfg/l3/vrrp/on>> # /cfg/slb>> # on>> # sync/peer 1>> # addr 10.10.4.10>> # ena>> # apply>> # save

Complete Primary Dirty-Side Switch Configuration

Step Action

1 Create an FWLB real server group on the primary dirty-sideapplication switch.

A real server group is used as the target for the FWLB redirectionfilter. Each IP address that is assigned to the group represents apath through a different firewall. In this case, since two firewalls areused, two addresses are added to the group.

Earlier, it was stated that this example uses IF 2 on all applicationswitches whenever routing through the top firewall, and IF 3 on allapplication switches whenever routing through the lower firewall.Therefore, the first address will represent the primary clean-side IF2, and the second represents the primary clean-side IF 3.




.


>> # /cfg/slb>> # on>> # real 1>> # rip 10.10.3.1>> # ena>> # /cfg/slb/real 2>> # rip 10.10.3.2>> # ena>> # /cfg/slb/group 1>> # add 1>> # add 2>> # metric hash

Using the hash metric, all traffic between specific IPsource/destination address pairs flows through the same firewall,ensuring that sessions established by the firewalls are maintainedfor their duration (persistence).

Note: Other load balancing metrics, such as leastconns,roundrobin, minmiss, response, and bandwidth, can be usedwhen enabling the Return to Sender (RTS) option. For moreinformation, see "Free-Metric FWLB" (page 701).

2 Create the FWLB filters.

Three filters are required on the port attaching to the routers:

• Filter 10 prevents local traffic from being redirected.

• Filter 20 prevents VRRP traffic (and other multicast traffic on thereserved 224.0.0.0/24 network) from being redirected.

• Filter 2048 redirects the remaining traffic to the firewall group.

>> # /cfg/slb/filt 10>> # dip 195.1.1.0>> # dmask 255.255.255.0>> # ena>> # /cfg/slb/filt 20>> # dip 224.0.0.0>> # dmask 255.255.255.0>> # ena>> # /cfg/slb/filt 2048>> # action redir>> # group 1>> # ena>> # /cfg/slb/port 1>> # filt ena>> # add 10>> # add 20>> # add 2048




.


3 Configure VRRP on the primary dirty-side application switch.

VRRP in this example requires two virtual routers–one for thesubnet attached to the routers, and one for the subnet attached tothe firewalls.

>> # /cfg/l3/vrrp>> # on>> # vr 1

>> # vrid 1 (Configure virtual router 1)

>> # addr 195.1.1.9 (For the subnet attached to therouters)

>> # if 1>> # prio 101>> # share dis>> # ena>> # track>> # ifs ena>> # ports ena>> # /cfg/l3/vrrp/vr 2

>> # vrid 2 (Configure virtual router 2)

>> # addr 10.10.2.9 (For the subnet attached to thefirewall)

>> # if 2>> # prio 101>> # share dis>> # ena>> # track>> # ifs ena>> # ports ena

4 Configure the VRRP peer on the primary dirty-side applicationswitch.

>> # /cfg/slb/sync>> # prios d>> # peer 1>> # ena>> # addr 195.1.1.11


>> # apply>> # save




.


6 Synchronize primary and secondary dirty-side applicationswitches for the VRRP configuration.

>> # /oper/slb/sync

—End—

Complete Primary Clean-Side Switch Configuration

Step Action

1 Create an FWLB real server group on the primary clean-sideapplication switch.

A real server group is used as the target for the FWLB redirectionfilter. Each IP address assigned to the group represents a returnpath through a different firewall. In this case, since two firewalls areused, two addresses are added to the group. The two addresses arethe interfaces of the dirty-side application switch, and are configuredas if they are real servers.

Note: IF 2 is used on all application switches whenever routingthrough the top firewall, and IF 3 is used on all applicationswitches whenever routing through the lower firewall.

>> # /cfg/slb>> # on>> # real 1

>> # rip 10.10.2.1 (IF2 of the primary dirty-side applicationswitch)

>> # ena>> # /cfg/slb/real 2

>> # rip 10.10.2.2 (IF2 of the primary dirty-side applicationswitch)

>> # ena>> # /cfg/slb/group 1>> # add 1>> # add 2>> # metric hash

Note: The clean-side application switch must use the samemetric as defined on the dirty side. For information on usingmetrics other than hash, see "Free-Metric FWLB" (page 701).




.


2 Create an SLB real server group on the primary clean-sideapplication switch, to which traffic will be load-balanced.

The external clients intend to connect to HTTP services at a publiclyadvertised IP address. The servers on this network are loadbalanced by a virtual server on the clean-side application switch.SLB options are configured as follows:

>> # /cfg/slb (Select the SLB menu)

>> # real 20 (Select real server 20)

>> # rip 10.10.4.20 (Set IP address of real server 20)

>> # ena (Enable)

>> # /cfg/slb/real 21 (Select real server 21)


>> # ena (Enable)

>> # /cfg/slb/real 22 (Select real server 22)


>> # ena (Enable)


>> # add 20 (Add the real servers to the group)

>> # add 21

>> # add 22

>> # metric leastconns (Select least connections as theload balancing metric)

>> # /cfg/slb/virt 1 (Select the virtual server 1 menu)

>> # vip 10.10.4.100 (Set the virtual server IP address)

>> # service http (Select HTTP for load balancing)

>> # group 2 (Add real server group 2)

>> # ena (Enable the virtual server)

>> # /cfg/slb/port26/server ena

(Enable server processing on theport connected to the real servers)

>> # /cfg/slb/port25/client ena

(Enable client processing on theport connected to the firewall)

>> # /cfg/slb/port28/client ena

(Enable client processing on theinterswitch connection)

Note: The virtual server IP address configured in this step willalso be configured as a Virtual Server Router (VSR) when VRRPis configured in a later step.




.


3 Create the FWLB filters on the primary clean-side applicationswitch.

Three filters are required on the port attaching to the real servers:

• Filter 10 prevents local traffic from being redirected.

• Filter 20 prevents VRRP traffic from being redirected.

• Filter 2048 redirects the remaining traffic to the firewall group.

>> # /cfg/slb/filt 10>> # dip 10.10.4.0>> # dmask 255.255.255.0>> # ena>> # /cfg/slb/filt 20>> # dip 224.0.0.0>> # dmask 255.255.255.0>> # ena>> # /cfg/slb/filt 2048>> # action redir>> # group 1>> # ena>> # /cfg/slb/port 4>> # filt ena>> # add 10>> # add 20>> # add 2048

4 Configure VRRP on the primary clean-side application switch.

VRRP in this example requires two virtual routers to beconfigured–one for the subnet attached to the real servers, and onefor the subnet attached to the firewalls.

>> # /cfg/l3/vrrp>> # on>> # vr 1>> # vrid 3>> # addr 10.10.4.9>> # if 1>> # prio 100>> # share dis>> # ena>> # track>> # ifs ena>> # ports ena>> # /cfg/l3/vrrp/vr 2>> # vrid 4>> # addr 10.10.3.9>> # if 2>> # prio 101




.


>> # share dis>> # ena>> # track>> # ifs ena>> # ports ena

A third virtual router is required for the virtual server used for optionalSLB.

>> # /cfg/l3/vrrp/vr 3>> # vrid 5>> # addr 10.10.4.100>> # prio 102>> # share dis>> # ena>> # track>> # ifs ena>> # ports ena

5 Configure the peer on the primary clean-side application switch.

>> # /cfg/slb/sync>> # prios d>> # peer 1>> # ena>> # addr 10.10.4.11


>> # apply>> # save

7 Synchronize primary and secondary dirty-side applicationswitches for the VRRP configuration.

>> # /oper/slb/sync

—End—




.


Advanced FWLB ConceptsFree-Metric FWLB

Free-metric FWLB allows to you use load-balancing metrics other than hash,such as leastconns, roundrobin, minmiss, response, and bandwidth formore versatility. The free-metric method uses the Return to Sender (RTS)option. RTS can be used with basic FWLB or four-subnet FWLB networks.

Free-Metric with Basic FWLBFor this example, review the basic FWLB example network.

Basic FWLB Example Network

To use free-metric FWLB in this network, the following configurationchanges are necessary.

Step Action

1 On the clean-side application switch, enable RTS on the portsattached to the firewalls (ports 2 and 3).

Enable filter and server processing on ports 2 and 3, so that theresponses from the real server are looked up in the session table.

>> # /cfg/slb/port 2/rts enable>> # /cfg/slb/port 3/rts enable

2 On the clean-side application switch, remove the redirectionfilter from the ports attached to the real servers (ports 4 and 5),but make sure filter processing is enabled.

The redirection filter is removed so that the return packet traversesthrough the same firewall. If the firewalls synchronize their states,then it is not required to remove the redirection filter. Filterprocessing is enabled to make use of the RTS-created sessions.




.


>> # /cfg/slb/port 4/rem 2048>> # filt ena>> # /cfg/slb/port 5/rem 2048>> # filt ena

Make sure to use the hash metric if the session is from an FTP orRTSP servers.

3 On the dirty-side application switch, set the FWLB metric.

>> # /cfg/slb/group 1>> # metric <metric type>

Any of the following load-balancing metrics can be used: hash,leastconns, roundrobin, minmiss, response, and bandwidth. See"Metrics for Real Server Groups" (page 202) for details on usingeach metric.

Note: Some metrics allow other options (such as weights) tobe configured.

—End—

Free-Metric with Four-Subnet FWLBFor this example, review the four-subnet example network.

Four-Subnet FWLB Example Network




.


To use free-metric FWLB in this network, the following configurationchanges are necessary.

Step Action

1 On the clean-side application switches, enable RTS on theports attached to the firewalls (port 3) and on the interswitchport (port 9).

Enable filter and server processing on ports 3 and 9, so that theresponses from the real server are looked up in the session table.

On both clean-side switches:

>> # /cfg/slb/port 3/rts enable>> # /cfg/slb/port 9/rts enable

2 On the clean-side application switches, remove the redirectionfilter from the ports attached to the real servers (ports 4), butmake sure filter processing is enabled.

To view the original redirection filters that were configured for thefour-subnet example, see Step step 3.

On both clean-side switches:

>> # /cfg/slb/port 4/rem 2048>> # filt ena

3 On the dirty-side application switches, set the FWLB metric.

On both dirty-side application switches:

>> # /cfg/slb/group 1>> # metric <metric type>

Any of the following load-balancing metrics can be used: hash,leastconns, roundrobin, minmiss, response, and bandwidth. See"Metrics for Real Server Groups" (page 202) for details on usingeach metric.

Note: Some metrics allow other options (such as weights) tobe configured.

—End—




.


Adding a Demilitarized Zone (DMZ)Implementing a DMZ in conjunction with firewall load balancing enables theNortel Application Switch to do the traffic filtering, off-loading this task fromthe firewall. A DMZ is created by configuring FWLB with another real servergroup and a redirection filter towards the DMZ subnets.

The DMZ servers can be connected to the application switch on the dirtyside of the firewall. A typical firewall load balancing configuration with aDMZ is shown in "Typical Firewall Load-Balancing Topology with DMZ"(page 704).

Typical Firewall Load-Balancing Topology with DMZ

The DMZ servers can be attached to the application switch directly orthrough an intermediate hub or switch. The application switch is thenconfigured with filters to permit or deny access to the DMZ servers. In thismanner, two levels of security are implemented: one that restricts accessto the DMZ through the use of application switch filters, and another thatrestricts access to the clean network through the use of stateful inspectionperformed by the firewalls.

You could add the filters required for the DMZ (to each application switch)as follows:

Step Action

1 On the dirty-side application switch, create the filter to allowHTTP traffic to reach the DMZ Web servers.

In this example, the DMZ Web servers use IP addresses205.178.29.0/24.

>> # /cfg/slb/filt 80 (Select filter 80)





.


>> Filter 80# dip205.178.29.0

(To the DMZ base destination)

>> Filter 80# dmask255.255.255.0

(For the range of DMZ addresses)



>> Filter 80# dport http (To an HTTP destination port)

>> Filter 80# action allow (Allow the traffic)


2 Create another filter to deny all other traffic to the DMZ Webservers.



>> Filter 89# dip 205.178.29.0 (To the DMZ basedestination)

>> Filter 89# dmask 255.255.255.0

(For the range of DMZaddresses)

>> Filter 89# proto any (For TCP protocol traffic)

>> Filter 89# action deny (Allow the traffic)


Note: The deny filter has a higher filter number than the allowfilter. This is necessary so that the allow filter has the higherorder of precedence.

3 Add the filters to the traffic ingress ports.

>> Filter 89# /cfg/slb/port 1 (Select the ingress port)

>> SLB Port 1# add 80 (Add the allow filter)

>> SLB Port 1# add 89 (Add the deny filter)



—End—




.


Firewall Health ChecksBasic FWLB health checking is automatic. No special configuration isnecessary unless you wish to tune the health checking parameters. See"Health Checking" (page 463) " for details.

Firewall Service MonitoringTo maintain high availability, application switches monitor firewall healthstatus and send packets only to healthy firewalls. There are two methodsof firewall service monitoring: ICMP and HTTP. Each application switchmonitors the health of the firewalls on a regular basis by pinging the IPinterfaces configured on its partner application switch on the other side ofthe firewall.

If an application switch IP interface fails to respond to a user-specifiednumber of pings, it (and, by implication, the associated firewall), is placedin a Server Failed state. At this time, the partner application switch stopsrouting traffic to that IP interface and, instead, distributes it across theremaining healthy application switch IP interfaces and firewalls.

When an application switch IP interface is in the Server Failed state, itspartner application switch continues to send pings to it at user-configurableintervals. After a specified number of successful pings, the IP interface (andits associated firewall) is brought back into service.

For example, to configure the switch to allow one-second intervals betweenhealth checks or pings, two failed health checks to remove the firewall,and four successful health checks to restore the firewall to the real servergroup, use the following command:

>> /cfg/slb/real <real server number> /inter 1/retry 2/restr4

Physical Link MonitoringNortel Application Switches also monitor physical link status of switch portsconnected to firewalls. If the physical link to a firewall goes down, thatfirewall is placed immediately in the Server Failed state. When a NortelApplication Switch detects that a failed physical link to a firewall has beenrestored, it brings the firewall back into service.

Using HTTP Health ChecksFor those firewalls that do not permit ICMP pings to pass through,application switches can be configured to perform HTTP health checks,as described below.




.


Step Action

1 Set the health check type to HTTP instead of ICMP.

>> # /cfg/slb/group 1/healthhttp

(Select HTTP healthchecks)

2 Enable HTTP access to the switch.

>> # /cfg/sys/access/http ena (Enable HTTP)

3 Configure a "dummy" redirect filter as the last filter (after theredirect all filter) to force the HTTP health checks to activate,as shown below:

>> # /cfg/slb/filt 2048 (Select filter 2048)


>> Filter 2048# action redir (Redirect the traffic)

>> Filter 2048# group 1 (Set real server group forredirection)

>> Filter 2048# rport http (Set real server port forredirection)


Note: Make sure that the number of each real filter is lower thanthe number of the "dummy" redirect filter.

4 Apply filter to the port directed to the firewall.

>> # /cfg/slb/port #/add 2048 (Add the dummy filter)

In addition to HTTP, Nortel Application Switch Operating Systemallows you to configure up to 5 different TCP services to listen forhealth checks. For example, you can configure FTP and SMTP portsto perform health checks. Refer to "Well-Known Application Ports"(page 199) for a list of other well-known application ports.

—End—




.


Virtual Private Network Load Balancing

The VPN (Virtual Private Network) load balancing feature in NortelApplication Switch Operating System allows the switch to load balancesimultaneously up to 255 VPN devices. The switch records from which VPNserver a session was initiated and ensures that the traffic returns back tothe same VPN server from which the session started.



This section describes a VPN network and how VPN load balancingworks on an Nortel Application Switch.

• "VPN Load-Balancing Configuration" (page 711)

This section provides step-by-step instructions to configure VPN loadbalancing on a four- subnet network with four application switches andtwo VPN devices.

OverviewA VPN is a connection that has the appearance and advantages of adedicated link, but it occurs over a shared network. Using a techniquecalled tunneling, data packets are transmitted across a routed network,such as the Internet, in a private tunnel that simulates a point-to-pointconnection. This approach enables network traffic from many sources totravel via separate tunnels across the infrastructure. It also enables trafficfrom many sources to be differentiated, so that it can be directed to specificdestinations and receive specific levels of service.

VPNs provide security features of a firewall, network address translation,data encryption, and authentication and authorization. Since most of thedata sent between VPN initiators and terminators is encrypted, networkdevices cannot use information inside the packet to make intelligent routingdecisions.

How VPN Load Balancing WorksVPN load balancing requires that all ingress traffic passing through aparticular VPN must traverse the same VPN as it egresses back to theclient. Traffic ingressing from the Internet is usually addressed to the VPNs,with the real destination encrypted inside the datagram. Traffic egressingthe VPNs into the intranet contains the real destination in the clear.




.

Virtual Private Network Load Balancing 709

In many VPN/firewall configurations it may not be possible to use the hashalgorithm on the source and destination address, because the address maybe encrypted inside the datagram. Also, the source/destination IP addressof the packet may change as the packet traverses from the dirty-sideswitches to clean-side switches and back.

To support VPN load balancing, the Nortel Application Switch records stateon frames entering the switch to and from the VPNs. This session tableensures that the same VPN server handles all the traffic between an insidehost and an outside client for a particular session.

Note: VPN load balancing is supported for connecting from remotesites to the network behind the VPN cluster IP address. Connectioninitiated from clients internal to the VPN gateways is not supported.

Basic frame flow, from the dirty side of the network to the clean side, isshown in "Basic Network Frame Flow and Operation" (page 709). Anexternal client is accessing an internal server. The VPN devices do notperform Network Address Translation (NAT).

Basic Network Frame Flow and Operation

The basic steps that occur at the switches when a request arrives fromthe Internet are described below:




.


Step Action

1 The client prepares to send traffic to the destination real server(with IP address E10).

2 The VPN client software encrypts the packet and sends it to thecluster IP address (D3) of the VPN devices.

3 Nortel Application Switch 1 makes an entry in the session tableand forwards the packet to VPN device 1.

It is recommended to use the hash load-balancing metric to selectthe VPN device.

4 The VPN device 1 strips the IP header and decrypts theencrypted IP header.

5 Nortel Application Switch 2 forwards the packet to the realserver.

—End—

If an entry is found, the frame is forwarded normally. If an entry is not found,the switch determines which VPN device processed the frame by performinga lookup with the source MAC address of the frame. If the MAC addressmatches a MAC address of a VPN device, the switch adds an entry to thesession table so that reverse traffic is redirected to the same VPN device.

VPN Load Balancing PersistenceVPN load balancing persistence ensures that VPN sessions that exist in aload balanced environment retain their persistence with the load balancedserver.

Since both the ISAKMP and IPSec protocols are used in a VPNenvironment, load balancing such an environment involves maintainingpersistence for two protocols. For each user VPN login, the securityassociations must be established and key exchanges performed using theISAKMP protocol before the IPSec protocols can be sent securely. Theswitch will redirect the ISAKMP request to a load balanced VPN serverand create a session. Subsequent ISAKMP requests will be sent to thissession. When the associated IPSec session arrives, the switch will lookfor the associated ISAKMP session using session lookup so that it can beload balanced to the same server. If the ISAKMP session is not found,the IPSec session will be bound to a VPN server according to previouslyconfigured load balancing metrics.




.


VPN Load-Balancing ConfigurationBefore you start configuring the switch for VPN load balancing, do thefollowing:

• Configure the switch with firewall load balancing. For more information,see "Firewall Load Balancing" (page 667).

• Enable the Return to Sender (RTS) feature on the ports attached to theVPN devices, using the following command:

>> # /cfg/slb/port <port number> /rts ena

The following example illustrates VPN load balancing with two VPN devicesand four Nortel Application Switches in a four subnet scenario.

VPN Load-Balancing Configuration Example

Build the topology illustrated in "VPN Load-Balancing ConfigurationExample" (page 711), and configure the switches as shown in the followingsections.




.


Configure the First Clean-Side Application Switch-CA

Step Action

1 Turn off BOOTP.

>> # /cfg/sys/bootp dis

2 Define and enable VLAN 2 for ports 25, and 26.

>> # /cfg/l2/vlan 2/ena/def 25 26

3 Turn off Spanning Tree Protocol (STP).



Create one clean-side IP interface on a different subnet for eachVPN device being load balanced.

>> # /cfg/l3/if 1/ena (Select IP interface 1 andenable)


(Set subnet mask for interface1)


(Set IP address for interface 1)

>> IP Interface 1# vlan 1 (For VLAN 1)

>> IP Interface 1#/cfg/l3/if 2/ena

(Select IP interface 2 andenable)






>> IP Interface 2#/cfg/l3/if 3/ena

(Select IP interface 3 andenable)









.


5 Configure routes for each of the IP interfaces you configured inStep 4 using the VPN devices as gateways.

One static route for redirection is required for each VPN devicebeing load balanced.

>> # /cfg/l3/route

>> IP Static Route# add10.0.0.10

(Static route destination IPaddress)

>> IP Static Route# 255.255.255.255

(Destination subnet mask)

>> IP Static Route# 20.0.0.101 (Enter gateway IP address)

>> IP Static Route# 2 (For interface 2)


(Enter destination IPaddress)

>> IP Static Route# 255.255.255.255





(Enter destination IPaddress)

>> IP Static Route# 255.255.255.255





(Static route destination IPaddress)

>> IP Static Route# 255.255.255.255




6 Configure VRRP for virtual routers 1 and 2.

>> # /cfg/l3/vrrp/on (Enable VRRP)

>> Virtual Router RedundancyProtocol# vr 1

(Select virtual router 1menu)

>> VRRP Virtual Router 1# ena (Enable the virtual router)


(Assign virtual router ID 1)

>> VRRP Virtual Router 1# if 1 (To interface number 1)




.


>> VRRP Virtual Router 1# prio101

(Set the renter priority)

>> VRRP Virtual Router 1# addr30.0.0.50

(Set IP address of virtualrouter)


(Disable sharing)

>> VRRP Virtual Router 1# track (Select virtual routertracking menu)

>> VRRP VR 1 Priority Tracking#vrs ena

(Enable tracking of virtualrouters)

>> VRRP VR 1 Priority Tracking#apply


>> VRRP VR 1 Priority Tracking#save

(Save the configuration)

>> VRRP VR 1 Priority Tracking# /cfg/l3/vrrp/vr 2(Select virtual router 2 menu)

>> VRRP Virtual Router 2# ena (Enable the virtual router)


(Assign virtual router ID 2)

>> VRRP Virtual Router 2# if 2 (To interface number 2)

>> VRRP Virtual Router 2# prio101

(Set the renter priority)

>> VRRP Virtual Router 2# addr20.0.0.1

(Set IP address of virtualrouter)


(Disable sharing)

>> VRRP Virtual Router 2# track (Select Virtual RouterTracking Menu)

>> VRRP VR 2 Priority Tracking#ports ena

(Track VLAN switch ports)

>> VRRP VR 2 Priority Tracking#apply


>> VRRP VR 2 Priority Tracking#save

(Save the configuration)

7 Enable Server Load Balancing (SLB) on the first clean switch.

>> # /cfg/slb/on

8 Configure real servers for health checking VPN devices.




.


>> # /cfg/slb/real 1/ena (Enable slb for real server1)


(Assign IP address for realserver 1)

>> Real server 1 # /cfg/slb/real 2/ena

(Enable SLB for real server2)











9 Configure real server group 1, and add real servers 1, 2, 3, and4 to the group.

>> # /cfg/slb/group 1 (Configure real server group1)



>> Real server group 1# add 1 (Add real servers 1-4 togroup 1)

>> Real server group 1# add 2/add 3/add 4

10 Enable RTS on the necessary ports.

>> # /cfg/slb/port 26/rts ena (Enable Return to Senderon port 26)

>> # /cfg/slb/port 25/rts ena (Enable Return to Senderon port 25)

11 Enable filter processing on the server ports so that theresponses from the real server is looked up in the VPN sessiontable.

>> # /cfg/slb/port 1/filt ena




.


12 When dynamic routing protocols are not used, configure agateway to the external router.

>> # /cfg/l3/gw 1/addr 192.168.10.50

13 Apply and save the configuration, and reboot the switch.


—End—

Configure the Second Clean-Side Application Switch-CB

Step Action

1 Turn off bootp.


2 Define and enable VLAN 2 for ports 25 and 26.


3 Turn off Spanning Tree Protocol.



Create one clean-side IP interface on a different subnet for eachVPN device being load balanced.

>> # /cfg/l3/if 1/ena/mask 255.255.255.0/addr30.0.0.11>> # /cfg/l3/if 2/ena/mask 255.255.255.0/addr20.0.0.20/vl 2>> # /cfg/l3/if 3/ena/mask 255.255.255.255/addr20.0.0.21/vl 2

5 Configure routes for each of the IP interfaces you configured inStep 4, using the VPN devices as gateways.




.


One static route is required for each VPN device being loadbalanced.

>> # /cfg/l3/route>> # add 10.0.0.10 255.255.255.255 20.0.0.101 2>> # add 10.0.0.11 255.255.255.255 20.0.0.102 3>> # add 10.0.0.20 255.255.255.255 20.0.0.101 2>> # add 10.0.0.21 255.255.255.255 20.0.0.102 3

6 Configure Virtual Router Redundancy Protocol (VRRP) forvirtual routers 1 and 2.

>> # /cfg/l3/vrrp/on>> Virtual Router Redundancy Protocol# vr 1>> VRRP Virtual Router 1# ena>> VRRP Virtual Router 1# vrid 1>> VRRP Virtual Router 1# if 1>> VRRP Virtual Router 1# addr 30.0.0.50>> VRRP Virtual Router 1# share dis>> VRRP Virtual Router 1# track/vrs ena>> VRRP Virtual Router 1 Priority Tracking#/cfg/l3/vrrp/vr 2>> VRRP Virtual Router 2# ena>> VRRP Virtual Router 2# vrid 2>> VRRP Virtual Router 2# if 2>> VRRP Virtual Router 2# addr 20.0.0.1>> VRRP Virtual Router 2# share dis>> VRRP Virtual Router 2# track/ports ena

7 Enable SLB.

>> VRRP Virtual Router 2 Priority Tracking#/cfg/slb/on


>> Layer 4# /cfg/slb/real 1/ena/rip 10.0.0.10>> Real server 1# /cfg/slb/real 2/ena/rip 10.0.0.11>> Real server 2# /cfg/slb/real 3/ena/rip 10.0.0.20>> Real server 3# /cfg/slb/real 4/ena/rip 10.0.0.21

9 Enable the real server group.

>> Real server 4# /cfg/slb/group 1>> Real server group 1# metric hash>> Real server group 1# add 1/add 2/add 3/add 4




.


10 Enable RTS on the necessary ports.

>> Real server group 1# /cfg/slb/port 26/rts ena>> SLB port 26# /cfg/slb/port 25/rts ena

11 Enable filter processing on the server ports so that the responsefrom the real server will be looked up in VPN session table.

>> SLB port 25# /cfg/slb/port 1/filt ena


>> SLB port 25# apply>> SLB port 25# save>> SLB port 25# /boot/reset

—End—

Configure the First Dirty-Side Application Switch-DA

Step Action

1 Turn off BOOTP.




3 Turn off STP.


4 Configure IP interfaces 1, 2, and 3.





.


5 Define static routes for each of the IP interfaces you configuredin Step 4, using the VPN devices as gateways.

One static route is required for each VPN device being loadbalanced.



>> # /cfg/l3/vrrp/on>> Virtual Router Redundancy Protocol# /cfg/l3/vrrp/vr 1>> VRRP Virtual Router 1# ena>> VRRP Virtual Router 1# vrid 1>> VRRP Virtual Router 1# if 1>> VRRP Virtual Router 1# prio 101>> VRRP Virtual Router 1# addr 192.168.10.50>> VRRP Virtual Router 1# share dis>> VRRP Virtual Router 1# track>> VRRP Virtual Router 1 Priority Tracking# vrs ena>> VRRP Virtual Router 1 Priority Tracking# ports ena>> VRRP Virtual Router 1 Priority Tracking#/cfg/l3/vrrp/vr 2>> VRRP Virtual Router 2# ena>> VRRP Virtual Router 2# vrid 2>> VRRP Virtual Router 2# if 2>> VRRP Virtual Router 2# prio 101>> VRRP Virtual Router 2# addr 10.0.0.1>> VRRP Virtual Router 2# share dis>> VRRP Virtual Router 2# track>> VRRP Virtual Router 2 Priority Tracking# vrs ena>> VRRP Virtual Router 2 Priority Tracking# ports ena

7 Enable SLB.

>> VRRP Virtual Router 1 Priority Tracking#/cfg/slb/on

8 Configure real servers for health-checking VPN devices.




.


>> Layer 4# real 1/ena/rip 20.0.0.10>> Real server 1# /cfg/slb/real 2/ena/rip 20.0.0.11>> Real server 2# /cfg/slb/real 3/ena/rip 20.0.0.20>> Real server 3# /cfg/slb/real 4/ena/rip 20.0.0.21

9 Enable the real server group.

>> Real server 1# /cfg/slb/group 1>> Real server group 1# metric hash>> Real server group 1# add 1/add 2/add 3/add 4

10 Configure the filters to allow local subnet traffic on the dirtyside of the VPN device to reach the VPN device interfaces.

>> # /cfg/slb/filt 100>> # ena>> # sip any>> # dip 192.168.10.0/dmask 255.255.255.0>> # action allow>> # /cfg/slb/filt 110>> # ena>> # sip any>> # dip 224.0.0.0/dmask 255.0.0.0>> # action allow

11 Create the redirection filter and enable firewall load balancing.

This filter will redirect inbound traffic, redirecting it among the definedreal servers in the group.

>> # /cfg/slb/filt 2048>> # ena>> # sip any>> # dip any>> # action redir>> # /cfg/slb/filt 2048/adv>> # fwlb ena

12 Create a filter to allow the management firewall (Policy Server)to reach the VPN firewall.

>> # /cfg/slb/filt 120 ena>> # sip 192.168.10.120>> # smask 255.255.255.255>> # dip 10.0.0.0>> # dmask 255.255.255.0




.



>> # /cfg/slb/port 1>> # filt ena>> # add 100/add 110/add 2048



—End—

Configure the Second Dirty-Side Application Switch-DB

Step Action

1 Turn off BOOTP.




3 Turn off STP.


4 Configure IP interfaces 1, 2, and 3.


5 Configure routes for each of the IP interfaces you configuredin Step 4.




.




>> # /cfg/l3/vrrp/on>> # /cfg/l3/vrrp/vr 1>> # ena>> # vrid 1>> # if 1>> # addr 192.168.10.50>> # share dis>> # track>> # vrs ena>> # ports ena>> # /cfg/l3/vrrp/vr 2>> # ena>> # vrid 2>> # if 2>> # addr 10.0.0.1>> # share dis>> # track>> # vrs ena>> # ports ena

7 Enable SLB.

>> # /cfg/slb/on


>> # /cfg/slb/real 1/ena/rip 20.0.0.10>> # /cfg/slb/real 2/ena/rip 20.0.0.11>> # /cfg/slb/real 3/ena/rip 20.0.0.20>> # /cfg/slb/real 4/ena/rip 20.0.0.21

9 Enable the real server group, and place real servers 1-4 intothe real server group.

>> # /cfg/slb/group 1>> # metric hash>> # add 1/add 2/add 3/add 4




.


10 Configure the filters to allow local subnet traffic on the dirtyside of the VPN device to reach the VPN device interfaces.

>> # /cfg/slb/filt 100>> # ena>> # sip any>> # dip 192.168.10.0/dmask 255.255.255.0>> # /cfg/slb/filt 110>> # ena>> # sip any>> # dip 224.0.0.0/dmask 255.0.0.0

11 Create the redirection filter and enable firewall load balancing.

This filter will redirect inbound traffic, among the defined real serversin the group.

>> # /cfg/slb/filt 2048>> # ena>> # sip any>> # dip any>> # proto any>> # action redir>> # /cfg/slb/filt 2048/adv>> # fwlb ena


>> # /cfg/slb/port 1>> # filt ena>> # add 100/add 110/add 2048

13 Apply and save the configuration and reboot the switch.


—End—

Test Configurations and General TopologyThe application switches should be able to perform health checks to eachother and all switches should see four real servers (see "Checkpoint Rulesfor Both VPN Devices as Seen in the Policy Editor" (page 724)).




.


Checkpoint Rules for Both VPN Devices as Seen in the Policy Editor

Step Action

1 Disconnect the cables (cause failures) to change the availableservers that are up

>> # /info/slb/dump (Verify which servers are up)

This should change the VRRP preferences. You can view VRRPpreferences using the CLI command /info/l3/vrrp.

2 Watch for accepted and dropped traffic. In the tool bar above,click on Window, then Log Viewer.

Note: To help simplify the logs, the health checks are not logged.

—End—

Test the VPN

Step Action

1 Launch the SecuRemote client on the dirty side of the network.

2 Add a new site.




.


3 Enter the policy server IP address: 192.168.10.120. You havethe option of adding a nickname.

4 Launch a browser (such as Netscape or Internet Explorer) andgo to http://30.0.0.100

5 You will be prompted for authentication.

Enter vpnuser for user name and alteon for the password.

6 A message is displayed verifying that you were authenticated.

7 Browse to the Web site.




.


If there are other services running on other servers in the internalnetwork, you should be able to reach those services. All traffictraveling over the VPN is decrypted at the VPN device. You canverify which VPN device is being used by looking at the Log Viewer.You should also be able to see the client authentication as well asthe decrypted traffic.

To verify that the FWLB and hash metric is working correctly on thedirty-side switches (that is, hashed on client IP address/destinationIP address), configure your current client with an IP address onehigher (or lower) in the last octet, and try to reestablish the VPNconnection. Or, add another PC on the dirty side and connect to it.

Note: When many clients are coming from behind a VPNgateway (for example, not using the SecuRemote clients butusing a VPN 1 Gateway or other compatible VPN Gateway),you will not see load balancing across those clients. EachSecuRemote client will be treated differently, but each VPN 1Gateway will be treated as one client each (that is, one ClientIP address). VPN Device 1 and VPN Device 2 belong to onecluster IP.

—End—




.

Global Server Load Balancing 727

Global Server Load Balancing

This chapter provides information for configuring Global Server LoadBalancing (GSLB) across multiple geographic sites. The following topicsare covered:

• "Enabling GSLB on the Switch" (page 727)

• "GSLB Overview" (page 728)

• "Configuring Basic GSLB" (page 735)

• "Configuring a Standalone GSLB Domain" (page 752)

• "Configuring GSLB with Rules" (page 759)

• "Configuring GSLB Network Preference" (page 762)

• "Configuring GSLB with Proxy IP for Non-HTTP Redirects" (page 764)

• "Using Border Gateway Protocol for GSLB" (page 767)

• "Verifying GSLB Operation" (page 768)

Enabling GSLB on the SwitchTo use GSLB on your application switch, you must purchase an additionalsoftware license and password key. Instructions for obtaining a passwordkey are provided with your software license certificate.

Once you have obtained the proper password key to enable GSLB, followthese instructions:

Step Action

1 Connect to the switch command line interface via Telnet orthe console port, and login as the administrator, followingthe directions in the Nortel Application Switch Operating SystemCommand Reference.

2 From the command line prompt, type the /oper/swkeycommand.

You will be prompted to enter the password key. If the key iscorrect for this MAC address, the switch will accept the password,permanently record it in the switch’s non-volatile RAM (NVRAM),and will then enable the feature.

—End—




.


DSSP version 1 vs. version 2Distributed Site Selection Protocol (DSSP) is a proprietary protocol thatresides above TCP. It enables the sending and receiving of remote siteupdates. By default, DSSP version 1 is enabled on the Nortel ApplicationSwitch and supports server response time and sessions available in theremote site updates.

DSSP version 2 supports server response time, CPU utilization, sessionavailability, and session utilization in the remote site updates. For moreinformation on the site selection metrics, see "GSLB Metrics" (page 731).Although both versions of DSSP are supported, it is recommended thatDSSP version 2 is utilized in most instances. DSSP version 1 remains toprovide backward compatiability to switches in a network running olderversions of the Nortel Application Switch Operating System.

If interconnection to switches running older software versions is notrequired, use DSSP version 2. The command to change to DSSP version 2is /cfg/slb/gslb/version 2.

Migrating Previous GSLB ConfigurationsGSLB configurations running in earlier versions of the Nortel ApplicationSwitch Operating System are maintained after upgrading to version 24.0.Simply upgrade the software image to the new version and the configurationwill be migrated.

GSLB License KeyIf GSLB is not already enabled on the application switch, obtain a GSLBkey specifically for this new version to use it. GSLB licenses from earlierversions of the Nortel Application Switch Operating System are still validafter an upgrade.

GSLB OverviewGSLB allows balancing server traffic load across multiple physical sites.The Nortel Application Switch Operating System GSLB implementationtakes into account an individual site’s health, response time, and geographiclocation to smoothly integrate the resources of the dispersed server sites forcomplete global performance.

BenefitsGSLB meets the following demands for distributed network services:

• High content availability is achieved through distributed content anddistributed decision making. If one site becomes disabled, the othersbecome aware of it and take up the load.

• There is no latency during client connection set up. Instant site hand-offdecisions can be made by any distributed switch.




.


• The best performing sites receive a majority of traffic over a given periodof time but are not overwhelmed.

• Switches at different sites regularly exchange information through theDistributed Site State Protocol ( DSSP), and can trigger exchangeswhen any site’s health status changes. This ensures that each activesite has valid state knowledge and statistics. DSSP v1.0 and DSSPv2.0 are supported.

• GSLB implementation takes geography as well as network topologyinto account.

• Creative control is given to the network administrator or Webmaster tobuild and control content by user, location, target application, and more.

• GSLB is easy to deploy, manage, and scale. Switch configuration isstraightforward. There are no complex system topologies involvingrouters, protocols, and so forth.

• Flexible design options are provided.

• All IP protocols are supported.

How GSLB WorksA GSLB device performs or initiates a global server selection to directclient traffic to the best server for a given domain during the initial clientconnection.

GSLB is based on the Domain Name System (DNS) and proximity bysource IP address. In the example in "DNS Resolution with Global ServerLoad Balancing" (page 730), a client is using a Web browser to view theWeb site for the Example Corporation at "www.example.com." The ExampleCorporation has two Web sites: one in San Jose, and one in Denver,each with identical content and available services. Both Web sites havean Nortel Application Switch configured for GSLB, with domain name setto "www.gslb.example.com." These switches are also configured as theAuthoritative Name Servers for "www.example.com."On the companymaster DNS server, the configuration is to delegate "www.example.com"to "www.gslb.example.com."




.


DNS Resolution with Global Server Load Balancing

The DNS resolution for GSLB is described in detail in the followingprocedure:

Step Action

1 The client Web browser requests the "www.example.com" IPaddress from the local DNS.

2 The client’s DNS asks its upstream DNS, which in turn asks thenext, and so on, until the address is resolved.

Eventually, the request reaches an upstream DNS server that hasthe IP address information available or the request reaches one ofthe Example, Inc. DNS servers.

3 The Example Inc.’s San Jose DNS tells the local DNS to querythe Nortel Application Switch with GSLB software as theauthoritative name server for "www.example.com."

4 The San Jose switch responds to the DNS request, listing theIP address with the current best service.

Each switch with GSLB software is capable of responding to theclient’s name resolution request. Since each switch regularly checksand communicates health and performance information with itspeers, either switch can determine which site(s) are best able toserve the client’s Web access needs. It can respond with a list ofIP addresses for the Example Inc.’s distributed sites, which areprioritized by performance, geography, and other criteria.




.


In this case, the San Jose switch knows that Example Inc. Denvercurrently provides better service, and lists Example Inc. Denver’svirtual server IP address first when responding to the DNS request.

5 The client connects to Example Inc. Denver for the best service.

The client’s Web browser will use the IP address informationobtained from the DNS request to open a connection to the bestavailable site. The IP addresses represent virtual servers at anysite, which are locally load balanced according to regular SLBconfiguration.

If the site serving the client HTTP content suddenly experiences afailure (no healthy real servers) or becomes overloaded with traffic(all real servers reach their maximum connection limit), the switchissues an HTTP Redirect and transparently causes the client toconnect to another peer site.

The end result is that the client gets quick, reliable service with nolatency and no special client-side configuration.

—End—

GSLB MetricsThis section describes all GSLB metrics. All metrics can be prioritized forselection order, and can be weighted on a per site basis.

For details on the configuration parameters of GSLB metrics, see the/cfg/slb/gslb/rule menu and the command descriptions in the NortelApplication Switch Operating System 24.0 Command Reference.

The following is a list of all GSLB metrics:

• Session utilization capacity threshold — This metric causes theGSLB-enabled application switch to not select the server when thesession utilization of the server goes above the threshold. The sessionutilization is the percentage of sessions used over total sessions thatresults in normalized sessions between servers. When the server is notavailable, the session utilization is 100%. This is a threshold metric andit overwrites all other metrics. This metric requires remote site updates.

• CPU utilization capacity threshold — This metric causes theGSLB-enabled application switch to not select the server when theCPU utilization of the site with the server goes above the threshold.CPU utilization is the highest CPU utilization for periods of up to 64seconds among SPs. This is a threshold metric and overwrites all othermetrics.This metric requires remote site updates.

• Session available capacity threshold — This metric does not select theserver when the number of available sessions on the server falls below




.


the threshold. When the server is not available, the session availableis 0. This is a threshold metric and it overwrites all other metrics. Thismetric requires remote site updates.

• Geographical preference — This metric causes the GSLB-enabledapplication switch to select the server based on the same IANA region ofthe source IP address and the server IP address. This metric does notrequire remote site updates. The command, /info/slb/gslb/geocan be used to obtain a list of the IP address ranges that are mapped toeach region. The regions are as follows:

— North America

— South America

— Europe

— Caribbean

— Pacific Rim

— Sub-Sahara

— Japan

• Network preference—This metric selects the server based on thepreferred network of the source IP address. This metric does not requireremote site updates.

• Weighted least connections — This metric selects the server basedon which server has the lowest session utilization. Session utilizationis the percentage of sessions used over total sessions, which resultsin normalized sessions between servers. A server whose sessionutilization is 100% is considered unavailable. This metric requiresremote site updates.

• Weighted response time — This metric selects the server based onthe lowest response time in milliseconds from an SLB health check ofthe servers. This metric requires SLB health checks and remote siteupdates.

• Weighted round robin — This metric selects the server based on roundrobin of the servers.

• Weighted random — This metric selects the server based on uniformrandom distribution of the servers.

• Availability — This metric selects the same server while the server is stillavailable. If the same server is not available, this metric selects the nextserver based on a ranking of the local virtual server and remote realserver in a list from the highest (48) to the lowest (1) ranking. Multipleservers can have the same priority. This metric allows servers to begrouped based on priorities, or into primary and secondary groups. Thismetric requires SLB health checks and remote site updates.




.


• Quality of service — This metric selects the server based on combinationof the lowest session utilization and the lowest response time of the SLBhealth check of the servers. This metric requires SLB health checksand remote site updates.

• Minmisses — This metric selects the same server based on the hashof source IP address and domain name. The hash calculation uses allthe servers that are configured for the domain irrespective of the stateof the server. When the server selected is not available, minmissesselects the next available server.

• Hashing — This metric selects the same server based on the hash ofsource IP address and domain name. The hash calculation uses onlythe servers that are available for the domain. The server selected maybe affected when a server become available or not available since thehash calculation uses only the servers that are available.

• DNS local — This metric selects the local virtual server only whenthe local virtual server is available. This metric applies to DNS-basedGSLB only.

• DNS always — This metric selects the local virtual server even thoughthe local virtual server is not available. This metric applies to DNS-basedGSLB only.

• Remote — This metric selects the remote real servers only.

Metric preferencesThis metric allows the GSLB selection to use multiple metrics from a metricpreference list. The GSLB selection starts with the first metric in the list.The GSLB selection goes to the next metric when no server is selected, ormore than the required servers is selected. The GSLB selection stops whenthe metric results at least one and no more than the required servers, orafter the last metric in the list is reached. For DNS direct-based GSLB, theDNS response can be configured to return up to 10 required servers. ForHTTP redirects based GSLB, the required server is one.

The following metrics can be selected from the metric preference list.

• Geographical preference

• Network preference

• Least connections

• Response time

• Round robin

• Random

• Availability

• Quality of service




.


• Minmisses

• Hashing

• DNS local

• DNS always

• Remote

RulesA rule allows the GSLB selection to use a different GSLB site selectionmetric preference list, and rules can be set based on the time of day. Eachdomain has one or more rules. Each rule has a metric preference list.The GSLB selection selects the first rule that matches for the domain andstarts with the first metric in the metric preference list of the rule. For moreinformation, see "Configuring GSLB with Rules" (page 759).

GSLB Availability PersistenceThe Global Server Load Balancing (GSLB) Availability metric is used inGSLB rules to select a server exclusively when that server is available.Should that server become unavailable, the next available server in a list isselected to service requests. Availability is determined by a rank assignedto each server ranging from the lowest score of 1 to the highest score of 48.Multiple servers can be scored the same.

Rules that use Availability as the primary metric handle failures by selectingthe server with the next highest score compared to that of the server thatfailed and begins forwarding requests to that server. Should the serverthat failed become operational again, that server regains precedence andrequests are routed to it once more.

GSLB Availability Persistence allows the switch administrator to changethe behavior of the Availability metric to reassign requests to a server thathad previously failed because of its higher initial score. With AvailabilityPersistence enabled, a server that takes over after a failure situation isautomatically assigned the highest possible Availablity value (48). Thisensures that after the server that failed becomes operational again, it cannotregain precedence from the recovery server. Should this new primaryserver fail, its original Availability value will be restored and the next serverin the list will gain the high precedence.

To enable GSLB Availability Persistence, the following tasks must beperformed:

Step Action

1 DSSP version 3 must be enabled.

DSSP version 3 must be enabled on all switches with GSLBconfigured. Use the following command to do so:




.


/cfg/slb/gslb/version 3

2 Availability must be the primary rule metric.

The Availability metric must be the first metric configured in the firstGSLB rule. For information on rule creation, refer to "Rules" (page734).

3 Enable Availability Persistence.

Enable Availability Persistence on the backup switch (the switch thatwill take over from the primary switch) using the following command:

/oper/slb/gslb/avpersis <virtual server number>enable

Note: This is an operational command that will not survive aswitch reboot.

After the primary server recovers, reversion to the configuredavailabilities can be accomplished at a convenient time. To do so,use the following command on the switch whose virtual servercurrently has precedence. This would be the switch with the virtualserver that is advertising an availability of 48.

/oper/slb/gslb/avpersis <virtual server number>disable.

After both sites are reporting their configured availability, turn thefeature back on. This is accomplished by enabling AvailabilityPersistence on the switch with the backup server using the followingcommand:

/oper/slb/gslb/avpersis <virtual server number>enable.

Nortel Application Switch Operating System 24.0 supports thefollowing command to enable or disable Availability Persistence onthe backup switch:

/cfg/slb/virt <virtual server number>/avpersisenable/disable.

—End—

Configuring Basic GSLBConfiguring GSLB is simply an extension of the configuration procedure forSLB. The process is summarized as follows:

• Use the administrator login to connect to the switch you want toconfigure.




.


• Activate the GSLB software key. See the Nortel Application SwitchOperating System Command Reference for details.

• Configure the switch at each site with basic attributes.

— Configure the switch IP interface.

— Configure the default gateways.

• Configure the switch at each site to act as the DNS server for eachservice that is hosted on its virtual servers. Also, configure the masterDNS server to recognize the switch as the authoritative DNS server forthe hosted services.

• Configure the switch at each site for local SLB.

— Define each local real server.

— Group local real servers into real server groups.

— Define the local virtual server with its IP address, services, and realserver groups.

— Define the switch port states.

— Enable SLB.

• Finally, configure each switch so that it recognizes its remote peers.

— Configure a remote real server entry on each switch for each remoteservice. This is the virtual server IP address that is configured onthe remote peer.

— Add the remote real server entry to an appropriate real server group.

— Enable GSLB.

Basic GSLB RequirementsThe following is required prior to configuration:

• You must be connected to the switch Command Line Interface (CLI)as the administrator.

• The optional GSLB software key must be activated

• Server Load Balancing must be enabled.

Example GSLB TopologyConsider the following example network:




.


GSLB Topology Example 1

In the following examples, many of the options are left to their defaultvalues. See "Additional Server Load Balancing Options" (page 199) formore options.

Note: For details about any of the processes or menu commandsdescribed in this example, see the Nortel Application Switch OperatingSystem Command Reference.

Task 1: Configure the Basics at the San Jose Site

Step Action

1 (Optional) On the San Jose switch, configure managementaccess, and management gateway address on the applicationswitch, then enable the management port.

>> # /cfg/sys/mmgmt/addr50.133.88.31

(Mgmt. port IP address)


(Mgmt. port mask)

>> Management Port# gw50.133.88.1

(Mgmt. port gateway addr.)

>> Management Port# ena (Enable the Mgmt port)

2 If using the Browser-Based Interface (BBI) for managing theSan Jose switch, change its service port.

By default, GSLB listens on service port 80 for HTTP redirection.By default, the Nortel Application Switch Operating SystemBrowser-Based Interface (BBI) also uses port 80. Both servicescannot use the same port. If the BBI is enabled (see the




.


/cfg/sys/access/http command in the Nortel ApplicationSwitch Operating System Command Reference), configure it to usea different port.

For example, enter the following command to change the BBI portto 8080:

>> # /cfg/sys/wport 8080 (Set service port 8080 for BBI)

3 Configure a VLAN for the Internet traffic.

>> # /cfg/l2/vlan 101/nameinternet

(VLAN 101 for Internet)

>> VLAN 101# add 2/ena (Add port 2 to VLAN 101)

Port 2 is an UNTAGGED port and its current PVID is 1.Confirm changing PVID from 1 to 101 [y/n]: yCurrent ports for VLAN 101: emptyPending new ports for VLAN 101: 2Current status: disabledNew status: enabled

4 Configure another VLAN for local server traffic, and add serverports to this VLAN.

>> # /cfg/l2/vlan 201/nameservers

(VLAN 201 for local servers)




Port 3 is an UNTAGGED port and its current PVID is 1.Confirm changing PVID from 1 to 201 [y/n]: yCurrent ports for VLAN 201: emptyPending new ports for VLAN 201: 3 4

5 Define an IP interface to the local real servers.







.



(Assign network mask)

>> IP Interface 201# vlan 201 (Assign interface to VLAN201)


6 Define an IP interface to the Internet.

The switch IP interface responds when asked to resolve client DNSrequests.








7 Define the default ga teway.

The router at the edge of the site acts as the default gateway to theInternet. The default gateway address should be on the same subnetas the IP interface 101, which points to the Internet. To configurethe default gateway for this example, enter these commands fromthe CLI:




(Assign IP address for thegateway)

>> Default gateway 1# ena (Enable default gateway 1)


>> # apply>> # save

9 Configure the master DNS server to recognize the local GSLBswitch as the authoritative name server for the hosted services.




.


Determine the domain name that will be distributed to both sites andthe host name for each distributed service. In this example, the SanJose DNS server is configured to recognize 200.200.200.1 (the IPinterface of the San Jose GSLB switch) as the authoritative nameserver for "www.gslb.example.com."

—End—

Task 2: Configure the San Jose Switch for Standard SLB

Step Action

1 Assign an IP address to each of the real servers in the localSan Jose server pool.

The real servers in any real server group must have an IP route tothe switch that will perform the SLB functions. This is most easilyaccomplished by placing the switches and servers on the sameIP subnet, although advanced routing techniques can be used aslong as they do not violate the topology rules outlined in "NetworkTopology Requirements" (page 192).

For this example, the host real servers have IP addresses on thesame IP subnet:

GSLB Example: San Jose Real Server IP Addresses


Server 10 200.2.2.10

Server 20 200.2.2.20

2 Define each local real server.

For each local real server, you must assign a real server number,specify its actual IP address, and enable the real server. Forexample:

>> Default gateway 1#/cfg/slb/real 10

(Configure Real Server 10)

>> Real server 10# rip200.2.2.10

(Assign IP address to server10)



(Configure Real Server 20)




.


>> Real server 20# rip200.2.2.20

(Assign IP address to server20)


3 On the San Jose switch, define a real server group.

Combine the real servers into one service group and set thenecessary health checking parameters. In this example, HTTPhealth checking is used to ensure that Web content is being served.If the index.html file is not accessible on a real server during healthchecks, the real server will be marked as down.







>> Real server group 1#health http

(Use HTTP for health checks)

>> Real server group 1#content index.html

(Set URL content for healthchecks)

4 On the San Jose switch, define a virtual server.

All client requests will be addressed to a virtual server IP addressdefined on the switch. Clients acquire the virtual server IP addressthrough normal DNS resolution. HTTP uses well-known TCP port80. In this example, HTTP is configured as the only service runningon this virtual server IP address and, is associated with the realserver group. For example:





>> Virtual Server 1# service 80



>> Virtual server 1 http Service# /cfg/slb/virt 1 ena(Enable virtual server)




.


Note: This configuration is not limited to HTTP services. Fora list of other well-known TCP/IP services and ports, see"Well-Known Application Ports" (page 199).

5 On the San Jose switch, define the type of Layer 4 trafficprocessing each port must support.


GSLB Example: San Jose Nortel Application Switch Port Usage

Port Host Layer 4 Processing

4 Server 10 Server

3 Server 20 Server

2 Default Gateway Router. This connectsthe switch to the Internet where allclient requests originate.

Client


>> Virtual server 1#/cfg/slb/port 4









6 On the San Jose switch, enable SLB.

>> SLB port 6# /cfg/slb/on

—End—




.


Task 3: Configure the San Jose Site for GSLB

Step Action

1 On the San Jose switch, turn on GSLB.

>> Virtual server 1# /cfg/slb/gslb/on

2 Enable DSSP version 2 to send out remote site updates.

Unless you are in the middle of network migration from an NortelApplication Switch Operating System version prior to 22.0 youshould always enable DSSP version 2.

>> # /cfg/slb/gslb/version 2 (Enable DSSP version 2updates)

3 On the San Jose switch, define each remote site.

When you start configuring at the San Jose site, San Jose islocal and Denver is remote. Add and enable the remote switch’sInternet-facing IP interface address. In this example, there is onlyone remote site: Denver, with an IP interface address of 74.14.70.2.The following commands are used:

>> # /cfg/slb/gslb/site 2 (Select remote site 2)

>> Remote site 2# name site_2 (Name remote site 2)

>> Remote site 2# prima174.14.70.2

(Define remote interface)

>> Remote site 2# ena (Enable remote site 1)

Each additional remote site would be configured in the samemanner. You can enable up to 64 remote sites.

4 On the San Jose switch, assign each remote distributed serviceto a local virtual server.

Configure the local San Jose site to recognize the services offeredat the remote Denver site. To do this, configure one real serverentry on the San Jose switch for each virtual server located at eachremote site. Since there is only one remote site (Denver) with onlyone virtual server, only one more local real server entry is needed atthe San Jose site.




.


The new real server entry is configured with the remote virtual serverIP address, i.e. Switch 2’s VIP address, rather than the usual IPaddress of a local physical server. Do not confuse this value with theIP interface address on the remote switch.

Also, the remote parameter is enabled, and the real server entry isadded to the real server group under the local virtual server for theintended service. Finally, since the real server health checks areperformed across the Internet, the health-checking interval shouldbe increased to 30 or 60 seconds to avoid generating excess traffic.The health check interval should also depend on the number ofremote sites. The more remote sites you have, the larger the timeinterval should be. For example:

>> # /cfg/slb/real 2 (Create an entry for real server2)

>> Real server 2# rip174.14.70.200

(Set remote virtual server IPaddress)

>> Real server 3# remoteenable

(Define the real server asremote)

>> Real server 3# inter 30 (Set a higher health checkinterval)

>> Real server 3# ena (Enable the real server entry)


(Select appropriate real servergroup)


(Add real server 2 to the group1)

Note: Take care to note where each configured value originates,or this step can result in improper configuration.

5 On the San Jose switch, define the domain name and hostname for each service hosted on each virtual server.

In this example, the domain name for the Example Inc. is"gslb.example.com," and the host name for the only service (HTTP)is "www." These values are configured as follows:



>> Virtual server 1# dname gslb.example.com (Definedomain name)

>> Virtual server 1# service80/hname www

(Define HTTP host name)




.


To define other services (such as FTP), make additional hostnameentries.


>> Global SLB# apply (Make your changes active)

>> Global SLB# cur (View current GSLB settings)

>> Global SLB# /cfg/slb/cur (View current SLB settings)

Examine the resulting information. If any settings are incorrect,make and apply any appropriate changes, and then check again.



—End—

Task 4: Configure the Basics at the Denver SiteFollowing the same procedure described for San Jose (see "Example GSLBTopology" (page 736)), configure the Denver site as follows:

Step Action

1 (Optional) On the Denver switch, configure managementaccess, and management gateway address on the applicationswitch.




(Mgmt. port mask)



>> Management Port# ena (Enable the Mgmt. port)

2 If using the Browser-Based Interface (BBI) for managing theSan Jose switch, change its service port.

By default, GSLB listens on service port 80 for HTTP redirection.By default, the Nortel Application Switch Operating SystemBrowser-Based Interface (BBI) also uses port 80. Both servicescannot use the same port. If the BBI is enabled (see the




.


/cfg/sys/access/http command in the Nortel ApplicationSwitch Operating System Command Reference), configure it to usea different port.

For example, enter the following command to change the BBI portto 8080:

>> # /cfg/sys/wport 8080 (Set service port 8080 for BBI)




>> VLAN 102# add 2/ena (Add port 2 to VLAN 102and enable)


4 Configure a VLAN for local server traffic, and add server portsto this VLAN.

>> # /cfg/l2/vlan 202/nameservers

(VLAN 202 for local servers)

>> VLAN 202# add 11/ena (Add port 11 to vlan 202)

Port 10 is an UNTAGGED port and itscurrent PVID is 1.Confirm changing PVID from 1 to 202 [y/n]: yCurrent ports for VLAN 202: emptyPending new ports for VLAN 202: 11Current status: disabledNew status: enabled


Port 11 is an UNTAGGED port and itscurrent PVID is 1.Confirm changing PVID from 1 to 202 [y/n]: yCurrent ports for VLAN 202: emptyPending new ports for VLAN 202: 11 12

5 Define an IP interface to the local real servers.




.









6 Define an IP interface to the Internet.








7 Define the default ga teway.







>> # apply>> # save

9 Configure the local DNS server to recognize the local GSLBswitch as the authoritative name server for the hosted services.

Determine the domain name that will be distributed to both sitesand the host name for each distributed service. In this example, theDenver DNS server is configured to recognize 174.14.70.2 (the IPinterface of the Denver GSLB switch, configured with the domainname "www.gslb.example.com") as the authoritative name serverfor "www.example.com."




.


—End—

Task 5: Configure the Denver Switch for Standard SLB

Step Action

1 Assign an IP address to each of the real servers in the localDenver server pool.

Denver Real Server IP Addresses


Server 11 174.14.7.11

Server 21 174.14.7.21

2 On the Denver switch, define each local real server.

>> Default gateway 1#/cfg/slb/real 11


>> Real server 11# rip174.14.7.11

(Assign IP address for Server 11)



(Server D is real server 21)

>> Real server 21# rip174.14.7.21

(Assign IP address for Server 21)


3 On the Denver switch, define a real server group.







>> Real server group 1#health http

(Use HTTP for health checks)

>> Real server group 1#content index.html

(Set URL content for healthchecks)




.


4 On the Denver switch, define a virtual server.




(Assign IP address)



>> Virtual server 1 httpservice# group 1


>> Virtual server 1 http service# /cfg/slb/virt 1/ena(Enable the virtual server)

5 On the Denver switch, define the type of Layer 4 processingeach port must support.




11 Server 11 Server

12 Server 12 Server


Client


>> # /cfg/slb/port 11 (Select physical switch port11)

>> SLB port 11# server ena (Enable server processingon port 11)



>> SLB port 12# server ena (Enable server processingon port 12)

>> SLB port 12# /cfg/slb/port 2 (Select physical switch port2)

>> SLB port 2# client ena (Enable client processingon port 2)

6 On the Denver switch, enable SLB.




.


>> # /cfg/slb/on

—End—

Task 6: Configure the Denver Site for GSLBFollowing the same procedure described for San Jose (see "Task 3:Configure the San Jose Site for GSLB" (page 743)), configure the Denversite as follows:

Step Action

1 On the Denver switch, turn on GSLB.

>> Virtual server 1# /cfg/slb/gslb/on

2 Enable DSSP version 2 to send out remote site updates.

Unless you are in the middle of network migration to 22.0, youshould always enable DSSP version 2.

>> # /cfg/slb/gslb/version 2 (Enable DSSP version 2updates)

3 On the Denver switch, define each remote site.

When you start configuring at the Denver site, Denver is local andSan Jose is remote. Add and enable the remote switch’s IP addressinterface. In this example, there is only one remote site: SanJose, with an IP interface address of 200.200.200.1. The followingcommands are used:

>> # /cfg/slb/gslb/site 1 (Select remote site 1)

>> Remote site 1# prima200.200.200.1

(Define remote IP interfaceaddress)

>> Remote site 1# ena (Enable remote site 1)

Each additional remote site would be configured in the samemanner. You can enable up to 64 remote sites.

4 On the Denver switch, assign each remote distributed serviceto a local virtual server.

In this step, the local Denver site is configured to recognize theservices offered at the remote San Jose site. As before, configureone real server entry on the Denver switch for each virtual server




.


located at each remote site. Since there is only one remote site (SanJose) with only one virtual server, only one more local real serverentry is needed at the Denver site.

The new real server entry is configured with the IP address of theremote virtual server, rather than the usual IP address of a localphysical server. Do not confuse this value with the IP interfaceaddress on the remote switch.

Also, the remote parameter is enabled, and the real server entry isadded to the real server group under the local virtual server for theintended service. Finally, since the real server health checks areheaded across the Internet, the health-checking interval should beincreased to 30 or 60 seconds to avoid generating excess traffic. Themore remote sites you have, the larger the time interval should be.

For example:

>> Remote site 1# /cfg/slb/real1

(Create an entry for realserver 1)

>> Real server 1# rip200.200.200.100

(Set remote virtual serverIP address)

>> Real server 1# remote enable (Define the real server asremote)

>> Real server 1# inter 30 (Set a high health checkinterval)

>> Real server 1# ena (Enable the real serverentry)


(Select appropriate. realserver group)


Note: Take care to note where each configured value originatesor this step can result in improper configuration.

5 On the Denver switch, define the domain name and host namefor each service hosted on each virtual server.

These will be the same as for the San Jose switch: the domain nameis "gslb.example.com," and the host name for the HTTP service is"www." These values are configured as follows:



>> Virtual server 1# dnamegslb.example.com

(Define domain name)




.


>> Virtual server 1# service 80 (Select HTTP for virtualserver)

>> Virtual server 1 http# hnamewww

(Define HTTP hostname)


>> Global SLB# apply (Make your changes active)







11 Server 11 Server

12 Server 12 Server


Client

—End—

Configuring a Standalone GSLB DomainAn Nortel Application Switch can serve as a standalone GSLB device, whichmeans that it can perform GSLB health checking and site selection to othersites, without supporting SLB to local real servers.

The remote sites can be other sites configured with an Nortel ApplicationSwitch running GSLB, an Nortel Application Switch running only SLB, oreven a site that uses another vendor’s load balancers.

An Nortel Application Switch running GSLB can operate in standalonemode as long as it uses site selection metrics that do not require remotesite updates.




.


GSLB Topology with a Standalone GSLB SiteGSLB Topology Example 2 - with Standalone GSLB

Task 1: Configure the Basics at the Tokyo SiteFollowing a similar procedure as described in "Configuring Basic GSLB"(page 735), configure a third site—Tokyo—in Standalone mode.

Remember that in Standalone mode, the Nortel Application Switch does notrequire SLB configuration of local real servers.

Step Action

1 (Optional) On the Tokyo switch, configure management accessand management gateway address.




(Mgmt. port mask)



>> Management Port# ena (Enable the Mgmt Port)





.




>> VLAN 103# add 3 (Add port 3 to VLAN 103)


3 Define anIP interface to the Internet.








4 Define the default gateway.







>> # apply>> # save

6 Configure the local DNS server to recognize the local GSLBswitch as the authoritative name server for the hosted services.

Determine the domain name that will be distributed to both sitesand the host name for each distributed service. In this example,the Tokyo DNS server is configured to recognize 43.10.10.3 (the IPinterface of the Tokyo GSLB switch) as the authoritative name serverfor "www.gslb.example.com."

—End—




.


Task 2: Configure the Tokyo Site for GSLBFollowing the similar procedure described for San Jose (see "Task 3:Configure the San Jose Site for GSLB" (page 743)), configure the Tokyosite as follows:

Step Action

1 On the Tokyo switch, turn on SLB and GSLB.

>> # /cfg/slb (Select the SLB Menu)

>> SLB# on (Activate SLB for the switch)

>> # /cfg/slb/gslb (Select the GSLB Menu)

>> Global SLB# on (Activate GSLB for the switch)

2 On the Tokyo switch, assign each remote distributed serviceto a local virtual server.

In this step, the local site, Tokyo, is configured to recognize theservices offered at the remote San Jose and Denver sites. Asbefore, configure one real server entry on the Tokyo switch for eachvirtual server located at each remote site.

The new real server entry is configured with the IP address of theremote virtual server, rather than the usual IP address of a localphysical server. Do not confuse this value with the IP interfaceaddress on the remote switch.

>> # /cfg/slb/real 1 (Create an entry for San Jose)


>> Real server 1# nameSan_Jose

(Set a name for the real serverentry)

>> Real server 1# rip200.200.200.100

(Set remote vip address of SanJose)



>> # /cfg/slb/real 2 (Create an entry for Denver)


>> Real server 2# nameDenver

(Set a name for the real serverentry)




.


>> Real server 2# rip74.14.70.200

(Set remote vip address forDenver)



Note: Take care to note where each configured value originates,or this step can result in improper configuration.

3 Define a network that will match and accept all incoming trafficfor the other sites.

>> # /cfg/gslb/net 1 (Create an entry for the newnetwork)

>> Network 1# ena (Enable the new network)

>> Network 1# sip 0.0.0.0 (Define a source IP addressmatch)

>> Network 1# mask 0.0.0.0 (Define a network maskmatch)

>> Network 1# addreal 1 (Add the San Jose site tothe network)

>> Network 1# addreal 2 (Add the Denver site to thenetwork)

4 Define a new rule that will make the new network active.

>> # /cfg/slb/gslb/rule 1/ena (Enable the new rule)

>> Rule 1# dname gslb.example.com

(Define a domain name)

>> Rule 1# metric 1/gmetricnetwork

(Define the metric this rulewill use)

>> Rule 1# metric 1/addnet 1 (Add network to the rulemetric)


>> Virtual Server 2 httpService# apply

(Make your changes active)







.




Note: Configuration for the Tokyo site is now complete.

—End—

A Standalone DNS Server ConfigurationA customer can use any DNS server that can provide the following specificfunctionality:

• It is possible to configure 2 NS records: NS1 with Alteon1 interface IPaddress and NS2 with Alteon2 interface IP address.

• If Alteon2 is alive, Alteon1 is down (domain name can not be resolvedby using NS1) DNS server switches to NS2.

• If Alteon1 is alive, Alteon2 is down (domain name can not be resolvedby using NS2) DNS server switches to NS1.

• If Alteon1 is alive (NS1 is used), Alteon2 was down; after that Alteon2 isalive, DNS server continues to use NS1.

• If Alteon2 is alive (NS2 is used), Alteon1 was down; after that Alteon1 isalive, DNS server continues to use NS2

• Round Robin algorithm for DNS server can be disabled.

The configuration example for Microsoft Windows 2003 DNS Server isexplained below.

The DNS server is configured to resolve domain name (e.g. “geored.com”)into active Alteon virtual IP address which represents active MCS system(Alteon1 vip1, Alteon1 vip2, or Alteon2 vip1, Alteon2 vip2).

Perform the following configuration steps on the DNS server machine:

Step Action

1 Run the DNS console.

2 Create a primary forward lookup zone “com”.

3 Create a delegation in zone “com”: Delegated domain “geored”;FQDN - “geored.com”.

4 Add first resource record: FQDN – Alteon1 interface IP address(which is set up by /c/l3/if 1); IP address – Alteon1 interface IPaddress.




.


5 Add second resource record: FQDN – Alteon2 interface IP address;IP address – Alteon2 interface IP address. The example of theconfiguration is as shown in "DNS Console" (page 758).

DNS Console

6 Set TTL = 10 seconds for records of zone “com”. 7.

7 Disable Round Robin algorithm for the server as shown in the"ZDEDIC-5 Properties window" (page 758).

ZDEDIC-5 Properties window

Note: If the DNS server is down the clients (PCC, Sigma phonethat supports DNS and AudioCodes GW) do not work.

—End—




.


Configuring GSLB with RulesGSLB rules can be configured on a per-domain basis to allow dynamic siteselection based on time of day for a given domain. The criteria for domainrules are as follows:

• Each domain has one or more rules.

• Each rule has a metric preference list.

• The site selection selects the first rule that matches for the domain andstarts with the first metric in the metric preference list of the rule.

Up to 128 rules can be configured, with up to eight metrics per rule. The siteselection metric sequence in the default Rule 1 is as follows:

Step Action

1 Network Preference

The first metric in rule 1 is set to "Network Preference," whichselects the server based on the preferred network of the source IPaddress for a given domain. If preferred networks are not configured,this metric is not used in the default rule. For more information onconfiguring preferred networks, see "Configuring GSLB NetworkPreference" (page 762).

2 None

The second metric in rule 1 is set to "None" in order to allow you toconfigure the local or availability metric here. The local server or theserver with the highest availability is selected before any subsequentmetric is used to select other servers.

3 Geographical preference

The third metric in rule 1 is set to "Geographical Preference" so thatthe IANA-defined geographical region based on the client source IPis used to redirect the request to the client’s region.

4 Least connections

5 Round robin

"Round robin" or random should be the last metric defined in a rule,because they always return a value if there is at least one functionalsite.

6 None

7 None




.


8 None

The last metric in rule 1 should be configured as dnsalways so thatthe GSLB selection selects at least the local virtual server when allservers are not available. In this case, metric 6 can be configuredwith DNS always.

—End—

Configuring Time-Based RulesTask 1: Configure the first time-based ruleUsing the base configuration "Configuring Basic GSLB" (page 735), you candefine a new time-based rule for certain networks, as follows:

Step Action

1 Disable the default rule 1, in order to ensure that the time basedrule is processed first.

>> # /cfg/slb/gslb/rule 1/dis (Disable rule 1)

2 Configure the networks to be added to the GSLB rule.

>> # /cfg/slb/gslb/net 43/sip 43.0.0.0/mask255.0.0.0/addvirt 1/ena>> # /cfg/slb/gslb/net 55/sip 55.0.0.0/mask255.0.0.0/addreal 10/ena>> # /cfg/slb/gslb/net 56/sip 56.0.0.0/mask255.0.0.0/addreal 10/ena

3 Configure a new rule.

>> # /cfg/slb/gslb/rule 2 (Select rule 2)

4 Specify a start and end time for this rule to be applied.

>> Rule 2# start 7 00/end 1800/ena

(From 7am until 6PM)

>> Rule 2# ena (Enable the rule)

5 Specify the GSLB metrics to be used to select a site if a serveris not selected at first.

Since network metric is the first metric, make sure to add theconfigured networks to metric 1.




.


>> # /cfg/slb/gslb/rule 2/metric 1/gmetric network>> # /cfg/slb/gslb/rule 2/metric 1/addnet 43/addnet55/addnet 56

6 Specify the other preferred GSLB metrics.

>> # /cfg/slb/gslb/rule 2/metric 2/gmetricgeographical>> # /cfg/slb/gslb/rule 2/metric 3/gmetric roundrobin

Task 2: Configure the second time-based rule

Using the steps in "Configuring Time-Based Rules" (page 760),configure another rule with the following parameters.

>> # /cfg/slb/gslb/net 48/sip 48.0.0.0/mask240.0.0.0/addreal 2/en>> # /cfg/slb/gslb/rule 4/start 18 00/end 7 00/ena>> # /cfg/slb/gslb/rule 4/metric 1/gmetricnetwork/addnet 48>> # /cfg/slb/gslb/rule 4/metric 2/gmetricgeographical>> # /cfg/slb/gslb/rule 4/metric 3/gmetric random

7 Add the rule to the configured virtual server. Using the basicGSLB example, add the following command to the virtual serverconfiguration steps on step 5 on step 5.

>> # /cfg/slb/virt 1/addrule2/addrule 4

(Add rules 2 and 4 to thevirtual server/domain)


>> Rule 2 Metric 4# apply>> Rule 2 Metric 4# save

—End—

Using the Availability Metric in a RuleThe availability metric selects the next server in a priority list when anycapacity thresholds of the previous servers has been reached.

Step Action

1 Set the availability metric for metric 2 in rule 1.




.


>> # /cfg/slb/gslb/rule 1/metric 2/gmetricavailability

2 Set the Availability values for the real/virt servers. For example:

>> Rule 1# /cfg/slb/virt1/avail 11

(Set avail. weight for virt.server)

>> Rule 1# /cfg/slb/real10/avail 22

(Set avail. weight for realserver)

>> Rule 1# /cfg/slb/real11/avail 33

(Set avail. weight for realserver)


>> Rule 1 Metric 4# apply>> Rule 1 Metric 4# save

—End—

Configuring GSLB Network PreferenceNortel Application Switch Operating System software allows clients to selectGSLB sites based on where the client is located. This is implemented byconfiguring network preference. Network preference selects the serverbased on the preferred network of the source IP address for a given domain.The preferred network contains a subset of the servers for the domain.

The following example, illustrated in "Configuring Client Proximity Table"(page 763), shows how to create rules based on client network preference.Two client networks, A and B, are configured in the network preferencerule on the master switch at Site 4. Client A with a subnet address of205.178.13.0 is configured with a network preference rule for preferredSites 1 and 3. Client B, with a subnet address of 204.165.0.0, is configureda network preference rule for preferred Sites 2 and 4.

Client A, with a source IP address of 205.178.13.10, initiates a requestthat is sent to the local DNS server. The local DNS server is configuredto forward requests to the DNS server at Site 4. The Nortel ApplicationSwitch at Site 4 looks up its network preference and finds Client A prefers toconnect to Sites 1 or 3. Similarly, Client B’s requests are always forwardedto Sites 2 or 4.




.


Configuring Client Proximity Table

Note: Nortel Application Switch Operating System allows you toconfigure up to 128 preferred client networks. Each network can containup to 1023 real servers.

Use the following commands to configure network preferences on theapplication switch at Site 4:

>> # /cfg/slb/gslb/net 1/ (Select Network 1)

>> Network 1# sip 205.178.13.0 (Assign source address forClient A)

>> Network 1# mask 255.255.255.0 (Assign the mask for Client A)

>> Network 1# addreal 1/addreal 3 (Add real servers 1 and 3)

>> # /cfg/slb/gslb/net 2/ (Select Network 2)

>> Network 2# sip 204.165.0.0 (Assign source address forClient B)

>> Network 2# mask 255.255.0.0 (Assign the mask for Client B)

>> Network 2# addreal 2 (Add real server 2)

>> Network 2# addvir 4 (Select preferred Site 4)




.


>> # /cfg/slb/gslb/rule 1/metric 1 (Select metric 1-networkpreference)

>> Rule 1 Metric 2# addnet 1/addnet2

(Add Network 1 and Network 2)

Using this configuration, the DNS request for "nortelnetworks.com" fromclient IP 205.178.13.0 will receive a DNS response with only the virtualserver IP address of Site 1, if Site 1 has less load than Site 3.

Configuring GSLB with Proxy IP for Non-HTTP RedirectsTypically, client requests for HTTP applications are automatically redirectedto the location with the best response and least load for the requestedcontent. The HTTP protocol has a built-in redirection function that allowsrequests to be redirected to an alternate site. However, if a client requestsa non-HTTP application such as FTP, POP3, or SMTP, then the lack of aredirection function in these applications requires that a proxy IP addressbe configured on the client port. The client port will initiate a redirect only ifresources are unavailable at the first site.

Note: This feature should be used as a method of last resort for GSLBimplementations in topologies where the remote servers are usuallyvirtual server IP addresses in other Nortel Application Switches.

"HTTP and Non-HTTP Redirects" (page 765) illustrates the packet-flow ofHTTP and non-HTTP redirects in a GSLB environment. "HTTP VersusNon-HTTP Redirects" (page 764) explains the packet -flow process in detail.In this example, the HTTP or non-HTTP request from the client reaches Site2, but Site 2 has no available services.

HTTP Versus Non-HTTP Redirects

Site 2 Nortel Application SwitchSwitch

Site 1 Nortel Application SwitchSwitch

HTTP application(built-in redirection)

1a Client HTTP request reaches Site2. Resources are unavailable at Site 2.Site 2 sends an HTTP redirect to Clientwith Site 1’s virtual server IP address.

2a. Client resends request to Site 1.Resources are available at Site 1.

Non-HTTPapplication (noredirection

1b. Client non-HTTP request reachesSite 2. Resources are unavailable atSite 2. Site 2 sends a request to Site1 with Site 2’s proxy IP address asthe source IP address and the virtualserver IP address of Site 1 as thedestination IP address.

2b. Site 1 processes the client proxyIP request. Resources are available atSite 1. Site 1 returns request to proxyIP port on Site 2.




.


HTTP and Non-HTTP Redirects

How Proxy IP Works"POP3 Request Fulfilled via IP Proxy" (page 765) shows examples of twoGSLB sites deployed in San Jose and Denver. The applications being loadbalanced are HTTP and POP3. Any request that cannot be serviced locallyis sent to the peer site. HTTP requests are sent to the peer site using HTTPRedirect. Any other application request will be sent to the peer site usingthe proxy IP feature.

POP3 Request Fulfilled via IP Proxy

The following procedure explains the three-way handshake between the twosites and the client for a non-HTTP application (POP3).




.


Step Action

1 A user POP3 TCP SYN request is received by the virtual serverat Site 2. The switch at that site determines that there are nolocal resources to handle the request.

2 The Site 2 switch rewrites the request such that it now containsa client proxy IP address as the source IP address, and thevirtual server IP address at Site 1 as the destination IP address.

3 The switch at Site 1 receives the POP3 TCP SYN request to itsvirtual server. The request looks like a normal SYN frame, soit performs normal local load-balancing.

4 Internally at Site 1, the switch and the real servers exchangeinformation. The TCP SYN ACK from Site 1’s local real server issent back to the IP address specified by the proxy IP address.

5 The Site 1 switch sends the TCP SYN ACK frame to Site 2, withSite 1’s virtual server IP address as the source IP address, andSite 2’s proxy IP address as the destination IP address.

6 The switch at Site 1 receives the frame and translates it, usingSite 1’s virtual server IP address as the source IP address andthe client’s IP address as the destination IP address.

This cycle continues for the remaining frames to transmit all theclient’s mail, until a FIN frame is received.

—End—

Configuring Proxy IP AddressesThe switch at Site 1 in San Jose is configured with switch port 6 connectingto the default gateway and real server 3 represents the remote server inDenver.

The following commands are used at Site 1 in San Jose to configure theproxy IP address for the remote server in Denver:

>> # /cfg/slb/pip (Select proxy IP address menu)


>> Proxy IP address# add 200.200.200.4

(Set unique proxy IP address)

>> # /cfg/slb/port 6/proxy enable (Enable proxy on the port)




.


>> Proxy IP address /cfg/slb/real 1/proxy dis (Disable local realserver proxy)

>> Real server 1# /cfg/slb/real 2/proxy dis (Disable proxy forlocal server)

>> Real server 2# /cfg/slb/real 3/proxy ena (Enable proxy forremote server)

>> Real server 3# apply (Apply configuration changes)

>> Real server 3# save (Save configuration changes)

For more information on proxy IP address, see "Proxy IP Addresses" (page228).

If you want to configure proxy IP addresses on Site 2, the followingcommands are issued on the Denver switch:

>> # /cfg/slb/pip (Select proxy IP address menu)


>> Proxy IP address# add 174.14.70.4

(Set unique proxy IP address)

>> # /cfg/slb/port 4/proxy enable (Enable proxy on the port)

>> Proxy IP address# /cfg/slb/real 1/proxy dis (Disable localreal server proxy)

>> Real server 1# /cfg/slb/real 2/proxy dis (Disable local realserver proxy)

>> Real server 2# /cfg/slb/real 3/proxy ena (Enable proxy forremote server)

>> Real server 3# apply (Apply configuration changes)

>> Real server 3# save (Save configuration changes)

Using Border Gateway Protocol for GSLBBorder Gateway Protocol (BGP)-based GSLB utilizes the Internet’s routingprotocols to localize content delivery to the most efficient and consistentsite. This is done by using a shared IP block that co-exists in each InternetService Provider’s (ISP’s) network and is then advertised, using BGP,throughout the Internet.

Because of the way IP routing works, BGP-based GSLB allows for therouting protocols to route DNS requests to the closest location, which thenreturns IP addresses of that particular site, locking in the requests to thatsite. In effect, the Internet is making the decision of the best location for you,avoiding the need for advanced GSLB.




.


Some corporations use more than one ISP as a way to increase thereliability and bandwidth of their Internet connection. Enterprises with morethan one ISP are referred to as being multi-homed. Instead of multi-hominga network to several other networks, BGP-based GSLB enables you tomulti-home a particular piece of content (DNS information) to the Internet bydistributing the IP blocks that contain that content to several sites.

When using DNS to select the site, a single packet is used to make thedecision so that the request will not be split to different locations. Throughthe response to the DNS packet, a client is locked in to a particular site,resulting in efficient, consistent service that cannot be achieved when thecontent itself is shared.

For example, in multi-homing, you can connect a data center to threedifferent Internet providers and have one DNS server that has the IP address1.1.1.1. In this case, all requests can be received via any given feed but arefunneled to the same server on the local network. In BGP-based GSLB, theDNS server (with the IP address 1.1.1.1) is duplicated and placed local tothe peering point instead of having a local network direct traffic to one server.

When a particular DNS server receives a request for a record (in thiscase, the application switch), it returns with the IP address of a virtualserver at the same site. This can be achieved using the local option(/cfg/slb/gslb/rule 1/metric 2/gmetric local) in the GSLBconfiguration. If one site is saturated, then the switch will failover and deliverthe IP address of a more available site.

For more information on configuring your switch to support BGP routing,see "Border Gateway Protocol" (page 131).

Verifying GSLB Operation• Use your browser to request the configured service (www.gslb.exam-

ple.com in the previous example).

• Examine the /info/slb and /info/slb/gslb information on eachswitch.

• Check to see that all SLB and GSLB parameters are working accordingto expectation. If necessary, make any appropriate configurationchanges and then check the information again.

• Examine the /stats/slb and /stats/slb/gslb statistics on eachswitch.




.

Bandwidth Management 769

Bandwidth Management

Bandwidth Management (BWM) enables Web site managers to allocatea portion of the available bandwidth for specific users or applications.It allows companies to guarantee that critical business traffic, such ase-commerce transactions, receive higher priority versus non-critical traffic.Traffic classification can be based on user or application information. BWMpolicies can be configured to set lower and upper bounds on the bandwidthallocation.


• "Enabling Bandwidth Management" (page 769)

• "Contracts" (page 770)

• "Policies" (page 776)

• "Rate Limiting" (page 777)

• "Traffic Shaping" (page 780)

• "Bandwidth Management Information" (page 781)

• "Packet Coloring (TOS bits) for Burst Limit" (page 783)

• "Configuring Bandwidth Management" (page 784)

• "Additional BWM Configuration Examples" (page 788)

Enabling Bandwidth ManagementTo use the bandwidth management features, you must purchase anadditional software license and password key. Instructions for obtaining apassword key are provided with your software license certificate.

There are two operational keys for BWM: a standard key and a demo key.The demo key automatically expires after a demo time period. These keysmay only be enabled if Layer 4 services have been enabled.

Once you have obtained the proper password key to enable BWM, followthese instructions:

Step Action

1 Connect to the switch command line interface via Telnet orthe console port, and login as the administrator, followingthe directions in the Nortel Application Switch Operating SystemCommand Reference.

2 From the command line prompt, type the /oper/swkeycommand.




.


You will be prompted to enter the password key. If the key is correctfor this switch’s MAC address, the switch will accept the password,permanently record it in the switch’s non-volatile RAM (NVRAM),and will then enable the feature.

—End—

ContractsA contract is created to assign a certain amount of bandwidth. Up to 1024contracts can be configured on a single Nortel Application Switch. Theswitch uses these contracts to limit individual traffic flows. Contracts canbe assigned to different types of traffic. Traffic can be classified based onlayer 2, layer 4, or layer 7 traffic. Traffic classification can be based on thefollowing: port, VLAN, trunk, filters, virtual IP address, service on the virtualserver, URL, and so on.

Any item that is configured with a filter can be used for BWM. Bandwidthclassification is performed using the following menus:

• /cfg/slb/filt is used to configure classifications based on the IPdestination address, IP source address, TCP port number, UDP, UDPport number, 802.1p priority value, or any filter rule.

• /cfg/slb/virt is used to configure classifications based on virtualservers.

• /cfg/port is used to configure classifications based on physical ports(in case of trunking, use /cfg/l2/trunk).

• /cfg/l2/vlan is used to configure classifications based on VLANs.

• /cfg/slb/layer7/lb is used to configure classification based onURL paths.

To associate a particular classification with a contract, enter the contractindex into the cont menu option under the applicable configuration menus.

When Virtual Matrix Architecture (VMA) is enabled, traffic classification isdone on the ingress port—that is, the port on which the frame is received(not the client port or the server port). If the traffic classification is doneon layer 4 through layer 7 traffic (filter-based or SLB traffic), then theclassification occurs on the designated port.




.


Bandwidth Management: How It Works

Classification RulesIn a classification rule certain frames are grouped together. For framesqualifying for multiple classifications, precedence of contracts is alsospecified per contract. If no precedence is specified, the default order isused (see "Classification Precedence" (page 772)).

The following classifications are aimed at limiting the traffic outbound fromthe server farm for bandwidth measurement and control.

• Physical Port - All frames are from a specified physical port.

• VLAN - All frames are from a specified VLAN. If a VLAN translationoccurs, the bandwidth policy is based on the ingress VLAN.

• IP Source Address - All frames have a specified IP source address orrange of addresses defined with a subnet mask.

• IP Destination Address - All frames have a specified IP destinationaddress or range of addresses defined with a subnet mask.

• Switch services on the virtual servers

The following are various Layer 4 groupings:

• A single virtual server

• A group of virtual servers

• A service for a particular virtual server

• Select a particular port number (service on the virtual server) within aparticular virtual server IP address.




.


The following are various Layer 7 groupings:

• A single URL path

• A group of URL paths

• A single cookie

Classification PrecedenceIf a frame qualifies for different classifications, it is important to be able tospecify the classification with which it should be associated. There are twomechanisms to address classification—a per-contract precedence valueand a default precedence ordering from 1-255. The higher numbers havingthe higher precedence. If a contract does not have an assigned precedencevalue, then the default ordering is applied as follows:

Step Action

1 Incoming source port/default assignment

2 VLAN

3 Filter

4 Layer 4 services on the virtual server

5 Layer 7 applications (for example, URL, HTTP, headers, cookies,and so forth

—End—

If a frame falls into all of classifications #1–5, and if the precedence issame for all the applicable contracts, then the Layer 7 applications contractclassification (#5) will be assigned since it comes last and has the highestpresentness.

Application Bandwidth ControlClassification policies allow bandwidth limitations to be applied to particularapplications; that is, they allow applications to be identified and grouped.Classification can be based on any filtering rule, including those listed below:

• Layer 7 strings that identify which application the traffic belongs to

• TCP Port Number - All frames with a specific TCP source or destinationport number

• UDP - All UDP frames

• UDP Port Number - All frames with a specific UDP source or destinationport number




.


CombinationsCombinations of classifications are limited to grouping items together into acontract. For example, if you wanted to have three different virtual serversassociated with a contract, you would specify the same contract index oneach of the three virtual server IP addresses. You can also combine filtersin this manner.

"Grouped Bandwidth Contracts" (page 773) describes how the contractscan be grouped together to aggregate BWM resources.

"IP User Level Contracts for Individual Sessions" (page 774) describesa user level contract.

Grouped Bandwidth ContractsThe Nortel Application Switch Operating System uses the concept ofmulti-tiered, or grouped bandwidth management contracts. In earlierNortel Application Switch Operating System releases, a single levelbandwidth management contract was used to manage bandwidth on anNortel Application Switch. BWM contract groups can now be configuredto aggregate contract resources and share unused bandwidth within thecontract group. A group level contract should contain two or more individualcontracts as defined in "Contracts" (page 770).

Based on how much traffic is sent in each contract in the group, the hardlimits of the contracts will be adjusted proportionately to their share in thegroup. For example, a group level contract is configured with four individualcontracts with rate limits of 10, 20, 30 and 40 Mbps each. Together, the totalrate limit of the member contracts is 100 Mbps. If a particular contract is notusing its full bandwidth allocation, the switch will re-allocate the bandwidthto the other members of the contract group by polling bandwidth statisticsevery second, and re-calculating the bandwidth allocation.

"Bandwidth Reallocation in Grouped Contracts" (page 774) shows howindividual contracts’ hard limits self-adjust when placed into a contractgroup. The hard limit indicates the actual hard limits set for each individualcontract. Since Contracts 1–4 are part of a contract group, the Total hardlimit allowed for the group in this example is 100 Mbps.

The actual traffic indicates that Contracts 1 and 4 have exceeded theirhard limits by a total of 25 Mbps. Contract 3 is underutilizing its hard limitby 10 Mbps.

Because all contracts are members of the group, the unused bandwidth isdivided proportionately between the two contracts that exceeded their hardlimits—Contracts 1 and 4.

• Contract 1 requests 15 Mbps, which is 5 Mbps over its hard limit.Because Contract 1 requested 5 of the 25 Mbps BW over the total BWHard Limit for the contract group, it will thus receive one-fifth of the




.


available Extra Share, or 2 Mbps. The remaining 3 Mbps that Contract 1requested is dropped.

• Contract 4 requests 60 Mbps, which is 20 Mbps over its hard limit.Because Contract 4 requested 20 of the 25 Mbps over the total BW HardLimit for the contract group, it will thus receive four-fifths of the ExtraShare, or 12 Mbps. The remaining 12 Mbps requested by Contract 4is dropped.

Bandwidth Reallocation in Grouped Contracts

Contract1

Contract2

Contract3

Contract4

Total

Hard Limit (Mbps) 10 20 30 40 100

Actual traffic 15 20 20 60 115

Unused BW NA NA 10 NA 10

BW over Hard 5 0 NA 20 25

Extra Share 0 NA 10

Adjusted HardLimit

12 20 20 48 100

(All units in Mbps)

a. Denotes the BW over hard limit in Contract 1, divided by the Total BW overhard limit for the contract group, multiplied by the total Extra Share bandwidth.

b. Denotes the BW over hard limit in Contract 4, divided by the Total BW overhard limit for the contract group, multiple by the total Extra Share bandwidth.

The soft and reserved (CIR) limits of each contract are not part of thegrouped contract’s calculation, and remain set at their individual contract’slevels.

For a group contract configuration example, see "ConfiguringGroupedContracts for Bandwidth Sharing" (page 791).

IP User Level Contracts for Individual SessionsThe Nortel Application Switch Operating System contains user limits forbandwidth management. User limits are policies that can be applied to acontract that specify a rate limit for each user who is sending or receivingtraffic in that contract. Each user is identified by his/her IP address. Thecontract can be configured to identify a user by either the source or thedestination IP address in the packets.

An individual users’ bandwidth can be restricted by setting a limit basedon the user’s IP address, monitoring the amount of bandwidth used persecond, and dropping any traffic that exceeds the configured limit. In order




.


to monitor a user’s bandwidth, the switch creates a user entry that recordsthe source or destination IP address, and the amount of bandwidth used.This user entry is called an IP user entry, because the user is identifiedby his/her IP address.

The user limit feature is extremely useful for limiting bandwidth hoggingby a few overactive internet users with unimportant traffic (for examplepeer-to-peer movie sharing), which may end up denying the other userswith legitimate traffic from their fair share. Since the user limiting is done onper-contract basis, different types of traffic can be classified into differentcontracts and can have different user limits applied according to the class oftraffic. Also, since user limiting for a contract is optional, it can be configuredfor some contracts with class of traffic where fair sharing of bandwidthis important, and not configured for the contracts where fair sharing ofbandwidth is not important or undesirable.

The following sections describe how user limits work.

User Limits are Overwritten by the Contract Hard LimitThe IP user limit is configured in addition to the contract’s hard limit.However, the contract’s hard limit overrides the individual user entry’s userlimit. For example, consider a contract with hard limit 10 Mbps and user limit1 Mbps. If there are 20 IP users for the contract with offered traffic rate of1 Mbps each (for total offered traffic rate for the contract 20 Mbps), thetotal traffic allowed for the contract will not exceed the hard limit (10 Mbps).Therefore, even though the individual IP user limits do not exceed their 1Mbps hard limit, some or all of the IP users may have some traffic droppedbecause the contract’s hard limit (10 Mbps) is less than the total of theoffered traffic rate for all 20 users (20 Mbps).

User Limits are Maintained when a Contract has AvailableBandwidthConsider another example for the same contract (hard limit 10 Mbps, userlimit 1 Mbps) where there are two IP users for the contract, with offeredtraffic rate of 5 Mbps each (total offered traffic rate for the contract 10 Mbps).Even though the offered traffic rate for the whole contract does not exceedthe hard limit, Nortel Application Switch Operating System will limit thetraffic for both the IP users to their user limits: 1 Mbps each.

The user limit configured for a contract will be the limit for one egress SPrather than the entire switch. For example; on an Nortel Application Switch2424, if a contract is configured for a user limit of 64 kbps—and traffic fora user (IP address) is egressing port 1 (SP 1) and 20 (SP 2) — that user(IP address) will be restricted to 64 kbps egressing on port 1 and 64 kbpsegressing out on port 20.




.


For an example, see "Configuring a IP User-Level Rate Limiting Contract"(page 794).

PoliciesBandwidth policies are bandwidth limitations defined for any set of frames,that specify the maximum, best effort, and minimum guaranteed bandwidthrates. A bandwidth policy is assigned to one or more contracts.

A bandwidth policy is often based on a rate structure whereby a Web hostor co-location provider could charge a customer for bandwidth utilization.There are three rates that are configured: a Committed Information Rate(CIR)/Reserved Limit, a Soft Limit, and a Hard Limit, as described below.

Bandwidth Policy IndexEach BWM contract is assigned a bandwidth policy index and (optionally)a name. This index can be viewed using the /cfg/bwm/cont menu.Contracts can be enabled and disabled. The set of classificationsassociated with each contract can be viewed using the /info/bwm menu.

Each bandwidth policy, composed of the reserved, soft, hard and optionaluser limits, is assigned an index. These policies can be found under the/cfg/bwm menu. Up to 64 bandwidth policies can be defined. Bandwidthlimits are usually entered in Mbps.

Note: For better granularity, rates can be entered in Kbps by appending"K" to the entered number. For example, 1 Mbps can be entered aseither "1" or as "1024k."

In addition, a queue size is associated with each policy. The queue sizeis measured in bytes.

Time PolicyA BWM contract can be configured to apply different time policies defined byranges of hours or days of the week. The time policy is based on the timeset in the switch’s system clock (/info/sys/general).

"Configuring Time and Day Policies" (page 809) describes how to configureand apply policies to different times and days.

Enforcing PoliciesIn order for BWM contracts and policies to take effect, the policies must beenforced using the /cfg/bwm/force ena command.




.


Even when BWM is not enforced, the Nortel Application Switch can stillcollect classification information and report it, allowing an administratorto observe a network for a while before deciding how to configure it.This feature can be disabled using /cfg/bwm/force dis. When thiscommand is used, no limits will be applied on any contract.

Rate LimitingA rate limiting contract is controlled by metering the traffic that egressesfrom the switch. If the egress rate is below the configured rate limit (hardlimit) for the port, the traffic is transmitted immediately without any buffering.If the egress rate is above the configured rate limit the traffic above therate limit is dropped.

Bandwidth Rate Limits

For rate limiting contracts, the queue depth is ignored because traffic isnot buffered.

Typically, bandwidth management occurs on the egress port of theswitch—that is, the port from which the frame is leaving. However, in thecase of multiple routes or trunk groups, the egress port can actually be oneof several ports (from the point-of-view of where the queues are located).

A bandwidth policy specifies four limits, listed and described in "BandwidthRate Limits" (page 778):




.


Bandwidth Rate Limits

Rate Limit Description

CommittedInformation Rate(CIR) or ReservedLimit

This is a rate that a bandwidth classification is alwaysguaranteed. In configuring BWM contracts, ensure thatthe sum of all committed information rates never exceedsthe link speeds associated with ports on which the trafficis transmitted. In a case where the total CIRs exceed theoutbound port bandwidth, the switch will perform a gracefuldegradation of all traffic on the associated ports.

Soft Limit For traffic shaping contracts, this is the desired bandwidthrate, that is, the rate the customer has agreed to pay ona regular basis. When output bandwidth is available, abandwidth class will be allowed to send data at this rate.No exceptional condition will be reported when the datarate does not exceed this limit. For rate limiting contracts,the soft limit is ignored.

Hard Limit This is a "never exceed" rate. A bandwidth class is neverallowed to transmit above this rate. Typically, traffic burstsbetween the soft limit and the hard limit are charged apremium. The maximum hard limit for a bandwidth policy is1 Gbps, even when multiple Gigabit ports are trunked. Toensure a specific amount of throughput on a port, configurehard and soft limits close together. For example: to ensure20Mbps of throughput on a 100Mbps port, create a policy ona contract that sets the hard limit to 20M, and the soft limit to19M. If you apply this contract to a filter on the egress port,20Mbps of throughput can be ensured.

User Limit A user limit is a Hard Limit rate for individual users. Itis defined as a policy and is applied and enabled foran individual contract. It is based on either a source IPor destination IP address. Setting user limits requiresthat a contract be configured that enables IP limiting(/cfg/bwm/cont <x> /iplimit ena), and sets thetype of limiting to source IP or destination IP address(/cfg/bwm/cont <x> /iptype {sip|dip}).

When configured, an individual IP address can be limited totraffic between 0kbps and 1000Mbps. A user limit based onsource IP address should be set if the goal is to limit theamount of data being transmitted from a source IP addressin your network.

A user limit based on destination IP address should be setif the goal is to limit the amount of data being downloadedfrom a destination IP address in your network.




.


Application Session CappingApplication Session Capping is a feature that allows limits to be placedon the number of sessions on a user per contract or per contract basis.Bandwidth contracts will now have an additional maximum sessionsparameter that will define the upper limit at which the application will becapped.

Note: Session capping per contract is applied on a per SP basis.Session capping per user is applied on a per switch basis.

Application Session Capping is applied in the following ways:

• Contract Capping - Session capping per contract is applied per SP.

• User Capping - Session capping per user is applied

Application Session Capping is a feature that is especially relevant intoday’s world of peer to peer applications that require a large amount ofnetwork bandwidth. This feature will allow the switch administrator to capthe number of sessions of an application assigned to each user. In this way,peer to peer (and other such non-business applications) can be limited orcompletely eliminated on the network.

Note: For the purposes of this feature, a user is defined as a uniquesource IP address and the application is identified based upon abandwidth contract

This feature functions by creating an entry in the session table thatdesignates the contract/user combination. Whenever a new session iscreated, this entry is checked against existing sessions in the sessiontable and if a match is made, the maximum sessions value is queried.If the maximum sessions value has been reached, the new session willbe dropped. If the value has not been reached, the session count isincremented and the session allowed to continue.

Note 1: Application Session Capping is not supported when a contractis assigned to a port, VLAN, trunk, or virtual service.

Note 2: Application Session Capping does not support an iplimitcontract based on DIP. It will however support on based on SIP.

Rate Limiting TimeslotsFor rate limiting contracts, metering of individual traffic flows is accomplishedusing several timeslots per second. The timeslot traffic limit is the trafficthat is sent for a particular contract for every timeslot corresponding to thecontract’s rate limit or the hard limit is initially calculated.




.


For any contract there is one timeslot traffic limit for each egress port. Thetimeslot traffic limit is calculated from the hard limit. The timeslot traffic limitis the amount of traffic that corresponds to the hard limit per second dividedby the number of timeslots per second.

Traffic is transmitted for every timeslot as long as the traffic is below thetimeslot traffic limit for the contract. Any traffic that exceeds the timeslottraffic is discarded.

Traffic ShapingA traffic shaping contract establishes queues and schedules when framesare sent from each queue. Traffic is shaped by pacing the packets accordingto the hard, soft and reserve limits. Each frame is put into a managed bufferand placed on a contract queue. The time that the next frame is supposedto be transmitted for the contract queue is calculated according to theconfigured rate of the contract, the current egress rate of the ports, and thebuffer size set for the contract queue. The scheduler then organizes allthe frames to be sent according to their time-based ordering and metersthem out to the port.

When packets in a contract queue have not yet been sent and the buffersize set for the queue is full, any new frames attempting to be placed in thequeue is discarded.

For traffic shaping contracts, a queue depth is also associated with apolicy. A queue depth is the size of the queue that holds the data. It canbe adjusted to accommodate delay-sensitive traffic (such as audio) versusdrop-sensitive traffic (such as FTP).

Data Pacing for traffic shaping ContractsThe mechanism used to keep the individual traffic flows under control in atraffic shaping contract is called data pacing. It is based on the conceptof a real-time clock and theoretical departure times (TDT). The actualcalculation of the TDT is based initially on the configured soft limit rate. Thesoft limit can be thought of as a target limit for the ISP’s customer. As longas bandwidth is available and the classification queue is not being filled ata rate greater than the soft limit, the TDT will be met for both incomingframes and outgoing frames and no borrowing or bandwidth limitation willbe necessary. If the classification queue exceeds the soft limit, a frame isqueued for transmittal and the TDT is increased by the size of the framemultiplied by the transmittal rate of the queue.

"Real-time Clocks and Theoretical Departure Times" (page 781) shows asimple illustration of how data may be paced in a traffic shaping contract.Six arriving frames are processed differently depending on rate of thequeue. Queue 1 processes each packet evenly. Queue 2 processes per




.


1500 bytes and inserts some delay as it processes the first three 500 byteframes and then the next three frames. Queue 3 processes at 3000 bytesper second and has ample capacity to process egress frames at the samerate as the ingress frames.

Real-time Clocks and Theoretical Departure Times

If the data is arriving more quickly than it can be transmitted at the softlimit and sufficient bandwidth is still available, the rate is adjusted upwardsbased on the depth of the queue, until the rate is fast enough to reduce thequeue depth or the hard limit is reached. If the data cannot be transmittedat the soft limit, then the rate is adjusted downward until the data canbe transmitted or the CIR is hit. If the CIR is overcommitted among allthe contracts configured for the switch, graceful degradation will reduceeach CIR until the total bandwidth allocated fits within the total bandwidthavailable.

Bandwidth Management InformationStatistics are stored in the individual Switch Processors (SP) and thencollected every second by the MP (Management Processor). The MP thencombines the statistics, as statistics for some classifications may be spreadacross multiple SPs.

Viewing BWM StatisticsThe /stats/bwm/dump command displays the total number of octets sent,octet discards, and times over the soft limit are kept for each contract. Thehistory buffer maintains the average queue size for the time interval and theaverage rate for the interval.

Packet counters also maintain bandwidth management statistics for packetson a per contract basis as well as calculation of the average packet size.




.


Configuring BWM HistoryHistory is maintained only for the contracts for which the history option isenabled (/cfg/bwm/cont x/hist).

Sending BWM HistoryThe MP maintains global statistics, such as total octets, and a window ofhistorical statistics. When the history buffer of 128K is ready to overflow, itcan be sent from the switch using either an e-mail or direct socket transfermechanism.

To configure the sending of bandwidth management statistics, follow thisprocedure:

Step Action

1 Select the statistics delivery method.

Bandwidth Management statistics can be sent through e-mail orby socket to a reporting server.

• To send BWM statistics through e-mail, issue this command:

>> Main# /cfg/bwm/email enable

• To send BWM statistics by socket to a reporting server, issuethe following commands:

>> Main# /cfg/bwm/emaildisable

(E-Mail statistics deliverymust be disabled)

>> Main# /cfg/bwm/report <Reporting Server IPAddress>

BWM statistics will be sent to TCP port 49152 of the specifiedreporting server.

2 Configure the selected delivery method.

• To configure e-mail usage, issue these commands:

>> Main# /cfg/bwm/user <SMTP User Name>>> Main# /cfg/sys/smtp <SMTP host name or IPaddress>

• To configure socket delivery usage, issue this commands:




.


>> Main# /cfg/sys/mmgmt/report {mgmt | data}

(Select to use themanagement or dataport to communicate withthe reporting server).

To obtain graphs, the data must be collected and processed byan external entity through SNMP.

—End—

Statistics and Management Information Bases

• For existing BWM classes:

As mentioned above, the MP maintains per-contract rate usagestatistics. These are obtainable via a private MIB.

• When BWM services are not enabled:

Even when BWM is not enforced, the MP can still collect classificationinformation and report it, allowing an administrator to observe a networkfor a while before deciding how to configure it. This feature can bedisabled using /cfg/bwm/force dis. When this command is used,no limits will be applied on any contract.

Synchronizing BWM Configurations in VRRPBWM configurations will optionally be synchronized to a backup switchduring VRRP synchronization. However, port contracts and VLAN contractswill not be synchronized. For more information on VRRP and synchronizedconfigurations, see "Configuring VRRP Peers for Synchronization" (page578).

Packet Coloring (TOS bits) for Burst LimitWhenever the soft limit is exceeded, optional packet coloring can be doneto allow downstream routers to use diff-serv mechanisms (that is, writingthe Type-Of-Service (TOS) byte of the IP header) to delay or discard theseout-of-profile frames. Frames that are not out-of -profile are marked witha different, higher priority value. This feature can be enabled or disabledon a per-contract basis, using the wtos option under the contract menu(/cfg/bwm/cont <x> /wtos) to enable/disable overwriting IP TOS.

The actual values used by the switch for overwriting TOS values (dependingon whether traffic is over or under the soft TOS limit) are set in the bandwidthpolicy menu (/cfg/bwm/pol <x>) with the utos and otos options. The




.


values allowed are 0-255. Typically, the values specified should match theappropriate diff-serv specification but could be different, depending on thecustomer environment.

Contract-Based Packet MirroringThe Nortel Application Switch Operating System features the availability ofcontract-based packet mirroring. This feature allows an egress packet thatmatches a contract to be mirrored to a specified port. This feature canbe used for troubleshooting and analysis as well as a tool to identify newsignatures for Internet Traffic Management (ITM) functionality.

The user enables packet mirroring on a contract by configuring a validmirroring port. When a packet is classified, if a mirroring port is configuredfor that contract, a copy of the packet will be mirrored to the configuredport. The packet is mirrored at the egress port after all modifications aremade to the packet.

Note: This feature is available in maintenance mode only.

To set a mirroring port for a contract, use the following command:

>> Main# /cfg/bwm/cont <contract number> /pmirr <port>

To disable a mirroring port on a contract, use the following command:

>> Main# /cfg/bwm/cont <contract number> /pmirr none

Note: Mirroring occurs before the application of the limiting contract.Packets that would have been otherwise discarded by the contract arealso copied to the mirroring port.

Configuring Bandwidth ManagementThe following procedure provides general instructions for configuring BWMon the switch. Specific configuration examples begin on "Additional BWMConfiguration Examples" (page 788).

Step Action

1 Configure the switch as you normally would for SLB.Configuration includes the following tasks:







.





For more information about SLB configuration, see "Server LoadBalancing" (page 188)."

2 Enable BWM on the switch.

Note: If you purchased the Bandwidth Management option,make sure you enable it by typing/oper/swkey and enteringits software key. For more information, see "Enabling BandwidthManagement" (page 769).

>> # /cfg/bwm/on (Turn BWM on)

3 Select a bandwidth policy.

Each policy must have a unique number from 1 to 64.

>> Bandwidth Management# pol 1 (Select bandwidth policy 1)

4 Set the hard, soft, and reserved rate limits for the policy, inMbps.

Typically, charges are applied for burst rates between the soft andhard limit. Each limit must be set between 64K-1000M.

Note: For rates less than 1 Mbps, append a "K" suffix to thenumber.

>> Policy 1# hard 6 (Set "never exceed" rate)

>> Policy 1# soft 5 (Set desired bandwidth rate)

>> Policy 1# resv 4 (Set committed information rate)

5 (Optional) Set the Type-Of-Service (TOS) byte value, between0-255, for the policy underlimit and overlimit.

There are two parameters for specifying the TOS bits: underlimit(utos) and overlimit (otos). These TOS values are used tooverwrite the TOS values of IP packets if the traffic for a contractis under or over the soft limit, respectively. These values onlyhave significance to a contract if TOS overwrite is enabled in theBandwidth Management Contract Menu (/cfg/bwm/cont <x>/wtos ena).

The administrator has to be very careful in selecting the TOS valuesbecause of their greater impact on the downstream routers.




.


>> Policy 1# utos 204 (Set BWM policy underlimit)

>> Policy 1# otos 192 (Set BWM policy overlimit)

6 Set the buffer limit for the policy.

Set a value between 8192-128000 bytes. The buffer depth for aBWM contract should be set to a multiple of the packet size.

Note: Keep in mind that the total buffer limit for the BandwidthManagement policy is 128K.

>> Policy 1# buffer 16320 (Set BWM policy bufferlimit)

7 On the switch, select a BWM contract and (optional) a name forthe contract.

Each contract must have a unique number from 1 to 256.

>> Policy 1# /cfg/bwm/cont 1 (Select BWM contract 1)

>> BWM Contract 1# name BigCorp (Assign contract name"BigCorp")

8 (Optional) Set a precedence value for the BWM contract.

Each contract can be given a precedence value from 1-255.The higher the number, the higher the precedence. If a frame isapplicable to different classifications, then the contract with higherprecedence will be assigned to the frame. If the precedence is thesame for the applicable contracts, then the following order will beused to assign the contract to the frame:

(1) Incoming port, (2) VLAN, (3) Filter, (4) Service on the Virtualserver, (5) URL/Cookie

>> BWM Contract 1# prec1

(Sets contract precedence value to1)

9 (Optional) Enable TOS overwriting for the BWM contract.

>> BWM Contract 1# wtos ena (Enables TOS overwritingfor contract)

10 Set the bandwidth policy for this contract.

Each bandwidth management contract must be assigned abandwidth policy.




.


>> BWM Contract 1# pol 1 (Assign policy 1 to BWMcontract 1)

11 (optional) Enable traffic shaping.

Rate limiting is enabled by default. Enabling traffic shapingautomatically disables rate limiting. See "Traffic Shaping" (page780) for more information.

>> BWM Contract 1# shaping e (Enables traffic shaping)

12 Enable the BWM contract.

>> BWM Contract 1# ena (Enables this BWM contract)

13 Classify the frames for this contract and assign the BWMcontract to the filter or virtual IP address.

Each BWM contract must be assigned a classification rule. Theclassification can be based on a filter or service(s) on the Virtualserver. Filters are used to create classification policies based on theIP source address, IP destination address, TCP port number, UDP,and UDP port number.

>> BWM Contract 1# /cfg/slb/virt 1/cont 1

(Assign contract to virtualserver)

>> Virtual Server 1# /cfg/slb/filt 1/adv/cont 1

(Assign contract 1 to filter 1)

In this case, all frames that match filter 1 or virtual server 1 will beassigned contract 1.

14 On the switch, apply and verify the configuration.

>> Filter 1 Advanced# apply (Make your changes active)

>> Filter 1 Advanced#/cfg/bwm/cur

(View current settings)

Examine the resulting information. If any settings are incorrect,make any appropriate changes.

15 On the switch, save your new configuration changes.

>> Bandwidth Management#save

(Save for restore after reboot)




.


16 On the switch, check theBWM information.

>> Bandwidth Management# /info/bwm <contract number>(View BWM information)

>> Bandwidth Management# /stats/bwm <contract number>(View BWM statistics)

Check that all BWM contract parameters are set correctly. Ifnecessary, make any appropriate configuration changes and thencheck the information again.

—End—

Additional BWM Configuration ExamplesExamples are provided for the following Bandwidth Managementapplications:

• "Configuring User/Application Fairness" (page 788)

• "ConfiguringGrouped Contracts for Bandwidth Sharing" (page 791)

• "Configuring a IP User-Level Rate Limiting Contract" (page 794)

• "Configuring BWMPreferential Services" (page 796)

• "Configuring Content Intelligent Bandwidth Management" (page 799)

• "Configuring Cookie-Based Bandwidth Management" (page 803)

• "ConfiguringSecurity Management" (page 807)

• "Configuring Time and Day Policies" (page 809)

• "Egress Bandwidth Tuning for Lower Speed Networks" (page 811)

• "Configuring Intelligent Traffic Management" (page 812)

Note: Ensure BWM is enabled on the switch (/cfg/bwm/on).

Configuring User/Application FairnessBandwidth Management can be applied to prevent heavy bandwidthbursters from locking out other users, such as the following:

• Customers using broadband access (such as DSL) blocking dial-upcustomers

• Customers using the same hosting facility locking out each otherbecause of flash crowd

• FTP locking out Telnet

• Rate limits of particular applications




.


In the following example, BWM is configured to prevent broadbandcustomers from affecting dial-up customer access. This is accomplishedby setting higher bandwidth policy rate limits for the port that processesbroadband traffic.

• Policy 1 is for dialup customers with lower bandwidth allocation needs

• Policy 2 is for broadband customers with higher bandwidth allocationneeds.

Step Action

1 Select the first bandwidth policy for dialup customers.

Each policy must have a number from 1 to 512.


>> # /cfg/bwm/pol 1 (Select BWM policy 1)

2 Set the hard, soft, and reserved rate limits for the bandwidthpolicy, in Mbps.




3 On the switch, select a BWM contract and name the contract.



>> BWM Contract 1# name dial-up (Assign contract name"dial-up")


Each BWM contract must be assigned a bandwidth policy.

>> BWM Contract 1# pol 1 (Assign policy 1 to BWM Contract1)

5 Enable this BWM contract.


6 Select the second bandwidth policy for broadband customers.




.


>> BWM Contract 1# /cfg/bwm/pol 2

(Select bandwidth policy 2)

7 Set the hard, soft, and reserved rate limits for this policy, inMbps.




8 On the switch, select the second BWM contract and name thecontract.


>> BWM Contract 2# namebroadband

(Assign contract name"broadband")



>> BWM Contract 2# pol 2 (Assign policy 2 to BWM contract 2)



11 Assign the BWM contracts to different switch ports.

Physical switch ports are used to classify which frames are managedby each contract—that is, one BWM contract will be applied to allframes from a specific port. The second contract will be applied toall frames from another specified port.

>> BWM Contract 2# /cfg/port1/cont 1

(Assign contract 1 to port 1)

>> Port 1# /cfg/slb/port 2/cont2



>> Port 2# apply (Make your changes active)

>> Port 2# /cfg/bwm/cur (View current BWM settings)




.




>> Bandwidth Management# save (Save for restore afterreboot)

14 On the switch, check the BWM information.



—End—

ConfiguringGrouped Contracts for Bandwidth SharingIn the following example, BWM is configured to allow sharing of BWMresources by configuring a group contract. While the group hard limit will beessentially the aggregate of the hard limits defined for each contract in thegroup, any unused bandwidth may be shared amongst all member contracts.

For example, a group level contract is defined with four individual contractsthat have committed information rates (CIR) of 10, 20, 30, and 40 Mbpseach. Together, the total CIR of the member contracts is 100 Mbps. Basedon how much traffic is actually being sent by all the contracts in the group,the hard limits of each contract are readjusted every few seconds, inproportion to each contract’s share in the group. In effect, the contract withonly 10 Mbps may be allowed at times to share any unused resources inthe group and burst up to a higher hard limit. If that contract is removedfrom the group, then the contract will revert to its individual hard limits, andany traffic above its configured hard limit would be dropped as usual. Fora more detailed explanation on how hard limits for contracts behave in acontract group, refer back to "Bandwidth Reallocation in Grouped Contracts"(page 774).

Note: While traffic shaping contracts may be added to a group levelcontract, their soft and reserved limits are not readjusted.

Step Action

1 Ensure BWM is enabled on the switch.




.


>> /cfg/bwm/on








3 Select the first bandwidth policy and set the hard, soft, andreserved rate limits for the bandwidth policy, in Mbps.


>> Policy 1# hard 10M (Set "never exceed" rate)

>> Policy 1# soft 5M (Set desired bandwidth rate)

>> Policy 1# resv 1M (Set committed information rate)

4 Configure BWM contract 1.



5 Assign the bandwidth policy 1 to contract 1.

>> BWM Contract 1# pol 1 (Assign policy 1 to BWM Contract1)

6 Enable contract 1.


7 Select bandwidth policy 2.

>> BWM Contract 1# /cfg/bwm/pol2

(Select bandwidth policy2)




.






9 On the switch, select BWM contract 2.


10 Assign bandwidth policy 2 to contract 2.



11 Enable contract 2.


12 Using the same CLI commands as described above, configurepolicy 3 with hard, soft, and reserved limits of 30, 25, and 20Mbps respectively. Then create contract 3 and apply policy3 to this contract.

13 Configure policy 4 with hard, soft, and reserved limits of 40, 35,and 30 Mbps respectively. Then create contract 4 and applypolicy 4 to this contract.

14 Assign the BWM contracts to different switch ports.

Physical switch ports are used to classify which frames are managedby each contract—that is, one BWM contract will be applied to allframes from a specific port. The second contract will be applied toall frames from another specified port.

>> BWM Contract 4# /cfg/port1/cont 1


>> Port 1# /cfg/port 2/cont 2 (Assign contract 2 to port 2)



15 Configure BWM contract group 1 and add all four contractsto this group.




.


>> /cfg/bwm/group 1 (Select contract group 1)

>> BW Group 1# add 1 (Add contract 1 to group 1)

Contract 1 added to group 1.








>> Port 2# apply (Make your changes active)

>> Port 2# /cfg/bwm/cur (View current BWM settings)




18 Check the BWM information.



—End—

Configuring a IP User-Level Rate Limiting ContractThe following example is for university that wants to restrict the amount ofTCP traffic for individual students and for the student body as a whole.Contract 1 is configured as follows:

• Each student (IP address) is limited to 64 kbps.




.


• All members of the student body is limited to maximum (hard limit) of10 Mbps.

• If the number of octets sent out exceeds the value of the entire contract(10 Mbps), excess octets will be dropped.

• If the number of octets is below the value of the contract (10 Mbps), asession is created on the switch that records the student’s IP address,the egress port number, and the contract number, as well as the numberof octets transferred for that second. The session updates the numberof octets being transferred every second, thus maintaining traffic withinthe configured user limit of 64 kbps.

The administrator would setup a configuration as follows:

Step Action

1 Select the first bandwidth policy.



2 Configure the BWM policy with a Hard Limit of 10 Mbps and a"user limit" of 64 kbps. Then apply that policy to Contract 1.

>> Policy 1# hard 10m

>> Policy 1# userlim 64k

>> Policy 1# /cfg/bwm/cont 1 (Select contract 1)

>> BW Contract 1# policy 1 (Apply policy 1 to this contract)

3 Configure a filter to match the source IP address range of thestudent body, and assign BWM Contract 1 to that filter.

/cfg/slb/filt 20/sip 150.150.0.0/smask 255.255.0.0/action allow (Allow student traffic)

>> Filter 20 # adv (Select the filter 20advanced menu)

>> Filter 20 Advanced# cont 1 (Apply BWM contract 1 tothis filter)

4 Add the filter to an ingress port on the Nortel ApplicationSwitch.

/cfg/slb/port 1/filt ena/add 20 (Add filter 20 to port 1)




.


5 In the BWM configuration, enable IP limiting.

/cfg/bwm/cont 1/iplimit e

6 Determine whether the user should be identified by their sourceor destination IP address.

• If the contract is used for traffic going out to the Internet, define itby the source IP address: iptype sip.

• If the contract is used to limit the amount of traffic downloadedfrom the user by a client on the Internet, define it by thedestination IP address: iptype dip.

>> BW Contract 1# iptype sip

7 Disable traffic shaping on this contract. Traffic shaping cannotbe used in user-level rate limiting contracts.

>> /cfg/bwm/cont 1/shaping dis


9 View the current per-user BWM sessions for the active contract.

/stats/bwm/port 1/cont 1

—End—

Configuring BWMPreferential ServicesBWM can be used to provide preferential treatment to certain traffic, basedon source IP blocks, applications, URL paths, or cookies. You may find ituseful to configure higher policy rate limits for specific sites, for example,those used for e-commerce.

In the following example, there are two Web sites, "A.com" and "B.com."BWM is configured to give preference to traffic sent to Web site "B.com:"

Step Action







.






For more information about SLB configuration, refer to "Server LoadBalancing" (page 188)."





3 Set the hard, soft, and reserved rate limits for the bandwidthpolicy in Mbps.




4 Select a BWM contract and name the contract.


>> Policy 1# /cfg/bwm/cont 1 (Select BWM Contract 1)

>> BWM Contract 1# name a.com (Assign contract name"a.com")

5 Assign the bandwidth policy to this contract.






>> BWM Contract 1# /cfg/bwm/policy 2

(Select BWM policy 2)




.






9 Select the second BWM contract and name the contract.


>> BWM Contract 2# name b.com (Assign contract name"b.com")

10 Assign the bandwidth policy to this contract.





12 Create a virtual server that will be used to classify the framesfor contract 1 and assign the Virtual server IP address for thisserver. Then, assign the BWM contract to the virtual server.Repeat this procedure for a second virtual server.

Note: This classification applies to the services within the virtualserver and not to the virtual server itself.

The classification rule for these BWM contracts is based on a virtualservice. One of the BWM contracts will be applied to any frames thatare sent to the virtual server associated with that contract.

>> BWM Contract 2# /cfg/slb/virt 1/service 80/cont 1(Assign contract to virtual server 1)


(Set virtual server VIP address)

>> Virtual Server 1# ena (Enable this virtual server)

>> Virtual Server 1#/cfg/slb/virt 2/cont 2

(Assign contract to virtual server)




.



(Set virtual server IP address)

>> Virtual Server 2# ena (Enable this virtual server)


>> Virtual Server 2# apply (Make your changes active)

>> Virtual Server 2# /cfg/bwm/cur

(View current BWMsettings)




15 Check the bandwidth management information.



—End—

Configuring Content Intelligent Bandwidth ManagementContent intelligent BWM allows the network administrator or Web sitemanager to control bandwidth based on Layer 7 content such as URLs,HTTP headers, or cookies.

All three types of BWM are accomplished by following the configurationguidelines on content switching described in "Content Intelligent ServerLoad Balancing" (page 210) and "Application Redirection" (page 409)." Youwould also need to assign a contract to each defined string, where the stringis contained in a URL, an HTTP header, or a cookie.

BWM based on Layer 7 content gives Web site managers the followingcapabilities:

• Ability to allocate bandwidth based on the type of request




.


The switch allocates bandwidth based on certain strings in the incomingURL request. For example, as shown in "URL-Based SLB withBandwidth Management" (page 800), if a Web site has 10Mbps ofbandwidth, the site manager can allocate 1 Mbps of bandwidth for staticHTML content, 3Mbps of bandwidth for graphic content and 4Mbps ofbandwidth for dynamic transactions, such as URLs with cgi-bin requestsand .asp requests.

• Ability to prioritize transactions or applications

By allocating bandwidth, the application switch can guarantee thatcertain applications and transactions get better response time.

• Ability to allocate a certain amount of bandwidth for requests that canbe cached

As shown in "URL-Based SLB with Bandwidth Management" (page800), users will be able to allocate a certain percentage of bandwidthfor Web cache requests by using the URL parsing and bandwidthmanagement feature.

URL-Based SLB with Bandwidth Management

The following example assumes you have configured URL-based SLBand the layer 7 strings as described in "Content Intelligent Server LoadBalancing" (page 210). For URL-based server load balancing, a user has




.


to first define strings to monitor. Each of these strings is attached to realservers, and any URL with the string is load balanced across the assignedservers. The best way to achieve URL-based bandwidth management isto assign a contract to each defined string. This allocates a percentage ofbandwidth to the string or URL containing the string.

Step Action

1 Configure "Content Intelligent Server Load Balancing" (page 210).

2 Configure BWM policies with the desired bandwidth limits. Inthis example, four policies are configured, as illustrated in"URL-Based SLB with Bandwidth Management" (page 800).

>> Main# /cfg/bwm/pol 1/hard 3M/soft 2M/res 1M>> Policy 1# /cfg/bwm/pol 2/hard 4M/soft 3M/res 2M>> Policy 2# /cfg/bwm/pol 3/hard 1M/soft 500k/res250k>> Policy 3# /cfg/bwm/pol 4/hard 2M/soft 1M/res 500k

3 Configure BWM contracts and apply the appropriate policies tothe contracts. In this example, the policy numbers correspondto the contract numbers.

>> Main# /cfg/bwm/cont 1/policy1

(Apply policy 1 to contract1)

>> BW Contract 1# /cfg/bwm/cont 2/policy 2>> BW Contract 2# /cfg/bwm/cont 3/policy 3>> BW Contract 3# /cfg/bwm/cont 4/policy 4

4 Identify the defined string IDs that were configured.


For easy configuration and identification, each defined string isassigned an ID number, as shown in the following example. Thethird column shows the BWM contracts to assign to the strings inthis example

ID SLB String BWM Contract

1 any 4

2 .gif 1

3 .jpg 1

4 .cgi 2

5 .bin 2




.


ID SLB String BWM Contract

6 .exe 2

7 .html 3

5 Assign BWM contracts to each string using the syntax shown:

>> Main# /cfg/slb/layer7/slb/cont <String ID> < BWMContract number>

6 Verify that the strings and contracts are assigned properly.:

>> Server Load Balance Resource# curNumber of entries: 21: any, cont 42: .gif, cont 13: .jpg, cont 14: .cgi, cont 25: .bin, cont 26: .exe, cont 27: .html, cont 3

7 Configure a real server to handle the URL request.


>> # /cfg/slb/real 2/layer7/addlb <SLB string ID>

where

SLB string ID is the identification number of the defined stringas displayed when you enter the cur command.

Example: /cfg/slb/real 2/layer7/addlb 3

8 Either enable Direct Access Mode (DAM) on the switch orconfigure a proxy IP address on the client port.

To turn on DAM:


To turn off DAM and configure a proxy IP address on the client port:

>> # /cfg/slb/adv/direct dis

>> # /cfg/slb/port 2/proxy ena (Enable use of proxy IP onthis port)




.


>> # /cfg/slb/pip/type port

>> # /cfg/slb/pip/add12.12.12.12

(Add this proxy IP addressto port 2)


Note: Port mapping for content intelligent server load balancingcan be performed by enabling DAM on the switch, or disablingDAM and configuring a proxy IP address on the client port.

9 Turn on HTTP SLB processing on the virtual server.

Configure everything under the virtual server as in ConfigurationExample 1.

>> # /cfg/slb/virt 1/service 80/httpslb urlslb

If the same string is used by more than one service, and you want toallocate a certain percentage of bandwidth to this URL string for thisservice on the virtual server, then define a rule using the urlcontcommand.

>> # /cfg/slb/virt 1/service 80/urlcont <SLB stringID> <BW Contract number>

This contract is tied to service 1. The urlcont command willoverride the contract assigned to the URL string ID.


>> # /cfg/slb/on


—End—

Configuring Cookie-Based Bandwidth ManagementCookie-based BWM enables Web site managers to prevent network abuseby bandwidth-hogging users. Using this feature, bandwidth can be allocatedby type of user or other user-specific information available in the cookie.

Cookie-based bandwidth management empowers service providers tocreate tiered services. For example, Web site managers can classify usersas first class, business class, and coach and allocate a larger share of thebandwidth for preferred classes.




.


Cookie-Based Bandwidth Management

Note: Cookie-based BWM does not apply to cookie-based persistencyor cookie passive/active mode applications.

In this example, you will assign bandwidth based on cookies. First, configurecookie-based server load balancing, which is very similar to URL-basedload balancing. Any cookie containing the specified string is redirected tothe assigned server.

Scenario 1: In this scenario, the Web site has a single virtual server IPaddress and supports multiple classes of users. Turn on cookie parsingfor the service on the virtual server.

>> # /cfg/slb/virt 1/service 80>> Virtual Server 1 http Service# httpslb cookie enaEnter the starting point of the cookie value [1-64]: 1Enter the number of bytes to be extract [1-64]: 8Look for cookie in URI [e|d]: d

Step Action

1 Define one or more load-balancing strings.

>> # /cfg/slb/layer7/slb/addstr <l7lkup|pattern> <SLBstring>

Example:

>> # /cfg/slb/layer7/slb/addstr l7lkup "Business">> # add l7lkup "First">> # add l7lkup "Coach"




.


2 Allocate bandwidth for each string.

To do this, assign a BWM contract to each defined string.

>> # /cfg/slb/layer7/slb/cont <SLB string ID> <BWMContract number>

3 Configure a real server to handle the cookie.


>> # /cfg/slb/real 2/layer7/addlb <SLB string ID>

where SLB string ID is the identification number of the defined string.

Example:

>> # /cfg/slb/real 2/layer7/addlb 3

4 Either enable DAM on the switch or configure a proxy IPaddress on the client port.

To turn on DAM:


To turn off DAM and configure a Proxy IP address on the client port:

>> # /cfg/slb/adv/direct dis>> # /cfg/slb/pip


>> Proxy IP Address# add12.12.12.12>> # /cfg/slb/port 2>> SLB Port 2# proxy ena


Note: By enabling DAM on the switch or, alternatively, disablingDAM and configuring a proxy on the client port, port mapping forURL-based load balancing can be performed.

5 Enable SLB.

>> # /cfg/slb/on




.


Scenario 2: In this scenario, the Web site has multiple virtual serverIP addresses, and the same user classification or multiple sitesuse the same string name. In this scenario, there are two VirtualIP (VIP) addresses: 172.17.1.1 and 172.17.1.2. Both the virtualservers and sites have first class and business class customers,with different bandwidth allocations, as shown in "Cookie-BasedPreferential Services" (page 806).

Cookie-Based Preferential Services

The configuration to support this scenario is similar to scenario 1.Note the following:

—End—

Step Action

1 Configure the string and assign contracts for the strings andservices.

2 If the same string is used by more than one service, and youwant to allocate a certain percentage of bandwidth to a userclass for this service on the virtual server, then define a ruleusing the urlcont command:

>> # /cfg/slb/virt 1/service 80/ urlcont <URL path ID><BW Contract number>




.


Note: When assigning /cfg/slb/virt 1/service80/urlcont (contract 1) and /cfg/slb/layer7/lb/cont(contract 2) to the same URL, urlcont will override contract 2,even if contract 2 has higher precedence.

—End—

ConfiguringSecurity ManagementBWM can be used to prevent Denial of Service (DoS) attacks that generatea flooding of "necessary evil" packets. BWM can be used to limit the rate ofTCP SYN, ping, and other disruptive packets. BWM can also be used toalert the network manager when soft limits are exceeded.

In the following example, a filter is configured to match ping packets, andBWM is configured to prevent DoS attacks by limiting the bandwidth policyrate of those packets:

Step Action

1 Configure the switch as usual for SLB (see "Server LoadBalancing" (page 188)):








2 Select a bandwidth policy.



3 Set the hard, soft, and reserved rate limits for this policy inKilobytes.




.


>> Policy 1# hard 250k (Set "never exceed" rate)

>> Policy 1# soft 250k (Set desired bandwidth rate)

>> Policy 1# resv 250k (Set committed information rate)

4 Set the buffer limit for the policy.

Set a parameter between 8192 and 128000 bytes. The buffer depthfor a BWM contract should be set to a multiple of the packet size.

>> Policy 1# buffer 8192 (Set policy buffer limit of 8192bytes)

5 On the switch, select a BWM contract and name the contract.


>> Bandwidth Management#/cfg/bwm/cont 1

(Select BWM contract 1)

>> BWM Contract 1# name icmp (Select contract name"icmp")

6 Set the bandwidth policy for the contract.



7 Enable the BWM contract.

>> BWM Contract 1# ena (Enable this BWM contract)

8 Create a filter that will be used to classify the frames for thiscontract and assign the BWM contract to the filter.

The classification rule for this BWM contract is based on a filterconfigured to match ICMP traffic. The contract will be applied toany frames that match this filter

>> BW Contract 1# /cfg/slb/filt1/proto icmp

(Define protocol affected byfilter)

>> Filter 1# adv/icmp any (Set the ICMP messagetype)

>> Filter 1 Advanced# cont 1 (Assign BWM contract 1 tothis filter)




.


>> Filter 1 Advanced#/cfg/slb/filt 1/ena

(Enable this filter)

>> Filter 1# apply (Port and enable filtering)


>> Filter 1 Advanced# apply (Make your changes active)

>> Filter 1 Advanced#/cfg/bwm/cur

(View current BWMsettings)




11 On the switch, check the BWM information.



—End—

Configuring Time and Day PoliciesBandwidth Management contracts can be configured to have different limitsdepending on the time of day and day of the week. For example, in officenetworks that are typically busy during a workday, higher bandwidth limitscan be applied during peak work hours. Lower bandwidth limits can beapplied during hours with minimal traffic, such as on evenings or weekends.

Up to two time policies can be applied to each contract. The default settingsfor each time policy is "Day everyday, From Hour 12am, To Hour12am, Policy 512, time policy disabled"

If both time policy 1 and time policy 2 are enabled on a contract, and bothpolicies match the current time set in the switch’s system clock, time policy1 will take effect.




.


CAUTIONWhen configuring time policies, the "to" hour cannot be earlierthan the "from" hour, as in a time policy set from 7pm to 7 am.Nortel Application Switch Operating System does not calculatetime policies that cross the 24-hour day boundary.

Step Action

1 Configure three BWM policies for high, low and defaultbandwidth. These policies will be applied to different timepolicies later in this procedure.

>> /cfg/bwm/policy 1/hard10M/soft 5M

(For peak working hours)


(For weekday eveninghours)


(For all other times)

2 Create a BWM contract that will contain the time policies.

>> /cfg/bwm/cont 1

3 Create the first time policy under contract 1, for peak workinghours.

>> # /cfg/bwm/cont 1/timepol 1

>> BW Contract 1 Time Policy 1# day weekdayCurrent Time Policy Day: everydayPending new Time Policy Day: weekday

>> BW Contract 1 Time Policy 1# from 7amCurrent Time Policy from hour: 12amPending new Time Policy from hour: 7am

>> BW Contract 1 Time Policy 1# to 7pmCurrent Time Policy to hour: 12amPending new Time Policy to hour: 7pm

>> BW Contract 1 Time Policy 1#policy 1

(Assign highest BW policyto this time policy)

>> BW Contract 1 Time Policy 1# enaCurrent status: disabledNew status: enabled




.


4 Create the second time policy under contract 1, for weekdayevening hours.

>> # /cfg/bwm/cont 1/timepol 2/day weekday/from7pm/to 11pm/policy 2/ena

5 Apply the default BWM policy 3 to this contract. This BW policywill be in effect at all other times beyond the specifications ofthe two time policies.

>> # /cfg/bwm/cont 1/policy 3/ena

6 Assign the contract to an ingress port on the ApplicationSwitch.

>> Main# /cfg/port 1>> Port 1# cont 1Current BW Contract: 256New pending BW Contract: 1


—End—

Egress Bandwidth Tuning for Lower Speed NetworksIn situations where an Nortel Application Switch is connected to a routerthat feeds into lower speed networks, the egress traffic from the NortelApplication Switch should be throttled down to prevent the packets frombeing dropped from the router as it forwards traffic into the slower network.For example, an Nortel Application Switch may be connected to a routerwith high bandwidth of 1Gbps. However that router may be connected into aWide Area Network (WAN) using a T1 line (1.544 Mbps) or a T3 line (44.736Mbps). Any packets that exceed the capacity of the WAN will be dropped.

Egress Bandwidth tuning is only available on 10/100/1000Base-T ports.To tune down the egress bandwidth to T3 speeds, enter the followingcommands.

>> # /cfg/port 1 (Select the desired port)

>> Port 1# egbw 44M (Change egress BW to 44Mbps)

Current port egress bandwidth: 0KNew pending port egress bandwidth: 44M




.


Overwriting the TCP Window SizeThe TCP window size set in the packet indicates how many bytes of data thereceiver of that TCP packet can send without waiting for acknowledgement.In network environments where congestion is a common problem and trafficusually exceeds the configured BWM soft limit in a BWM contract, the TCPwindow size may be overwritten to better accommodate the prevailing trafficrates. It would be beneficial if the TCP traffic was slowed down by modifyingthe TCP window size rather than by dropping TCP packets, which wouldcause retransmissions.

By default, the TCP window size is overwritten only when traffic exceedsthe soft limit of the BWM contract, and when the window size is above 1500bytes. To overwrite TCP window size on a contract, enter the followingcommand:

>> # /cfg/bwm/cont 1/wtcpwine

(Enable overwriting of TCP window)

Configuring Intelligent Traffic ManagementIntelligent Traffic Management (ITM) can be used to configure, monitorand limit IP and non-IP traffic based on well-known application signatures.Content intelligent traffic management includes classifying different types oftraffic by denying, rate limiting, or shaping according to your policies.

To setup Nortel Intelligent Traffic Management (ITM), it is recommended thatyou use the Traffic Management Wizard in the Nortel ASEM client software.For more information on Intelligent Traffic management and how to classifytraffic see the Nortel Intelligent Traffic Management User’s Guide.

The ITM wizard enables you to configure complex filters for BWM contractsand policies using a simple click of a mouse. This wizard also includesNortel signature files to classify different types of traffic, for example, youcan allow HTTP traffic, Deny peer-to-peer uploads, Rate limit peer-to-peerdownloads, User limit traffic, Allow Instant Messaging chat, Deny InstantMessaging file transfers, Guarantee Voice over Internet Protocol (VoIP)traffic, etc. Nortel ITM has the ability to combat high-profile network wormsand viruses without stopping valid application traffic. Shape and prioritizecritical business application traffic, so that it is not impacted when a newworm attacks the network.

Initially you can setup the Nortel ASEM wizard to monitor all available trafficon a switch for a few days. Monitor the unclassified traffic to identify thepopular applications on the network. Use the Nortel Traffic ManagementReporting tool to graph application traffic. Analyze the data in your reportand determine the traffic you want denied or rate limited on your network.Run the Traffic Management wizard again to classify the traffic.




.


Reverse session update avoids the need to inspect traffic in both directions.This feature can also supply a "reverse contract" association so thatreturning traffic can be classified, through Bandwidth Management, into adifferent contract than was configured on the ingress filter.

For more information on how to run the wizard and classify traffic seeChapter 2, "Getting Started" in the Nortel Intelligent Traffic ManagementUser’s Guide. Run the Reporting tool frequently to verify if the policiesare being enforced.




.


XML Switch Configuration API

The Nortel Application Switch Operating System supports an ExtensibleMarkup Language (XML) configuration application programming interface(API). This support has been introduced to provide a common interface forapplications that wish to interoperate with a Nortel Application Switch. Also,XML was chosen for its wide adoption and usage. XML is also supported bythe Nortel Threat Protection System.

Software ComponentsThis feature uses two distinct software components that will work together tointerpret XML files sent to the switch. These two software components are:

Step Action

1 Schema Document

The Schema, document is the roadmap that allows the switchsoftware to interpret the XML documents that are sent to it. ThisSchema document defines the markup tags that appear in theXML document and what each means. "Schema Document"(page 814) illustrates the Schema document used by the XMLConfiguration API.

Schema Document

<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"elementFormDefault="qualified"attributeFormDefault="unqualified">

<xs:element name="AlteonConfig"><xs:annotation><xs:documentation>

Comment describing your rootelement</xs:documentation>

</xs:annotation><xs:complexType><xs:sequence>

<xs:elementname="Cli" maxOccurs="unbounded">

<xs:complexType><xs:attribute

name="Command" type="xs:string"use="required"/>

</xs:complexType></xs:element>

</xs:sequence>




.

XML Switch Configuration API 815

<xs:attributename="Version" type="xs:int" use="required"/>

</xs:complexType></xs:element>

</xs:schema>

2 XML Parser

An XML parser is embedded in the software. This parser is usedto interpret an XML file received by the switch into usable CLIcommands.

—End—

XML Configuration FileThe XML configuration file will conform to the rules laid out by the DTDdocument. The configuration file can either be produced by an applicationequipped to do so or manually in a text editor. For information about theform and format of the Extensible Markup Language, refer to the WorldWide Web Consortium XML web site at http://www.w3.org/XML/.

"XML Configuration File" (page 815) illustrates an example of an XML filethat could be used to configure a Nortel Application Switch.

XML Configuration File

<?xml version="1.0" encoding="UTF-8"?><AlteonConfig xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance"xsi:noNamespaceSchemaLocation="AOSConfig.xsd" Version="1"><Cli Command="/c/ip/if 1/en"/>

<Cli Command="/c/l3/if 1 addr 47.81.24.189"/><Cli Command="/c/l3/if 1 mask 255.255.255.0"/><Cli Command="/c/l3/if 1 broad 47.81.24.255"/>

</AlteonConfig>

XML File TransmissionSSL is used as the transport medium for sending XML configuration filesto the switch. An SSL client will be needed to connect to the switch usingcertificate authentication. This SSL client could be a standalone applicationor embedded as part of another application. After authentication takesplace, the file can be sent securely.

Certificates used for authentication purposes must be in DER format.Self-signed certificates are supported for this purpose.




.

http://www.w3.org/XML/


Feature ConfigurationTo make use of this feature, several steps must be taken:

Note: All Command Line Interface commands ending with enable toenable a feature can be used to disable a feature as well. Simply repeatthe command and substitute enable with disable.

Step Action

1 Globally enable XML configuration.

The XML Switch Configuration API is disabled by default. To enablethis feature, enter the following command:

>> Main# /cfg/sys/access/xml/xml enable

2 (Optional) Set the XML transport port number.

Since SSL is the transport mechanism for the XML configuration file,the port used by the switch to receive these files is the SSL port bydefault. This can be changed by using the following command:

>> Main# /cfg/sys/access/xml/port <port number>

Note: Since both HTTPS and XML use SSL as a transport layer,the two are closely tied together. Both HTTPS and XML mustuse the same port if both are enabled.

3 Import client certificate.

Certificate authentication is required to send an XML configurationfile to the switch. To import a client certificate, complete the processoutlined below:

>> Main# /cfg/sys/access/xml/gtcert <TFTP/FTP IPAddress><Certificate File Name> <FTP User Name> <FTPPassword>

After entering the required information, the client certificate will bedownloaded to the switch.

—End—




.

XML Switch Configuration API 817

Additional Feature CommandsAlthough not necessary for the configuration of this feature, the followingcommands are used to maintain and monitor the XML Switch ConfigurationAPI:

Step Action

1 Delete client certificate.

To delete the client certificate, issue this command:

>> Main# /cfg/sys/access/xml/delcert

2 Display client certificate.

To display the current client certificate, issue this command:

>> Main# /cfg/sys/access/xml/dispcert

3 Debug XML operations.

Enabling XML debug operations causes all commands in the XMLfile to be echoed to the Console and prefaces each one with runningXML cmd: or Invalid XML cmd:. All responses to the commands willalso be output to the Console.

To debug XML switch operations, issue this command:

>> Main# /cfg/sys/access/xml/debug enabled

4 Display the current XML API configuration.

To display the current XML API configuration, issue this command:

>> Main# /cfg/sys/access/xml/cur

—End—




.





.

819

AppendixTroubleshooting

This section discusses some tools to help you troubleshoot commonproblems on the Nortel Application Switch:

• "Port Mirroring" (page 819)

• "Filtering the Session Dump" (page 822)

Port MirroringMirroring Individual Ports

The port mirroring feature in the Nortel Application Switch Operating Systemallows you to attach a sniffer to a monitoring port that is configured to receivea copy of all packets that are forwarded from the mirrored port. NortelApplication Switch Operating System enables you to mirror port traffic for alllayers (Layer 2 - 7). Port mirroring can be used as a troubleshooting tool orto enhance the security of your network. For example, an IDS server can beconnected to the monitor port to detect intruders attacking the network.

As shown in "Monitoring Ports" (page 819), port 19 is monitoring ingresstraffic (traffic entering the switch) on port 3 and egress traffic (traffic leavingthe switch) on port 11. You can attach a device to port 19 to monitor thetraffic on ports 3 and 11.

Monitoring Ports




.

820 Appendix Troubleshooting

"Monitoring Ports" (page 819) shows two mirrored ports monitored by asingle port. Similarly, you can have a single or groups of

• a mirrored port to a monitored port

• many mirrored ports to one monitored port

• a mirrored port on one or more vlans to a monitored port (see "MirroringVLANs on a Port" (page 821))

• many mirrored ports on one or more vlans to one monitored port (see"Mirroring VLANs on a Port" (page 821))

Nortel Application Switch Operating System does not support a single portbeing monitored by multiple ports.

Ingress traffic is duplicated and sent to the mirrored ports before processingand egress traffic is duplicated and sent to the mirrored ports afterprocessing.

To configure port mirroring for the example shown in "Monitoring Ports"(page 819):

Step Action

1 Specify the monitoring port.

>> # /cfg/pmirr/monport 19 (Select port 19 for monitoring)

2 Select the ports that you want to mirror.

>> Port 19 # add 3 (Select port 3 to mirror)

>> Enter port mirror direction [in, out, or both]:in

(Monitor ingress traffic on port 3)

>> Port 19 # add 11 (Select port 11 to mirror)

>> Enter port mirror direction [in, out, or both]:out

(Monitor egress traffic on port 11)

3 Enable port mirroring.

>> # /cfg/pmirr/mirr ena (Enable port mirroring)





.

Port Mirroring 821

>> PortMirroring# apply (Apply the configuration)

>> PortMirroring# save (Save the configuration)

5 View the current configuration.

>> Port 19# cur (Display the current settings)

Monitoring port (Mirrored port,direction,vlans)19 (3,in,vlans: ) (11,out,vlans: )

—End—

Mirroring VLANs on a PortVLAN-ba sed port mirroring allows the user to monitor traffic based onVLANs associated with a port. If a mirrored port is configured as a memberof more than one VLAN, you may wish to monitor only traffic entering thatport on a specific VLAN. You can add specific VLAN(s) to be mirrored, evenif there are multiple VLANs associated with that port. If you do not specify aVLAN, all traffic on the port will be mirrored.

Enabling VLAN-based port mirroring feature is simply a matter of selectinga VLAN as one of the command parameters when choosing the mirroredport. You can use the same commands described in "Mirroring IndividualPorts" (page 819), and specify which VLANs’ traffic that you wish to mirror,using the following syntax:

add <mirrored port (port to mirror from)> <direction> <vlanindex or Carriage Return for all vlans>

To enable mirroring of ingress traffic for VLAN 3 on port 3, and egress trafficfor VLAN 4 on port 11 of step 1 and step 2 step 2, change the commandsto the following:.

>> # /cfg/pmirr/monport 19 (Select port 19 for monitoring)

>> Port 19 # add 3 in 3 (Mirror only vlan 3 ingress traffic onport 3)

>> Port 19 # add 11 out 4 (Mirror only vlan 4 egress traffic on)

To view the current configuration:

>> Port 19# cur (Display the current settings)

Monitoring port (Mirrored port,direction,vlans)19 (3,in,vlans: 3) (11,in,vlans: 4)




.


Filtering the Session DumpTypically, session dumps are long and unwieldy. Nortel Application SwitchOperating System however, provides a tool to filter session dumps basedon any of the following attributes:

• Client IP address

• Source port

• Destination IP address

• Destination port

• Proxy IP address

• Proxy port

• Matching filter

• Matching flag

• Ingress port

• Real IP address

• SP

Only one attribute can be used at a time to filter the session dump. Forexample, to filter a session dump based on client IP address 10.10.10.1,use the following command:

>> # /info/slb/sess/cip 10.10.10.1Printing Sessions for SP 11,01: 10.10.10.1 137, 205.178.13.100 137ALLOW age 2 f:100 E1,01: 10.10.10.1 2592, 172.21.31.100 http -> 1429110.20.1.2 http age 01,01: 10.10.10.1 2593, 172.21.31.100 http -> 1429210.20.1.3 http age 01,01: 10.10.10.1 2594, 172.21.31.100 http -> 1430710.20.1.2 http age 01,01: 10.10.10.1 2595, 172.21.31.100 http -> 1430810.20.1.3 http age 01,01: 10.10.10.1 2596, 172.21.31.100 http -> 1430910.20.1.4 http age 01,01: 10.10.10.1 2597, 172.21.31.100 http -> 1431010.20.1.3 http age 01,01: 10.10.10.1 2598, 172.21.31.100 http -> 1431110.20.1.4 http age 01,01: 10.10.10.1 2599, 172.21.31.100 http -> 1433910.20.1.3 http age 01,01: 10.10.10.1 2600, 172.21.31.100 http -> 1434010.20.1.4 http age 0




.

Filtering the Session Dump 823

1,01: 10.10.10.1 2601, 172.21.31.100 http -> 1436710.20.1.3 http age 01,01: 10.10.10.1 2602, 172.21.31.100 http -> 1438410.20.1.2 http age 101,01: 10.10.10.1 2603, 172.21.31.100 http -> 1438510.20.1.3 http age 101,01: 10.10.10.1 2604, 172.21.31.100 http -> 1441410.20.1.2 http age 10

>> Session Table Information#

Because VMA is enabled, the command displayed all sessions for client IPaddress 10.10.10.1 on SP 1. The sessions hash on source IP addressand destination IP address.




.





.

825

AppendixLayer 7 String Handling

This appendix describes how to create and manage the Layer 7 contentused for configuring content-intelligent load balancing and redirectionfeatures described elsewhere in this manual.


• "Exclusionary String Matching for Real Servers" (page 825)

• "Regular Expression Matching" (page 827)

• "Content Precedence Lookup" (page 829)

• "String Case Insensitivity" (page 832)

• "Configurable HTTP Methods" (page 833)

Note: For all content-intelligent switching features enable Direct AccessMode (DAM) or configure proxy IP addresses. For more information, see"Direct Access Mode" (page 239).

Exclusionary String Matching for Real ServersURL-based SLB and application redirection can match or exclude up to 128strings. Examples of strings are as follows:

• "/product," matches URLs that starts with /product.

• "product," matches URLs that have the string "product" anywhere inthe URL.

You can assign one or more strings to each real server. When more thanone URL string is assigned to a real server, requests matching any stringare redirected to that real server. There is also a special string known as"any" that matches all content.

Nortel Application Switch Operating System also supports exclusionarystring matching. Using this option, you can define a server to accept anyrequests regardless of the URL, except requests with a specific string.




.

826 Appendix Layer 7 String Handling

Note: Once exclusionary string matching is enabled, clients cannotaccess the URL strings that are added to that real server. This meansyou cannot configure a dedicated server to receive a certain string and,at the same time, have it exclude other URL strings. The exclusionaryfeature is enabled per server, not per string.

For example, the following strings are assigned to a real server:string 1 = cgistring 2 = NOT cgi/form_Astring 3 = NOT cgi/form_B

As a result, all cgi scripts are matched except form_A and form_B.

Configuring Exclusionary URL String MatchingThis configuration example shows you how to configure a server to handleany requests except requests that contain the string "test" or requests thatstart with "/images" or "/product".

To configure exclusionary URL string matching, perform the followingprocedure:

Step Action

1 Before you can configure URL string matching, ensure that theswitch has already been configured for basic SLB:






• Enable SLB.

For information on how to configure your network for server loadbalancing, see "Server Load Balancing" (page 188)."

2 Add the load balancing strings (for example test, /images,and /product ) to the real server.

>> # /cfg/slb/layer7/slb/addstr "test">> Server Loadbalance Resource# addstr "/images">> Server Loadbalance Resource# addstr "/product"





.

Regular Expression Matching 827


>> Server Loadbalance Resource# cur

ID SLB String

1 any

2 test

3 /images

4 /product

5 Assign the URL string ID to the real server.

>> Real Server 1 Layer 7 commands# addlb 2>> Real Server 1 Layer 7 commands# addlb 3>> Real Server 1 Layer 7 commands# addlb 4

6 Enable the exclusionary string matching option.

>> Real Server 1 Layer 7 commands# exclude enable

If you configured a string "any" and enabled the exclusion option,the server will not handle any requests. This has the same effectas disabling the server.

—End—

Regular Expression MatchingRegular expressions are used to describe patterns for string matching.They enable you to match the exact string, such as URLs, host names, or IPaddresses. It is a powerful and effective way to express complex rules forLayer 7 string matching. Both Layer 7 HTTP SLB and cache redirection canuse regular expressions as a resource. configuring regular expressions canenhance content-based switching in the following areas:

• HTTP header matching

• URL matching

Standard Regular Expression CharactersThe following is a list of standard regular expression special characters thatare supported in Nortel Application Switch Operating System:




.


Standard Regular Expression Special Characters

Construction Description

* Matches any string of zero or more characters

. Matches any single character

+ Matches one or more occurrences of the pattern itfollows

? Matches zero or one occurrences of its followed pattern

$ Matches the end of a line

\ Escape the following special character

[abc] Matches any of the single character inside the bracket

[^abc] Matches any single character except those inside thebracket

^ Matches the pattern exactly only if it appears at thebeginning of a line

Use the following rules to describe patterns for string matching:

• Supports one layer of parenthesis.

• Supports only single "$" (match at end of line) which must appear at theend of the string. For example, "abc$*def" is not supported.

• Size of the user input string must be 40 characters or less.

• Size of the regular expression structure after compilation cannot exceed43 bytes for load balancing strings and 23 bytes for cache redirection.The size of regular expression after compilation varies, based on regularexpression characters used in the user input string.

• Use "/" at the beginning of the regular expression. Otherwise a regularexpression will have "*" prefixed to it automatically. For example,"html/*\.htm" appears as "*html/*\.htm".

• Incorrectly or ambiguously formatted regular expressions are rejectedinstantly. For example:

— where a "+" or "?" follows a special character like the "*"

— A single "+" or "?" sign

— Unbalanced brackets and parenthesis

Configuring Regular ExpressionsThe regular expression feature is applicable to both path strings usedfor URL-based server load balancing, and expression strings used forURL-based application redirection. Configure regular expressions at thefollowing CLI prompt:




.

Content Precedence Lookup 829

>> # /cfg/slb/layer7/slb/addstr

As a result, both HTTP SLB and application redirection can use regularexpression as the resource.

Note: The more complex the structure of the string, the longer it willtake for the server to load balance the incoming packets.

Content Precedence LookupThe Layer 7 Precedence Lookup feature in Nortel Application SwitchOperating System allows you to give precedence to one Layer 7 parameterover another and selectively decide which parameter should be analyzedfirst.

The Content Precedence Lookup feature allows you to combine up to twoLayer 7 load balancing mechanisms. You can specify which types of Layer7 content to examine, the order in which they are examined, and a logicaloperator (and/or) for their evaluation.The following Layer 7 content typescan be specified:

• URL SLB

• HTTP Host

• Cookie

• Browsers (User agent)

• URL hash

• Header hash

Using the above content types with the and and or operators, the applicationswitch is configured to refine HTTP-based server load balancing multipletimes on a single client HTTP request in order to bind it to an appropriateserver. Typically, when you combine two content types with an operator(and/or), URL hash and Header hash are used in combination with Host,Cookie, or Browser content types. For example, the following types of loadbalancing can be configured using the Content Precedence Lookup feature:

• Virtual host and/or URL-based load balancing

• Cookie persistence and URL-based load balancing

• Cookie load balancing and/or URL-based load balancing

• Cookie persistence and HTTP SLB together in the same service

• Multiple HTTP SLB process type on the same service




.


Note: Cookie persistence can also be combined with the Layer 7content types. For more information on cookie persistence, see"Persistence" (page 588)."

For example, the Content Precedence Lookup feature can be used in thefollowing scenarios:

• If the client request is sent without a cookie and if no HTTP SLB isconfigured, then the switch binds the request to the real server usingnormal SLB.

• If the client request is sent without a cookie, but HTTP SLB is configuredon the switch, then the request is bound to real server based on HTTPSLB.

• If the client request is sent with a cookie, and a real server associated tothe cookie is found in the local session table, then the request will staybound to that real server.

Requirements

• Enable Direct Access Mode (DAM), or configure proxy IP address ifDAM is disabled.

• Enable delayed binding.

Using the or / and Operators"Content Precedence Lookup Protectors Example" (page 830) shows anetwork with real servers 1 and 3 configured for URL SLB and real servers2 and 3 configured for HTTP Host SLB.

Content Precedence Lookup Protectors Example

If the Content Precedence Lookup feature is configured with the or and andoperators, the request from the client is as follows:

• HTTP Host or URL SLB




.

Content Precedence Lookup 831

The HTTP Host header takes precedence because it is specified first.If there is no Host Header information and because or is the operator,the URL string is examined next.

— If a request from a client contains no Host Header but has a URLstring (such as "/gold"), the request is load balanced among Server1 or Server 3.

— If a request from a client contains a Host Header, then the requestis load balanced among Server 2 and Server 3. The URL string isignored because the HTTP Host was specified and matched first.

• HTTP Host and URL SLB

The HTTP Host header takes precedence because it is specified first.Because and is the operator, both a Host Header and URL string arerequired. If either is not available, the request is dropped.

— If a request from a client contains a URL string (such as "/gold") butnot a Host Header, it is not served by any real server.

— If a request from a client contains a URL string (such as "/gold") andHost Header, it is served only by real server 3.

Assigning Multiple Strings"Content Precedence Lookup Multiple Strings Example" (page 832) showsan example of a company providing content for two large customers:Customers A and B. Customer A uses www.a.com as their domain name,and Customer B uses www.b.com.

The company has a limited number of public IP addresses and wishesto assign them on a very conservative basis. As a result, the companyimplements virtual hosting by advertising a single virtual server IP addressthat includes both customers’ Web sites. Additionally, the hosting companyassigns only one service (HTTP port 80) to support the virtual server.

The virtual hosting company wishes to maintain the flexibility to allowdifferent types of content to be placed on different servers. To make mostefficient use of their server resources, they separate their servers into twogroups, using their fastest servers to process dynamic content (such as .cgifiles) and their slower servers to process all static content (such as .jpg files).




.


Content Precedence Lookup Multiple Strings Example

To configure content precedence lookup for the example in "ContentPrecedence Lookup Multiple Strings Example" (page 832), the hostingcompany groups all the real servers into one real server group even thoughdifferent servers provide services for different customers and different typesof content. In this case, the servers are set up for the following purpose:

Real Server Content

Server Customer Content

Server 1 Customer A Static .jpg files

Server 2 Customer A Static .jpg files

Server 3 Customer A Dynamic .cgi files

Server 4 Customer B Static .jpg files

Server 5 Customer B Dynamic .cgi files

When a client request is received with www.a.com in the Host Header and.jpg in the URL, the request will be load balanced between Server 1 andServer 2.

To accomplish this configuration, you must assign multiple strings (a HostHeader string and a URL string) for each real server.

String Case InsensitivityBy default, Nortel Application Switch Operating System supports casesensitive matching when performing lookup of Layer 7 string content.

If the following strings were configured for a real server:

1. default.asp2. search.asp




.

Configurable HTTP Methods 833

Any incoming request containing "GET /Default.asp" would not bind tostring 1 because of the capitalized D in Default.asp.

String case sensitivity may be disabled, so that any incoming requestcontaining "GET /Default.asp, GET /DEFAULT.ASP, and other casecombinations, all map to string 1.

>> # /cfg/slb/layer7/slb/casedisable

(Disable case-sensitive matching)

Configurable HTTP MethodsVarious types of HTTP methods to be processed by the Nortel ApplicationSwitch’s Layer 7 engine are now configurable. To view the currentlysupported HTTP methods, enter the following:


HTTP method types:1 GET 2 POST 3 HEAD 4 BCOPY5 BMOVE 6 BDELETE 7 BPROPPATCH 8 COPY9 CONNECT 10 DELETE 11 LINK 12 MKCOL13 MOVE 14 OPTIONS 15 POLL 16 PUT17 PROPFIND 18 PROPPATCH 19 SEARCH 20 SUBSCRIBE21 TRACE 22 UNLINK

To add an HTTP method type, select the method by its index number fromthe above list, and enter the following:

>> # /cfg/slb/layer7/slb/addmeth 2 (Add HTTP POST method)

The list of supported HTTP methods will be updated regularly in NortelApplication Switch Operating System as the HTTP protocol evolves.




.





.

835

Glossary

DIP (Destination IP Address)The destination IP address of a frame.

Dport (Destination Port)The destination port (application socket: for example, http-80/https-443/DNS-53)

NAT (Network Address Translation)Any time an IP address is changed from one source IP or destination IPaddress to another address, network address translation can be said tohave taken place. In general, half NAT is when the destination IP or sourceIP address is changed from one address to another. Full NAT is whenboth addresses are changed from one address to another. No NAT iswhen neither source nor destination IP addresses are translated. Virtualserver-based load balancing uses half NAT by design, because it translatesthe destination IP address from the Virtual Server IP address, to that ofone of the real servers.

PreemptionIn VRRP, preemption will cause a Virtual Router that has a lower priority togo into backup should a peer Virtual Router start advertising with a higherpriority.

PriorityIn VRRP, the value given to a Virtual Router to determine its ranking with itspeer(s). Minimum value is 1 and maximum value is 254. Default is 100. Ahigher number will win out for master designation.

Proto (Protocol)The protocol of a frame. Can be any value represented by a 8-bit valuein the IP header adherent to the IP specification (for example, TCP, UDP,OSPF, ICMP, and so on.)




.

836 Glossary

Real Server GroupA group of real servers that are associated with a Virtual Server IP address,or a filter.

Redirection or Filter-Based Load BalancingA type of load balancing that operates differently from virtual server-basedload balancing. With this type of load balancing, requests are transparentlyintercepted and "redirected" to a server group. "Transparently" means thatrequests are not specifically destined for a Virtual Server IP address that theswitch owns. Instead, a filter is configured in the switch. This filter interceptstraffic based on certain IP header criteria and load balances it. Filters canbe configured to filter on the SIP/Range (via netmask), DIP/Range (vianetmask), Protocol, SPort/Range or DPort/Range. The action on a filter canbe Allow, Deny, Redirect to a Server Group, or NAT (translation of either thesource IP or destination IP address). In redirection-based load balancing,the destination IP address is not translated to that of one of the real servers.Therefore, redirection-based load balancing is designed to load balancedevices that normally operate transparently in your network—such as afirewall, spam filter, or transparent cache.

RIP (Real Server)Real Server IP Address. An IP addresses that the switch load balances towhen requests are made to a Virtual Server IP address (VIP).

SIP (Source IP Address)The source IP address of a frame.

SPort (Source Port)The source port (application socket: for example, HTTP-80/HTTPS-443/DNS-53).

TrackingIn VRRP, a method to increase the priority of a virtual router and thus masterdesignation (with preemption enabled). Tracking can be very valuable in anactive/active configuration.

You can track the following:

• Vrs: Virtual Routers in Master Mode (increments priority by 2 for each)

• Ifs: Active IP interfaces on the application switch (increments priority by2 for each)

• Ports: Active ports on the same VLAN (increments priority by 2 for each)

• l4pts: Active Layer 4 Ports, client or server designation (incrementspriority by 2 for each

• reals: healthy real servers (increments by 2 for each healthy real server)




.

Glossary 837

• hsrp: HSRP announcements heard on a client designated port(increments by 10 for each)

VIP (Virtual Server IP Address)An IP address that the switch owns and uses to load balance particularservice requests (like HTTP) to other servers.

VIR (Virtual Interface Router)A VRRP address that is an IP interface address shared between two ormore virtual routers.

Virtual RouterA shared address between two devices utilizing VRRP, as defined in RFC2338. One virtual router is associated with an IP interface. This is one ofthe IP interfaces that the switch is assigned. All IP interfaces on the NortelApplication Switches must be in a VLAN. If there is more than one VLANdefined on the application switch, then the VRRP broadcasts will only besent out on the VLAN of which the associated IP interface is a member.

Virtual Server Load BalancingClassic load balancing. Requests destined for a Virtual Server IP address(VIP), which is owned by the switch, are load balanced to a real servercontained in the group associated with the VIP. Network address translationis done back and forth, by the switch, as requests come and go.

Frames come to the switch destined for the VIP. The switch then replacesthe VIP and with one of the real server IP addresses (RIP’s), updates therelevant checksums, and forwards the frame to the server for which it is nowdestined. This process of replacing the destination IP (VIP) with one of thereal server addresses is called half NAT. If the frames were not half NAT’edto the address of one of the RIPs, a server would receive the frame that wasdestined for it’s MAC address, forcing the packet up to Layer 3. The serverwould then drop the frame, since the packet would contain the destinationIP of the VIP and not that of the server (RIP).

VRID (Virtual Router Identifier)In VRRP, a value between 1 and 255 that is used by each virtual routerto create its MAC address and identify its peer for which it is sharingthis VRRP address. The VRRP MAC address as defined in the RFC is00-00-5E-00-01-{VRID}. If you have a VRRP address that two switches aresharing, then the VRID number needs to be identical on both switches soeach virtual router on each switch knows whom to share with.




.

838 Glossary

VRRP (Virtual Router Redundancy Protocol)A protocol that acts very similarly to Cisco’s proprietary HSRP addresssharing protocol. The reason for both of these protocols is so devices havea next hop or default gateway that is always available. Two or more devicessharing an IP interface are either advertising or listening for advertisements.These advertisements are sent via a broadcast message to an addresssuch as 224.0.0.18.

With VRRP, one switch is considered the master and the other the backup.The master is always advertising via the broadcasts. The backup switch isalways listening for the broadcasts. Should the master stop advertising,the backup will take over ownership of the VRRP IP and MAC addressesas defined by the specification. The switch announces this change inownership to the devices around it by way of a Gratuitous ARP, andadvertisements. If the backup switch didn’t do the Gratuitous ARP the Layer2 devices attached to the switch would not know that the MAC address hadmoved in the network. For a more detailed description, refer to RFC 2338.

VSR (Virtual Server Router)A VRRP address that is a shared Virtual Server IP address. VSR isNortel Application Switch Operating System proprietary extension to theVRRP specification. The switches must be able to share Virtual Server IPaddresses, as well as IP interfaces. If they didn’t, the two switches wouldfight for ownership of the Virtual Server IP address, and the ARP tables inthe devices around them would have two ARP entries with the same IPaddress but different MAC addresses.




.

839

Index

Symbols/Numerics80 (port) 737, 745802.1Q VLAN tagging 72, 72

Aaccessing the switch

defining source IP addresses 48RADIUS authentication 49security 46using ASEM 35using the Browser-based Interface 36using the CLI 26

active cookie mode 597administrator account 53aggregating routes 137

example 143allow (filtering) 190, 329, 365application health checking 479application portsapplication redirection 367, 409

client IP address authentication 423example with NAT 415games and real-time applications 423non cacheable sites 423non-HTTP redirects for GSLB 764proxies 411, 415, 421rport 415, 422See cache redirection 411topologies 412Web-cache redirection example 409, 423

Application Switch Element Manager(ASEM) 35

authenticating, in OSPF 158

authoritative name servers 729autonomous systems (AS) 151

Bbackup servers 208, 209, 209bandwidth management

burst limit 783configuration, general 770, 788configuration, preferential service 796configuration, security 807configuration, user fairness 788content intelligent 799, 803contracts 773cookie-based 803data pacing 780egress bandwidth tuning 811grouped contracts 773, 774, 791operational keys 769overwriting TCP window 811rate limiting 787statistics and history 781time policy 776

configuration example 809, 811traffic shaping 780, 780, 787user limits 776

configuration example 794, 796VMA 770

bandwidth managmentpolicies 776

bandwidth metric 206bandwidth policies

ratesblat 626Border Gateway Protocol (BGP) 131




.

840 Index

attributes 138failover configuration 139route aggregation 137route maps 133selecting route paths 139use with GSLB 767

Bridge Protocol Data Unit (BPDU) 94broadcast domains 71, 72, 74, 115Browser-Based Interface 471, 737, 745

Ccache redirection

browser-based 434delayed binding 417example 411HTTP header-based 433layer 7 traffic 423RTSP 417, 417, 439See application redirection 410servers 410, 412, 412URL hashing 436URL-based 424

CGI-bin scripts 193, 207Cisco EtherChannel 87CIST 105client traffic processing 193, 197command conventions 19Command Line Interface 26, 151configuring

BGP failover 139cache redirectioncookie-based persistence 598default filter 368delayed binding 245DNS load balancing 263dynamic NAT 388filter-based security 379FTP Server Load Balancing 256, 257,

261IDS load balancing 295IP load balancing 254IP routing 113LDAP load balancing 260multi-response cookie search 604multiple services 202OSPF 164

port trunking 86proxy IP addresses 232RTSP cache redirection 418server load balancing 194static NAT 386tunable hash for filter redirection 377VLAN-based filters 373WAP load balancing 281, 284, 288

configuring WAN linksbasic example 338summary 336with SLB 350

connection time-out 207console port 26content intelligent

cache redirection 423server load balancing 210

contracts, bandwidth management 773cookie

active 597different types 594expiration timer 600header 593names 593passive mode 596permanent 592rewrite 597temporary 592values 593

cookie-based persistence 591

Ddata pacing 780datagram 708default gateway 112, 112

configuration example 78, 79, 114, 739,747, 754

VLAN-based 75default password 53default route

OSPF 155delayed binding 242, 244

cache redirection 417denial of service protection 646deny (filtering) 190, 329, 365detecting SYN attacks 245




.

Index 841

dip (destination IP address for filtering) 369Direct Access Mode (DAM) 345, 355direct real server access 238disabling real servers 200Distributed Site State Protocol (DSSP) 729dmask

destination mask for filtering 369DNS load balancing 263Domain Name Server 348, 360Domain Name System (DNS)

filtering 379, 383Global SLB (diagram) 730load balancing, layer 7 265round robin 189, 329

dport (filtering option) 380, 415DSSP. See Distributed Site State

Protocol. 729duplex mode for jumbo frames 81dynamic NAT 388, 388

Eegress traffic 708encrypt 708End user access control

configuring 64EtherChannel 83

as used with port trunking 87expiration timer, insert cookie 600external routing 131, 150

Ffailed server protection, SLB 188, 329fault tolerance

port trunking 85Server Load Balancing 192, 329

filter redirectiontunable hash 378

filteringconfiguration example 379default filter 368, 380IP address ranges 369layer 7 deny 401NAT configuration example 385, 388numbering 369order of precedence 367, 367proto (option) 380, 415

rate limiting 631security example 378session dumps 822

filtering-based VLANs 373firewalls 379fraggle 624fragmenting jumbo frames 110, 112frame processing 80frame tagging. See VLANs tagging. 72FTP

applications 200proxy IP 764Server Load Balancing 255

configuring 256, 257, 261

Ggateway. See default gateway. 112Gigabit adapters

jumbo frames 80Global SLB

configuration tutorial 736, 752, 757Distributed Site State Protocol 729DNS resolution (diagram) 730domain name configuration 744health check interval 744hostname configuration 744HTTP redirect 731port states 742real server groups 741real servers 740remote site configuration 743tests 768using proxy IP 764

group SLB, metrics 202grouped contracts, bandwidth 773, 774,

791example 791, 794

Hhalf-duplex for jumbo frames 81hash metric 203hashing

redirection filters 378hashing on any HTTP header 225health checks 415, 488

configuration using scripts 474




.

842 Index

format 471Global SLB interval 744hostname for HTTP content 479, 480HTTPS/SSL 492IMAP server 488RADIUS server 489, 490real server parameters 479real servers 201script-based 470, 478SNMP 483verifying scripts 478wireless session protocol 492, 498WTLS 498

Host routesOSPF 160

hostname, for HTTP health checks 479, 744HP-OpenView 27HTTP

application health checks 479redirects (Global SLB option) 731

HTTP headerhashing 225

HTTP redirectionIP-based 447, 450MIME header-based 452, 454TCP service port-based 450, 452URL-based 454

HTTP URL request 400HTTPS/SSL health checks 492

IICMP 366IDS load balancing 295IEEE 802.1Q VLAN tagging 72IEEE standards

802.1s 104IF. See IP interfaces. 72IGMP 366IMAP server health checks 488, 488imask 201inbound traffic 332incoming route maps 134ingress traffic 708insert cookie mode

expiration timer 600Intelligent Traffic Management 812

internal routing 131, 150Internet Service Provider (ISP), SLB

example 191Intrusion Detection System (IDS) 290IP address

conservation 385filter ranges 369local route cache ranges 117private 386proxies 192, 228, 411, 415, 421real server groups 196, 430, 741real servers 190, 194, 330, 340, 351, 740routing example 77, 113SLB real servers 195virtual servers 190, 192, 196, 196, 330,

346, 358, 741IP interfaces

configuration example 195, 739, 739,747, 747, 754, 754

example configuration 77, 113, 116VLAN 1 (default) 72VLANs 72

IP packet format 638IP proxies

for application redirection 421for Global Server Load Balancing 764for Server Load Balancing 228See also proxies, proxy IP address

(PIP). 228IP routing 194

cross-subnet example 110default gateway configuration 78, 79, 114IP interface configuration 77, 113, 116IP subnets 111network diagram 111subnet configuration example 112switch-based topology 112

IP subnets 112routing 111, 112VLANs 71, 73

ISL Trunking 83ITM. See Intelligent Traffic Management 812

Jjumbo frames

fragmenting to normal size 110, 112




.

Index 843

frame size 80Gigabit adapter 80isolating with VLANs 80routing 110, 112supported duplex modes 81VLANs 80

Llandattack 619Layer 4

administrator account 52, 53cache redirection 412server load balancing 194, 336

Layer 7cache redirection 423deny filter 401precedence lookup 829regular expression matching 827server load balancing 210string matching 825

Layer 7 lookupwith deny filter 401

LDAP load balancing 260least connections (SLB Real Server

metric) 205leastconn metric 205link load balancing

basic example 338benefits 328configuration summary 336example with SLB 350inbound traffic 332outbound traffic 330using virtual servers 330WAN links 327

Link load balancingusing filters 329

lmask (local route cache parameter) 117lnet (local route cache parameter) 117load balancing

DNS 261, 265FTP traffic 255IDS traffic 290layer 7 traffic 210SIP traffic 310TFTP traffic 256

types of 254, 327WAN traffic 327, 327WAP traffic 279

local route cache address range 117local route cache parameters

lmask 117lnet 117

logfiltering option 365

log (filtering option) 379logical segment. See IP subnets. 71LSAs 150

MMAC address 710Main Menu

Command-Line Interface (CLI) 26management port

setting up 38management port, using 37Management Processor (MP)

use in switch security 48manual style conventions 19mapping ports 422mapping virtual ports to real ports 234matchall 642matching TCP flags 394maxcons limit 207, 208maximum connections 207, 208metrics

real server groups 202MIME header, in HTTP redirection 452, 454minimum misses (SLB real server

metric) 203minmiss metric 203mirroring ports 819monitoring ports 819monitoring real servers 242MSTPMultiple Spanning Tree Protocol

(MSTP) 104multi-homing 768

WAN links 327multi-links between switches

using port trunking 83using VLANs 74

multimedia servers 268




.

844 Index

multiple services, configuring 202multiple spanning tree groups 98Multiple Spanning Tree Protocol 104

Nname servers, Global SLB configuration

example 729Network Address Translation (NAT) 415

configuration example 385, 388filter action 367filter example 388proxy 388static example 386

network management 27network performance

statistics, with use of proxy addresses 228NFS server 191non cacheable sites in application

redirection 423non-HTTP redirects for GSLB 764none (port processing mode) example 197Nortel ASEM 27nullscan 621

Ooffset 637optional software 409OSPF

area types 147authentication 158configuration examples 165, 185default route 155external routes 164filtering criteria 366host routes 160link state database 150neighbors 149overview 146redistributing routes 133, 137route maps 133, 135route summarization 155router ID 157virtual link 156

outbound traffic 330outgoing route maps 134overflow servers 208, 209, 209

Pparallel links 74password

administrator account 53default 53L4 administrator account 52, 53user account 52

pattern group 639pattern matching

criteria 637depth 638groups 639matchall 642offset 637operation 638TCP or UDP 636

persistenceClient IP-based 590, 591cookie-based 591multi-response cookie search 604SSL session ID-based 605, 607

persistentbindings 193

ping flood 627, 634ping of death 628, 643, 646PIP. See proxies, proxy IP address. 421POP3 764port 80 737, 745port mapping 422port mirroring 819, 821port processing mode

client 197none 197server 193, 197

port states 742port trunking 84

configuration example 85description 87EtherChannel 83fault tolerance 85

portsfor servicesmonitoring 819physical. See switch ports. 71SLB configuration example 197




.

Index 845

precedence, in bandwidth classifica-tions 772

private IP address 386private network 386protocol typesproxies 192, 228, 411, 421

configuration example 388NAT 388

proxy IP address (PIP) 192, 228, 240, 421,421

proxy servers 410PVID (port VLAN ID) 72

QQuickTime Streaming Server 269

RRADIUS

authentication 49health checks 489port 1812 and 1645 199, 280, 281, 285port 1813 199, 286, 289SSH/SCP 63

RADIUS snooping 283, 283, 287RADIUS static session entries 280RADIUS/WAP persistence 287Rapid Spanning Tree Protocol 102Rapid Spanning Tree Protocol

(RSTP)RSTP 102rate limiting 777, 787

filter 631hold down periods 629protocol-based 628, 635TCP 629time window 628timeslots 779UDP and ICMP 629

Rate limiting 778real server groups

configuration example 430, 741real servers 192

backup/overflow servers 208configuration example 740connection timeouts 207disable/enable 200health checks 479

maximum connections 207SLB configuration example 195weights 206

redirect (HTTP) 731redirecting filters

tunable hash 378redirecting non-HTTP applications 764redirection. See application redirection 409redistributing routes 133, 137, 143remote (Global SLB real server

property) 744response metric 205Return-to-Sender (RTS)

for link load balancing 332, 344, 355, 357RIP (Routing Information Protocol)

advertisements 126distance vector protocol 126hop count 126metric 126TCP/IP route information 18, 126version 1 126

roundrobinSLB Real Server metric 205

route aggregation 137, 143route cache, sample 76route maps 133

configuring 135incoming and outgoing 134

route paths in BGP 139Router ID

OSPF 157routers 78, 111, 114

border 151peer 151port trunking 83switch-based routing topology 112using redirection to reduce Internet

congestion 409web-cache redirection example 410

routes, advertising 151routing 131

internal and external 150Routing Information Protocol. See RIP 126rport (filtering) 415, 422RSA keys 62RSTP 102RTSP




.

846 Index

cache redirection 417server load balancing 268

Sscalability, service 188, 329SCP

client commands 60, 61configuring administrator password 59enabling 59services 60, 60

script-based health checks 470, 478searching for cookie 604SecurID 63security

allowable SIP addresses 48denial of service protection 615, 646filter-based 378filtering 365, 378firewalls 379from viruses 365IP access control lists 612, 614layer 7 deny filter 400port mirroring 819private networks 385RADIUS authentication 49switch management 48VLANs 71

segmentation. See IP subnets. 71segments. See IP subnets. 71server (port processing mode) example 197server failure 507Server Load Balancing

across subnets 110backup servers 208, 209, 209complex network topologies 227, 228configuration example 191, 228distributed sites 728DNS 261, 265failed server protection 188, 329fault tolerance 192, 329FTP 255health checks 479IDS 290, 310maximum connections 207metrics 202overflow servers 209, 209

overview 189persistent bindings 193port processing modes 193, 197proxies 192, 228proxy IP addresses 240real server group 196, 430real server IP address (RIP) 190, 330real servers 192remote sites 728topology considerations 192virtual IP address (VIP) 190, 192, 330virtual servers 190, 196, 330WAN links 327, 327WAP 279weights 206

server pool 188server port processing 193service failure 506service portssession dumps 822Session Initiation Protocol (SIP) 310shared services 188, 328SIP (source IP address for filtering) 369smask

source mask for filtering 369SMTP 764smurf 624SNMP 27

assign health check 471HP-OpenView 27Nortel ASEM 27SNMP content health check 483

SNMP health check 483Spanning-Tree Protocol

multiple instances 98VLANs 74

spoofing, prevention of 48sport (filtering option) 380, 415SSH

client commands 60, 61RSA host and server keys 62

SSH/SCPclient commands 60, 61configuring 58encryption and authentication

methods 61with Radius authentication 63




.

Index 847

with SecurID 63static NAT 386static session entries 280statistical load distribution 84, 84streaming media 268summarizing routes 155switch management

security 48via IP interface 72

switch ports VLANs membership 71synfin scan 622syslog

messages 365

Ttagging. See VLANs tagging. 72TCP 366, 383, 383

health checking using 201port 80 241

TCP flags 394TCP window size

overwriting 811TCP/UDP port numbers 234TDT (Theoretical Departure Times) 780Telnet 379text conventions 19Theoretical Departure Times (TDT) 780timeouts for real server connections 207Traffic shaping 778, 780traffic shaping 787

bandwidth management 780transparent proxies 228, 411, 415, 421troubleshooting 822tunable hashing 378tunneling 708typographic conventions 19

UUDP 366, 383, 383

jumbo frame traffic fragmentation 112server status using 201

UDP blast protection 635, 636URL, in HTTP redirection 454user account 52user limits, bandwidth 774, 776

Using proxy IPGSLB 764

Vvirtual clocks 780virtual IP address (VIP) 190, 192, 330virtual link, OSPF 156Virtual Local Area Networks. See

VLANs. 71Virtual Matrix Architecture (VMA) 227virtual port mapping to multiple real

ports 234, 237virtual servers 190, 330

configuration example 196IP address 196, 346, 358, 741

virus attacks, preventing 400VLAN-based 821VLAN-based filtering 373VLANs

broadcast domains 71, 72, 74, 115default PVID 72example showing multiple VLANs 73filtering 373gateway, default 75ID numbers 71IP interface configuration 116IP interfaces 72jumbo frames 80multiple links 74multiple spanning trees 93multiple VLANs 72, 73parallel links example 74port members 71port mirroring 821PVID 72routing 115security 71Spanning-Tree Protocol 74, 93, 93tagging 71, 74topologies 72VLAN 1 (default) 72, 72, 195, 413VLAN-tagging adapter support for 73

VPN 708VPN cluster 709VPN Load Balancing overview 708




.

848 Index

WWAN links

configuration summary 336configuring basic example 338configuring with SLB 350inbound traffic 332load balancing 329multi-homing 327outbound traffic 330

WAPWTLS health check 498

WAP Gateway 279WAP load balancing

RADIUS snooping 283, 283, 287RADIUS/WAP persistence 287

static session entries 280Web cache redirection

See application redirection 409Web hosting 191weights 206Wide Area Networking (WAN)

load balancing 327, 327Wireless Application Protocol 279World Wide Web, client security for

browsing 379WSP health checks 492, 498WTLS health check 498

Xxmascan 622




.

Nortel Application Switch Operating System

Application GuideCopyright © 2008, Nortel NetworksAll Rights Reserved.

Publication: NN47220-104 (320507-D)Document status: StandardDocument version: 01.01Document date: 28 January 2008

To provide feedback or report a problem in this document, go to www.nortel.com/documentfeedback

Sourced in Canada, India and the United States of America

The information in this document is subject to change without notice. Nortel Networks reserves the right to make change in designor components as progress in engineering and manufacturing warrant.

*Nortel, Nortel Networks, the Nortel logo and the Globemark are trademarks of Nortel Networks.Trademarks are acknowledged with an asterisk (*) at their first appearance in the document.All other trademarks are the property of their respective owners.

http://www.nortel.com/documentfeedback

Documents

24.0.0 Application Guide