24.0.0 Application Guide

Nortel Application Switch Operating System
Application Guide
NN47220-104 (320507-D)
.
Document status: Standard Document version: 01.01 Document date: 28 January 2008 Copyright 2008, Nortel Networks All 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 written authorization of Nortel Networks, Inc. Documentation is provided "as is" without warranty of any kind, either express or implied, including any kind of implied or express warranty of non-infringement or the implied warranties of merchantability or tness for a particular purpose. U.S. Government End Users: This document is provided with a "commercial item" as dened by FAR 2.101 (Oct 1995) and contains "commercial technical data" and "commercial software documentation" as those terms are used in FAR 12.211-12.212 (Oct 1995). Government End Users are authorized to use this documentation only in accordance with those rights and restrictions set forth herein, consistent with FAR 12.211- 12.212 (Oct 1995), DFARS 227.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, except as expressly agreed to in writing by Nortel Networks, Inc. The use and purchase of this product does not convey a license 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 are trademarks 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 other trademarks appearing in this manual are owned by their respective companies.
Contents
Preface
Who should use this guide 17 What you will nd in this guide 17 Part 1: Basic Switching 17 Part 2: IP Routing 18 Part 3: Application Switching Fundamentals 18 Part 4: Advanced Switching 19 Typographic Conventions 19 Related Documentation 20 How to get help 20
17
New in this release

Features 23 Other changes 23
23
Part 1: Basic Switching

Accessing the Switch 26 Using the CLI 26 Using SNMP 27 SNMP v1.0 27 SNMP v3.0 28 Using Nortel ASEM 35 Using the Browser-Based Interface 36 Conguring BBI Access via HTTP 36 Conguring BBI Access via HTTPS 37 Using the Management Port 37 Setting Up the Management Port 38 Limiting Management Access 40 Feature Description 40 File Transfers 41 Time Conguration 41 Time Zone Conguration 41 Network Time Protocol 44 Securing the Switch 46 Protecting Switch-Owned Addresses from Attacks
25
46
Nortel Application Switch Operating System Application Guide NN47220-104 (320507-D) 01.01 Standard 24.0 28 January 2008
Copyright 2008, Nortel Networks
.
4 Contents How Different Protocols Attack the Switch 46 Conguring Denial of Service Protection 47 Viewing Dropped Packets 47 Setting Source IP Address Ranges for Switch Management 48 RADIUS Authentication and Authorization 49 RADIUS Authentication Features 49 How Radius Authentication Works 50 Conguring RADIUS Authentication on the Switch 50 Switch User Accounts 52 RADIUS Attributes for User Privileges 53 TACACS+ Authentication 54 How TACACS+ Authentication Works 54 TACACS+ Authentication Features 55 Authorization 55 Accounting 56 Conguring TACACS+ Authentication on the Switch 56 Secure Shell and Secure Copy 58 Conguring SSH/SCP features on the switch 58 Conguring the SCP Administrator Password 59 SCP Services 60 Using SSH and SCP Client Commands 60 SSH and SCP Encryption of Management Messages 61 Generating RSA Host and Server Keys for SSH Access 62 SSH/SCP Integration with Radius Authentication 63 SSH/SCP Integration with SecurID 63 End User Access Control 64 Considerations for Conguring End User Accounts 64 User Access Control Menu 65 Setting up User IDs 65 Dening User Names and Passwords 65 Changing Passwords 65 Dening User Access Level 66 Assigning One or More Real Servers to the End User 66 Validating User Conguration 66 Listing Current Users 66 Enabling or Disabling a User 67 Logging into an End User Account 67 Deny Routes 67 Conguring a Deny Route 68 Viewing a Deny Route 68
VLANs
VLAN ID Numbers 71 VLAN Tagging 72
.
71
Contents 5 VLANs and the IP Interfaces 72 VLAN Topologies and Design Issues 72 Example 1: Multiple VLANS with Tagging Adapters 73 Example 2: Parallel Links with VLANs 74 VLANs and Default Gateways 75 Segregating VLAN Trafc 75 Conguring the Local Network 77 Conguring Gateways per VLAN 77 VLANs and Jumbo Frames 80 Limitations 80 Isolating Jumbo Frame Trafc using VLANs 80 Conguring VLANs for Jumbo and Non-Jumbo Frames 81 Port Trunking 83 Overview 83 Statistical Load Distribution 84 The Trunk Hash Algorithm 84 Built-In Fault Tolerance 85 Static Port Trunking Example 85 Link Aggregation Control Protocol Trunking 87 Conguring LACP 89 Port Teaming 91 Spanning Tree Protocol 93 Overview 93 Bridge Protocol Data Units (BPDUs) 94 Determining the Path for Forwarding BPDUs 94 Spanning Tree Compatibility between BPDU Formats 95 Spanning Tree Group Conguration Guidelines 96 Adding a VLAN to a Spanning Tree Group 96 Creating a VLAN 96 Multiple Spanning Trees 97 Why Do We Need Multiple Spanning Trees? 98 Four-Switch Topology with a Single Spanning Tree 99 Four-Switch Topology with Multiple Spanning Trees 100 Switch-Centric Spanning Tree Protocol 101 VLAN Participation in Spanning Tree Groups 101 Rapid Spanning Tree Protocol 102 Port State Changes 102 Port Type and Link Type 102 RSTP Conguration Guidelines 103 RSTP Conguration Example 103 Multiple Spanning Tree Protocol 104 MSTP Region 105 Common Internal Spanning Tree 105
.
6 Contents MSTP Conguration Guidelines 105 MSTP Conguration Example 105
Part 2: IP Routing
Basic IP Routing 110 IP Routing Benets 110 Routing Between IP Subnets 110 Example of Subnet Routing 112 Dening IP Address Ranges for the Local Route Cache 117 Dynamic Host Conguration Protocol 118 DHCP Relay Agent 118 DHCP Relay Agent Conguration 119 Gratuitous ARP (GARP) Command 120 Static Routes 120 IPv4 Static Routes 121 IPv6 Static Routes 121 IPv6 123 IPv6 Address Format 123 IPv6 Address Types 123 Unicast Address 123 Multicast 124 Anycast 124 Pinging IPv6 Addresses 124 Verifying IPv6 Conguration 125 Verifying IPv6 Statistics 125 Routing Information Protocol 126 Border Gateway Protocol 131 Internal Routing Versus External Routing 131 Forming BGP Peer Routers 133 What is a Route Map? 133 Incoming and Outgoing Route Maps 134 Precedence 134 Conguration Overview 135 Aggregating Routes 137 Redistributing Routes 137 BGP Attributes 138 Local Preference Attribute 138 Metric (Multi-Exit Discriminator) Attribute 138 Selecting Route Paths in BGP 139 BGP Failover Conguration 139 Default Redistribution and Route Aggregation Example 143 Open Shortest Path First (OSPF) 146 OSPF Overview 146 Equal Cost Multipath Routing Support 147
.
109
Contents 7 Types of OSPF Areas 147 Types of OSPF Routing Devices 148 Neighbors and Adjacencies 149 The Link-State Database 150 The Shortest Path First Tree 150 Internal Versus External Routing 150 OSPF Implementation 151 Congurable Parameters 151 Dening Areas 152 Interface Cost 154 Electing the Designated Router and Backup 154 Summarizing Routes 155 Default Routes 155 Virtual Links 156 Router ID 157 Authentication 158 Host Routes for Load Balancing 160 Redistributing Routes into OSPF 161 OSPF Features Not Supported in This Release 164 OSPF Conguration Examples 164 Example 1: Simple OSPF Domain 165 Example 2: Virtual Links 167 Example 3: Summarizing Routes 173 Example 4: Host Routes 176 Verifying OSPF Conguration 185
Part 3: Application Switching Fundamentals

Server Load Balancing 188 Understanding Server Load Balancing 188 Identifying Your Network Needs 189 How Server Load Balancing Works 189 Implementing Basic Server Load Balancing 191 Network Topology Requirements 192 Conguring Server Load Balancing 194 Additional Server Load Balancing Options 199 Supported Services and Applications 199 Disabling and Enabling Real Servers 200 IP Address Ranges Using imask 201 Health Checks for Real Servers 201 Conguring Multiple Services 202 Metrics for Real Server Groups 202 Weights for Real Servers 206 Connection Time-outs for Real Servers 207 Maximum Connections for Real Servers 207
.
187
8 Contents Unlimited Connections to Real Servers 208 Backup/Overow Servers 208 Backup Only Server 209 Connection Pooling 210 Content Intelligent Server Load Balancing 210 URL-Based Server Load Balancing 211 Virtual Hosting 216 Cookie-Based Preferential Load Balancing 219 Browser-Smart Load Balancing 222 URL Hashing for Server Load Balancing 223 Header Hash Load Balancing 225 Inserting the X-Forwarded-For Header in HTTP Requests 226 Extending SLB Topologies 227 Virtual Matrix Architecture 227 Proxy IP Address Conguration 229 Port-based Proxy IP Addresses 229 VLAN-based Proxy IP Addresses 230 Selecting a Proxy IP Based on the Egress Port or VLAN 230 Proxy IP Addresses in Filters 231 Using a Virtual Server IP Address as the Proxy IP Address 231 Conguring Proxy IP Addresses 232 Proxy IP Limitation 234 Mapping Ports 234 Direct Server Return 238 Direct Access Mode 239 Assigning Multiple IP Addresses 240 Delayed Binding 242 Session Timeout Per Service 245 IPv6 and Server Load Balancing 246 IPv6 to IPv4 Server Load Balancing 247 IPv6 to IPv6 Server Load Balancing 251 IPv6 Layer 4 SLB Information 253 IPv6 Real Server Health Checks 253 Load Balancing Special Services 254 IP Server Load Balancing 254 FTP Server Load Balancing 255 Active FTP Conguration 255 FTP Network Topology Restrictions 256 Conguring FTP Server Load Balancing 256 TFTP Server Load Balancing 256 Requirements 257 Conguring TFTP Server Load Balancing 257 Lightweight Directory Access Server SLB 257
.
Contents 9 LDAP Operations and Server Types 258 How LDAP SLB Works 258 Selectively Resetting a Real Server 258 Conguring LDAP SLB 259 Domain Name Server (DNS) SLB 261 Preconguration Tasks 262 Conguring UDP-based DNS Load Balancing 263 Conguring TCP-based DNS Load Balancing 264 Layer 7 DNS Load Balancing 265 Real Time Streaming Protocol SLB 268 How RTSP Server Load Balancing Works 268 Supported RTSP Servers 269 RTSP Port Conguration 269 Conguring RTSP Load Balancing 270 Content-Intelligent RTSP Load Balancing 273 Wireless Application Protocol SLB 279 WAP SLB with RADIUS Static Session Entries 280 WAP SLB with RADIUS Snooping 283 WAP SLB with Radius/WAP Persistence 287 Intrusion Detection System SLB 290 How Intrusion Detection Server Load Balancing Works 291 Setting Up IDS Servers 292 IDS Load Balancing Congurations 293 Session Initiation Protocol Server Load Balancing 310 SIP Processing on the Switch 310 TCP based SIP Servers 310 Conguring SIP Server Load Balancing 310 UDP based SIP servers 314 Conguring SIP Server Load Balancing 314 Enhancements to SIP Server Load Balancing 317 SoftGrid Load Balancing 319 Workload Manager Support 322 WAN Link Load Balancing 327 Multi-homing 327 Benets of WAN Link Load Balancing 328 Identifying Your Network Needs 329 What is Load Balancing? 329 How WAN Link Load Balancing Works 330 Outbound Trafc 330 Inbound Trafc 332 Conguring WAN Link Load Balancing 336 Before You Begin 336 Conguration Summary 336
.
10 Contents Example 1: Simple WAN Link Load Balancing 338 Example 2: WAN Link Load Balancing with Server Load Balancing Health Checking and Multi-homing 362 Filtering 364 Overview 365 Filtering Benets 365 Filtering Criteria 365 Filtering Actions 366 Stacking Filters 367 Overlapping Filters 367 The Default Filter 368 Optimizing Filter Performance 369 IP Address Ranges 369 Filter Logs 369 Cached versus Non-cached Filters 371 MAC-Based Filters for Layer 2 Trafc 372 VLAN-based Filtering 373 Conguring VLAN-based Filtering 373 Filtering on 802.1p Priority Bit in a VLAN Header 376 802.1p Priorities 376 Classifying Packets Based on 802.1p Priority Bits 376 Tunable Hash for Filter Redirection 377 Filter-based Security 378 Network Address Translation 385 Static NAT 386 Dynamic NAT 388 FTP Client NAT 389 Overlapping NAT 391 SIP NAT and Gleaning Support 392 Matching TCP Flags 394 Matching ICMP Message Types 399 Deny Filter Based on Layer 7 Content Lookup 400 Denying HTTP URL Requests 401 Denying HTTP Headers 403 Multicast Filter Redirection 405 IPv6 Filtering 406 Application Redirection 409 Overview 409 Cache Redirection Environment 410 Additional Application Redirection Options 411 Cache Redirection Conguration Example 411 RTSP Cache Redirection 417 IP Proxy Addresses for NAT 421
350
.
Contents 11 Excluding Noncacheable Sites 423 Content Intelligent Cache Redirection 423 URL-Based Cache Redirection 424 HTTP Header-Based Cache Redirection 433 Browser-Based Cache Redirection 434 URL Hashing for Cache Redirection 436 RTSP Streaming Cache Redirection 439 HTTP Redirection 444 Congure SLB Strings for HTTP Redirection 444 IP based HTTP redirection 447 TCP Service Port Based HTTP Redirection 450 MIME Type Header-Based Redirection 452 URL-Based Redirection 454 Source IP from HTTP header and Host Header-Based Redirection HTTP to HTTPS Redirection 458 IPv6 Redirection Filter 459 Peer-to-Peer Cache Load Balancing 461 Health Checking 463 Real Server Health Checks 465 Advanced Group Health Check 465 Disabling the Fast Link Health Check 467 DSR Health Checks 467 Link Health Checks 468 Conguring Link Health Checks 469 TCP Health Checks 469 ICMP Health Checks 470 Script-Based Health Checks 470 Conguring Script-Based Health Checks 470 Script Formats 471 Scripting Commands 473 Scripting Guidelines 474 Script Conguration Examples 474 Application-Specic Health Checks 478 HTTP Health Checks 479 UDP-Based DNS Health Checks 481 TFTP Health Check 482 SNMP Health Check 483 FTP Server Health Checks 485 POP3 Server Health Checks 486 SMTP Server Health Checks 487 IMAP Server Health Checks 488 NNTP Server Health Checks 488 RADIUS Server Health Checks 489
456
.
12 Contents HTTPS/SSL Server Health Checks 492 WAP Gateway Health Checks 492 LDAP Health Checks 499 Windows Terminal Server Health Checks 501 ARP Health Checks 501 Buddy Server Health Checks 503 DHCP Health Checks 505 Failure Types 506 Service Failure 506 Server Failure 507 High Availability 508 VRRP Overview 509 Standard VRRP Components 509 IPv6 VRRP Support 521 IPv6 VRRP packets 522 IPv6 VRRP conguration 523 IPv6 VRRP information 523 Failover Methods and Congurations 524 Active-Standby Redundancy 525 Active-Active Redundancy 529 Hot-Standby Redundancy 539 Tracking Virtual Routers 548 Service-Based Virtual Router Groups 550 IPv6 VRRP Conguration Examples 555 Hot Standby Conguration Example 555 Active-Standby Conguration Example 562 Active-Active Conguration Example 569 Virtual Router Deployment Considerations 576 Mixing Active-Standby and Active-Active Virtual Routers 577 Eliminating Loops with STP and VLANs 577 Assigning VRRP Virtual Router ID 578 Conguring VRRP Peers for Synchronization 578 Synchronizing Active/Active Failover 580 Stateful Failover of Persistent Sessions 580 What Happens When a Switch Fails 581 Viewing Statistics on Persistent Port Sessions 583 Service-based Session Failover 584 Peer Synchronization 586
Part 4: Advanced Switching

Persistence 588 Overview of Persistence 588 Using Source IP Address 589 Using Cookies 589
.
587
Contents 13 Using SSL Session ID 590 HTTP and HTTPS Persistence Based on Client IP 590 Cookie-Based Persistence 591 Permanent and Temporary Cookies 592 Cookie Formats 593 Cookie Properties 593 Client Browsers that Do Not Accept Cookies 594 Cookie Modes of Operation 594 Conguring Cookie-Based Persistence 598 Server-Side Multi-Response Cookie Search 604 Proxy Support for Insert Cookie 604 SSL Session ID-Based Persistence 605 How SSL Session ID-Based Persistence Works 605 Conguring SSL Session ID-Based Persistence 607 Windows Terminal Server Load Balancing and Persistence 607 Advanced Denial of Service Protection 611 Background 611 Security Inspection Workow 612 Other Types of Security Inspection 612 IP Address Access Control Lists 612 Conguring Blocking with IP Access Control Lists 613 Viewing IP ACL statistics 614 Bogon List 614 Protection Against Common Denial of Service Attacks 615 Conguring Ports with DoS Protection 615 Viewing DOS statistics 616 Viewing DOS statistics per port 617 Understanding the types of DOS attacks 618 DoS Attack Prevention Conguration 627 Preventing other types of DOS attack 627 Protocol-BasedRate Limiting 628 Time Windows and Rate Limits 628 Hold Down Periods 629 UDP and ICMP Rate Limiting 629 TCP Rate Limiting 629 Conguring Protocol-Based Rate Limiting Filters 630 Protection Against UDP Blast Attacks 635 Conguring UDP Blast Protection 635 TCP or UDP Pattern Matching 636 Pattern Criteria 637 Matching Groups of Patterns 639 Nortel Threat Protection System 4.1 Enforcement Point 647 Remediation Subsystem 647
.
14 Contents Operations IP Access Control List 648 Session Deletion 649 Symantec Intelligent Network Protection 651 Overview 652 Intelligent Network Protection Components 653 Installing Software Keys 653 Conguration Tasks 654 CLI Command Analogs 655 Tunable Resources 656 Monitoring Symantec Functionality 657 General Symantec Information 657 Signature Names 658 Conguration Example 659 Troubleshooting 665 Conguration Synchronization - Different Memory Proles 665 Conguration Synchronization - Similar Memory Proles 665 Firewall Load Balancing 667 Firewall Overview 667 Basic FWLB 669 Basic FWLB Implementation 670 Conguring Basic FWLB 672 Four-Subnet FWLB 682 Four-Subnet FWLB Implementation 683 Conguring Four-Subnet FWLB 684 Advanced FWLB Concepts 701 Free-Metric FWLB 701 Adding a Demilitarized Zone (DMZ) 704 Firewall Health Checks 706 Virtual Private Network Load Balancing 708 Overview 708 How VPN Load Balancing Works 708 VPN Load Balancing Persistence 710 VPN Load-Balancing Conguration 711 Congure the First Clean-Side Application Switch-CA 712 Congure the Second Clean-Side Application Switch-CB 716 Congure the First Dirty-Side Application Switch-DA 718 Congure the Second Dirty-Side Application Switch-DB 721 Test Congurations and General Topology 723 Test the VPN 724 Global Server Load Balancing 727 Enabling GSLB on the Switch 727 DSSP version 1 vs. version 2 728 Migrating Previous GSLB Congurations 728
.
Contents 15 GSLB License Key 728 GSLB Overview 728 Benets 728 How GSLB Works 729 GSLB Metrics 731 Metric preferences 733 Rules 734 GSLB Availability Persistence 734 Conguring Basic GSLB 735 Basic GSLB Requirements 736 Example GSLB Topology 736 Conguring a Standalone GSLB Domain 752 GSLB Topology with a Standalone GSLB Site 753 A Standalone DNS Server Conguration 757 Conguring GSLB with Rules 759 Conguring Time-Based Rules 760 Using the Availability Metric in a Rule 761 Conguring GSLB Network Preference 762 Conguring GSLB with Proxy IP for Non-HTTP Redirects How Proxy IP Works 765 Conguring Proxy IP Addresses 766 Using Border Gateway Protocol for GSLB 767 Verifying GSLB Operation 768 Bandwidth Management 769 Enabling Bandwidth Management 769 Contracts 770 Classication Rules 771 Grouped Bandwidth Contracts 773 IP User Level Contracts for Individual Sessions 774 Policies 776 Bandwidth Policy Index 776 Time Policy 776 Enforcing Policies 776 Rate Limiting 777 Application Session Capping 779 Rate Limiting Timeslots 779 Trafc Shaping 780 Bandwidth Management Information 781 Viewing BWM Statistics 781 Conguring BWM History 782 Sending BWM History 782 Statistics and Management Information Bases 783 Synchronizing BWM Congurations in VRRP 783
764
.
16 Contents Packet Coloring (TOS bits) for Burst Limit 783 Contract-Based Packet Mirroring 784 Conguring Bandwidth Management 784 Additional BWM Conguration Examples 788 Conguring User/Application Fairness 788 ConguringGrouped Contracts for Bandwidth Sharing 791 Conguring a IP User-Level Rate Limiting Contract 794 Conguring BWMPreferential Services 796 Conguring Content Intelligent Bandwidth Management 799 Conguring Cookie-Based Bandwidth Management 803 ConguringSecurity Management 807 Conguring Time and Day Policies 809 Egress Bandwidth Tuning for Lower Speed Networks 811 Overwriting the TCP Window Size 812 Conguring Intelligent Trafc Management 812 XML Switch Conguration API 814 Software Components 814 XML Conguration File 815 XML File Transmission 815 Feature Conguration 816 Additional Feature Commands 817 Port Mirroring 819 Mirroring Individual Ports 819 Mirroring VLANs on a Port 821 Filtering the Session Dump 822 Exclusionary String Matching for Real Servers 825 Conguring Exclusionary URL String Matching 826 Regular Expression Matching 827 Standard Regular Expression Characters 827 Conguring Regular Expressions 828 Content Precedence Lookup 829 Requirements 830 Assigning Multiple Strings 831 String Case Insensitivity 832 Congurable HTTP Methods 833
Index
839
.
17
Preface
This Application Guide describes how to congure and use the Nortel Application Switch Operating System software on the Nortel Application Switches. For documentation on installing the switches physically, see the Hardware Installation Guide for your particular switch model.
Who should use this guide

This Application Guide is intended for network installers and system administrators engaged in conguring and maintaining a network. The administrator should be familiar with Ethernet concepts, IP addressing, Spanning Tree Protocol, and SNMP conguration parameters.
What you will nd in this guide

This guide helps you to plan, implement, and administer Nortel Application Switch Operating System software. Where possible, each section provides feature overviews, usage examples, and conguration instructions.

"Accessing the Switch" (page 26), describes how to access the Nortel Application Switch to congure, view information and run statistics on the 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 switch from attacks, unauthorized access, and also discusses different methods to manage the switch for remote administrators using specic IP addresses, RADIUS authentication, Secure Shell (SSH), and Secure Copy (SCP). "VLANs" (page 71), describes how to congure Virtual Local Area Networks (VLANs) for creating separate network segments, including how to use VLAN tagging for devices that use multiple VLANs. This chapter also describes how Jumbo frames can be used to ease server processing overhead.
.
18 Preface
"Port Trunking" (page 83), describes how to group multiple physical ports together to aggregate the bandwidth between large-scale network devices. "Port Teaming" (page 91), describes how to congure port teaming. "Spanning Tree Protocol" (page 93), discusses how Spanning Trees congure the network so that the switch uses the most efcient path when multiple paths exist.
Part 2: IP Routing
"Basic IP Routing" (page 110), describes how to congure the Nortel Application Switch for IP routing using IP subnets, and DHCP Relay. "IPv6" (page 123), describes how to congure the IP version 6 features of the Nortel Application Switch. "Routing Information Protocol" (page 126), describes how the Nortel Application Switch Operating System software implements standard RIP for exchanging TCP/IP route information with other routers "Border Gateway Protocol" (page 131), describes BGP concepts and BGP features supported in Nortel Application Switch Operating System. "Open Shortest Path First (OSPF)" (page 146), describes OSPF concepts, how OSPF is implemented in Nortel Application Switch Operating System, and four examples of how to congure your switch for OSPF support.

"Server Load Balancing" (page 188), describes how to congure the Nortel Application Switch to balance network trafc among a pool of available servers for more efcient, robust, and scalable network services. "Load Balancing Special Services" (page 254), describes how to extend server load balancing congurations to load balance services including source IP addresses, FTP, RTSP, DNS, WAP, IDS, and Session Initiation Protocol (SIP). " WAN Link Load Balancing" (page 327), describes how to congure the Nortel Application Switch to balance user session trafc among a pool of available WAN Links. "Filtering" (page 364), describes how to congure and optimize network trafc lters for security and Network Address Translation. "Application Redirection" (page 409), describes how to use lters for redirecting trafc to such network streamlining devices as caches.
.
Typographic Conventions
19
"Health Checking" (page 463), describes how to congure the Nortel Application Switch to recognize the availability of the various network resources used with the various load-balancing and application redirection features. "High Availability" (page 508), describes how to use the Virtual Router Redundancy Protocol (VRRP) to ensure that network resources remain available if one Nortel Application Switch is removed for service.

"Persistence" (page 588), describes how to ensure that all connections from a specic client session reach the same server. Persistence can be based on cookies or SSL session ID. "Advanced Denial of Service Protection" (page 611), describes the advanced Denial of Service protection features in Nortel Application Switch Operating System that can be used to prevent a wide range of network attacks. "Symantec Intelligent Network Protection" (page 651), describes the Symantec Intelligent Network Protection features that can be used to guard against malicious attacks and intrusions on a network. "Firewall Load Balancing" (page 667), describes how to combine features to provide a scalable solution for load balancing multiple rewalls. "Virtual Private Network Load Balancing" (page 708), describes using your Nortel Application Switch to load balance secure point-to-point links. "Global Server Load Balancing" (page 727), describes conguring Server Load Balancing across multiple geographic sites. This chapter also describes new GSLB features added in this release. "Bandwidth Management" (page 769), describes how to congure the Nortel Application Switch for allocating specic portions of the available bandwidth for specic users or applications. "XML Switch Conguration API" (page 814), describes how to use and congure the XML Conguration API. "Troubleshooting" (page 819), discusses two tools for troubleshooting your application switchmonitoring ports and ltering session dumps. "Layer 7 String Handling" (page 825), describes how to perform load balancing and application redirection based on Layer 7 packet content information (such as URL, HTTP Header, browser type, and cookies).
Typographic Conventions
The following table describes the typographic styles used in this book.
.
20 Preface Typographic Conventions Typeface or Symbol AaBbCc123 Meaning This type is used for names of commands, files, and directories used within the text. It also depicts on-screen computer output and prompts. AaBbCc123 This bold type appears in command examples. It shows text that must be typed in exactly as shown. This italicized type appears in command examples as a parameter placeholder. Replace the indicated text with the appropriate real name or value when using the command. Do not type the brackets. This also shows book titles, special terms, or words to be emphasized. [* ] Command items shown inside brackets are optional and can be used or excluded as the situation demands. Do not type the brackets. Example View the readme.txt file. Main# Main# sys
<AaBbCc123>
To establish a Telnet session, enter: host# telnet <IP address>
Read your Users Guide thoroughly. host# ls [-a]
Related Documentation
Nortel Application Switch Operating System 24.0 Release Notes (NN47220-401). Provides up-to-date information about Nortel Application Switch Operating 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 congure and access it.
How to get help

If you purchased a service contract for your Nortel Networks product from a distributor or authorized reseller, contact the technical support staff for that distributor or reseller for assistance.
.
How to get help
21
If you purchased a Nortel Networks service program, contact one of the following Nortel Networks Technical Solutions Centers:
Technical Solutions Center Europe, Middle East, and Africa North America Asia Pacific China Telephone 00800 8008 9009 or +44 (0) 870 907 9009 (800) 4NORTEL or (800) 466-7835 (61) (2) 8870-8800 (800) 810-5000
Additional information about the Nortel Networks Technical Solutions Centers is available at the following URL: http://www.nortel.com/help/contact/global An Express Routing Code (ERC) is available for many Nortel Networks products and services. When you use an ERC, your call is routed to a technical support person who specializes in supporting that product or service. To locate an ERC for your product or service, refer to the following URL: http://www.nortel.com/help/contact/erc/index.html
.
22 Preface
.
23
New in this release

This section details whats new in Nortel Application Switch Operating System 24.0 Application Guide (NN47220-104) for release 24.0.
Features
See the following sections for information about feature changes: "New Conguration options" (page 601) "Cookie Insert Mode Enhancement " (page 595) "Proxy support for Passive Cookie" (page 597) "A Standalone DNS Server Conguration" (page 757) "Accounting" (page 56) "Session Initiation Protocol Server Load Balancing" (page 310)
Other changes
See the following sections for information about changes that are not feature-related: "Limiting Management Access" (page 40) "Hot-Standby Conguration" (page 541) "Virtual Matrix Architecture" (page 227)
.
24 New in this release
.
25

This part describes how to access and manage the switch, and how to congure basic Layer 12 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 means for accessing, conguring, and viewing information and statistics about the Nortel Application Switch. The following topics are addressed in this chapter: "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 CLI

The Command Line Interface (CLI) is a built-in, text-based menu system for access via local terminal or remote Telnet or SSH session. The CLI is the most direct method for collecting switch information and performing switch conguration. The Main Menu of the CLI with administrator privileges is displayed in the following table:
[Main Menu] info - Information Menu stats - Statistics Menu cfg - Configuration Menu oper - Operations Command Menu boot - Boot Options Menu maint - Maintenance Menu diff - 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 congure the application switch by using a computer running terminal emulation software. Using the management port The management port is a Fast Ethernet port on the Nortel Application Switch that is used exclusively for managing the switch.
.
27
For more information on the management port, see "Using the Management Port" (page 37). Using a Telnet connection over the network A Telnet connection offers the convenience of accessing the switch from any workstation connected to the network. Telnet access provides the same options for user and administrator access as those available through the console port. To establish a Telnet connection with the switch, run the Telnet program on your workstation and issue the Telnet command, followed by the switch IP address:
telnet <switch IP address>
Using a SSH connection to securely log into another computer over a network. The SSH (Secure Shell) protocol enables you to securely log into another computer over a network to execute commands remotely. As a secure alternative to using Telnet to manage switch conguration, SSH ensures that all data sent over the network is encrypted and secure. For more information, see "Secure Shell and Secure Copy" (page 58).
For more information on the CLI, see the Nortel Application Switch Operating System Command Reference.
Using SNMP
Nortel Application Switch Operating System provides SNMP v1.0 and SNMP v3.0 support for access through any network management software, such as Nortel ASEM or HP-OpenView.
SNMP v1.0
To access the SNMP agent on the Nortel Application Switch, the read and write community strings on the SNMP manager should be congured to match those on the switch. The default read community string on the switch is public and the default write community string is private. Note: Leaving the default community strings enabled on the switch presents a security risk. Use the commands noted below to change these community strings. The read and write community strings on the switch can be changed using the 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.0
SNMPv3 is an enhanced version of the Simple Network Management Protocol, approved by the Internet Engineering Steering Group in March, 2002. SNMP v3.0 contains additional security and authentication features that provide data origin authentication, data integrity checks, timeliness indicators and encryption to protect against threats such as masquerade, modication of information, message stream modication 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 congure SNMP on the switch, see the Nortel Application Switch Operating System Command Reference.
Default conguration
The Nortel Application Switch Operating System has two users by default. Both the users adminmd5 and adminsha have access to all the MIBs supported by the switch. Step 1 2 Action username 1: adminmd5/password adminmd5. Authentication used is MD5. username adminsha/password adminsha. Authentication used is SHA. To congure an SNMP user name, enter the following command from the CLI:
>> # /cfg/sys/ssnmp/snmpv3/usm <x>
End
.
29
User Conguration
Users can be congured to use the authentication and privacy options. Currently Nortel Application Switch Operating System supports two authentication algorithms: MD5 and SHA. Authentication and privacy options are specied using the following command:
>> # /cfg/sys/ssnmp/snmpv3/usm <x> /auth md5|sha
Step 1
Action To congure a user with name test, authentication type MD5, and authentication password of test, privacy option DES with privacy 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
Once a user is congured, specify the access level for this user along with the views to which the user is allowed access. This is specied 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"
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 "View based Congurations" (page 30). End
.
View based Congurations

To congure an SNMP user equivalent to the CLI access level for user, use the following conguration:
/cfg/sys/ssnmp/snmpv3/usm 4 name "usr" /cfg/sys/ssnmp/snmpv3/access 3 name "usrgrp" rview "usr" wview "usr" nview "usr" /cfg/sys/ssnmp/snmpv3/group 4 uname usr gname usrgrp /cfg/sys/ssnmp/snmpv3/view 6 name "usr" tree "1.3.6.1.4.1.1872.2.5.1.2" /cfg/sys/ssnmp/snmpv3/view 7 name "usr" tree "1.3.6.1.4.1.1872.2.5.1.3" /cfg/sys/ssnmp/snmpv3/view 8 name "usr" tree "1.3.6.1.4.1.1872.2.5.2.2" /cfg/sys/ssnmp/snmpv3/view 9 name "usr" tree "1.3.6.1.4.1.1872.2.5.2.3" /cfg/sys/ssnmp/snmpv3/view 10 name "usr" tree "1.3.6.1.4.1.1872.2.5.3.2" /cfg/sys/ssnmp/snmpv3/view 11 name "usr" tree "1.3.6.1.4.1.1872.2.5.3.3" /cfg/sys/ssnmp/snmpv3/view 12 name "usr" tree "1.3.6.1.4.1.1872.2.5.4.2" /cfg/sys/ssnmp/snmpv3/view 13 name "usr" tree "1.3.6.1.4.1.1872.2.5.4.3" /cfg/sys/ssnmp/snmpv3/view 14 name "usr" tree "1.3.6.1.4.1.1872.2.5.5.2" /cfg/sys/ssnmp/snmpv3/view 15 name "usr" tree "1.3.6.1.4.1.1872.2.5.5.3" /cfg/sys/ssnmp/snmpv3/view 16 name "usr" tree "1.3.6.1.4.1.1872.2.5.6.2"
To congure an SNMP user equivalent to the CLI access level for oper, use the following conguration:
.
31
/cfg/sys/ssnmp/snmpv3/usm 5 name "slboper" /cfg/sys/ssnmp/snmpv3/access 4 name "slbopergrp" rview "slboper" wview "slboper" nview "slboper" /cfg/sys/ssnmp/snmpv3/group 4 uname slboper gname slbopergrp /cfg/sys/ssnmp/snmpv3/view 20 name "slboper" tree "1.3.6.1.4.1.1872.2.5.1.2" /cfg/sys/ssnmp/snmpv3/view 21 name "slboper" tree "1.3.6.1.4.1.1872.2.5.1.3" /cfg/sys/ssnmp/snmpv3/view 22 name "slboper" tree "1.3.6.1.4.1.1872.2.5.2.2" /cfg/sys/ssnmp/snmpv3/view 23 name "slboper" tree "1.3.6.1.4.1.1872.2.5.2.3" /cfg/sys/ssnmp/snmpv3/view 24 name "slboper" tree "1.3.6.1.4.1.1872.2.5.3.2" /cfg/sys/ssnmp/snmpv3/view 25 name "slboper" tree "1.3.6.1.4.1.1872.2.5.3.3" /cfg/sys/ssnmp/snmpv3/view 26 name "slboper" tree "1.3.6.1.4.1.1872.2.5.4" /cfg/sys/ssnmp/snmpv3/view 27 name "slboper" tree "1.3.6.1.4.1.1872.2.5.4.1" type excluded /cfg/sys/ssnmp/snmpv3/view 28 name "slboper" tree "1.3.6.1.4.1.1872.2.5.5.2" /cfg/sys/ssnmp/snmpv3/view 29 name "slboper" tree "1.3.6.1.4.1.1872.2.5.5.3" /cfg/sys/ssnmp/snmpv3/view 30 name "slboper" tree "1.3.6.1.4.1.1872.2.5.6.2"
Conguring SNMP Trap Hosts

SNMPv1 trap host
.
Step 1
Action To congure a SNMPv1 trap host, rst congure a user with no authentication and password.
>> # /cfg/sys/ssnmp/snmpv3/usm 10 name "v1trap"
Congure an access group and group table entries for the user. The nview command is used to specify which traps can be received by the user. In the example below, the user will receive the traps send by the switch.
>> >> >> >> >> >> >> >> # /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 SNMPv3 vacmSecurityToGroup 10 SNMPv3 vacmSecurityToGroup 10 SNMPv3 vacmSecurityToGroup 10 10 # model snmpv1 # uname v1trap # gname v1trap
Congure an entry in the notify table.

>> # /cfg/sys/ssnmp/snmpv3/notify 10 >> SNMPv3 vacmSecurityToGroup 10 # name v1trap >> SNMPv3 vacmSecurityToGroup 10 # tag v1trap
Specify the IP address and other trap parameters in the targetAddr and targetParam tables. The uname command is used to specify the user name used with this targetParam table.
>> # /cfg/sys/ssnmp/snmpv3/taddr 10 >> >> >> >> SNMPv3 SNMPv3 SNMPv3 SNMPv3 snmpTargetAddrTable snmpTargetAddrTable snmpTargetAddrTable snmpTargetAddrTable 10 10 10 10 # # # # (Access the targetAddr Table Menu) name v1trap addr 50.80.23.245 taglist v1trap pname v1param
.
33
>> # /cfg/sys/ssnmp/snmpv3/tparam 10 >> >> >> >> SNMPv3 SNMPv3 SNMPv3 SNMPv3 snmpTargetParamsTable snmpTargetParamsTable snmpTargetParamsTable snmpTargetParamsTable 10 10 10 10
(Access the targetParams table menu) # # # # name v1param mpmodel snmpv1 uname v1trap model snmpv1
Specify the community string used in the traps using the community table.
>> # /cfg/sys/ssnmp/snmpv3/comm 10 (Select the Community Table)
>> SNMPv3 snmpCommunityTable 10 # index v1trap >> SNMPv3 snmpCommunityTable 10 # name public >> SNMPv3 snmpCommunityTable 10 # uname v1trap
End
SNMPv2 trap host conguration The v2 trap host conguration is similar to the SNMPv1 trap host conguration. Wherever you specify the model make sure to specify snmpv2 instead of snmpv1.
/cfg/sys/ssnmp/snmpv3/usm 10 name "v2trap" /cfg/sys/ssnmp/snmpv3/access 10 name "v2trap" model snmpv2 nview "iso" /cfg/sys/ssnmp/snmpv3/group 10 model snmpv2 uname v2trap gname v2trap /cfg/sys/ssnmp/snmpv3/taddr 10 name v2trap addr 50.81.25.66 taglist v2trap pname v2param /cfg/sys/ssnmp/snmpv3/tparam 10 name v2param mpmodel snmpv2c uname v2trap model snmpv2 /cfg/sys/ssnmp/snmpv3/notify 10 name v2trap tag v2trap
.
/cfg/sys/ssnmp/snmpv3/comm 10 index v2trap name public uname v2trap
SNMPv3 trap host conguration To congure a user for SNMPv3 traps, you can choose to send the traps with both privacy and authentication, with authentication only, or with neither. An SNMPv3 trap host is congured in the access table using the following commands:
>> # /cfg/sys/ssnmp/snmpv3/access <x> /level Enter 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 congured accordingly from the SNMPv3 usmUser 1 Menu, which is accessed from the following command:
>> /cfg/sys/ssnmp/snmpv3/usm <usmUser number: (1-16)>
It is not necessary to congure the community table for SNMPv3 traps because the community string is not used by SNMPv3. The following example shows how to congure an SNMPv3 user v3trap with authentication only:
/cfg/sys/ssnmp/snmpv3/usm 11 name "v3trap" auth md5 authpw v3trap /cfg/sys/ssnmp/snmpv3/access 11 name "v3trap" level authNoPriv nview "iso" /cfg/sys/ssnmp/snmpv3/group 11 uname v3trap gname v3trap /cfg/sys/ssnmp/snmpv3/taddr 11 name v3trap addr 50.81.25.66 taglist v3trap pname v3param /cfg/sys/ssnmp/snmpv3/tparam 11
.
35
name v3param uname v3trap level authNoPriv /cfg/sys/ssnmp/snmpv3/notify 11 name v3trap tag v3trap
Using Nortel ASEM

The Nortel Application Switch Element Manager is a Java GUI application that runs on many platforms used for conguring and monitoring Nortel Application Switches. The application communicates with the switches via the SNMP protocol. Nortel ASEM can be integrated into larger Network Management 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 the following: Manage multiple switches simultaneously Nortel ASEM has a tree control and a view panel similar to Windows Explorer. View panels can be "torn off" and docked back into the view. Nortel ASEM allows you to view multiple aspects of a single switch, or compare the same view of two different switches. Congure the switch Nortel ASEM allows you to congure all the features on the switch, except security. View switch summary Nortel ASEM provides an overall summary of the switch, such as port level statistics, layer 3 statistics, server load balancing health, Syslog viewer, MP statistics, and sessions. View server load balancing summary Nortel ASEM allows you see the hierarchical association of server load balancing components and at the same time view their state and statistics. Color is used to give visual clues as to the health of the real server. Enable/disable real servers Congure lters Nortel ASEM allows you to insert a new lter, move a block of lters, or assign lters to ports. Monitor the switch
.
Nortel ASEM monitors data in tables and graphs. You must rst select a few items in the table before the graph icons are enabled. Nortel ASEM generates line, bar, or pie charts. Export data to a le such as an Excel spreadsheet
"Nortel ASEM Screen Example" (page 36)illustrates an example of a Nortel ASEM screen.
Nortel ASEM Screen Example
Using the Browser-Based Interface

Nortel Application Switch Operating System Browser-based Interface (BBI) is a Web-based management interface for interactive switch access through your Web browser.
Conguring BBI Access via HTTP

To 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 the following command:
/cfg/sys/access/wport <x>
.
37
To access your switch via the Browser-Based Interface, open a Web browser window and type in the URL using the IP interface address of the switch, such as http://10.10.10.1.
Conguring BBI Access via HTTPS

The BBI can also be accessed via a secure HTTPS connection over management 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 certicate to be used during the key exchange. A default certicate is created the rst time HTTPS is enabled, but you can create a new certicate dening the information you want to be used in the various elds.
>> /cfg/sys/access/https/generate Country 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]: y Generating certificate. Please wait (approx 30 seconds) restarting SSL agent
The certicate can be saved to ash for use if the switch is rebooted by using the apply and save commands. When a client (e.g. web browser) connects to the switch, they will be asked if they accept the certicate and can verify that the elds are what expected. Once BBI access is granted to the client, the BBI can be used as described in the BBI Quick Guide.
Using the Management Port

The management port is a Fast Ethernet port on the Nortel Application Switch that is used exclusively for managing the switch. While the switch can be managed from any network port, the management port conserves a
.
data port that could otherwise be used for processing requests. You can use the 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 routing protocols that run on the data ports, but it can be used to perform management 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 1 Action Congure a default gateway address.
>> Main# /cfg/sys/mmgmt/gw 10.10.10.1 (Configure a default gateway)
Congure a static IP address.

>> Management Port# addr 10.10.10.5 >> Management Port# mask 255.255.255.0 (Configure a static IP address) (Configure a network mask)
Enable the management port.
.
39
When the management port is enabled, you can use it to access the switch via Telnet, SSH, BBI, and SNMP (ASEM), provided the commands are enabled on the switch. These commands can occur simultaneously on both the management port and the data ports.
>> Management Port# ena (Enable the management port)
Note: There is a maximum of four concurrent Telnet sessions on the Nortel Application Switch over the management and data ports combined. 4 Congure the default port type for each management function. Select the management port or the default data port for each management function. For example, select the management port for NTP, Radius, and Syslog functions only. SMTP, TFTP, and SNMP traps are congured to use the default data ports.
>> Management Port# ntp mgmt >> Management Port# radius mgmt >> Management Port# syslog mgmt (Select the management port for NTP) (Select the management port for radius) (Select the management port 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 conguration, and save the changes.
>> Management Port # apply >> Management Port # cur >> Management Port # save (Make your changes active) (View current settings) (Save for restore after reboot)
End
.
Limiting Management Access

In previous versions of the Nortel Application Switch Operating System, when a management service such as Telnet, SSH, or SNMP was enabled on the switch, the service was accessible from the management and data ports. The switch administrator now has the capability to disable access to a management service from a data port. "Management Access Commands" (page 40)outlines commands that can be used to limit management services from data ports.
Management Access Commands Action Command
Enable port for management /cfg/sys/access/port/add <port number> access. Disable port from management access. Disable all ports from management access. Current listing of data ports with management access. /cfg/sys/access/port/rem <port number> /cfg/sys/access/port/arem /cfg/sys/access/port/cur
Feature Description
To support conguring 128 management IP addresses and mask pairs, support need to be added to provide more restriction if needed by enabling only a particular type of access for a given network like Telnet, SSH, SNMP, or BBI.
Action Now accepts 128 networks addr: IP Address mask: Network mask acctype: all | telnet | ssh | snmp | bbi Note: By default access type is all Removes a defined network, which consists of a management network address and management network mask address. /cfg/sys/access/mgmt/rem Command /cfg/sys/access/mgmt/add <1-128> /cfg/sys/access/mgmt/add <1-128> <addr> <mask> <acctype>
.
41
Action When a user enters a specific access type, only that protocol access is removed. Network can access through other access protocols. When all (default feature) is entered, network is removed. addr: IP Address mask: Network mask acctype: all | telnet | ssh | snmp | bbi Note: By default access type is all
Command /cfg/sys/access/mgmt/rem <addr> <mask> <acctype>
/cfg/sys/access/mgmt/arem When a user enters this command all the entries are removed giving all type of access to all the users as if no restrictions are configured. It displays Network address, mask and access protocol for all the networks configured upto 128. /cfg/sys/access/mgmt/cur
File Transfers
The Nortel Application Switch Operating System supports the usage of the File Transfer Protocol (FTP) as a le transfer alternative to the Trivial File Transfer Protocol (TFTP). FTP is supported over data and management ports for the upload and download of the following le types: Software Images Conguration Files TSDumps Panic Dumps
A FTP host name, le name, user name, and password is requested when using FTP. The initiation of boot image uploads and downloads is also supported through SNMP and the Browser-Based Interface.
Time Conguration
This section describes the time conguration options available in the Nortel Application Switch Operating System.
Time Zone Conguration

Upon set up, the switch should be congured with the appropriate time zone conguration. This enables the switch to provide proper time offsets and to be able to adjust for Daylight Savings Time.
.
The following example sets the time zone to Atlantic Time for a switch that is physically located in Atlantic Canada. Step 1 Action Access time zone conguration.
>> Main# /cfg/sys/timezone
Select the general geographic zone in which the switch is located.

Please identify a location so that time zone rules can be set correctly. Please select a continent or ocean. 1) Africa 2) Americas 3) Antarctica 4) Arctic Ocean 5) Asia 6) Atlantic Ocean 7) Australia 8) Europe 9) Indian Ocean 10) Pacific Ocean 11) None - disable timezone setting Enter the number of your choice: 2
Note: The time zone setting can be disabled in this menu by selecting 11. 3 Select the country inside the geographic zone previously selected.
Please select a country. 1) Anguilla 18) Ecuador 35) Paraguay 2) Antigua & Barbuda 19) El Salvador 36) Peru 3) Argentina 20) French Guiana 37) Puerto Rico 4) Aruba 21) Greenland 38) St Kitts & Nevis 5) Bahamas 22) Grenada 39) St Lucia 6) Barbados 23) Guadeloupe 40) St Pierre & Miquelon 7) Belize 24) Guatemala 41) St Vincent 8) Bolivia 25) Guyana 42) Suriname
.
43
9) Brazil 26) Haiti 43) Trinidad & Tobago 10) Canada 27) Honduras 44) Turks & Caicos Is 11) Cayman Islands 28) Jamaica 45) United States 12) Chile 29) Martinique 46) Uruguay 13) Colombia 30) Mexico 47) Venezuela 14) Costa Rica 31) Montserrat 48) Virgin Islands (UK) 15) Cuba 32) Netherlands Antilles 49) Virgin Islands (US) 16) Dominica 33) Nicaragua 17) Dominican Republic 34) Panama Enter the number of your choice: 10
Select the time zone appropriate to the specic geographic location of the switch.
Please select one of the following time zone regions. 1) Newfoundland Island 2) Atlantic Time - Nova Scotia (most places), NB, W Labrador, E Quebec & PEI 3) Atlantic Time - E Labrador 4) Eastern Time - Ontario & Quebec - most locations 5) Eastern Time - Thunder Bay, Ontario 6) Eastern Standard Time - Pangnirtung, Nunavut 7) Eastern Standard Time - east Nunavut 8) Eastern Standard Time - central Nunavut 9) Central Time - Manitoba & west Ontario 10) Central Time - Rainy River & Fort Frances, Ontario 11) Central Time - west Nunavut 12) Central Standard Time - Saskatchewan most locations 13) Central Standard Time - Saskatchewan - midwest 14) Mountain Time - Alberta, east British Columbia & west Saskatchewan 15) Mountain Time - central Northwest Territories 16) Mountain Time - west Northwest Territories 17) Mountain Standard Time - Dawson Creek & Fort Saint John, British Columbia 18) Pacific Time - west British Columbia 19) Pacific Time - south Yukon 20) Pacific Time - north Yukon
.
Enter the number of your choice:
Apply and save the conguration change. End
Network Time Protocol

The network time protocol (NTP) is used to provide a switch with an accurate time by synchronizing with a time server on either an internal or external network. Using NTP ensures that the switch always has an accurate time for 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/cur Current NTP state: disabled Current primary NTP server: 0.0.0.0 Current resync interval: 1440 minutes Current GMT timezone offset: -8:00
The following example congures NTP for a switch: Step 1 Action Access the NTP menu.
>> Main# /cfg/sys/ntp
Set the IP address of the primary NTP server. This would be the NTP server that the switch would regularly synchronize with to adjust its time.
>> NTP Server# prisrv Current NTP server address: 0.0.0.0 Enter new NTP server address: 192.168.249.13
Set the IP address of the secondary NTP server. This would be the NTP server that the switch would synchronize with in instances where the primary server is not available.
>> NTP Server# secsrv Current NTP server address: 0.0.0.0 Enter new NTP server address: 192.168.249.45
.
45
Set the resynchronisation interval. The resynchronisation interval is the amount of time the switch waits between queries to the NTP server.
>> NTP Server# intrval Current resync interval (minutes): 1440 Enter new resync interval (minutes) [1-44640]:
2000
(Optional) Set the NTP time zone offset. The NTP time zone offset from Greenwich Mean Time defaults to the setting congured with the switch time zone was set up. If this has not been done, or you wish to override the current value, do the following:
>> NTP Server# tzone Current GMT timezone offset: -8:00 Enter new GMT timezone offset in hours [-12:00, +12:00]: +4:00
Enable NTP functionality. After NTP functionality has been congured, it must be enabled.
>> NTP Server# on Current status: OFF New status: ON
Note: To disable NTP functionality use the off command. End
.
Securing the Switch

Secure switch management is necessary for environments in which signicant management functions are performed across the Internet. The following 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" (page 54) "Secure Shell and Secure Copy" (page 58) "End User Access Control" (page 64) "Deny Routes" (page 67)
Protecting Switch-Owned Addresses from Attacks

Denial of Service (DOS) attacks can be targeted not only at real servers, but at any IP address that is owned by an Nortel Application Switch. A DOS attack can potentially overwhelm switch resources. The system-wide rate limiting command can be used to prevent DOS attacks over ARP, ICMP, TCP and UDP protocols by setting the maximum rate at which packets can enter the switch. After the congured limit has been reached, packets are dropped. The maximum rate (packets per second) can be congured differently for each of the supported protocols.
How Different Protocols Attack the Switch

Without the system-wide rate limiting commands enabled, the following protocol packets destined to a switch-owned management interface could potentially overwhelm its management processors CPU capacity: Address Resolution Protocol (ARP) requests to the switch management interface IP address. ICMP pings to the switch management interface IP address. TCP SYN packets sent the switch management interface IP addressincluding Telnet sessions, HTTP requests via the Browser-Based Interface, and BGP peer connections to the switch. "TCP Rate Limiting" (page 629) should also be congured to limit TCP packets destined to a switch virtual server IP (vip) address. UDP packets sent to a switch interface addressincluding routing information protocol (RIP) and simple network management protocol (SNMP) packets.
.
Securing the Switch
47
Conguring Denial of Service Protection

Step 1 Action Set the rate limit for the desired protocol.
>> /cfg/sys/access/rlimit Enter protocol [arp|icmp|tcp|udp]: Current max rate: 0 Enter new max rate: 1000
arp
(Set rate to 1000 packets per second)
2 3
Repeat step 1 to congure rate limits on any other of the supported protocols. Apply and save the conguration. End
Viewing Dropped Packets

The /stats/sp/maint command is used to view the number of dropped packets for each protocol which is congured for system-wide rate limiting. The information is available on a per-switch processor (SP) basis:
>> Main# /stats/sp/maint Enter SP number: (1-4) 2 2 -----------------------------------------------------------Maintenance statistics for SP 2: Receive Letter success from MP: 6487510 Receive Letter success from SP 1: 0 Receive Letter success from SP 3: 0 Receive Letter success from SP 4: 0 Receive Letter errors from MP: 0 Receive Letter errors from SP 1: 0 Receive Letter errors from SP 3: 0 Receive Letter errors from SP 4: 0 Send Letter success to MP: 13808935 Send Letter success to SP 1: 0 Send Letter success to SP 3: 0 Send Letter success to SP 4: 8 Send Letter failures to MP: 13 Send Letter failures to SP 1: 0 Send Letter failures to SP 3: 0 Send Letter failures to SP 4: 0 learnErrNoddw: 0 resolveErrNoddw: 0 ageMPNoddw: 0 deleteMiss: 0
.
pfdbFreeEmpty: arpDiscards: tcpDiscards:
0 0 0
icmpDiscards: udpDiscards:
0 0
Dynamic Memory statistics -------------------------------------------------Total memory in bytes 36699136 Current memory in bytes 5580064 allocs 28 frees 2 alloc failures 0 bytes hiwait 5580064
Setting Source IP Address Ranges for Switch Management

To limit access to the switch without having to congure lters for each switch port, you can set a source IP address (or range) that allows to connect to the switch IP interface through Telnet, SSH, SNMP, or the Nortel Application Switch Operating System Browser-Based Interface (BBI). This also helps to prevent spoong or attacks on the switchs TCP/IP stack. When an IP packet reaches the application switch, the source IP address is checked against range of addresses dened by the management network and 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 IP interface with a source IP address outside this range is discarded. Up to ve management IP address and mask pairs can be congured on the switch. For example, to dene a range of allowed source IP addresses between 192.192.192.1 to 192.192.192.127, enter the following:
>> Main# /cfg/sys/access/mgmt add Enter Management Network Address:192.192.192.0 Enter Management Network Mask: 255.255.255.128
The following source IP addresses are granted or not granted access to the switch: A host with a source IP address of 192.192.192.21 falls within the dened range and would be allowed to access the switch. A host with a source IP address of 192.192.192.192 falls outside the dened range and is not granted access. To make this source IP address valid, you would need to shift the host to an IP address within the valid range specied by the addr and mask or modify the addr to be 192.192.192.128 and the mask to be 255.255.255.128. This would put the 192.192.192.192 host within the valid range allowed by the addr and mask (192.192.192.128-255).
.
Securing the Switch
49
RADIUS Authentication and Authorization

Nortel Application Switch Operating System supports the RADIUS (Remote Authentication Dial-in User Service) method to authenticate and authorize remote administrators for managing the switch. This method is based on a client/server model. The Remote Access Server (RAS)the switchis a client to the back-end database server. A remote user (the remote administrator) interacts only with the RAS, not the back-end server and database. RADIUS authentication consists of the following components: A protocol with a frame format that utilizes UDP over IP (based on RFC 2138 and 2866) A centralized server that stores all the user authorization information A client, in this case, the switch
RADIUS Authentication Features

Nortel Application Switch Operating System supports the following Radius authentication features: Supports Radius client on the switch, based on the protocol denitions in 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 primary authentication server is unreachable, the switch can send client authentication requests to the secondary authentication server. Use the /cfg/sys/radius/cur command to show the currently active RADIUS authentication server. Supports user-congurable 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 RADIUS server in 1-3 retries. The switch also automatically retries connecting to the RADIUS server before it declares the server down. Supports user-congurable RADIUS application port. The default is 1812/UDP-based on RFC 2138. Allows network administrator to dene privileges for one or more specic users to access the switch at the RADIUS user database. Supports SecurID if the RADIUS server can do an ACE/Server client proxy. The password is the PIN number, plus the token code of the SecurID card.
.
How Radius Authentication Works

In "RADIUS Authentication and Authorization: How It Works" (page 50), the Nortel Application Switchacting as the RADIUS clientcommunicates to the RADIUS server to authenticate and authorize a remote administrator using the protocol denitions specied in RFC 2138 and 2866. Transactions between the client and the RADIUS server are authenticated using a shared key that is not sent over the network. In addition, the remote administrator passwords are sent encrypted between the RADIUS client (the switch) and the back-end RADIUS server.
RADIUS Authentication and Authorization: How It Works
Step 1 2 3 4
Action Remote administrator connects to the switch and provides user name and password. Using Authentication/Authorization protocol, the switch sends request to authentication server. Authentication server checks the request against the user ID database. Using RADIUS protocol, the authentication server instructs the switch to grant or deny administrative access. End
Conguring RADIUS Authentication on the Switch

Step 1 Action Turn RADIUS authentication on, then congure the Primary and Secondary RADIUS servers.
.
Securing the Switch
51
>> Main# /cfg/sys/radius >> RADIUS Server# on Current status: OFF New status: ON >> RADIUS Server# prisrv 10.10.1.1
(Select the RADIUS Server menu) (Turn RADIUS on)
(Enter primary server IP)
Current primary RADIUS server: 0.0.0.0 New pending primary RADIUS server: 10.10.1.1 >> RADIUS Server# secsrv 10.10.1.2 (Enter secondary server IP)
Current secondary RADIUS server: 0.0.0.0 New pending secondary RADIUS server: 10.10.1.2
Congure the RADIUS secret.

>> RADIUS Server# secret Enter new RADIUS secret: <1-32 character secret>
CAUTION
If you congure the RADIUS secret using any method other than a direct console connection, the secret may be transmitted over the network as clear text.
If desired, you may change the default TCP port number used to listen to RADIUS. The well-known port for RADIUS is 1812.
>> RADIUS Server# port Current RADIUS port: 1812 Enter new RADIUS port [1500-3000]: <port number>
Congure the number retry attempts for contacting the RADIUS server, and the timeout period.
>> RADIUS Server# retries Current RADIUS server retries: Enter new RADIUS server retries [1-3]:
3 < server retries>
.
>> RADIUS Server# time Current RADIUS server timeout: Enter new RADIUS server timeout [1-10]: 10
3 (Enter the timeout period in minutes)
Apply and save the conguration. End
Switch User Accounts

The user accounts listed in "Nortel Application Switch Operating System User Accounts and Access Levels" (page 52) are provided as a reference here for understanding user levels that can be dened in the RADIUS server dictionary le (see "RADIUS Attributes for User Privileges" (page 53)), or for dening Class of Service for the End User Access Control feature (see "End User Access Control" (page 64)).
Nortel Application Switch Operating System User Accounts and Access Levels User Account User Description and Tasks Performed The User has no direct responsibility for switch management. He/she can view all switch status information and statistics but cannot make any configuration changes to the switch. The SLB Operator manages content servers and other Internet services and their loads. In addition to being able to view all switch information and statistics, the SLB Operator can enable/disable servers using the SLB operation menu. The Layer 4 Operator manages traffic on the lines leading to the shared Internet services. This user currently has the same access level as the SLB operator. This level is reserved for future use, to provide access to operational commands for operators managing traffic on the line leading to the shared Internet services. The Operator manages all functions of the switch. In addition to SLB Operator functions, the Operator can reset ports or the entire switch. Password user
SLB Operator
slboper
Layer 4 Operator
l4oper
Operator
oper
.
Securing the Switch
53
User Account SLB Administrator
Description and Tasks Performed The SLB Administrator configures and manages content servers and other Internet services and their loads. In addition to SLB Operator functions, the SLB Administrator can configure parameters on the SLB menus, with the exception of not being able to configure filters or bandwidth management. The Layer 4 Administrator configures and manages traffic on the lines leading to the shared Internet services. In addition to SLB Administrator functions, the Layer 4 Administrator can configure all parameters on the SLB menus, including filters and bandwidth management. The super-user Administrator has complete access to all menus, information, and configuration commands on the switch, including the ability to change both the user and administrator passwords.
Password slbadmin
Layer 4 Administr ator
l4admin
Administrator
admin
RADIUS Attributes for User Privileges

When the user logs in, the switch authenticates his/her level of access by sending the RADIUS access request, that is, the client authentication request, to the RADIUS authentication server. If the remote user is successfully authenticated by the authentication server, the switch veries the privileges of the remote user and authorize the appropriate access. When both the primary and secondary authentication servers are not reachable, the administrator has an option to allow backdoor access via the console only or console and Telnet access. The default is disable for Telnet access and enable for console access. All user privileges, other than those assigned to the Administrator, have to be dened in the RADIUS dictionary. Radius attribute 6 which is built into all Radius servers denes the administrator. The le name of the dictionary is RADIUS vendor-dependent. The following Radius attributes are dened for Nortel Application Switch Operating System user privileges levels:
Nortel Application Switch Operating System-Proprietary Attributes for Radius User Name/Access user slboper l4oper User-Service-Type Vendor-supplied Vendor-supplied Vendor-supplied Value 255 254 253
.
User Name/Access oper slbadmin l4admin admin
User-Service-Type Vendor-supplied Vendor-supplied Vendor-supplied Vendor-supplied
Value 252 251 250 6 (pre-defined)
TACACS+ Authentication
Nortel Application Switch Operating System supports authentication and authorization 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 authentication and authorization sessions with the TACACS+ access server. The remote user is dened as someone requiring management access to the Nortel Application Switch either through a data or management port. TACACS+ offers the following advantages over RADIUS: TACACS+ uses TCP-based connection-oriented transport; whereas RADIUS is UDP-based. TCP offers a connection-oriented transport, while UDP offers best-effort delivery. RADIUS requires additional programmable variables such as re-transmit attempts and time-outs to compensate for best-effort transport, but it lacks the level of built-in support that a TCP transport offers. TACACS+ offers full packet encryption whereas RADIUS offers password-only encryption in authentication requests. TACACS+ separates authentication, authorization and accounting. TACACS+ offers privilege level mapping. By enabling cmap, the privilege level 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 Works

TACACS+ works much in the same way as RADIUS authentication as described on "How Radius Authentication Works" (page 50). Step 1 2 Action Remote administrator connects to the switch and provides user name and password. Using Authentication/Authorization protocol, the switch sends request to authentication server.
.
Securing the Switch
55
3 4
Authentication server checks the request against the user ID database. Using TACACS+ protocol, the authentication server instructs the switch to grant or deny administrative access. End
TACACS+ uses the AAA architecture, which separates authentication, authorization, and accounting. This allows separate authentication solutions that can still use TACACS+ for authorization and accounting. For example, with TACACS+, it is possible to use Kerberos authentication and TACACS+ authorization and accounting. After the Nortel Application Switch authenticates on a Kerberos server, it requests authorization information from a TACACS+ server without requiring re-authentication. The Nortel Application Switch informs the TACACS+ server that it has successfully authenticated on a Kerberos server, and the server then provides authorization information. During a session, if additional authorization checking is needed, the Nortel Application Switch checks with a TACACS+ server to determine if the user is granted permission to use a particular command.
TACACS+ Authentication Features

Authentication is the action of determining the identity of a user, and is generally done when the user rst attempts to log in to a device or gain access to its services. Nortel Application Switch Operating System supports ASCII inbound login to the device. PAP, CHAP and ARAP login methods, TACACS+ change password requests, and one-time password authentication are not supported.
Authorization
Authorization is the action of determining a users privileges on the device, and usually takes place after authentication. The mapping between TACACS+ authorization levels and Nortel Application Switch Operating System management access levels is shown in "Nortel Application Switch Operating System-Proprietary Attributes for TACACS+" (page 55).
Nortel Application Switch Operating System-Proprietary Attributes for TACACS+ Nortel Application Switch Operating System User Access Level user TACACS+ level 0
.
Nortel Application Switch Operating System User Access Level slboper l4oper oper slbadmin l4admin admin
TACACS+ level 1 2 3 4 5 6
Accounting
Accounting is the action of recording a users activities on the device for the purposes of billing and/or security. It follows the authentication and authorization actions. If the authentication and authorization is not performed through TACACS+, there will be no TACACS+ accounting messages sent out. The approach is simple. Whenever there is successful command execution on 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 also supported for command logging.
Conguring TACACS+ Authentication on the Switch

Step 1 Action Turn TACACS+ authentication on, then congure the Primary and Secondary TACACS+ servers.
>> Main# /cfg/sys/tacacs >> TACACS+ Server# on Current status: OFF New status: ON (Select the TACACS+ Server menu) (Turn TACACS+ on)
.
Securing the Switch
57
>> TACACS+ Server# prisrv 10.10.1.1
(Enter primary server IP)
Current primary TACACS+ server: 0.0.0.0 New pending primary TACACS+ server: 10.10.1.1 >> TACACS+ Server# secsrv 10.10.1.2 (Enter secondary server IP)
Current secondary TACACS+ server: 0.0.0.0 New pending secondary TACACS+ server: 10.10.1.2
Congure the TACACS+ secret.

>> TACACS+ Server# secret Enter new TACACS+ secret: <1-32 character secret>
CAUTION
If you congure the TACACS+ secret using any method other than a direct console connection, the secret may be transmitted over the network as clear text.
If desired, you may change the default TCP port number used to listen to TACACS+. The well-known port for TACACS+ is 49.
>> TACACS+ Server# port Current TACACS+ port: 49 Enter new TACACS+ port [1-65000]: <port number>
Congure the number retry attempts for contacting the TACACS+ server, and the timeout period.
>>TACACS+ Server# retries Current TACACS+ server retries: Enter new TACACS+ server retries [1-3]: >> TACACS+ Server# time Current TACACS+ server timeout: Enter new TACACS+ server timeout [1-15]: 10
3 <server retries>
4 (Enter the timeout period in minutes)
Apply and save the conguration.
.
End
Secure Shell and Secure Copy

The Telnet method of managing an Nortel Application Switch does not provide a secure connection. Secure Shell (SSH) and Secure Copy (SCP) however, use secure tunnels so that messages between a remote administrator and the switch is encrypted and secured. SSH is a protocol that enables remote administrators to log securely into another computer over a network to execute management commands. SCP is typically used to copy les securely from one machine to another. SCP uses SSH for encryption of data on the network. On a Nortel Application Switch, SCP is used to download and upload the switch conguration via secure channels. The Nortel Application Switch Operating System implementation of SSH supports both versions 1.5 and 2.0. and supports SSH clients version 1.52.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 Dyke Technologies, 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 four simultaneous Telnet/SSH/SCP connections at one time. The /cfg/sys/radius/telnet command also applies to SSH/SCP connections.
Conguring SSH/SCP features on the switch

SSH/SCP parameters can be congured via the console port only, using the CLI. However, SCP putcfg and TFTP getcfg can also change the SSH/SCP conguration. When SSH is enabled, SCP is also enabled. The switch SSH daemon uses TCP port 22 only and is not congurable.
.
Securing the Switch
59
Before you can use SSH commands, use the following commands to turn on SSH/SCP.
Enabling or disabling SSH

Connect to the switch CLI and enter the following commands:
>> Main# /cfg/sys/access/sshd/on Current status: New status: ON OFF (Turn SSH off) (Turn SSH on)
>> Main# /cfg/sys/access/sshd/off Current status: ON New status: OFF
Enabling or disabling SCP apply and save

Enter the following commands from the switch CLI to enable the SCP putcfg_apply and putcfg_apply_save commands:
>> # /cfg/sys/access/sshd/ena SSH Server# apply (Enable SCP apply and save) (Apply the changes to start generating RSA host and server keys)
RSA host key generation starts ............................................................ ...................................................... RSA host key generation completes (lasts 212549 ms) RSA host key is being saved to Flash ROM, please dont reboot the 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 dont reboot the box immediately. ----------------------------------------------------------------Apply complete; dont forget to "save" updated configuration. >> Main# /cfg/sys/access/sshd/dis (Disable SSH/SCP apply and save)
Conguring the SCP Administrator Password

To congure the scpadmin (SCP Administrator) password, rst connect to the switch via the RS-232 management console. For security reasons, the scpadmim password may only be congured when connected directly to the switch console.
.
To congure the password, enter the following command via the CLI. At factory default settings, the current SCP administrator password is admin.
>> /cfg/sys/access/sshd/scpadmin Changing SCP-only Administrator password; validation required... 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 Services
To perform SCP commands, you need the SCP admin password with administrator privileges (this password must be different from the admin password). The following SCP commands are supported in this service. These commands are entered using the CLI on the client that is running the SCP application: getcfg is used to download the switchs conguration to the remote host via SCP. putcfg is used to upload the switchs conguration from a remote host to the switch; the diff command is automatically executed at the end of putcfg to notify the remote client of the difference between the new and the current congurations. putcfg_apply runs the apply command after the putcfg is done. putcfg_apply_save saves the new conguration to the ash after putcfg_apply is done.
The putcfg_apply and putcfg_apply_save commands are provided because extra apply and save commands are usually required after a putcfg; however, an SCP session is not in an interactive mode at all.
Using SSH and SCP Client Commands

This section shows the format for using some client commands. The examples 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 IP address>
Example:
.
Securing the Switch
61
>> # ssh 192.168.249.13 >> # ssh -l <login-name> 192.168.249.13 (Login to the switch)
Downloading the switch conguration using SCP:

Syntax:
scp <switch IP address> :getcfg <local filename>
Example:
>> # scp 192.168.249.13:getcfg applSwitch.cfg
Uploading the conguration to the switch:

Syntax:
scp <local filename> <switch IP address> :putcfg
Example:
>> # scp applSwitch.cfg 192.168.249.13:putcfg
Applying and saving the conguration

The apply and save commands are still needed after the last command (scp applSwitch.cfg 192.168.249.13:putcfg). Or, instead, you can 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 putcfg to notify the remote client of the difference between the new and the current congurations. putcfg_apply runs the apply command after the putcfg is done. putcfg_apply_save saves the new conguration to the ash after putcfg_apply is done. The putcfg_apply and putcfg_apply_save commands are provided because extra apply and save commands are usually required after a putcfg; however, an SCP session is not in an interactive mode at all.
SSH and SCP Encryption of Management Messages

The following encryption and authentication methods are supported for SSH and SCP:
.
Server Host Authentication: Key Exchange: Encryption: User Authentication:
Client RSA authenticates the switch at the beginning of every connection RSA 3DES-CBC, DES Local password authentication, RADIUS, SecurID (via RADIUS, for SSH onlydoes not apply to SCP)
Generating RSA Host and Server Keys for SSH Access

To support the SSH server feature, two sets of RSA keys (host and server keys) are required. The host key is 1024 bits and is used to identify the Nortel Application Switch. The server key is 768 bits and is used to make it impossible to decipher a captured session by breaking into the Nortel Application Switch at a later time. When the SSH server is rst enabled and applied, the switch automatically generates the RSA host and server keys and is stored in the FLASH memory. To congure RSA host and server keys, rst connect to the switch via the console port (these commands are not available via Telnet connection), and enter the following commands to generate the keys manually
>> # /cfg/sys/access/sshd/hkeygen >> # /cfg/sys/access/sshd/skeygen (Generates the host key) (Generates the server key)
These two commands take effect immediately without the need of an apply command. When the switch reboots, it retrieves the host and server keys from the FLASH memory. If these two keys are not available in the ash and if the SSH server feature is enabled, the switch automatically generates them during the system reboot. This process may take several minutes to complete. The switch can also automatically regenerate the RSA server key. To set the 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 available when connected through the console port.
.
Securing the Switch
63
The number of hours must range between 024. A value of 0 denotes that RSA server key autogeneration is disabled. When greater than 0, the switch autogenerates the RSA server key every specied interval; however, RSA server key generation is skipped if the switch is busy doing other key or cipher generation when the timer expires. Note: The Nortel Application Switch performs only one session of key/cipher generation at a time. Thus, an SSH/SCP client is not be able to log in if the switch is performing key generation at that time, or if another client has logged in immediately prior. Also, key generation fails if an SSH/SCP client is logging in at that time.
SSH/SCP Integration with Radius Authentication

SSH/SCP is integrated with RADIUS authentication. After the RADIUS server is enabled on the switch, all subsequent SSH authentication requests is redirected to the specied RADIUS servers for authentication. The redirection is transparent to the SSH clients.
SSH/SCP Integration with SecurID

SSH/SCP can also work with SecurID, a token card-based authentication method. 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 for SecurID because the SecurID server, ACE, is a one-time password authentication and requires an interactive session.
Using SecurID with SSH

Using SecurID with SSH involves the following tasks. To log in using SSH, use a special username, "ace," to bypass the SSH authentication. After an SSH connection is established, you are prompted to enter the username and password (the SecurID authentication is being performed now). Provide your username and the token in your SecurID card as a regular Telnet user.
Using SecurID with SCP

Using SecurID with SCP can be accomplished in two ways: Using a RADIUS server to store an administrator password. You can congure a regular administrator with a xed password in the RADIUS server if it can be supported. A regular administrator with a xed password in the RADIUS server can perform both SSH and SCP with no additional authentication required.
.
Using an SCP-only administrator password. Use the command, /cfg/sys/access/sshd/scpadmin to bypass the checking of SecurID. Note: The /cfg/sys/access/sshd/scpadmin command is only available when connected through the console port.
An SCP-only administrators password is typically used when SecurID is used. For example, it can be used in an automation program (in which the tokens of SecurID are not available) to back up (download) the switch congurations each day. Note: The SCP-only administrators password must be different from the regular administrators password. If the two passwords are the same, the administrator using that password is not allowed to log in as a SSH user because the switch recognizes him as the SCP-only administrator and only allow the administrator access to SCP commands. Alternately, you can congure a regular administrator with a xed password in the RADIUS server if it can be supported. A regular administrator with a xed password in the RADIUS server can perform both SSH and SCP with no additional authentication required.
End User Access Control

Nortel Application Switch Operating System allows an administrator to dene end user accounts that permit end users to operationally act on their own real servers via the switch CLI commands. Once end user accounts are congured and enabled, the switch requires the username/password authentication. For example, an administrator can assign a user to manage real servers 1 and 2 only. The user can then log into the switch and perform operational commands (effective only until the next switch reboot), to enable or disable the real servers, or change passwords on the real servers.
Considerations for Conguring End User Accounts

Only one user ID can be assigned to a real server resource to enable or disable a real server. Consequently, a single end user may be assigned the maximum number of real servers that can be congured on the switch, 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 or groups belonging to a virtual service are owned by the same end user ID. The switch does not automatically validate congurations. The
.
Securing the Switch
65
criterion for displaying virtual service information for end users is based on the validation of ownership of the rst real server in the group for a given virtual server port. The Nortel Application Switch Operating System has end user support for Console and Telnet access to the switch. As a result, only very limited access is granted to the Primary Administrator under the BBI/SSH1 mode of access. If RADIUS authentication is used, the user password on the Radius server will override the user password on the Nortel Application Switch. Also note that the password change command on the switch ONLY modies the use switch password and has no effect on the user password on the Radius server. Radius authentication and user password 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 Menu

The end user access control menu is located in the System access menu.
>> # /cfg/sys/access/user
Setting up User IDs

Up to 10 user IDs can be congured.
/cfg/sys/access/user/uid 1
Dening User Names and Passwords

>> User ID 1 # name jane Current user name: New user name: jane (Assign name "jane" to user ID 1)
Changing Passwords
>> User ID 1 # passwd Changing user password; validation required: Enter current admin password: <current administrator password> Enter new user password: <new user password> Re-enter new user password: <new user password> New user password accepted.
.
Dening User Access Level

The end user is by default assigned to the user access level (also known as class of service, or CoS). CoS for all user accounts have global access to all resources except for User CoS, which has access to view resources that the user owns only. For more information, see "Nortel Application Switch Operating System User Accounts and Access Levels" (page 52). To change the users level, enter the class of service cos command, and select one of the following options:
>> User ID 1 # cos <user|slboper|l4oper|oper|slbadmin|l4adm in|admin>
Assigning One or More Real Servers to the End User

A 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 # add Enter real server number:
(1-1023) 23
Validating User Conguration

User ID 2 # cur name jane , dis, cos user , password valid, offline real servers: 23: 0.0.0.0, disabled, name , weight 1, timeout 20 mins, maxcon 200000 24: 0.0.0.0, disabled, name , weight 1, timeout 20 mins, maxcon 200000
Listing Current Users

The cur command displays dened user accounts and whether or not each user is currently logged into the switch.
# /cfg/sys/access/user/cur Usernames: user slboper l4oper oper slbadmin l4admin admin
Enabled Disabled Disabled Disabled Disabled Disabled Always Enabled
.
Securing the Switch
67
Current User ID table: 1: name jane , ena, cos user , password valid, 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 200000 2: name john , ena, cos user , password valid, online real servers: 3: 10.10.10.213, enabled, name , weight 1, timeout 10 mins, maxcon 200000
Enabling or Disabling a User

An end user account must be enabled before the switch recognizes and permits login under the account. Once enabled, the switch requires any user to enter both username and password.
>> # /cfg/sys/access/user/uid <#> /ena >> # /cfg/sys/access/user/uid <#> /dis
Logging into an End User Account

Once an end user account is congured and enabled, the user can login to the switch username/password combination. The level of switch access is determined by the CoS established for the end user account.
Deny Routes
A deny route, or black hole route, can be congured to deny Layer 3 routable packets to destinations covered by a static route. A deny route is created by setting the gateway address in a static route to 0. If the longest prex match route (which is obtained via route lookup) is deny route, the packet is dropped. A deny route may be congured when an administrator nds a specic user or network that is under attack. For example, IP addresses in the 62.62.x.x network are under attack from an unknown source. The Nortel Application Switch can be congured temporarily with a deny route so that any trafc destined to this network is dropped. In the meantime the attack pattern and source can be detected.
.
This feature is similar to a deny lter, except that it works only on routable Layer 3 trafc; it does not deny Layer 2 trafc.
Conguring a Deny Route

To deny trafc to the destination network 62.62.0.0, enter the following commands.
>> # /cfg/l3/route >> IP Static Route# add Enter destination IP address: 62.62.0.0 (Select the IP Static Route menu) (Add a static route) (Of this IP network address)
Enter destination subnet mask: 255.255.0.0(And this mask address) 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 Inter face number, so dont enter one here.)
CAUTION
Do not congure a deny route that covers the destination/mask pair of an existing IP interfaces IP address/mask pair. For example, if you have an IP interface of 50.0.0.1/255.0.0.0, and a deny route of 50.0.0.0/255.0.0, then trafc to the interface as well as the subnet is deniedwhich is not the desired result.
Viewing a Deny Route

To view a deny route, enter the /info/l3/dump command. A deny route appears in the routing table in bold.
Status code: * - best Destination Mask Gateway Type Tag Metr If --------------- --------------- ----------------------- --------- ---- -* 0.0.0.0 0.0.0.0 47.80.16.1 indirect static 47 * 52.80.16.0 255.255.254.0 47.80.16.59 direct fixed 47 * 52.80.16.59 255.255.255.255 47.80.16.59 local addr 47 * 52.80.17.255 255.255.255.255 47.80.17.255 broadcast broadcast 47
.
Securing the Switch
69
* 62.62.0.0 deny static
255.255.0.0
0.0.0.0
.
.
71
VLANs
This chapter describes network design and topology considerations for using Virtual Local Area Networks (VLANs). VLANs are commonly used to split up groups of network users into manageable broadcast domains, to create logical segmentation of workgroups, and to enforce security policies among 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 briey describes how management functions can only be accomplished from stations on VLANs that include an IP interface to the switch. "VLAN Topologies and Design Issues" (page 72) This section discusses how you can logically connect users and segments to a host that supports many logical segments or subnets by using the exibility of the multiple VLAN system. "VLANs and Default Gateways" (page 75) Note: Basic VLANs can be congured during initial switch conguration (see "Using the Setup Utility" in the Nortel Application Switch Operating System Command Reference). More comprehensive VLAN conguration can be done from the Command Line Interface (see "VLAN Conguration" as well as "Port Conguration" in the Nortel Application Switch Operating System Command Reference).
VLAN ID Numbers
Nortel Application Switch Operating System supports up to 2048 VLANs per switch. Even though the maximum number of VLANs supported at any given time is 2048, each can be identied with any number between 1 and 4090. VLANs are dened on a per-port basis. Each port on the switch can belong to one or more VLANs, and each VLAN can have any number of switch ports 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 congurable default VLAN number, known as its PVID. The factory default value for all PVIDs is 1. This places all ports on the same VLAN initially, although each ports PVID is congurable to any VLAN number between 1 and 4090. Any untagged frames (those with no VLAN specied) are classied with the sending ports PVID.
VLAN Tagging
Nortel Application Switch Operating System software supports 802.1Q VLAN tagging, providing standards-based VLAN support for Ethernet systems. Tagging places the VLAN identier in the frame header, allowing multiple VLANs per port. When you congure multiple VLANs on a port, you must also enable tagging on that port. Since tagging fundamentally changes the format of frames transmitted on a tagged port, you must carefully plan network designs to prevent tagged frames from being transmitted to devices that do not support 802.1Q VLAN tags.
VLANs and the IP Interfaces

Carefully consider how you create VLANs within the switch, so that communication with the switch remains possible. You can access the switch for remote conguration, trap messages, and other management functions only from stations on VLANs that include an IP interface to the switch (see "IP Interface Menu" section in the Nortel Application Switch Operating System Command Reference). Likewise, you can cut off access to management functions to any VLAN by excluding IP interfaces from the VLANs membership. For example, if all IP interfaces are left on VLAN 1 (the default), and all ports are congured for VLANs other than VLAN 1, then switch management features are effectively cut off. If an IP interface is added to one of the other VLANs, the stations in that VLAN will all have access to switch management features.
VLAN Topologies and Design Issues

By default, the Nortel Application Switch Operating System software has a single VLAN congured on every port. This conguration groups all ports into the same broadcast domain. The VLAN has an 802.1Q VLAN PVID of 1. VLAN tagging is turned off, because by default only a single VLAN is congured per port.
.
VLAN Topologies and Design Issues
73
Since VLANs are most commonly used to create individual broadcast domains and/or separate IP subnets, host systems should be present on more than one VLAN simultaneously. Nortel Application Switches and VLAN-tagging server adapters support multiple VLANS on a per-port or per-interface basis, allowing very exible congurations. You can congure multiple VLANs on a single VLAN-tagging server adapter, with each VLAN being congured through a logical interface and logical IP address on the host system. Each VLAN congured on the server adapter must also be congured on the switch port to which it is connected. If multiple VLANs are congured on the port, tagging must be turned on. Using this exible multiple VLAN system, you can logically connect users and segments to a host with a single VLAN-tagging adapter that supports many logical segments or subnets. Note: If a 802.1Q tagged frame is sent to a port that has vlan-tagging disabled, then the frames are dropped at the ingress port.
Example 1: Multiple VLANS with Tagging Adapters

Example 1: Multiple VLANs with VLAN-Tagged Gigabit Adapters
The features of this VLAN are described below:
.
74 VLANs
Component Application Switch
Description This switch is configured for three VLANs that represent three different IP subnets. Two servers and five clients are attached to the switch. This server is part of VLAN 3 and only has presence in one IP subnet. The port that the VLAN is attached to is configured only for VLAN 3, so VLAN tagging is off. This high-use server needs to be accessed from all VLANs and IP subnets. The server has a VLAN-tagging adapter installed with VLAN tagging turned on. The adapter is attached to one of the application switchs Gigabit Ethernet ports, that is configured for VLANs 1, 2, and 3. Tagging is turned on. Because of the VLAN tagging capabilities of both the adapter and the switch, the server is able to communicate on all three IP subnets in this network. Broadcast separation between all three VLANs and subnets, however, is maintained. These PCs are attached to a shared media hub that is then connected to the switch. They belong to VLAN 2 and are logically in the same IP subnet as Server 2 and PC 5. Tagging is not enabled on their switch port. A member of VLAN 1, this PC can minimize its broadcast domain to Server 2 and PC 5. A member of VLAN 3, this PC can minimize its broadcast domain to Server 1 and Server 2. A member of both VLAN 1 and VLAN 2, this PC has VLAN-tagging Gigabit Ethernet adapter installed. It can minimize its broadcast domain to Server #2 via VLAN 1, and to PC #1 and PC #2 via VLAN 2. The switch port to which it is connected is configured for both VLAN 1 and VLAN 2 and has tagging enabled.
Server #1
Server #2
PCs #1 and #2
PC #3 PC #4 PC #5
Note: VLAN tagging is required only on ports that are connected to other Nortel Application Switches or on ports that connect to tag-capable end-stations, such as servers with VLAN- tagging adapters.
Example 2: Parallel Links with VLANs

Example 2 shows how it is possible, through the use of VLANs, to create congurations where there are multiple links between two switches, without creating broadcast loops. In "Example 2: Parallel Links with VLANs" (page 75), two Nortel Application Switches are connected with two different Gigabit Ethernet links. Without VLANs, this conguration 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. Both switch-to-switch links are on different VLANs and, thus, are separated into their own broadcast domains.
Example 2: Parallel Links with VLANs
In this example the Gig ports are on different VLANs and Spanning Tree Protocol is disabled. For information on Spanning Tree Protocol, see "Spanning Tree Protocol" (page 93)."
VLANs and Default Gateways

Nortel Application Switch Operating System allows you to assign different gateways for each VLAN. You can effectively map multiple customers to specic gateways on a single switch. The benets of segregating customers to different default gateways are: Resource optimization Enhanced customer segmentation Improved service differentiation
Segregating VLAN Trafc

Deploy this feature in an environment where you want to segregate VLAN trafc to a congured default gateway. In "Default Gateways per VLAN" (page 76), VLANs 2 and 3 have different routing requirements. VLAN 2 is required to route trafc through default gateway 5 and VLAN 3 is required to route trafc through default gateway 6.
.
76 VLANs Default Gateways per VLAN
You can congure up to 255 gateways with one gateway per VLAN with values starting from 5 through 259. If the gateways per VLAN fail, then trafc is directed to default gateways 1 through 4. Default gateways 1 through 4 are used for load balancing session requests and as backup when a specic gateway that has been assigned to a VLAN is down. In the example shown in "Default Gateways per VLAN" (page 76), if gateways 5 or 6 fail, then trafc is directed to default gateway 1, which is congured with IP address 10.10.4.1. If default gateways 1 through 4 are not congured on the switch, then packets from VLAN 2 and VLAN 3 are discarded. The route cache table on the switch records each session request by mapping the destination IP address with the MAC address of the default gateway. The command /info/l3/arp/dump on the switch command line displays the entries in the route cache similar to those shown in "Route Cache Example" (page 76). The destination IP addresses (see the last two rows) are associated with the MAC addresses of the gateways.
Route Cache Example Destination IP address 10.10.1.1 10.10.1.20 Flags P MAC address 00:60:cf:46:48:60 00:60:cf:44:cd:a0 VLAN 4 4 25 (Gig) Port Referenced SPs 1-4 empty
.
Destination IP address 10.10.1.30 10.10.4.1 10.10.4.40 172.21.2.27 172.21.2.200 172.21.3.14 172.21.2.200 192.168.20.200 200.1.2.200
Flags
MAC address 00:60:cf:42:3b:40 00:60:cf:42:77:e0
VLAN 4 1 1 2 2 3 3 4 4
Port 26 (Gig) 27 (Gig) 7
Referenced SPs empty empty 1-4 1 1-4
00:60:cf:46:48:60 00:50:da:17:c8:05
00:60:cf:46:48:60 00:c0:4f:09:3e:56
2 1-4
P R R
00:60:cf:46:48:60 00:60:cf:44:cd:a0 00:60:cf:42:3b:40
1 2
7 8
As shown in "Route Cache Example" (page 76), trafc from VLAN 2 uses Gateway 5 to access destination IP address 192.168.20.200. If trafc from VLAN 3 requests the same destination address, then trafc is routed via Gateway 5 instead of Gateway 6, because 192.168.20.200 in the route cache is mapped to Gateway 5. If the requested route is not in the route cache, then the switch reads the routing table. If the requested route is not in the routing table, then the switch looks at the congured default Gateway.
Conguring the Local Network

To completely segregate VLAN trafc to its own default gateway, you can congure the local network addresses of the VLAN. This ensures that all trafc from VLAN 2 is forwarded to Gateway 5 and all trafc from VLAN 3 is forwarded to Gateway 6. Typically, the switch routes trafc based on the routes in the routing table. The routing table contains an entry of the congured local network with the default gateway. The route cache will not contain the route entry. This conguration provides a more secure environment, but affects performance if the routing table is close to its maximum capacity.
Conguring Gateways per VLAN

Follow this procedure to congure the example shown in "Default Gateways per VLAN" (page 76): Step 1 2 Action Assign an IP address for each router and client workstation. Assign an IP interface for each subnet attached to the switch.
.
78 VLANs
>> /cfg/l3/if 1 >> IP Interface 1# 10.10.1.1 >> IP Interface 1# 255.255.255.0 >> IP Interface 1# >> IP Interface 1# 2 >> IP Interface 2# 10.10.4.40 >> IP Interface 2# 255.255.255.0 >> IP Interface 2# >> IP Interface 2# 3 >> IP Interface 3# 172.21.2.200 >> IP Interface 3# 255.255.255.0 >> IP Interface 3# >> IP Interface 3# 4 >> IP Interface 4# 172.21.3.200 >> IP Interface 4# 255.255.255.0 >> IP Interface 4# addr mask vlan 4 /cfg/l3/if addr mask vlan 1 /cfg/l3/if addr mask vlan 2 /cfg/l3/if addr mask vlan 3
(Select IP interface 1 for gateway 5 & 6 subnet) (Assign IP address for interface 1) (Assign mask for IF 1) (Assign VLAN 4 to IF 1) (Select IP interface 2 for gateway 1) (Assign IP address for interface 2) (Assign mask for IF 2) (Assign VLAN 1 to IF 2) (Select IP interface 3 for VLAN 2 subnet) (Assign IP address for interface 3) (Assign mask for IF 3) (Assign VLAN 2 to IF 3) (Select IP interface 4 for VLAN 3) subnet) (Assign IP address for interface 4) (Assign mask for IF 4) (Assign VLAN 3 to IF 4)
Congure the default gateways . Conguring gateways 5 and 6 for VLANs 2 and 3 respectively. Congure default gateway 1 for load balancing session requests and as backup when gateways 5 and 6 fail.
>> /cfg/l3/gw 5 addr (Select gateway 5) ( Assign IP address for gateway 5) (Select default gateway 6) addr (Assign IP address for gateway 6)
>> Default gateway 5# 10.10.1.20 >> Default gateway 5# /cfg/l3/gw 6 >> Default gateway 6# 10.10.1.30
.
>> Default gateway 6# /cfg/l3/gw 1 >> Default gateway 1# 10.10.4.1 addr
(Select default gateway 1) (Assign IP address for gateway 1)
Note: The IP address for default gateways 1 to 4 must be unique. IP addresses for default gateways 5 to 259 can be set to the same IP address as the other gateways (including default gateway 1 to 4). For example, you can congure two default gateways with the same IP address for two different VLANs. 4 Add the VLANs to the gateways and enable them.
>> /cfg/l3/gw 5 vlan 2 ena (Select gateway 5) (Add VLAN 2 for default gateway 5) (Enable gateway 5) (Select gateway 6) vlan 3 ena (Add VLAN 3 for default gateway 6) (Enable gateway 6) (Select default gateway 1) ena (Enable gateway 1 for all VLAN s)
>> Default gateway 5# >> Default gateway 5# >> Default gateway 5# /cfg/l3/gw 6 >> Default gateway 6# >> Default gateway 6# >> Default gateway 6# /cfg/l3/gw 1 >> Default gateway 1#
Apply and verify your conguration.

>> Default gateway 1# /cfg/l3/cur (View current L3 settings)
(Optional) Congure the local networks using address and mask pairs to ensure that the VLANs use the congured default gateways.
>> Default gateway 1# /cfg/l3/frwd/local >> IP Forwarding# add 10.10.0.0 255.255.0.0 (Select the local network Menu) (Specify the network for routers 1, 2, & 3)
.
80 VLANs
>> IP Forwarding# add 172.21.2.0 255.255.255.0 >> IP Forwarding# add 172.21.3.0 255.255.255.0
(Specify the network for VLAN 2) (Specify the network for VLAN 3)
Apply and save your new conguration changes.

>> IP Forwarding# apply >> IP Forwarding# save
End
VLANs and Jumbo Frames

To reduce host frame processing overhead, Gigabit network adapters that can handle frame sizes of 9014 bytes (such as the 3COM PCI-X/PCI Gigabit adapters) and Nortel Application Switches running operating Nortel Application Switch Operating System version 21.0 or later, can receive and transmit frames that are far larger than the maximum normal Ethernet frame. By sending one jumbo frame instead of myriad smaller frames, the same task is accomplished with less processing. The switches and the adapter should support jumbo frame sizes up to 9018 octets. jumbo frames can be transmitted and received between Gigabit adapter-enabled hosts through the switch across any VLAN that has jumbo frames enabled.
Limitations
Jumbo frames are supported on the switch uplink ports and not supported on switch downlink ports. For information on uplink vs. downlink ports on your particular switch model, refer Nortel Application Switch Hardware Installation Guide. Jumbo frames are not supported if Bandwidth Management is enabled on the switch. Jumbo Frames are supported only for ROHS/E model Application Switches in NAS 23.2.X and 24.X.
Isolating Jumbo Frame Trafc using VLANs

Jumbo frame trafc must not be used on a VLAN where there is any device that cannot process frame sizes larger than Ethernet maximum frame size. On Nortel Application Switch 2000 and 3000 series switches, additional VLANs can be congured on the adapters and switches to support non-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-capable Gigabit adapters, and attached to application switches can communicate across both the jumbo frame VLANs and regular frame VLANs at the same time. In the example illustrated in "Jumbo Frame VLANs" (page 81), the two servers can handle jumbo frames but the two clients cannot; therefore jumbo frames should only be enabled and used on the VLAN represented by the solid lines but not for the VLAN with the dashed lines. Jumbo frames are not supported on ports that are congured for half-duplex mode.
Jumbo Frame VLANs
Conguring VLANs for Jumbo and Non-Jumbo Frames

To congure a Nortel Application Switch 2424 for jumbo and non-jumbo frame trafc, congure two VLANs: Step 1 Action 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 name stg - Assign VLAN to a Spanning Tree Group cont - Set BW contract add - Add port to VLAN rem - Remove port from VLAN
.
82 VLANs
def jumbo learn ena dis del cur >> VLAN Port 25 current Confirm Current Pending >> VLAN Port 26 current Confirm Current Pending
Define VLAN as list of ports Enable/disable Jumbo Frame support Enable/disable smac learning Enable VLAN Disable VLAN Delete VLAN Display current VLAN configuration
2# add 25 is an UNTAGGED port and its PVID is 1. changing PVID from 1 to 2 [y/n]: ports for VLAN 2: empty new ports for VLAN 2: 25 2# add 26 is an UNTAGGED port and its PVID is 1. changing PVID from 1 to 2 [y/n]: ports for VLAN 2: empty new ports for VLAN 2: 25 26
>> VLAN 2#
Enable jumbo frame processing on VLAN 2, then apply and save the changes.
>> VLAN 2# jumbo enable Current jumbo frame support: disabled New jumbo frame support: enabled >> apply >> save
End
.
Port Trunking
83
Port Trunking
Trunk groups can provide super-bandwidth, multi-link connections between Nortel Application Switches or other trunk-capable devices. A trunk group is a group of ports that act together, combining their bandwidth to create a single, larger virtual link. This chapter provides conguration background and examples for trunking multiple ports together either in a static (manually congured) trunk group, or dynamic trunk group using Link Aggregation Control Protocol. The following topics are addressed in this chapter: " "Overview" (page 83) " on this page "Static Port Trunking Example" (page 85) "Link Aggregation Control Protocol Trunking" (page 87)
Overview
When using port trunk groups between two Nortel Application Switches as shown in "Port Trunk Group" (page 83), you can create a virtual link between the switches operating up to 4 Gigabits per second, depending on how many physical ports are combined. The switch supports up to 12 static trunk 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 to third-party devices that support link aggregation, such as Cisco routers and switches with EtherChannel technology (not ISL trunking technology) and Suns Quad Fast Ethernet Adapter. Nortel Networks trunk group technology is compatible with these devices when they are congured manually.
.
84 VLANs
Statistical Load Distribution

Network trafc is statistically load balanced between the ports in a trunk group. The Nortel Application Switch Operating System-powered switch uses both the Layer 2 MAC address and Layer 3 IP address information present in each transmitted frame for determining load distribution. The addition of Layer 3 IP address examination is an important advance for trafc distribution in trunk groups. In some port trunking systems, only Layer 2 MAC addresses are considered in the distribution algorithm. Each packets particular combination of source and destination MAC addresses results in selecting one line in the trunk group for data transmission. If there are enough Layer 2 devices feeding the trunk lines, then trafc distribution becomes relatively even. In some topologies, however, only a limited number of Layer 2 devices (such as a handful of routers and servers) feed the trunk lines. When this occurs, the limited number of MAC address combinations encountered results in a lopsided trafc distribution, which can reduce the effective combined bandwidth of the trunked ports. By adding Layer 3 IP address information to the distribution algorithm, a far wider variety of address combinations is seen. Even with just a few routers feeding the trunk, the normal source/destination IP address combinations (even within a single LAN) can be widely varied. This results in a wider statistical load distribution and maximizes the use of the combined bandwidth available to trunked ports.
The Trunk Hash Algorithm

In order to distribute the load across all active ports in a trunk group, the following algorithm is used to determine which port within the trunk group to 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 parameters A and B are given below for different types of forwarding and frames. These two parameters are XORed together to give the hash index. The modulus x of the lower 6 bits of the hash index is then taken to give the port of the trunk group. Note: The same algorithm is used across all Nortel Application Switches including Nortel Application Switch 180 and AD series, Nortel Switched 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 (trafc 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 Application Switch Operating System 21.0 and higher.
Built-In Fault Tolerance

Since each trunk group is comprised of multiple physical links, the trunk group is inherently fault tolerant. As long as one connection between the switches is available, the trunk remains active. Statistical load balancing is maintained whenever a port in a trunk group is lost or returned to service.
Static Port Trunking Example

In the example below, three ports will be trunked between two Nortel Application Switches.
Port Trunk Group Conguration Example
Prior to conguring each switch in the above example, you must connect to the appropriate switchs Command Line Interface (CLI) as the administrator.
.
86 VLANs
Note: For details about accessing and using any of the menu commands described in this example, see the Nortel Application Switch Operating System Command Reference. In this example, two Nortel Application Switches are used. If a third-party device supporting link aggregation is used (such as Cisco routers and switches with EtherChannel technology or Suns Quad Fast Ethernet Adapter), trunk groups on the third-party device should be congured manually. Connection problems could arise when using automatic trunk group negotiation on the third-party device.
CAUTION
To prevent spanning tree instability, do not change the spanning tree parameters on individual ports belonging to any trunk group.
Step 1 2
Action Connect the switch ports that is involved in the trunk group. On application switch 1, dene a trunk group.
>> # /cfg/l2/trunk 1 >> Trunk group 1# add 2 >> Trunk group 1# add 12 >> Trunk group 1# add 25 >> Trunk group 1# ena (Select trunk group 1) (Add port 2 to trunk group 1) (Add port 12 to trunk group 1) (Add port 25 to trunk group 1) (Enable trunk group 1)
Apply and verify the conguration.

>> Trunk group 1# apply >> Trunk group 1# cur (Make your changes active) (View current trunking configuration)
Examine the resulting information. If any settings are incorrect, make appropriate changes. 4 Save your new conguration changes.
>> Trunk group 1# save (Save for restore after reboot)
Repeat the process on application switch 2.
.
Port Trunking
87
>> # /cfg/l2/trunk 3 >> Trunk group 3# add 6 >> Trunk group 3# add 11 >> Trunk group 3# add 26 >> Trunk group 3# ena >> Trunk group 3# apply >> Trunk group 3# cur >> Trunk group 3# save
(Select trunk group 3) (Add port 6 to trunk group 3) (Add port 11 to trunk group 3) (Add port 26 to trunk group 3) (Enable trunk group 3) (Make your changes active) (View current trunking configuration) (Save for restore after reboot)
Trunk group 1 (on application switch 1) is now connected to trunk group 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 congured trunk group is displayed. Make sure that trunk groups consist of the expected ports and 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 trunk group are congured for the same speed. Trunking from non-Nortel devices must comply with Cisco EtherChannel technology. End
Link Aggregation Control Protocol Trunking

Link Aggregation Control Protocol (LACP) is an IEEE 802.3ad standard for grouping several physical ports into one logical port (known as trunk group or Link Aggregation group) with any device that supports the standard. If a link in a LACP trunk group fails, trafc is reassigned dynamically to any of the remaining links of the LACP trunk group. Link aggregation is a method of grouping physical link segments of the same media type and speed in full duplex, and treating them as if they were part of a single, logical link segment. Refer to IEEE 802.3ad-2002 for full description of the standard.
.
88 VLANs
When using LACP, any trunk groups you may have already congured according to the manual procedure described in "Static Port Trunking Example" (page 85) "Static Port Trunking Example" (page 85) are "static trunks." Any trunk groups using LACP are "dynamic trunks." With LACP, the maximum number of trunk groups has increased to 40; static trunks continue to be limited to trunk IDs 112, and LACP trunks use IDs 13 through 40. The Nortel Application Switch Operating System implementation of LACP allows you to group a maximum of eight physical ports into one logical port (LACP trunk group). Standby ports in LACP are created only when there are more than eight LACP ports congured in a trunk. The switch automatically assigns any non-trunked LACP-congured ports as standby ports for the LACP trunk. If any of the eight primary LACP ports fails, the switch dynamically replaces it with the standby port. The Nortel Application Switch can form trunk groups with any device which supports the IEEE 802.3ad standard. Each LACP port in the switch has a parameter called admin key. An LACP trunk group is formed with the ports with the same admin key. The value of admin key can be any integer between 1 and 65535. For example, consider two switches as shown in "Actor vs. Partner LACP conguration" (page 88).
Actor vs. Partner LACP conguration Actor Switch Port 1 (admin key = 100) Port 2 (admin key = 100) Port 3 (admin key = 100) Port 4 (admin key = 100) Partner Switch 1 Port 1 (admin key = 50) Port 2 (admin key = 50) Port 3 (admin key = 50) Port 4 (admin key = 50)
In the conguration shown in "Actor vs. Partner LACP conguration" (page 88), Actor switch ports 1-4 can aggregate to form an LACP trunk group with the Partner switch ports 1-4. Note that the port admin key value has local signicance only the admin key value for the partner switch ports can be any integer value but it should be same for all ports 1-4. In this example it is 50. Each port in the Nortel Application Switch can have one of the following LACP modes. off (default) The user can congure this port into a regular static trunk group. active
.
Port Trunking
89
The port is capable of forming an LACP trunk. This port sends LACPDU packets to partner system ports. passive The port is capable of forming an LACP trunk. This port only responds to the LACPDU packets sent from an LACP active port. Each active LACP port transmits LACP data units (LACPDUs), while each passive LACP port listens for LACPDUs. During LACP negotiation, the admin key value is exchanged. The LACP trunk group is enabled as long as the information matches at both ends of the link. If the admin key value changes for a port at either end of the link, that ports association with the LACP trunk group is lost. When the system is initialized, all ports by default are in LACP off mode and are assigned unique admin keys. To make a group of ports eligible for aggregation, you assign them all the same admin key. You must set the ports LACP mode to active to activate LACP negotiation. You can set other ports LACP mode to passive, to reduce the amount of LACPDU trafc, at the initial trunk-forming stage. Note: LACP implementation in Nortel Application Switch Operating System 22.0 does not support the Churn machine, an option used for detecting the port is operable within a bounded time period between the actor and the partner. Only the Marker responder is implemented, and there is no marker protocol generator. Refer to 802.3ad-2002 for details.
Conguring LACP
Use the following procedure to congure LACP for port 1 through port 4 for the actor switch to participate in link aggregation. Perform a similar conguration on the partner switch with adminkey 50. Step 1 Action Set the LACP mode on port 1.
>> # /cfg/l2/lacp/port 1/mode >> LACP port 1# active (Select port 1 for LACP mode of operation) (Set port 1 to LACP active)
Current Port 1 LACP mode setting: off New Port 1 LACP mode setting: active
Dene the admin key on port 1. Only ports with the same admin key can form a LACP trunk group.
.
90 VLANs
>> # /cfg/l2/lacp/port 1/adminkey 100
(Set port 1 adminkey to 100)
Current LACP port adminkey: 1 New pending LACP port adminkey: 100
Set the LACP mode on ports 2 to 4.

>> # /cfg/l2/lacp/port 2/mode active >> # /cfg/l2/lacp/port 3/mode active >> # /cfg/l2/lacp/port 4/mode active (Select port 2 mode of operation) (Select port 3 mode of operation) (Select port 4 mode of operation)
Dene the admin key on ports 2 to 4.

>> # /cfg/l2/lacp/port 2/adminkey 100 >> # /cfg/l2/lacp/port 3/adminkey 100 >> # /cfg/l2/lacp/port 4/adminkey 100 (Select port 2 adminkey to 100) (Select port 3 adminkey to 100) (Select port 4 adminkey to 100)

>> LACP port 4# apply >> LACP port 4# cur (Make your changes active) (View current trunking configuration)
Save your new conguration changes.

>> LACP port 4# save (Save for restore after reboot)
End
.
Port Teaming 91
Port Teaming
Port teaming is a feature deployed in scenarios where VRRP is not used to detect link failures. If an uplink connection fails, then the switch noties uplink routers and switches of the failure instead of waiting for the routers and switches to time out. This feature is also used to team ports or trunks so that when one port or trunk in the team is down, all others in the team are operationally disabled. The following examples create two simple port teams. The rst example creates a simple, two port team and the second creates a simple two trunk team. The following example creates a simple two port team: Step 1 Action Create a new port team.
>> Main# /cfg/l2/team 1
Add ports to the new team.

>> Port Team 1# addport 1 >> Port Team 1# addport 2
Enable port team.

>> Port Team 1# ena
End
The following example creates a simple two trunk team: Step 1 Action Create a new port team.
>> Main# /cfg/l2/team 2
Add trunks to the new team.
.
92 VLANs
>> Port Team 2# addtrunk 1 >> Port Team 2# addtrunk 2
Enable port team.

>> Port Team 2# ena
In both examples above, the teams are placed in passive mode with either the ports or trunks operational. The team is in passive mode is when all ports or trunks are operational and the team is waiting for any one of the ports or trunks to become disabled. When one of the ports or trunks is disabled, the team goes to active mode and the other ports or trunks in the team are operationally disabled. The port or trunk that triggered this becomes the master port. When the master port or trunk becomes operational once more, the other ports or trunks in the team are operationally enabled. When all the ports or trunks are operational, the team goes back to passive mode. There are scenarios when, after operationally enabled, some of the other ports or trunks in the team are not operational due to a link being down or operational or conguration disabling. When this happens the team goes into off mode. In this mode, the team waits until all ports or trunks are operational before going back to passive mode to repeat the cycle. The Nortel Application Switch Operating System supports a maximum of 8 port teams. End
.
Spanning Tree Protocol
93

When multiple paths exist on a network, Spanning Tree Protocol (STP) congures the network so that a switch uses only the most efcient path. The following topics are addressed in this chapter: "Overview" (page 93) "Bridge Protocol Data Units (BPDUs)" (page 94) "Spanning Tree Group Conguration Guidelines" (page 96) "Multiple Spanning Trees" (page 97) "Rapid Spanning Tree Protocol" (page 102) "Multiple Spanning Tree Protocol" (page 104)
Overview
Spanning Tree Protocol (STP) detects and eliminates logical loops in a bridged or switched network. STP forces redundant data paths into a standby (blocked) state. When multiple paths exist, Spanning Tree congures the network so that a switch uses only the most efcient path. If that path fails, Spanning Tree automatically sets up another active path on the network to sustain network operations. The relationship between port, trunk groups, VLANs, and Spanning Trees is shown in "Ports, Trunk Groups, and VLANs" (page 93).
Ports, Trunk Groups, and VLANs Switch Element Port Belongs to Trunk group or One or more VLANs One or more VLANs One Spanning Tree group
Trunk group VLAN
Note: Due to Spanning Trees sequence of listening, learning, and forwarding or blocking, lengthy delays may occur. For more information on using STP in cross-redundant topologies, see "Eliminating Loops with STP and VLANs" (page 577).
.
94 VLANs
Bridge Protocol Data Units (BPDUs)

To create a Spanning Tree, the application switch generates a conguration Bridge Protocol Data Unit (BPDU), which it then forwards out of its ports. All switches in the Layer 2 network participating in the Spanning Tree gather information about other switches in the network through an exchange of BPDUs. A BPDU is a 64-byte packet that is sent out at a congurable interval, which is typically set for two seconds. The BPDU is used to establish a path, much like a "hello" packet in IP routing. BPDUs contain information about the transmitting bridge and its ports, including bridge and MAC addresses, bridge priority, port priority, and path cost. If the ports are tagged, each port sends out a special BPDU containing the tagged information. The generic action of a switch on receiving a BPDU is to compare the received BPDU to its own BPDU that it transmits. If the received BPDU is better than its own BPDU, it will replace its BPDU with the received BPDU. Then, the application switch adds its own bridge ID number and increments the path cost of the BPDU. The application switch uses this information to block any necessary ports.
Determining the Path for Forwarding BPDUs

When determining which port to use for forwarding and which port to block, application switches use information in the BPDU, including each bridge priority ID. A technique based on the "lowest root cost" is then computed to determine the most efcient path for forwarding. For more information on bridge priority, port priority, and port cost, refer to the Nortel Application Switch Operating System Command Reference. Much like least-cost routing, root cost assigns lower values to high-bandwidth ports, such as Gigabit Ethernet, to encourage their use. For example, 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 a cost of 1. The objective is to use the fastest links so that the route with the lowest cost is chosen.
Bridge Priority
The bridge priority parameter controls which bridge on the network is the STP root bridge. To make one switch the root bridge, congure the bridge priority lower than all other switches and bridges on your network. The lower the value, the higher the bridge priority. The bridge priority is congured using the /cfg/l2/stg/brg/prior command in the CLI.
.
95
Port Priority
The port priority helps determine which bridge port becomes the designated port. In a network topology that has multiple bridge ports connected to a single segment, the port with the lowest port priority becomes the designated port for the segment. The port priority is congured using the /cfg/l2/stg/port/prior command in the CLI.
Port Path Cost

The port path cost assigns lower values to high-bandwidth ports, such as Gigabit Ethernet, to encourage their use. The cost of a port also depends on 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. The objective is to use the fastest links so that the route with the lowest cost is chosen. A value of 0 indicates that the default cost will be computed for an auto-negotiated link speed.
Spanning Tree Compatibility between BPDU Formats

When a tagged port belongs to more than one spanning tree group, the spanning tree bridge protocol data units (BPDUs) are tagged to distinguish the BPDUs of one spanning tree group from those of another. BPDUs from the 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 such as the Baystack 470 handle the transmission of spanning tree BPDUs differently than equipment vendors such as Cisco Systems. In the Cisco implementation, only ONE of the ports in the trunk transmits a BPDU. In the Nortel implementation, all of the ports in the trunk each transmit an identical copy of the BPDU, and the tagged BPDUs are transmitted using a multicast MAC address as tagged frames with a VLAN ID. An Nortel Application Switch by default uses the Cisco-type BPDU transmission format, and can also be enabled for compatibility with the Nortel-type BPDU format. The Nortel tagged BPDU format should be enabled on an Nortel Application Switch when it is connected it to a Nortel product that uses tagging. Use the following commands to enable Nortel tagged BPDU format:
Main # /cfg/l2/ntmstg ena Main # /boot/reset (Enable Nortel tagged BPDU format) (Reset the switch to enable)
.
96 VLANs
Spanning Tree Group Conguration Guidelines

This section provides important information on conguring Spanning Tree Groups (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 move the 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 desired STG.
Rules for VLAN Tagged ports

Tagged ports can belong to more than one STG, but untagged ports can belong to only one STG. When a tagged port belongs to more than one STG, the egress BPDUs are tagged to distinguish the BPDUs of one STG from those of another STG. 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 also added to the STG. However, if the port you are adding is an untagged port and is already a member of an STG, that port is not added to an additional STG because an untagged port cannot belong to more that one STG. For example, assume that VLAN1 belongs to STG1. You add an untagged port, port 1, that does not belong to any STG to VLAN1, and port 1 becomes part of STG1.
.
97
If you add untagged port 5 (which is a member to STG2) to STG1, the switch 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 port will also be removed from the STG. However, if that port belongs to another VLAN in the same STG, the port remains in the STG. As an example, assume that port 1 belongs to VLAN1, and VLAN1 belongs to STG1. When you remove port 1 from VLAN1, port 1 is also removed from STG1. However, if port 1 belongs to both VLAN1 and VLAN2 and both VLANs belong to STG1, removing port 1 from VLAN1 does not remove port 1 from STG1 because VLAN2 is still a member of STG1.
An STG cannot be deleted, only disabled. If you disable the STG while it still contains VLAN members, Spanning Tree will be off on all ports belonging to that VLAN.
Spanning Tree Implementations in Trunk Groups

In both Cisco and Nortel spanning tree implementation as described in "Spanning Tree Compatibility between BPDU Formats" (page 95), the trunking methodology applies for both the default and non-default spanning tree groups. Make sure that all members of the trunk group are congured to the correct spanning tree group parameters, and determine whether or not to enable use of the Nortel multiple spanning tree group mode.
CAUTION
All ports that are within a trunk group should be congured to have the same Spanning Tree and VLAN parameters. Spanning Tree parameters should not be changed on individual ports that belong to a trunk group. To change spanning tree on one or more ports belonging to a trunk group, rst remove individual members from the trunk group before changing their spanning tree parameters.
Multiple Spanning Trees

The Nortel Application Switch Operating System supports Multiple Spanning Tree Protocol (MSTP) and Rapid Spanning Tree Protocol (RSTP) as dened in the IEEE 802.1S (MSTP) and 802.1W (RSTP) standards. This is an improvement over previous spanning tree implementations in that it is a standards-based approach to implementing this functionality.
.
98 VLANs
Before the 802.1S standard, MSTP was implemented through a variety of proprietary protocols such as Nortel MSTP and Cisco PVST+. Each one of these proprietary protocols had advantages and disadvantages but they were never interoperable. The 801.S standard solves this by creating standards-based MSTP. The 802.1W standard takes the same approach in creating standards-based RSTP. In this implementation of MSTP, up to 2048 VLANs can be mapped to any of the 16 spanning tree instances. Each spanning tree instance handles multiple VLANs that have the same Layer 2 topology but each spanning tree instance can have a topology independent of other instances. As well, MSTP provides multiple forwarding paths for data trafc, enables load balancing, and improves overall network fault tolerance. This implementation of RSTP improves upon previous implementations by addressing slow convergence times. Note: By default, all newly created VLANs are members of Spanning Tree Group 1. For specic 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 simple example of why we need multiple Spanning Trees. Two VLANs, VLAN 1 and VLAN 100 exist between Nortel Application Switch A and Nortel Application Switch B. If you have a single Spanning Tree group, the switches see an apparent 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, then the two instances of Spanning Tree separate the topology without forming a loop. Both VLANs can forward packets between the application switches without losing connectivity.
Multiple Instances of Spanning Tree Protocol
.
99
Four-Switch Topology with a Single Spanning Tree

In the four-switch topology example shown in "VLAN 3 Isolated in a Single Spanning Tree Group" (page 99), and assuming Nortel Application Switch A has a higher priority, you can have at least three loops on the network: Data owing from application switches A to B to C and back to application switch A. Data owing from application switches A to C to D and back to application switch A Data owing from application switches A to B to C to D and back to application switch A.
With a single Spanning Tree environment, as shown in "VLAN 3 Isolated in a Single Spanning Tree Group" (page 99), you will have two links blocked to prevent loops on the network. It is possible that the blocks may be between application switches C and D and between application switches B and C, depending on the bridge priority, port priority, and port cost. The two blocks would prevent looping on the network, but the blocked link between application switches B and C will inadvertently isolate VLAN 3 altogether. Note: For more information on bridge priority, port priority, and port cost see the Nortel Application Switch Operating System Command Reference.
VLAN 3 Isolated in a Single Spanning Tree Group
.
100 VLANs
Four-Switch Topology with Multiple Spanning Trees

If multiple Spanning Trees are implemented and each VLAN is on a different Spanning Tree, elimination of logical loops will not isolate any VLAN. "Implementing Multiple Spanning Tree Groups" (page 100) shows the same four-switch topology as in "VLAN 3 Isolated in a Single Spanning Tree Group" (page 99), but with multiple Spanning Trees enabled. The VLANs are identied 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 congured in the example shown in "Implementing Multiple Spanning Tree Groups" (page 100). Refer to "Multiple Spanning Tree Groups per VLAN" (page 100) to identify the Spanning Tree group a VLAN is participating in for each switch.
Multiple Spanning Tree Groups per VLAN VLAN 1 Nortel Application Switch A Spanning Tree Group 1 Ports 1 and 2 VLAN 2 Spanning Tree Group 2 Port 8 Spanning Tree Group 1 Port 1 Spanning Tree Group 2 Port 8 VLAN 3
Nortel Application Switch B
.
101
VLAN 1 Nortel Application Switch C Spanning Tree Group 1 Ports 1 and 2 Spanning Tree Group 1 Ports 1 and 8
VLAN 2
VLAN 3 Spanning Tree Group 2 Port 8
Nortel Application Switch D
Switch-Centric Spanning Tree Protocol

In "Implementing Multiple Spanning Tree Groups" (page 100), VLAN 2 is shared by application switch A and B on ports 8 and 1 respectively. Nortel Application Switch A identies VLAN 2 in Spanning Tree group 2 and application switch B identies VLAN 2 in Spanning Tree group 1. Spanning Tree group is switch-centricit is used to identify the VLANs participating in the Spanning Tree groups. The Spanning Tree group ID is not transmitted in the BPDU. Each Spanning Tree decision is based on the conguration of that switch.
VLAN Participation in Spanning Tree Groups

The VLAN participation for each Spanning Tree group in "Implementing Multiple Spanning Tree Groups" (page 100) is discussed in the following sections: VLAN 1 Participation If application switch A is the root bridge, then application switch A transmits the BPDU for VLAN 1 on ports 1 and 2. Nortel Application Switch C receives the BPDU on its port 2 and application switch D receives the BPDU on its port 1. Nortel Application Switch D blocks port 8 or application switch C blocks port 1 depending on the information provided in the BPDU. VLAN 2 Participation Nortel Application Switch A, the root bridge generates another BPDU for Spanning Tree Group 2 and forwards it out from port 8. Nortel Application Switch B receives this BPDU on its port 1. Port 1 on application switch B is on VLAN 2, Spanning Tree group 1. Because application switch B has no additional ports participating in Spanning Tree group 1, this BPDU is not be forwarded to any additional ports and application switch A remains the designated root. VLAN 3 Participation 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 Tree group 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 is identied as participating in VLAN 3, Spanning Tree group 2. Since application switch C has no additional ports participating in Spanning Tree group 2, this BPDU is not forwarded to any additional ports and application switch B remains the designated root.
Rapid Spanning Tree Protocol

Rapid Spanning Tree Protocol (RSTP) provides rapid convergence of the spanning tree and provides for the fast reconguration critical for networks carrying delay-sensitive trafc such as voice and video. RSTP signicantly reduces the time to recongure the active topology of the network when changes occur to the physical topology or its conguration parameters. RSTP reduces the bridged-LAN topology to a single Spanning Tree. RSTP parameters are congured in Spanning Tree Group 1. STP Groups 2-32 do not apply to RSTP, and must be cleared. There are new STP parameters to support RSTP, and some values to existing parameters are different. RSTP is compatible with devices that run 802.1d Spanning Tree Protocol. If the switch detects 802.1d BPDUs, it responds with 802.1d-compatible data units. RSTP is not compatible with the Per VLAN Spanning Tree (PVST+) protocol.
Port State Changes

The port state controls the forwarding and learning processes of Spanning Tree. In RSTP, the port state has been consolidated to the following: discarding, learning, and forwarding. "RSTP vs. STP Port states" (page 102) compares the port states between 802.1d Spanning Tree and 802.1w Rapid Spanning Trees.
RSTP vs. STP Port states Operational status Enabled Enabled Enabled Enabled Disabled STP Port State Blocking Listening Learning Forwarding Disabled RSTP Port State Discarding Discarding Learning Forwarding Discarding
Port Type and Link Type

Spanning Tree conguration includes the edge port and link type parameters to support RSTP and MSTP. Although these parameters are congured for Spanning Tree Groups 1-32, they only take effect when RSTP/MSTP is turned on.
.
103
Edge Port
A port that does not connect to a bridge is called an edge port. Edge ports are generally connected to a server. Edge ports can start forwarding as soon as the link is up. Edge ports do not take part in Spanning Tree, and should not receive BPDUs. If a port with edge enabled does receive a BPDU, it begins STP processing only if it is connected to a spanning tree bridge. If it is connected to a host, the edge port ignores BPDUs.
Link Type
The link type determines how the port behaves in regard to Rapid Spanning Tree. The link type corresponds to the duplex mode of the port. A full-duplex link is point-to-point (p2p), while a half-duplex link should be congured as shared. If you select auto as the link type, the port dynamically congures the link type.
RSTP Conguration Guidelines

These guidelines should be followed when conguring Rapid Spanning Tree Groups: When RSTP is turned on, STP parameters apply only to STP Group 1. When RSTP is turned on, all VLANs (including the management VLAN 4095) are moved to Spanning Tree Group 1.
RSTP Conguration Example

This section provides steps to congure Rapid Spanning Tree using the CLI.
Congure Rapid Spanning Tree

Step 1 Action Create VLAN and add ports. Once ports have been readied for VLAN membership, VLAN 3 can be created and the ports added to the VLAN.
>> Main# /cfg/l2/vlan 2 <If the VLAN was not already created, it would be created with this command.> >> VLAN 2# add 2 >> VLAN 2# add 3 >> VLAN 2# add 4
Disable and clear STP groups 2 through 32.
.
104 VLANs
>> Main# /cfg/l2/stg 2 >> Spanning Tree Group 2# clear >> Spanning Tree Group 2# off
(Select Spanning Tree Group 2) (Clear STP Group 2 parameters) (Turn off STP Group 2)
Set the Spanning Tree mode to Rapid Spanning Tree.

>> Main# /cfg/l2/mrst >> Multiple Spanning Tree# mode rstp >> Multiple Spanning Tree# on (Select Multiple Spanning Tree menu) (Set mode to Rapid Spanning Tree) (Turn Rapid Spanning Tree on)
Congure STP Group 1 parameters.

>> /cfg/l2/stg 1 >> Spanning Tree Group 1# add 2 >> Spanning Tree Group 1# apply >> Spanning Tree Group 1# save (Select Spanning Tree Protocol menu) (Add VLAN 2 to STP Group 1) (Apply the configurations) (Save the configuration)
End
Multiple Spanning Tree Protocol

IEEE 802.1s Multiple Spanning Tree extends the IEEE 802.1w Rapid Spanning Tree Protocol through multiple Spanning Tree Groups. MSTP maintains up to 16 spanning-tree instances, that correspond to STP Groups 1-16. In Multiple Spanning Tree Protocol (MSTP), several VLANs can be mapped to each Spanning-Tree instance. Each Spanning-Tree instance is independent of other instances. MSTP allows frames assigned to different VLANs to follow separate paths, each path based on an independent Spanning-Tree instance. This approach provides multiple forwarding paths for data trafc, enabling load-balancing, and reducing the number of Spanning-Tree instances required to support a large number of VLANs.
.
105
By default, the spanning tree on the management ports is turned off in both STP/PVST+ mode and in MSTP/RSTP mode.
MSTP Region
A group of interconnected bridges that share the same attributes is called an Multiple Spanning Tree (MST) region. Each bridge within the region must share the following attributes: Alphanumeric name Version number VLAN-to STG mapping scheme
MSTP provides rapid reconguration, scalability and control due to the support of regions, and multiple Spanning-Tree instances support within each region.
Common Internal Spanning Tree

The Common Internal Spanning Tree (CIST) provides a common form of Spanning Tree Protocol, with one Spanning-Tree instance that can be used throughout the MSTP region. CIST allows the switch to interoperate with legacy equipment, including devices that run IEEE 802.1d (STP). CIST allows the MSTP region to act as a virtual bridge to other bridges outside of the region, and provides a single Spanning-Tree instance to interact with them. CIST port conguration includes Hello time, Edge port enable/disable, and Link Type. These parameters do not affect Spanning Tree Groups 1-32. They apply only when the CIST is used.
MSTP Conguration Guidelines

Adhere to these guidelines when conguring MSTP: When MSTP is turned on, the switch automatically moves management VLAN 4095 to the CIST. When MSTP is turned off, the switch moves VLAN 4095 from the CIST to Spanning Tree Group 32. For enabling MSTP, Region Name must be congured, and a default version number of 1 is congured automatically. Each bridge in the region must have the same name, version number, and VLAN mapping.
MSTP Conguration Example

This section provides steps to congure Multiple Spanning Tree Protocol using the CLI.
.
106 VLANs
Congure Multiple Spanning Tree Protocol

Step 1 Action Ready ports for VLAN membership. To create a VLAN, ports must rst be readied for VLAN membership. To do this, the port PVID (Port VLAN ID) is changed from the default of 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
Create VLAN and add ports. Once ports have been readied for VLAN membership, VLAN 3 can be created and the ports added to the VLAN.
>> Main# /cfg/l2/vlan 2 <If the VLAN was not already created, it would be created with this command.> >> VLAN 2# add 2 >> VLAN 2# add 3 >> VLAN 2# add 4
Set the mode to Multiple Spanning Tree, and congure MSTP region parameters.
>> Main# /cfg/l2/mrst >> Multiple Spanning Tree# mode mstp >> Multiple Spanning Tree# on >> Multiple Spanning Tree# name xxxxxx (Select Multiple Spanning Tree menu) (Set mode to Multiple Spanning Trees) (Turn Multiple Spanning Trees on) (Define the Region name)
Assign VLANs to Spanning Tree Groups.

>> Main# /cfg/l2/stg 2 >> Spanning Tree Group 2# add 2 (Select Spanning Tree Group 2) (Add VLAN 2)
Turn off Layer 3 forwarding.


.
107
>> Main# /cfg/l3/frwd off >> IP Forwarding# apply >> IP Forwarding# save
(Turn Layer 3 forwarding off) (Apply the configuration) (Save the configuration)
End
.
108 VLANs
.
109
Part 2: IP Routing
This section discusses Layer 3 switching functions. In addition to switching trafc at near line rates, the application switch can perform multi-protocol routing. This section discusses basic routing and advanced routing protocols: "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 conguration background and examples for using the Nortel Application Switch to perform IP routing functions. The following topics are addressed in this chapter: "IP Routing Benets" (page 110) "Routing Between IP Subnets" (page 110) "Example of Subnet Routing" (page 112) "Dening IP Address Ranges for the Local Route Cache" (page 117) "Dynamic Host Conguration Protocol" (page 118) "Gratuitous ARP (GARP) Command" (page 120) "Static Routes" (page 120)
IP Routing Benets
The Nortel Application Switch uses a combination of congurable IP switch interfaces and IP routing options. The switch IP routing capabilities provide the following benets: Connects the server IP subnets to the rest of the backbone network. Performs server load balancing (using both Layer 3 and Layer 4 switching in combination) to server subnets that are separate from backbone subnets. Provides another means to invisibly introduce Jumbo frame technology into the server-switched network by automatically fragmenting UDP Jumbo frames when routing to non-Jumbo frame VLANs or subnets. Provides the ability to route IP trafc between multiple Virtual Local Area Networks (VLANs) congured on the switch.
Routing Between IP Subnets

The 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 Application Switches are intelligent and fast enough to perform routing functions on a par with wire speed Layer 2 switching. The combination of faster routing and switching in a single device provides another serviceit allows you to build versatile topologies that account for legacy congurations. 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-centric topology to a faster, more powerful, switch-based topology. As is often the case, the legacy of network growth and redesign has left the system with a mix of illogically distributed subnets. This is a situation that switching alone cannot cure. Instead, the router is ooded with cross-subnet communication. This compromises efciency in two ways: Routers can be slower than switches. The cross-subnet side trip from the switch to the router and back again adds two hops for the data, slowing throughput considerably. Trafc to the router increases, increasing congestion.
Even if every end-station could be moved to better logical subnets (a daunting task), competition for access to common server pools on different subnets still burdens the routers. This problem is solved by using Nortel Application Switches with built-in IP routing capabilities. Cross-subnet LAN trafc can now be routed within the application switches with wire speed Layer 2 switching performance. This not only eases the load on the router but saves the network administrators from reconguring each and every end-station with new IP addresses.
.
Take a closer look at the Nortel Application Switch in the following conguration example:
Switch-Based Routing Topology
The Nortel Application Switch connects the Gigabit Ethernet and Fast Ethernet trunks from various switched subnets throughout one building. Common servers are placed on another subnet attached to the switch. A primary and backup router are attached to the switch on yet another subnet. Without Layer 3 IP routing on the switch, cross-subnet communication is relayed to the default gateway (in this case, the router) for the next level of routing intelligence. The router lls in the necessary address information and sends the data back to the switch, which then relays the packet to the proper destination subnet using Layer 2 switching. With Layer 3 IP routing in place on the Nortel Application Switch, routing between different IP subnets can be accomplished entirely within the switch. This leaves the routers free to handle inbound and outbound trafc for this group of subnets. To make implementation even easier, UDP Jumbo frame trafc is automatically fragmented to regular Ethernet frame sizes when routing to non-Jumbo frame VLANS or subnets. This automatic frame conversion allows servers to communicate using Jumbo frames, all transparently to the user.
Example of Subnet Routing

Prior to conguring, you must be connected to the switch Command Line Interface (CLI) as the administrator.
.
Basic IP Routing 113
Note: For details about accessing and using any of the menu commands described in this example, see the Nortel Application Switch Operating System Command Reference. Step 1 Action Assign an IP address (or document the existing one) for each real server, router, and client workstation. In the example topology in "Switch-Based Routing Topology" (page 112), the following IP addresses are used:
Subnet Routing Example: IP Address Assignments Subnet 1 2 3 4 Devices Primary and Secondary Default Routers First Floor Client Workstations Second Floor Client Workstations Common Servers IP Addresses 205.21.17.1 and 205.21.17.2 100.20.10.2-254 131.15.15.2-254 206.30.15.2-254
Assign an IP interface for each subnet attached to the switch. Since there are four IP subnets connected to the switch, four IP interfaces are needed:
Subnet Routing Example: IP Interface Assignments Interface IF 1 IF 2 IF 3 IF 4 Devices Primary and Secondary Default Routers First Floor Client Workstations Second Floor Client Workstations Common Servers IP Interface Address 205.21.17.3 100.20.10.1 131.15.15.1 206.30.15.1
IP interfaces are congured using the following commands at the CLI:

>> # /cfg/l3/if 1 addr ena (Select IP interface 1) (Assign IP address for the interface) (Enable IP interface 1)
>> IP Interface 1# 205.21.17.3 >> IP Interface 1#
.
>> IP Interface 1# 2 >> IP Interface 2# 100.20.10.1 >> IP Interface 2# >> IP Interface 2# 3 >> IP Interface 3# 131.15.15.1 >> IP Interface 3# >> IP Interface 3# 4 >> IP Interface 4# 206.30.15.1 >> IP Interface 4#
/cfg/l3/if addr ena /cfg/l3/if addr ena /cfg/l3/if addr ena
(Select IP interface 2) (Assign IP address for the interface) (Enable IP interface 2) (Select IP interface 3) (Assign IP address for the interface) (Enable IP interface 3) (Select IP interface 4) (Assign IP address for the interface) (Enable IP interface 5)
Set each server and workstations default gateway to the appropriate switch IP interface (the one in the same subnet as the server or workstation). Congure the default gateways to the routers addresses. Conguring the default gateways allows the switch to send outbound trafc to the routers:
>> IP Interface 5# 1 /cfg/l3/gw addr ena (Select primary default gateway) ( Assign IP address for primary router) (Enable primary default gateway) (Select secondary default gateway) addr ena (Assign address for secondary router) ( Enable secondary default gateway)
>> Default gateway 1# 205.21.17.1 >> Default gateway 1# >> Default gateway 1# /cfg/l3/gw 2 >> Default gateway 2# 205.21.17.2 >> Default gateway 2#
Enable, apply, and verify the conguration.

>> Default gateway 2# /cfg/l3/fwrd >> IP Forwarding# on (Select the IP Forwarding Menu) (Turn IP forwarding on)
.
>> IP Forwarding# >> IP Forwarding#
apply /cfg/l3/cur
(Make your changes active) (View current IP settings)
Examine the resulting information. If any settings are incorrect, make the appropriate changes. 6 Save your new conguration changes.
>> IP# save (Save for restore after reboot)
End
Using VLANs to Segregate Broadcast Domains

In the previous example, devices that share a common IP network are all in the same broadcast domain. If you want to limit the broadcasts on your network, you could use VLANs to create distinct broadcast domains. For example, as shown in the following procedure, you could create one VLAN for the client trunks, one for the routers, and one for the servers. In this example, you are adding to the previous conguration. Step 1 Action Determine which switch ports and IP interfaces belong to which VLANs. The following table adds port and VLAN information:
Subnet Routing Example: Optional VLAN Ports VLAN 1 Devices First Floor Client Workstations Second Floor Client Workstations 2 Primary Default Router Secondary Default Router 3 Common Servers 1 Common Servers 2 IP Interface 2 3 1 1 4 4 Switch Port 1 2 3 4 5 6 VLAN # 1 1 2 2 3 3
Add the switch ports to their respective VLANs.


.
The VLANs shown in "Subnet Routing Example: Optional VLAN Ports" (page 115) are congured as follows:
>> # /cfg/l2/vlan 1 add port 1 add port 2 ena /cfg/l2/vlan 2 add port 3 add port 4 ena /cfg/l2/vlan 3 add port 5 add port 6 ena (Select VLAN 1) (Add port for 1st floor to VLAN 1) (Add port for 2nd floor to VLAN 1) (Enable VLAN 1) (Select VLAN 2) (Add port for default router 1) (Add port for default router 2) (Enable VLAN 2) (Add port for default router 3) (Select VLAN 3) (Select port for common server 1) (Enable VLAN 3)
>> VLAN 1# >> VLAN 1# >> VLAN 1# >> VLAN 1# >> VLAN 2# >> VLAN 2# >> VLAN 2# >> VLAN 2# >> VLAN 3# >> VLAN 3# >> VLAN 3#
Each time you add a port to a VLAN, you may get the following prompt:
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 interface for each subnet must be placed in the appropriate VLAN. From "Subnet Routing Example: Optional VLAN Ports" (page 115), the settings are made as follows:
>> VLAN 3# /cfg/l3/if 1 vlan 2 /cfg/l3/if vlan 1 (Select IP interface 1 for def. routers) (Set to VLAN 2) (Select IP interface 2 for first floor) (Set to VLAN 1)
>> IP Interface 1# >> IP Interface 1# 2 >> IP Interface 2#
.
>> IP Interface 2# 3 >> IP Interface 3# >> IP Interface 3# 4 >> IP Interface 4#
/cfg/l3/if vlan 1 /cfg/l3/if vlan 3
(Select IP interface 3 for second floor) (Set to VLAN 1) (Select IP interface 4 for servers) (Set to VLAN 3)

>> IP Interface 5# >> IP Interface 5# /info/l2/vlan >> Layer 2# /info/port apply (Make your changes active) (View current VLAN information) (View current port information)
>> Information# save (Save for restore after reboot)
End
Dening IP Address Ranges for the Local Route Cache

A local route cache lets you use switch resources more efciently. The local network address and local network mask parameters (accessed via the /cfg/l3/frwd/local/add command) dene a range of addresses that are cached on the switch. The local network address is used to dene the base IP address in the range that will be cached. The local network mask is applied to produce the range. To determine if a route should be added to the memory cache, the destination address is masked (bit-wise AND) with the local network mask and checked against the local network address. By default, the local network address and local network mask are both set to 0.0.0.0. This produces a range that includes all Internet addresses for route caching: 0.0.0.0 through 255.255.255.255. To limit the route cache to your local hosts, you could congure the parameters as shown in the following example:
.
118 Part 2: IP Routing Local Routing Cache Address Ranges Local Host Address Range 0.0.0.0 - 127.255.255.255 128.0.0.0 - 128.255.255.255 205.32.0.0 - 205.32.255.255 Local Network Address 0.0.0.0 128.0.0.0 205.32.0.0 Local Network Mask 128.0.0.0 128.0.0.0 or 255.0.0.0 255.255.0.0
Note: Static routes must be congured within the congured range. All other addresses that fall outside the dened range are forwarded to the default gateway.
Dynamic Host Conguration Protocol

Dynamic Host Conguration Protocol (DHCP) is a transport protocol that provides a framework for automatically assigning IP addresses and conguration information to other IP hosts or clients in a large TCP/IP network. Without DHCP, the IP address must be entered manually for each network device. DHCP allows a network administrator to distribute IP addresses from a central point and automatically send a new IP address when 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 able to dynamically allocate reusable network addresses and conguration parameters for client operation. Built on the client/server model, DHCP allows hosts or clients on an IP network to obtain their congurations from a DHCP server, thereby reducing network administration. The most signicant conguration the client receives from the server is its required IP address; (other optional parameters include the "generic" le name to be booted, the address of the default gateway, and so forth). Nortel Networks DHCP relay agent eliminates the need to have DHCP/BOOTP servers on every subnet. It allows the administrator to reduce the number of DHCP servers deployed on the network and to centralize them. Without the DHCP relay agent, there must be at least one DHCP server deployed at each subnet that has hosts needing to perform the DHCP request.
DHCP Relay Agent

DHCP is described in RFC 2131, and the DHCP relay agent supported on Nortel Application Switches is described in RFC 1542. DHCP uses UDP as its transport protocol. The client sends messages to the server on port 67 and the server sends messages to the client on port 68.
.
DHCP denes the methods through which clients can be assigned an IP address for a nite lease period and allowing reassignment of the IP address to another client later. Additionally, DHCP provides the mechanism for a client to gather other IP conguration parameters it needs to operate in the TCP/IP network. In the DHCP environment, the Nortel Application Switch acts as a relay agent. The DHCP relay feature (/cfg/l3/bootp) enables the switch to forward a client request for an IP address to two BOOTP servers with IP addresses that have been congured on the switch. When a switch receives a UDP broadcast on port 67 from a DHCP client requesting an IP address, the switch acts as a proxy for the client, replacing the client source IP (SIP) and destination IP (DIP) addresses. The request is then forwarded as a UDP Unicast MAC layer message to two BOOTP servers whose IP addresses are congured on the switch. The servers respond as a a UDP Unicast message back to the switch, with the default gateway and IP address for the client. The destination IP address in the server response represents the interface address on the switch that received the client request. This interface address tells the switch on which VLAN to send the server response to the client.
DHCP Relay Agent Conguration

To enable the Nortel Application Switch to be the BOOTP forwarder, you need to congure the DHCP/BOOTP server IP addresses on the switch. Generally, you should congure the command on the switch IP interface closest to the client so that the DHCP server knows from which IP subnet the newly allocated IP address should come. The following gure shows a basic DHCP network example:
DHCP Relay Agent Conguration
In this Nortel Application Switch implementation, there is no need for primary or secondary servers. The client request is forwarded to the BOOTP servers congured on the switch. The use of two servers provide failover redundancy. However, no health checking is supported. Use the following commands to congure the switch as a DHCP relay agent:
.
>> #
/cfg/l3/bootp addr addr2 on off cur (Set IP address of BOOTP server) (Set IP address of 2nd BOOTP server) (Globally turn BOOTP relay on) (Globally turn BOOTP relay off) (Display current configuration)
>> Bootstrap Protocol Relay# >> Bootstrap Protocol Relay# >> Bootstrap Protocol Relay# >> Bootstrap Protocol Relay# >> Bootstrap Protocol Relay#
Additionally, DHCP Relay functionality can be assigned on a per interface basis. Use the following command to enable the Relay functionality:
>> #/cfg/l3/if <interface number> /relay ena
Gratuitous ARP (GARP) Command

Gratuitous ARP packets are used to force a next-hop router to learn an IP and MAC pair. For security reasons, this command can only be used for an IP address belonging to a VIP, PIP, or Interface. Use the GARP command as follows:
>> Main#/oper/ip/garp <IP Address> <VLAN Number>
Static Routes
A switch has two basic mechanisms for learning networking routes. The primary mechanism is through the use of routing protocols like the Routing Information Protocol (RIP) and Open Shortest Path First (OSPF) protocol. Routes learned in this manner are often referred to dynamic routes because they are updated periodically by the routing protocols to reect the current conditions in the network. For more information on these protocols and their use, refer to "Routing Information Protocol" (page 126) and "Open Shortest Path First (OSPF)" (page 146). Switches also learn networking routes through static routes. Static routes are manually entered into the switch by an administrator. Although whole networks could be built upon static routes, they do not have the capacity to change without user intervention and therefore do not adequately represent the every changing reality of an enterprise network. It is because of this that static routes have an important but limited role in the enterprise network. Typically static routes are used in situations when a protocol like RIP or OSPF cannot provide the information necessary to create connectivity between two nodes.
.
For example, a node in a network that is running OSPF may need to know the route to a node in a network that is not running OSPF. OSPF would not be able to provide information about either network to its counterpart. In this situation, a static route should be used to provide connectivity. The Nortel Application Switch supports both IPv4 and IPv6 static routes through the Layer 3 conguration menu. Up to 128 IPv4 and 128 IPv6 static routes are supported.
IPv4 Static Routes

IPv4 static routes are used to support static connectivity to an IPv4 network. IPv4 static routes are added to the switch using the /cfg/l3/route/ip4/add command. This command has the following syntax:
>> 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 following syntax:
>> Main#/cfg/l3/route/ip4/rem <destination> <mask>
The IPv4 static routes that are currently part of the switch conguration can be displayed using the /cfg/l3/route/ip4/cur command. This command has no parameters.
IPv6 Static Routes

IPv6 static routes are used to support static connectivity to an IPv6 network. IPv6 static routes are conceptually identical to their IPv4 counterparts and only differ in the addressing format used. For information about IPv6 concepts 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 the following 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 following syntax:
.
>> Main#/cfg/l3/route/ip6/rem <destination> <prefix length> <next hop>
The IPv6 static routes that are currently part of the switch conguration can be displayed using the /cfg/l3/route/ip6/cur command. This command has no parameters.
.
IPv6 123
IPv6
IPv6, or Internet Protocol version 6, is a network layer protocol intended to expand the network address spaces of IPv4. IPv6 will differ in a number of ways from IPv4 that makes it more robust and expandable protocol as the need for physical address space goes up. IPv6 was mainly conceived as a protocol to help alleviate the shortage of available network addresses. Currently, IPv4 supports the creation and use of approximately 4 billion IP addresses. IPv6 expands the number of available addresses to approximately 3.4 x 1038. IPv6 is dened in RFC 2373, RFC 2460, and RFC 2461. The Nortel Application Switch Operating System 24.0 supports IPv6 in a number of different areas. Refer to the individual feature sections for details on the level of support. This section describes the basic conguration and management of IPv6 on the switch.
IPv6 Address Format

The IPv6 address is 128 bits long and is represented as a sequence of eight 16-bit hex values, separated by colons. The preferred format is xxxx: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 contiguous sequence of zeros can be compressed to :: (double colon). For example, the address of FE80:0:0:0:2AA:FF:FA:4CA2 can be compressed to FE80::2AA:FF:FA:4CA2. Unlike IPv4, a subnet mask is not used for IPv6 addresses. IPv6 uses prex length for network identier. For example,
21DA:D300:0000:2F3C::/64
where 64 is the network prex.
IPv6 Address Types

There are three types of IPv6 addresses: unicast, multicast, and anycast.
Unicast Address
There are two types of unicast addresses: Global Unicast address: An address that can be reached and identied globally.
.
Global Unicast addresses use the high-order bit range from 2000 to 3FFF. If the last 64 bits of the address are not congured, Nortel Application Switch Operating System will default automatically to utilize the EUI-64 (Extended Unique Identier 64-bit) address format. RFC 3513 denes the expanding of the Ethernet MAC address based on a 48-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 a neighbor on the same link. Link-local addresses use the high-order bit range from FE80 to FEBF. Link-local unicast addresses are automatically congured on the interface by using the link-local prex FE80::/10 and the interface identier in EUI-64 format for its low-order 64-bit. Link-local packets are not routed between subnets.
Multicast
A multicast address (FF00 - FFFF) is an identier for a group interface. The multicast address most often encountered is a solicited-mode multicast address using prex FF02::1:FF00:0000/104 with the low-order 24 bits of the unicast or anycast address.
Anycast
Anycast addresses can be global unicast, site-local or link-local addresses used for a one-to-nearest node member of the anycast group communication. Nortel Application Switch Operating System does not support anycast addresses.
Pinging IPv6 Addresses

The 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 unicast address.
>> IP6 Neighbor Discovery Protocol# ping6 fe80::20d:56 ff:fe22:df09 Enter interface number: (1-256) 200 fe80:0:0:0:20d:56ff:fe22:df09 is alive
.
IPv6 125
Verifying IPv6 Conguration

To verify IPv6 conguration, 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 Statistics

To 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 track of available routes. Routers can learn about available routes dynamically using the Routing Information Protocol (RIP). Nortel Application Switch Operating System software supports RIP version 1 (RIPv1) and RIP version 2 (RIPv2) for exchanging TCP/IP route information with other routers.
Distance Vector Protocol

RIP is known as a distance vector protocol. The vector is the network number and next hop, and the distance is the cost associated with the network number. RIP identies network reachability based on cost, and cost is dened as hop count. One hop is considered to be the distance from one switch to the next which is typically 1. This cost or hop count is known as the metric. When a switch receives a routing update that contains a new or changed destination network entry, the switch adds 1 to the metric value indicated in the update and enters the network in the routing table. The IP address of the sender is used as the next hop.
Stability
RIP includes a number of other stability features that are common to many routing protocols. For example, RIP implements the split horizon and hold-down mechanisms to prevent incorrect routing information from being propagated. RIP prevents routing loops from continuing indenitely by implementing a limit on the number of hops allowed in a path from the source to a destination. The maximum number of hops in a path is 15. The network destination network is considered unreachable if increasing the metric value by 1 causes the metric to be 16 (that is innity). This limits the maximum diameter of a RIP network to less than 16 hops. RIP is often used in stub networks and in small autonomous systems that do not have many redundant paths.
Routing Updates
RIP sends routing-update messages at regular intervals and when the network topology changes. Each router " advertises" routing information by sending a routing information update every 30 seconds. If a router doesnt receive an update from another router for 180 seconds, those routes provided by that router are declared invalid. After another 120 seconds without receiving an update for those routes, the routes are removed from the routing table and respective regular updates.
.
127
When a router receives a routing update that includes changes to an entry, it updates its routing table to reect the new route. The metric value for the 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 metric value) to a destination. For more information see the Conguration Menu, Routing Information Protocol Conguration (/cfg/l3/rip) in the Nortel Application Switch Operating System 24.0 Command Reference (NN47220-105).
RIPv1
RIP version 1 uses broadcast User Datagram Protocol (UDP) data packets for the regular routing updates. The main disadvantage is that the routing updates do not carry subnet mask information. Hence, the router cannot determine whether the route is a subnet route or a host route. It is of limited usage after the introduction of RIPv2. For more information about RIPv1 and RIPv2, refer to RFC 1058 and RFC 2453.
RIPv2
RIPv2 is the most popular and preferred conguration for most networks. RIPv2 expands the amount of useful information carried in RIP messages and provides a measure of security. For a detailed explanation of RIPv2, refer to RFC 1723 and RFC 2453. RIPv2 improves efciency by using multicast UDP (address 224.0.0.9) data packets for regular routing updates. Subnet mask information is provided in the routing updates. A security option is added for authenticating routing updates, by using a shared password. Nortel Application Switch Operating System 24.0 supports using clear text passwords for RIPv2.
RIP Version 2 Enhancements

RIP 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 mode

Nortel Application Switch Operating System 24.0 allows for RIPv2 conguration RIPv1compatibility mode to use both RIPv2 and RIPv1 routers within a network. In this mode, the regular routing updates use broadcast UDP data packet to allow RIPv1 routers to receive those packets. With
.
RIPv1 routers as recipients, the routing updates have to carry natural or host mask. Hence, it is not a recommended conguration for most network topologies. Note: When using both RIPv1 and RIPv2 within a network, use a single subnet mask throughout the network.
RIP Features
Nortel Application Switch Operating System 24.0 provides the following features to support RIPv1 and RIPv2:
Poison
Simple split horizon in the RIP scheme omits routes learned from one neighbor in updates sent to that neighbor. That is the most common conguration used in RIP network topology. Split horizon with poisoned reverse includes such routes in updates, but sets their metrics to 16. The disadvantage of using this feature is the increase of size in the routing updates. So, it is recommended to disable split horizon with poisoned reverse.
Triggered updates
Triggered updates are an attempt to speed up convergence. When Triggered Updates is enabled, whenever a router changes the metric for a route, it sends update messages almost immediately, without waiting for the regular update interval. It is recommended to enable Triggered Updates.
Multicast
RIPv2 messages use IP multicast address (224.0.0.9) for periodic broadcasts. Multicast RIPv2 announcements are not processed by RIPv1 routers. To congure RIPv2 in RIPv1 compatibility mode, set multicast to DISABLE.
Default
The RIP router can listen and supply a default route, usually represented as 0.0.0.0 in the routing table. When a router does not have an explicit route to a destination network in its routing table, it uses the default route to forward those packets.
Metric
The metric eld contains a congurable value between 1 and 15 which species the current metric for the interface. The metric value typically indicates the total number of hops to the destination. The metric value of 16 represents an unreachable destination.
.
129
Authentication
RIPv2 authentication uses clear text passwords for authentication. If congured using Authentication password, then it is necessary to enter an authentication key value. The following method is used to authenticate a RIP message: If the router is not congured to authenticate RIPv2 messages, then RIPv1 and unauthenticated RIPv2 messages are accepted; authenticated RIPv2 messages are discarded. If the router is congured to authenticate RIPv2 messages, then RIPv1 messages and RIPv2 messages which pass authentication testing are accepted; unauthenticated and failed authentication RIPv2 messages are discarded.
For maximum security, RIPv1 messages are ignored when authentication is enabled. If not, the routing information from authenticated messages is propagated by RIPv1 routers in an unauthenticated manner.
RIP Conguration Example

Note: A disabled RIP interface uses all the default values of the RIP, no matter how the RIP parameters are congured for that interface. RIP sends out RIP regular updates to include an UP interface, but not a DOWN interface. Step 1 Action Add VLANs for routing interfaces.
>> Main# cfg/l2/vlan 2/ena >> VLAN 2# add 2 (Enable VLAN 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 >> VLAN 3# add 3 (Enable VLAN 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
Add IP interfaces to VLANs.

>> Main# cfg/l3/if 2/ena >> IP Interface 2# addr 102.1.1.1 >> IP Interface 2# vlan 2 (Enable interface 2) (Define IP address for interface 2) (Add interface 2 to VLAN 2)
.
>> IP Interface 2# /cfg/l3/if 3/ena >> IP Interface 3# addr 103.1.1.1 >> IP Interface 3# vlan 3
(Enable interface 3) (Define IP address for interface 3) (Add interface 3 to VLAN 3)
Turn on RIP globally and enable RIP for each interface.

>> Main# cfg/l3/rip on >> Routing Information Protocol# if 2/ena >> RIP Interface 2# .. >> Routing Information Protocol# if 3/ena >> RIP Interface 3# apply >> RIP Interface 3# save (Enable RIP on IP interface 3) (Apply your changes) (Save the configuration) (Turn on RIP globally) (Enable RIP on IP interface 2)
Use the /maint/route/dump command to check the current valid routes 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 congured static routes do not appear in the RIP Routes table. End
.
Border Gateway Protocol
131

Border Gateway Protocol (BGP) is an Internet protocol that enables routers on a network to share and advertise routing information with each other about the segments of the IP address space they can access within their network and with routers on external networks. BGP allows you to decide what is the "best" route for a packet to take from your network to a destination on another network rather than simply setting a default route from your border router(s) to your upstream provider(s). BGP is dened in RFC 1771. Nortel Application Switches can advertise their IP interfaces and virtual server IP addresses using BGP and take BGP feeds from as many as 16 BGP router peers. This allows more resilience and exibility in balancing trafc from the Internet. The following topics are addressed in this chapter: "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 Conguration" (page 139) "Default Redistribution and Route Aggregation Example" (page 143)
BGP-based Global Server Load Balancing utilizes the Internets routing protocols to localize content delivery to the most efcient and consistent site. For more information on BGP-based GSLB, see "Using Border Gateway Protocol for GSLB" (page 767).
Internal Routing Versus External Routing

To ensure effective processing of network trafc, every router on your network needs to know how to send a packet (directly or indirectly) to any other location/destination in your network. This is referred to as internal routing and can be done with static routes or using active, internal dynamic routing protocols, such as RIP, RIPv2, and OSPF.
.
Static routes, should have a higher degree of precedence than dynamic routing protocols. If the destination route is not in the route cache, then the packets are forwarded to the default gateway which may be incorrect if a dynamic routing protocol is enabled. It is also useful to tell routers outside your network (upstream providers or peers) about the routes you can access in your network. External networks (those outside your own) that are under the same administrative control are referred to as autonomous systems (AS). Sharing of routing information between autonomous systems is known as external routing. External BGP (eBGP) is used to exchange routes between different autonomous systems whereas internal BGP (iBGP) is used to exchange routes within the same autonomous system. An iBGP is a type of internal routing protocol you can use to do active routing inside your network. It also carries AS path information, which is important when you are an ISP or doing BGP transit. Note: The iBGP peers must be part of a fully meshed network, as shown in "iBGP and eBGP" (page 132).
iBGP and eBGP
Typically, an AS has one or more border routerspeer routers that exchange routes with other ASsand an internal routing scheme that enables routers in that AS to reach every other router and destination within that AS. When you advertise routes to border routers on other autonomous systems, you are effectively committing to carry data to the IP space represented in the route being advertised. For example, if you advertise 192.204.4.0/24, you are declaring that if another router sends you data destined for any address in 192.204.4.0/24, you know how to carry that data to its destination.
.
133
Forming BGP Peer Routers

Two BGP routers become peers or neighbors once you establish a TCP connection between them. For each new route, if a peer is interested in that route (for example, if a peer would like to receive your static routes and the new route is static), an update message is sent to that peer containing the new route. For each route removed from the route table, if the route has already been sent to a peer, an update message containing the route to withdraw is sent to that peer. For each Internet host, you must be able to send a packet to that host, and that host has to have a path back to you. This means that whoever provides Internet connectivity to that host must have a path to you. Ultimately, this means that they must "hear a route" which covers the section of the IP space you are using; otherwise, you will not have connectivity to the host in question.
What is a Route Map?

A route map is used to control and modify routing information. Route maps dene conditions for redistributing routes from one routing protocol to another or controlling routing information when injecting it in and out of BGP. Route maps are used by OSPF only for redistributing routes. For example, a route map is used to set a preference value for a specic route from a peer router and another preference value for all other routes learned via the same peer router. For example, the following command is used to dene a route map:
>> # /cfg/l3/rmap 1 (Select a route map)
A route map allows you to match attributes, such as metric, network address, and AS number. It also allows users to overwrite the local preference metric and to append the AS number in the AS route. See "BGP Failover Conguration" (page 139). The Nortel Application Switch Operating System allows you to congure 32 route maps. Each route map can have up to eight access lists. Each access list consists of a network lter. A network lter denes an IP address and subnet mask of the network that you want to include in the lter. "Distributing Network Filters in Access Lists and Route Maps" (page 134) illustrates the relationship between route maps, access lists and network lters.
.
134 Part 2: IP Routing Distributing Network Filters in Access Lists and Route Maps
Incoming and Outgoing Route Maps

You can have two types of route maps: incoming and outgoing. A BGP peer router can be congured to support up to eight route maps in the incoming route map list and outgoing route map list. If a route map is not congured in the incoming route map list, the router imports all BGP updates. If a route map is congured in the incoming route map list, the router ignores all unmatched incoming updates. Route maps in an outgoing route map list behave similar to route maps in an incoming route map list. If a route map is not congured in the outgoing route map list, all routes are advertised or permitted. If a route map is congured in the outgoing route map list, matched routes are advertised and unmatched routes are ignored.
Precedence
You can set a priority to a route map by specifying a precedence value with the following command:
>> /cfg/l3/rmap <x> /pre (Specify a precedence)
.
135
The smaller the value the higher the precedence. If two route maps have the same precedence value, the smaller number has higher precedence.
Conguration Overview
To congure route maps, you need to do the following: Step 1 Action Dene network lter.
>> # /cfg/l3/nwf 1 >> IP Network Filter 1# addr <IP address> >> IP Network Filter 1# mask <IP mask> >> IP Network Filter 1# ena (Specify a network filter number) (Specify network address) (Specify network mask) (Enable network filter)
Enter a lter number from 1 to 256. Specify the IP address and subnet mask of the network that you want to match. Enable the network lter. You can distribute up to 256 network lters among 32 route maps each containing eight access lists. 2 (Optional) Dene the criteria for the access list and enable it. Specify the access list and associate the network lter number congured in Step 1.
>> # /cfg/l3/rmap 1 >> IP Route Map 1# alist 1 >> IP Access List 1# nwf 1 >> IP Access List 1# metric >> IP Access List 1# action deny >> IP Access List 1# ena (Specify a route map number) (Specify the access list number) (Specify the network filter number) (Define a metric) (Specify action for the access list) (Enable the access list)
Steps 2 and 3 are optional, depending on the criteria that you want to match. In Step 2, the network lter number is used to match the subnets dened in the network lter. In Step 3, the autonomous system number is used to match the subnets. Or, you can use both (Step 2 and Step 3) criteria: access list (network lter) and access path (AS lter) to congure the route maps.
.
(Optional) Congure the attributes in the AS lter menu.

>> # cfg/l3/rmap 1/aspath 1 >> AS Filter 1# as 1 >> AS Filter 1# action deny >> AS Filter 1# ena (Specify the attributes in the filter) (Specify the AS number) (Specify the action for the filter) (Enable the AS filter)
Set up the BGP attributes. If you want to overwrite the attributes that the peer router is sending, then dene the following BGP attributes: Specify the AS numbers that you want to prepend to a matched route and the local preference for the matched route. Specify the metric [Multi Exit Discriminator (MED)] for the matched route.
>> # /cfg/l3/rmap 1 >> IP Route Map 1# ap >> IP Route Map 1# lp >> IP Route Map 1# med (Specify a route map number) (Specify the AS numbers to prepend) (Specify the local preference) (Specify the metric)
Enable the route map.

>> # /cfg/l3/rmap 1/en (Enable the route map)
Assign the route map to a peer router. Select the peer router and then add the route map to the incoming route map list,
>> # /cfg/l3/bgp/peer 1/addi (Add to the incoming route map)
or to the outgoing route map list.

>> # /cfg/l3/bgp/peer 1/addo (Add to the outgoing route map)
.
137
End
Aggregating Routes
Aggregation is the process of combining several different routes in such a way that a single route can be advertised, which minimizes the size of the routing table. You can congure aggregate routes in BGP either by redistributing an aggregate route into BGP or by creating an aggregate entry in the BGP routing table. When a subnet is redistributed from an Interior Gateway Protocol (IGP) into BGP, only the network route is injected into the BGP table. By default, this automatic summarization is disabled. To dene the route to aggregate, use the following commands:
>> # /cfg/l3/bgp >> Border Gateway Protocol# aggr 1 >> BGP aggr 1 # addr >> BGP aggr 1 # mask >> BGP aggr 1 # ena (Specify BGP) (Specify aggregate list number) (Enter aggregation network address) (Enter aggregation network mask) (Enable aggregation)
An example of creating a BGP aggregate route is shown in "Default Redistribution and Route Aggregation Example" (page 143).
Redistributing Routes
In addition to running multiple routing protocols simultaneously, the Nortel Application Switch Operating System software can redistribute information from one routing protocol to another. For example, you can instruct the switch to use BGP to readvertise static routes. This applies to all of the IP-based routing protocols. You can also conditionally control the redistribution of routes between routing domains by dening a method known as route maps between the two domains. For more information on route maps, see "What is a Route Map?" (page 133). Redistributing routes is another way of providing policy control over whether to export OSPF routes, xed routes, static routes, and virtual IP address routes. For an example conguration, see "Default Redistribution and Route Aggregation Example" (page 143). Default routes can be congured using the following methods: Import
.
OriginateThe router sends a default route to peers even though it does not have any default routes in its routing table. RedistributeDefault routes are either congured through the default gateway or learned via other protocols and redistributed to peer routers. If the default routes are from the default gateway, enable the static routes because default routes from the default gateway are static routes. Similarly, if the routes are learned from another routing protocol, make sure you enable that protocol for redistribution. None
BGP Attributes
The following two BGP attributes are discussed in this section: Local preference and metric (Multi-Exit Discriminator).
Local Preference Attribute

When there are multiple paths to the same destination, the local preference attribute indicates the preferred path. The path with the higher preference is preferred (the default value of the local preference attribute is 100). Unlike the weight attribute, which is only relevant to the local router, the local preference attribute is part of the routing update and is exchanged among routers 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, affecting the outbound direction only. /cfg/l3/rmap/lp This command uses the route map local preference method, which affects both inbound and outbound directions.
Metric (Multi-Exit Discriminator) Attribute

This attribute is a hint to external neighbors about the preferred path into an AS when there are multiple entry points. A lower metric value is preferred over 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 is used for decision making within the AS. When BGP sends that update to another AS, the metric is reset to 0. Unless otherwise specied, the router compares metric attributes for paths from external neighbors that are in the same AS.
.
139
Selecting Route Paths in BGP

BGP selects only one path as the best path. It does not rely on metrics attributes to determine the best path. When the same network is learned via more than one BGP peer, BGP uses its policy for selecting the best route to that network. The BGP implementation on the Nortel Application Switches uses the following criteria to select a path when the same route is received from multiple peers. Step 1 2 3 Action Local xed and static routes are preferred over learned routes. With iBGP peers, routes with higher local preference values are selected. In the case of multiple routes of equal preference, the route with lower AS path weight is selected. AS path weight = 128 x AS path length (number of autonomous systems transversed). 4 In the case of equal weight and routes learned from peers that reside in the same AS, the lower metric is selected. Note: A route with a metric is preferred over a route without a metric. 5 6 7 The lower cost to the next hop of routes is selected. In the case of equal cost, the eBGP route is preferred over iBGP. If all routes are from eBGP, the route with the lower router ID is selected. When the path is selected, BGP puts the selected path in its routing table and propagates the path to its neighbors. End
BGP Failover Conguration

Use the following example to create redundant default gateways for an Nortel Application Switch at a Web Host/ISP site, eliminating the possibility, should one gateway go down, that requests is forwarded to an upstream router unknown to the switch.
.
As shown in "BGP Failover Conguration Example" (page 140), the switch is connected to ISP 1 and ISP 2. The customer negotiates with both ISPs to allow the Application switch to use their peer routers as default gateways. The ISP peer routers will then need to announce themselves as default gateways to the Application switch.
BGP Failover Conguration Example
On the Application switch, one peer router (the secondary one) is congured with a longer AS path than the other, so that the peer with the shorter AS path will be seen by the switch as the primary default gateway. ISP 2, the secondary peer, is congured with a metric of "3," thereby appearing to the switch to be three router hops away. Step 1 Action Congure the switch as you normally would for Server Load Balancing (SLB). Assign an IP address to each of the real servers in the server pool. Dene each real server. Dene a real server group. Dene a virtual server. Dene the port conguration.
.
141
For more information about SLB conguration, refer to "Server Load Balancing" (page 188)." 2 Dene the VLANs. For simplicity, both default gateways are congured in the same VLAN in this example. The gateways could be in the same VLAN or different VLANs.
>> # /cfg/l2/vlan 1 >> vlan 1# add <port number> (Select VLAN 1) (Add a port to the VLAN membership)
Dene the IP interfaces. The switch needs an IP interface for each default gateway to which it is connected. Each interface needs to be placed in the appropriate VLAN. These interfaces is used as the primary and secondary default gateways for the switch.
>> /cfg/l3/arp/rearp 10 >> IP# /cfg/l3/metric strict >> IP# if 1 >> IP Interface 1# ena >> IP Interface 1# addr 200.200.200.1 >> IP Interface 1# mask 255.255.255.0 >> IP Interface 1# /cfg/l3/if 2 >> IP Interface 2# ena >> IP Interface 2# addr 210.210.210.1 >> IP Interface 2# mask 255.255.255.0 (Set re-ARP period for interface to 10) (Set metric for default gateway) (Select default gateway interface 1) (Enable switch interface 1) (Configure IP address of interface 1) (Configure IP subnet address mask) (Select default gateway interface 2) (Enable switch interface 2) (Configure IP address of interface 2) (Configure IP subnet address mask)
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 default gateways are on different subnets or if the switch is connected to different subnets and those subnets need to communicate through the 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 disabled by default. 5 Globally turn on BGP.
>> # /cfg/l3/bgp/on
Congure BGP peer router 1 and 2. Peer 1 is the primary gateway router. Peer 2 is congured with a metric of 3. The metric option is key to ensuring gateway trafc is directed to Peer 1, as it makes Peer 2 appear to be three router hops away from the switch. Thus, the switch should never use it unless Peer 1 goes down.
>> # /cfg/l3/bgp/peer 1 >> BGP Peer 1# ena >> BGP Peer 1# addr 200.200.20 0.2 >> BGP Peer 1# if 200.200.200.1 >> BGP Peer 1# ras 100 >> BGP Peer 1# /cfg/l3/bgp/peer 2 >> BGP Peer 2# ena >> BGP Peer 2# addr 210.210.21 0.2 >> BGP Peer 2# if 210.210.210.1 >> BGP Peer 2# ras 200 >> BGP Peer 2# metric 3 (Select BGP peer router 1) (Enable this peer configuration) (Set IP address for peer router 1) (Set IP interface for peer router 1) (Set remote AS number) (Select BGP peer router 2) (Enable this peer configuration) (Set IP address for peer router 2) (Set IP interface for peer router 2) (Set remote AS number) (Set AS path length to 3 router hops)
.
143
The metric command in the peer menu tells the Nortel Application Switch to create an AS path of "3" when advertising via BGP. 7 On the switch, apply and save your conguration changes.
>> BGP Peer 2# apply >> save (Make your changes active) (Save for restore after reboot)
End
Default Redistribution and Route Aggregation Example

This example shows you how to congure the switch to redistribute information from one routing protocol to another and create an aggregate route entry in the BGP routing table to minimize the size of the routing table. As illustrated in "Route Aggregation and Default Route Redistribution" (page 143), you have two peer routers: an internal and an external peer router. Congure the Nortel Application Switch to redistribute the default routes from AS 200 to AS 135. At the same time, congure for route aggregation to allow you to condense the number of routes traversing from AS 135 to AS 200.
Route Aggregation and Default Route Redistribution
Step 1
Action Congure the IP interface.
.
Congure 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 have to be an IP address. However, for convenience, this id is typically one of IP addresses assigned in IP interfaces.
>> # /cfg/l3/bgp >> Border Gateway Protocol# as 135 (Select the BGP menu) (Specify an AS number)
>> Border Gateway Protocol# /cfg/l3/rtrid 10.1.1.135 (Specify the router ID number)
Congure internal peer router 1 and external peer router 2.

>> # /cfg/l3/bgp/peer 1 >> BGP Peer 1# ena >> BGP Peer 1# addr 10.1.1.4 >> BGP Peer 1# ras 135 >> BGP Peer 1# /cfg/l3/bgp/peer 2 >> BGP Peer 2# ena >> BGP Peer 2# addr 20.20.20.2 >> BGP Peer 2# ras 200 (Select internal peer router 1) (Enable this peer configuration) (Set IP address for peer router 1) (Set remote AS number) (Select external peer router 2) (Enable this peer configuration) (Set IP address for peer router 2) (Set remote AS number)
Congure redistribution for Peer 1.

>> # /cfg/l3/bgp/peer 1/redist >> BGP Peer 1# default redistribute >> BGP Peer 1# fixed ena (Select redistribute) (Set default to redistribute) (Enable fixed routes)
Congure aggregation policy control. Congure the routes that you want aggregated.
.
145
>> # /cfg/l3/bgp/aggr 1 >> BGP Aggr 1# addr 135.0.0.0 >> BGP Aggr 1# mask 255.0.0.0 >> BGP Aggr 1# ena
(Set aggregation number) (Add IP address to aggregate 1) (Add IP mask to aggregate 1) (Enable route aggregation)

>> # apply >> # save
End
.
Open Shortest Path First (OSPF)

Nortel Application Switch Operating System supports the Open Shortest Path First (OSPF) routing protocol. The Nortel Application Switch Operating System implementation conforms to the OSPF version 2 specications detailed in Internet RFC 1583. The following topics are addressed in this chapter: "OSPF Overview" (page 146). This section provides information on OSPF concepts, such as types of OSPF areas, types of routing devices, neighbors, adjacencies, link state database, authentication, and internal versus external routing. "OSPF Implementation" (page 151). This section describes how OSPF is implemented in Nortel Application Switch Operating System, such as conguration parameters, electing the designated router, summarizing routes, dening route maps and so forth. "OSPF Conguration Examples" (page 164). This section provides step-by-step instructions on conguring four different conguration examples: Creating a simple OSPF domain Creating virtual links Summarizing routes Creating host routes
OSPF Overview
OSPF is designed for routing trafc within a single IP domain called an Autonomous System (AS). The AS can be divided into smaller logical units known 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 not exchanged between different areas. Only routing updates are exchanged between areas, thereby signicantly reducing the overhead for maintaining routing information on a large, dynamic network. The following sections describe key OSPF concepts.
.
147
Equal Cost Multipath Routing Support

Equal-cost multipath (ECMP) is a routing technique for routing packets along multiple paths of equal cost. The routing table contains multiple next-hops for any given destination. The router load balances packets along the multiple next-hops. Nortel Application Switch Operating System supports ECMP, and there are no CLI additions or changes.
Types of OSPF Areas

An AS can be broken into logical units known as areas. In any AS with multiple areas, one area must be designated as area 0, known as the backbone. The backbone acts as the central OSPF area. All other areas in the AS must be connected to the backbone. Areas inject summary routing information into the backbone, which then distributes it to other areas as needed. As shown in "OSPF Area Types" (page 148), OSPF denes the following types of areas: Stub Areaan area that is connected to only one other area. External route information is not distributed into stub areas. Not-So-Stubby-Area (NSSA)similar to a stub area with additional capabilities. Routes originating from within the NSSA can be propagated to adjacent transit and backbone areas. External routes from outside the AS can be advertised within the NSSA but are not distributed into other areas. Transit Areaan area that allows area summary information to be exchanged between routing devices. The backbone (area 0), any area that contains a virtual link to connect two areas, and any area that is not a stub area or an NSSA are considered transit areas.
.
148 Part 2: IP Routing OSPF Area Types
Types of OSPF Routing Devices

As 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 the same area. IRs maintain LSDBs identical to those of other routing devices within the local area. Area Border Router (ABR)a router that has interfaces in multiple areas. ABRs maintain one LSDB for each connected area and disseminate routing information between areas. Autonomous System Boundary Router (ASBR)a router that acts as a gateway between the OSPF domain and non-OSPF domains, such as RIP, BGP, and static routes.
.
Open Shortest Path First (OSPF) OSPF Domain and an Autonomous System
149
Neighbors and Adjacencies

In areas with two or more routing devices, neighbors and adjacencies are formed. Neighbors are routing devices that maintain information about each others health. To establish neighbor relationships, routing devices periodically send hello packets on each of their interfaces. All routing devices that share a common network segment, appear in the same area, and have the same health parameters (hello and dead intervals) and authentication parameters respond to each others hello packets and become neighbors. Neighbors continue to send periodic hello packets to advertise their health to neighbors. In turn, they listen to hello packets to determine the health of their neighbors and to establish contact with new neighbors. The hello process is used for electing one of the neighbors as the areas Designated Router (DR) and one as the areas Backup Designated Router (BDR). The DR is adjacent to all other neighbors and acts as the central contact for database exchanges. Each neighbor sends its database information to the DR, which relays the information to the other neighbors. The BDR is adjacent to all other neighbors (including the DR). Each neighbor 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 DR fails, the BDR takes over the task of distributing database information to the other neighbors.
.
The Link-State Database

OSPF is a link-state routing protocol. A link represents an interface (or routable path) from the routing device. By establishing an adjacency with the DR, each routing device in an OSPF area maintains an identical Link-State Database (LSDB) describing the network topology for its area. Each routing device transmits a Link-State Advertisement (LSA) on each of its interfaces. LSAs are entered into the LSDB of each routing device. OSPF uses ooding to distribute LSAs between routing devices. When LSAs result in changes to the routing devices LSDB, the routing device 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 of periodically. For each new route, if an adjacency is interested in that route (for example, if congured to receive static routes and the new route is indeed static), an update message containing the new route is sent to the adjacency. For each route removed from the route table, if the route has already been sent to an adjacency, an update message containing the route to withdraw is sent.
The Shortest Path First Tree

The routing devices use a link-state algorithm (Dijkstras algorithm) to calculate the shortest path to all known destinations, based on the cumulative cost required to reach the destination. The cost of an individual interface in OSPF is an indication of the overhead required to send packets across it. The cost is inversely proportional to the bandwidth of the interface. A lower cost indicates a higher bandwidth.
Internal Versus External Routing

To ensure effective processing of network trafc, every routing device on your network needs to know how to send a packet (directly or indirectly) to any other location/destination in your network. This is referred to as internal routing and can be done with static routes or using active internal routing protocols, such as OSPF, RIP, or RIPv2. It is also useful to tell routers outside your network (upstream providers or peers) about the routes you have access to in your network. Sharing of routing information between autonomous systems is known as external routing.
.
151
Typically, an AS has one or more border routers (peer routers that exchange routes with other OSPF networks) as well as an internal routing system enabling every router in that AS to reach every other router and destination within that AS. When a routing device advertises routes to boundary routers on other autonomous systems, it is effectively committing to carry data to the IP space represented in the route being advertised. For example, if the routing device advertises 192.204.4.0/24, it is declaring that if another router sends data destined for any address in the 192.204.4.0/24 range, it will carry that data to its destination.
OSPF Implementation
Nortel Application Switch Operating System supports a single instance of OSPF and up to 4 K routes on the network. The following sections describe OSPF implementation in Nortel Application Switch Operating System: "Congurable Parameters" (page 151) "Dening 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" (page 160)
Congurable Parameters
In Nortel Application Switch Operating System, OSPF parameters can be congured through the Command Line Interface (CLI)
The CLI supports the following parameters: interface output cost, interface priority, dead and hello intervals, retransmission interval, and interface transmit delay. In addition to the above parameters, you can also specify the following: Shortest Path First (SPF) intervalTime interval between successive calculations of the shortest path tree using the Dijkstras algorithm. Stub area metricA stub area can be congured to send a numeric metric value such that all routes received via that stub area carry the congured metric to potentially inuence routing decisions.
.
Default routesDefault routes with weight metrics can be manually injected into transit areas. This helps establish a preferred route when multiple routing devices exist between two areas. It also helps route trafc to external networks.
Dening Areas
If you are conguring multiple areas in your OSPF domain, one of the areas must be designated as area 0, known as the backbone. The backbone is the central OSPF area and is usually physically connected to all other areas. 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 a contiguous area. If the backbone is partitioned (possibly as a result of joining separate OSPF networks), parts of the AS will be unreachable, and you will need to congure virtual links to reconnect the partitioned areas (see "Virtual Links" (page 156)). Up to three OSPF areas can be connected to the Nortel Application Switch with Nortel Application Switch Operating System software. To congure an area, the OSPF number must be dened and then attached to a network interface on the switch. The full process is explained in the following sections. An OSPF area is dened by assigning two pieces of informationan area index and an area ID. The command to dene 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 the switch and does not represent the actual OSPF area number. The actual OSPF area number is dened in the areaid portion of the command as explained in the following sections.
Assigning the Area Index

The aindex <area index> option is actually just an arbitrary index (0-2) used only by the switch. This index does not necessarily represent the OSPF area number, though for conguration simplicity, it should where possible. For example, both of the following sets of commands dene OSPF area 0 (the backbone) and area 1 because that information is held in the area ID portion of the command. However, the rst set of commands is easier to maintain because the arbitrary area indexes agree with the area IDs: Area index and area ID agree
.
153
/cfg/l3/ospf/aindex 0/areaid 0.0.0.0 /cfg/l3/ospf/aindex 1/areaid 0.0.0.1
(Use index 0 to set area 0 in ID octet format) (Use index 1 to set area 1 in ID octet format)
Area index set to an arbitrary value

/cfg/l3/ospf/aindex 1/areaid 0.0.0.0 /cfg/l3/ospf/aindex 2/areaid 0.0.0.1 (Use index 1 to set area 0 in ID octet format) (Use index 2 to set area 1 in ID octet format)
Using the Area ID to Assign the OSPF Area Number

The OSPF area number is dened in the areaid <IP address> option. The octet format is used in order to be compatible with two different systems of notation used by other OSPF network vendors. There are two valid ways to 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 single number. For example, the Cisco IOS-based router command "network 1.1.1.0 0.0.0.255 area 1" denes 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 can be specied directly on the Nortel Application Switch as "areaid 2.2.2.2". Note: Although both types of area ID formats are supported, be sure that the area IDs are in the same format throughout an area.
Attaching an Area to a Network

Once an OSPF area has been dened, it must be associated with a network. To attach the area to a network, you must assign the OSPF area index to an IP interface that participates in the area. The format for the command is as follows:
>> # /cfg/l3/ospf/if <interface number> /aindex <area index>
For example, the following commands could be used to congure IP interface 14 for a presence on the 10.10.10.1/24 network, to dene OSPF area 1, and to attach the area to the network:
.
>> # /cfg/l3/if 14 >> IP Interface 14# addr 10.10.10.1 >> IP Interface 14# mask 255.255.2 55.0 >> IP Interface 14# ena >> IP Interface 14# /cfg/l3/ospf/a index 1 >> OSPF Area (index) 1 # areaid 0.0.0.1 >> OSPF Area (index) 1 # ena >> OSPF Area (index) 1 # /cfg/l3/ ospf/if 14 >> OSPF Interface 14# aindex 1 >> OSPF Interface 14# enable
(Select menu for IP interface 14) (Define IP address on backbone network) (Define IP mask on backbone) (Enable IP interface 14) (Select menu for area index 1) (Define area ID as OSPF area 1) (Enable area index 1) (Select OSPF menu for interface 14) (Attach area to network on interface 14) (Enable interface 14 for area index 1)
Interface Cost
The OSPF link-state algorithm (Dijkstras algorithm) places each routing device at the root of a tree and determines the cumulative cost required to reach each destination. Usually, the cost is inversely proportional to the bandwidth of the interface. Low cost indicates high bandwidth. You can manually enter the cost for the output route with the following command:
>> # /cfg/l3/ospf/if <OSPF interface number> /cost <cost value (1-65535)>
Electing the Designated Router and Backup

In 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 election can be inuenced by assigning a priority value to the OSPF interfaces on the Nortel Application Switch. The command is as follows:
>> # /cfg/l3/ospf/if <OSPF interface number> /prio <priority value (0-255)>
.
155
A priority value of 255 is the highest, and 1 is the lowest. A priority value of 0 species that the interface cannot be used as a DR or BDR. In case of a tie, the routing device with the highest router ID wins.
Summarizing Routes
Route summarization condenses routing information. Without summarization, each routing device in an OSPF network would retain a route to every subnet in the network. With summarization, routing devices can reduce some sets of routes to a single advertisement, reducing both the load on the routing device and the perceived complexity of the network. The importance of route summarization increases with network size. Summary routes can be dened for up to 16 IP address ranges using the following command:
>> # /cfg/l3/ospf/range <range number> /addr <IP address> /mask <mask>
where <range number> is a number 1 to 16, <IP address> is the base IP address for the range, and <mask> is the IP address mask for the range. For a detailed conguration example, see "Example 3: Summarizing Routes" (page 173).
Default Routes
When an OSPF routing device encounters trafc for a destination address it does not recognize, it forwards that trafc along the default route. Typically, the default route leads upstream toward the backbone until it reaches the intended area or an external router. Each Nortel Application Switch acting as an ABR automatically inserts a default route into each attached area. In simple OSPF stub areas or NSSAs with only one ABR leading upstream (see Area 1 in "Injecting Default Routes" (page 156)), any trafc for IP address destinations outside the area is forwarded to the switchs IP interface, and then into the connected transit area (usually the backbone). Since this is automatic, no further conguration is required for such areas.
.
156 Part 2: IP Routing Injecting Default Routes
In more complex OSPF areas with multiple ABRs or ASBRs (such as area 0 and area 2 in "Injecting Default Routes" (page 156)), there are multiple routes leading from the area. In such areas, trafc for unrecognized destinations cannot tell which route leads upstream without further conguration. To resolve the situation and select one default route among multiple choices in an area, you can manually congure a metric value on each ABR. The metric assigns a priority to the ABR for its selection as the priority default route in an area. The following command is used for setting the metric value:
>> # /cfg/l3/ospf/default <metric value> <metric type (1 or 2)>
where <metric value> sets the priority for choosing this switch for default route. The value none sets no default and 1 sets the highest priority for default route. Metric type determines the method for inuencing routing decisions for external routes. To clear a default route metric from the switch, use the following command:
>> # /cfg/l3/ospf/default none
Virtual Links
Usually, 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. Virtual links are created to connect one area to the backbone through another non-backbone area (see "OSPF Area Types" (page 148)).
.
157
The area which contains a virtual link must be a transit area and have full routing information. Virtual links cannot be congured inside a stub area or NSSA. The area type must be dened as transit using the following command:
>> # /cfg/l3/ospf/aindex <area index> /type transit
The virtual link must be congured on the routing devices at each endpoint of the virtual link, though they may traverse multiple routing devices. To congure a Nortel Application Switch as one endpoint of a virtual link, use the 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 the OSPF area index of the transit area, and <router ID> is the IP address of the virtual neighbor (nbr), the routing device at the target endpoint. Another router ID is needed when conguring a virtual link in the other direction. To provide the Nortel Application Switch with a router ID, see the following section "Router ID" (page 157). For a detailed conguration example on Virtual Links, see "Example 2: Virtual Links" (page 167).
Router ID
Routing devices in OSPF areas are identied by a router ID. The router ID is expressed in IP address format. The IP address of the router ID is not required to be included in any IP interface range or in any OSPF area. The router ID can be congured in one of the following two ways: DynamicallyOSPF protocol congures the lowest IP interface IP address as the router ID. This is the default. StaticallyUse the following command to manually congure the router ID:
>> # /cfg/l3/rtrid <IP address>
To modify the router ID from static to dynamic, set the router ID to 0.0.0.0, save the conguration, and reboot the Nortel Application Switch. To view the router ID, enter:
>> # /info/l3/ospf/gen
.
Authentication
OSPF protocol exchanges can be authenticated so that only trusted routing devices can participate. This ensures less processing on routing devices that are not listening to OSPF packets. OSPF allows packet authentication and uses IP multicast when sending and receiving packets. Routers participate in routing domains based on predened passwords. Nortel Application Switch Operating System supports simple password (type 1 plain text passwords) and MD5 cryptographic authentication. This type of authentication allows a password to be congured per area. "OSPF Authentication" (page 158) shows authentication congured for area 0 with the password test. Simple authentication is also congured for the virtual link between area 2 and area 0. Area 1 is not congured for OSPF authentication.
OSPF Authentication
To congure simple plain text OSPF passwords on the Nortel Application Switches shown in "OSPF Authentication" (page 158) use the following commands: Step 1 Action Enable OSPF authentication for Area 0 on Nortel Application Switches 1, 2, and 3.
>> # /cfg/l3/ospf/aindex 0/auth password (Turn on OSPF password authentication)
Congure a simple text password up to eight characters for each OSPF IP interface in Area 0 on Nortel Application Switches 1, 2, and 3.

.
159
>> >> >> >> >> >>
# /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
Enable OSPF authentication for Area 2 on Nortel Application Switch 4.

>> # /cfg/l3/ospf/aindex 2/auth password (Turn on OSPF password authentication)
Congure a simple text password up to eight characters for the virtual link between Area 2 and Area 0 on Nortel Application Switches 2 and 4.
>> # /cfg/l3/ospf/virt 1/key alteon
Use the following commands to congure MD5 authentication on the Nortel Application Switches shown in "OSPF Authentication" (page 158): End
Step 1
Action Enable OSPF MD5 authentication for Area 0 on Nortel Application Switches 1, 2, and 3.
>> # /cfg/l3/ospf/aindex 0/auth md5 (Turn on MD5 authentication)
Congure MD5 key ID for Area 0 on Nortel Application Switches 1, 2, and 3.

>> # /cfg/l3/ospf/md5key 1/key test
Assign MD5 key ID to OSPF interfaces on Nortel Application Switches 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
Enable OSPF MD5 authentication for Area 2 on Nortel Application Switch 4.

>> # /cfg/l3/ospf/aindex 2/auth md5
Congure MD5 key for the virtual link between Area 2 and Area 0 on Nortel Application Switches 2 and 4.
>> # /cfg/l3/ospf/md5key 2/key alteon
Assign MD5 key ID to OSPF virtual link on Nortel Application Switches 2 and 4.
>> # /cfg/l3/ospf/virt 1/mdkey 2
End
Host Routes for Load Balancing

Nortel Application Switch Operating System implementation of OSPF includeshost routes. Host routes are used for advertising network device IP addresses 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 the server pools in an OSPF environment. For more information on SLB, see "Server Load Balancing" (page 188) " and your Nortel Application Switch Operating System Command Reference. ABR Load Sharing As a second form of load balancing, host routes can be used for dividing OSPF trafc among multiple ABRs. To accomplish this, each application switch provides identical services but advertises a host route for a different virtual server IP address to the external network. If each virtual server IP address serves a different and equal portion of the external world, incoming trafc from the upstream router should be split evenly among ABRs.
.
161
ABR Failover Complementing ABR load sharing, identical host routes can be congured on each ABR. These host routes can be given different costs so that a different ABR is selected as the preferred route for each virtual server 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 defaults to the OSPF-derived route. For a conguration example, see "Example 4: Host Routes" (page 176).
Redistributing Routes into OSPF

Nortel Application Switch Operating System software allows your switch to emulate an ASBR by redistributing information from other routing protocols (static, RIP, iBGP, eBGP, and xed routes) into OSPF. For information on ASBR, see "Types of OSPF Routing Devices" (page 148). For example, you can instruct OSPF to readvertise a RIP-derived route into OSPF as an AS-External LSA. Based on this LSA, other routers in the OSPF routing domain 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 xed. By default, these protocol routes are not redistributed into OSPF. Use one of the following three methods to redistribute the routes of a particular protocol into OSPF: Exporting all the routes of the protocol Using route maps Route maps allow you to control the redistribution of routes between routing domains. For conceptual information on route maps, see "What is 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 Routes

To redistribute all routes of a protocol, use the following command:
/cfg/l3/ospf/redist <protocol name> /export <metric> <metric type>
.
where metric sets the OSPF cost for the route and metric type (either 1 or 2) determines whether the routes cost includes or excludes external costs of the route. If you want to remove a previous conguration to export all the routes 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 Routes

Use route maps to specify which routes of the protocol that you want exported into OSPF. "Commands for Using Route MapsRoute Maps" (page 162) shows the tasks that you can perform using route maps.
Route Maps Task Adding a route map for a particular protocol Adding all 32 route maps Removing a route map for a particular protocol Removing all 32 route maps for a particular protocol Command /cfg/l3/ospf/redist <protocol name> /add <route map numbers> /cfg/l3/ospf/redist <protocol name> /add all /cfg/l3/ospf/redist <protocol name> /rem <route map numbers> /cfg/l3/ospf/redist <protocol name> /rem all
OSPF does not require you to set all the elds in the route map menu. However, set the following parameters in the route maps and network lter menu: Step 1 Action Enable the route map.
/cfg/l3/rmap <route map number> /ena
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 the routes of that protocol match any of the routes in the access lists, and if action is set to permit, then those routes are redistributed into OSPF using the metric and metric type assigned for that route map. Metric sets the priority for choosing this switch for default route.
.
163
Enable the access list.

/cfg/l3/rmap <route map number> /alist <access list number> /ena
Set the action to permit for the access list.

/cfg/l3/rmap <route map number> /alist <access list number> /action permit
To redistribute routes matched by the route map, the action in the alist must be set to permit. If the action is set to deny the routes matched by the route map is not be redistributed. 5 Link a network lter to the access list.
/cfg/l3/rmap <route map number> /alist <access list number> /nwf <network filter number>
Enable the network lter.

/cfg/l3/nwf <network filter number> /ena
Specify the IP address and mask for the network lter.

/cfg/l3/nwf 1/addr <IP address> /mask <IP mask>
End
Optional Parameters for Route Maps

Set the following optional parameters (metric type and metric) for route redistribution into OSPF: Step 1 Action Assign the metric type in the AS-External LSA.
/cfg/l3/rmap <route map number> /type [1|2]
Metric type determines the method for inuencing routing decisions for 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 for the route. End
Exporting All Routes Except a Few Selected Routes

This method is a combination of the previous two methods. The basic steps to congure this method are outlined below: Step 1 Action Congure OSPF to export all routes of the protocol using the export command as described in the rst method ( "Exporting All Routes" (page 161) ). Use route maps to congure routes to be denied by setting the action in the access list of the route map to deny. The conguration of the route map is similar to that described in the second method except that the action is set to deny. End
OSPF Features Not Supported in This Release

The following OSPF features are not supported in this release: Summarizing external routes Filtering OSPF routes Using OSPF to forward multicast routes Conguring OSPF on non-broadcast multi-access networks (such as frame relay, X.25, and ATM)
OSPF Conguration Examples

A summary of the basic steps for conguring OSPF on the Nortel Application Switch is listed here. Detailed instructions for each of the steps is covered in the following sections:
.
165
Step 1
Action Congure IP interfaces. One IP interface is required for each desired network (range of IP addresses) being assigned to an OSPF area on the Nortel Application Switch.
(Optional) Congure the router ID. The router ID is required only when conguring virtual links on the Nortel Application Switch.
3 4 5
Enable OSPF on the switch. Dene the OSPF areas. Congure OSPF interface parameters. IP interfaces are used for attaching networks to the various areas.
6 7 8
(Optional) Congure route summarization between OSPF areas. (Optional) Congure virtual links. (Optional) Congure host routes. End
Example 1: Simple OSPF Domain

In this example, two OSPF areas are denedone area is the backbone and the other is a stub area. A stub area does not allow advertisements of external routes, thus reducing the size of the database. Instead, a default summary route of IP address 0.0.0.0 is automatically inserted into the stub area. Any trafc for IP address destinations outside the stub area is forwarded to the stub areas IP interface, and then into the backbone.
A Simple OSPF Domain
.
Follow this procedure to congure OSPF support as shown in "A Simple OSPF Domain" (page 165): Step 1 Action Congure IP interfaces on each network that is attached to OSPF areas. In this example, two IP interfaces are needed: one for the backbone network on 10.10.7.0/24 and one for the stub area network on 10.10.12.0/24.
>> # /cfg/l3/if 1 >> IP Interface 1 # addr 10.10.7.1 >> IP Interface 1 # mask 255.255.255.0 >> IP Interface 1 # enable >> IP Interface 1 # /cfg/l3/if 2 >> IP Interface 2 # addr 10.10.12.1 >> IP Interface 2 # mask 255.255.255.0 >> IP Interface 2 # enable (Select menu for IP interface 1) (Set IP address on backbone network) (Set IP mask on backbone network) (Enable IP interface 1) (Select menu for IP interface 2) (Set IP address on stub area network) (Set IP mask on stub area network) (Enable IP interface 2)
Enable OSPF.
>> IP Interface 2 # /cfg/l3/os pf/on (Enable OSPF on the Nortel Application Switch)
Dene the backbone. The backbone is always congured as a transit area using areaid 0.0.0.0.
>> Open Shortest Path First # aindex 0 >> OSPF Area (index) 0 # areaid 0.0.0.0 >> OSPF Area (index) 0 # type transit >> OSPF Area (index) 0 # enable (Select menu for area index 0) (Set the ID for backbone area 0) (Define backbone as transit type) (Enable the area)
.
167
Dene the stub area.

>> OSPF Area (index) 0 # /cfg/l3/ospf/aindex 1(Select menu for area index 1) >> OSPF Area (index) 1 # areaid 0.0.0.1 >> OSPF Area (index) 1 # type stub >> OSPF Area (index) 1 # enable (Set the area ID for OSPF area 1) (Define area as stub type) (Enable the area)
Attach the network interface to the backbone.

>> OSPF Area 1 # /cfg/l3/ospf/i f 1 >> OSPF Interface 1 # aindex 0 >> OSPF Interface 1 # enable (Select OSPF menu for IP interface 1) (Attach network to backbone index) (Enable the backbone interface)
Attach the network interface to the stub area.

>> OSPF Interface 1 # /cfg/l3/ospf/if 2 >> OSPF Interface 2 # aindex 1 >> OSPF Interface 2 # enable (Select OSPF menu for IP interface 2) (Attach network to stub area index) (Enable the stub area interface)
Apply and save the conguration changes.

>> OSPF Interface 2 # apply >> OSPF Interface 2 # save (Global command to apply all changes) (Global command to save all changes)
End
Example 2: Virtual Links

In the example shown in "Conguring a Virtual Link" (page 168), area 2 is not 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 congured at each endpoint.
.
168 Part 2: IP Routing Conguring a Virtual Link
Conguring OSPF for a Virtual Link on Switch 1

Step 1 Action Congure IP interfaces on each network that is attached to the switch. In this example, two IP interfaces are needed on Switch #1: one for the backbone network on 10.10.7.0/24 and one for the transit area network on 10.10.12.0/24.
>> # /cfg/l3/if 1 >> IP Interface 1 # addr 10.10.7.1 >> IP Interface 1 # mask 255.255.255.0 >> IP Interface 1 # enable >> IP Interface 1 # /cfg/l3/if 2 >> IP Interface 2 # addr 10.10.12.1 >> IP Interface 2 # mask 255.255.255.0 >> IP Interface 2 # enable (Select menu for IP interface 1) (Set IP address on backbone network) (Set IP mask on backbone network) (Enable IP interface 1) (Select menu for IP interface 2) (Set IP address on transit area network) (Set IP mask on transit area network) (Enable interface 2)
Congure the router ID. A router ID is required when conguring virtual links. Later, when conguring the other end of the virtual link on Nortel Application Switch 2, the router ID specied here is used as the target virtual neighbor (nbr) address.
>> IP Interface 2 # /cfg/l3/rt rid 10.10.10.1 (Set static router ID on Nortel Application Switch 1)
.
169
Enable OSPF.
>> IP # /cfg/l3/ospf/on (Enable OSPF on Nortel Application Switch 1)
Dene the backbone.

>> Open Shortest Path First # aindex 0 >> OSPF Area (index) 0 # areaid 0.0.0.0 >> OSPF Area (index) 0 # type transit >> OSPF Area (index) 0 # enable (Select menu for area index 0) (Set the area ID for backbone area 0) (Define backbone as transit type) (Enable the area)
Dene the transit area. The area that contains the virtual link must be congured as a transit area.
>> OSPF Area (index) 0 # /cfg/l3/ospf/aindex 1(Select menu for area index 1) >> OSPF Area (index) 1 # areaid 0.0.0.1 >> OSPF Area (index) 1 # type transit >> OSPF Area (index) 1 # enable (Set the area ID for OSPF area 1) (Define area as transit type) (Enable the area)

>> OSPF Area (index) 1 # /cfg/l3/ospf/if 1 >> OSPF Interface 1 # aindex 0 >> OSPF Interface 1 # enable (Select OSPF menu for IP interface 1) (Attach network to backbone index) (Enable the backbone interface)
Attach the network interface to the transit area.
.
>> OSPF Interface 1 # /cfg/l3/ospf/if 2 >> OSPF Interface 2 # aindex 1 >> OSPF Interface 2 # enable
(Select OSPF menu for IP interface 2) (Attach network to transit area index) (Enable the transit area interface)
Congure the virtual link. The nbr router ID congured in this step must be the same as the router ID that is congured for Switch #2 in step 2.
>> OSPF Interface 2 # /cfg/l3/ospf/virt 1 >> OSPF Virtual Link 1 # aindex 1 >> OSPF Virtual Link 1 # nbr 10.10.14.1 >> OSPF Virtual Link 1 # enable (Specify a virtual link number) (Specify the transit area for the virtual link) (Specify the router ID of the recipient) (Enable the virtual link)

End
Conguring OSPF for a Virtual Link on Switch 2

Step 1 Action Congure IP interfaces on each network that is attached to OSPF areas. Two IP interfaces are needed on Switch #2: one for the transit area network on 10.10.12.0/24 and one for the stub area network on 10.10.24.0/24.
.
171
>> # /cfg/l3/if 1 >> IP Interface 1 # addr 10.10.12.2 >> IP Interface 1 # mask 255.255.255.0 >> IP Interface 1 # enable >> IP Interface 1 # /cfg/l3/if 2 >> IP Interface 2 # addr 10.10.24.1 >> IP Interface 2 # mask 255.255.255.0 >> IP Interface 2 # enable
(Select menu for IP interface 1) (Set IP address on transit area network) (Set IP mask on transit area network) (Enable IP interface 1) (Select menu for IP interface 2) (Set IP address on stub area network) (Set IP mask on stub area network) (Enable IP interface 2)
Congure the router ID. A router ID is required when conguring virtual links. This router ID should be the same one specied as the target virtual neighbor (nbr) on Nortel Application Switch 1 in Step 8.
>> IP Interface 2 # /cfg/l3/rt rid 10.10.14.1 (Set static router ID on Nortel Application Switch 2)
Enable OSPF.
>> IP# /cfg/l3/ospf/on (Enable OSPF on Nortel Application Switch 2)
Dene the backbone. This version of Nortel Application Switch Operating System requires that a backbone index be congured on the non-backbone end of the virtual link as follows:
>> Open Shortest Path First # aindex 0 >> OSPF Area (index) 0 # areaid 0.0.0.0 >> OSPF Area (index) 0 # enable (Select the menu for area index 0) (Set the area ID for OSPF area 0) (Enable the area)
Dene the transit area.
.
>> OSPF Area (index) 0 # /cfg/l3/ospf/aindex 1(Select menu for area index 1) >> OSPF Area (index) 1 # areaid 0.0.0.1 >> OSPF Area (index) 1 # type transit >> OSPF Area (index) 1 # enable (Set the area ID for OSPF area 1) (Define area as transit type) (Enable the area)
Dene the stub area.


>> OSPF Area (index) 2 # /cfg/l3/ospf/if 1 >> OSPF Interface 1 # aindex 1 >> OSPF Interface 1 # enable (Select OSPF menu for IP interface 1) (Attach network to transit area index) (Enable the transit area interface)
Attach the network interface to the transit area.

Congure the virtual link. The nbr router ID congured in this step must be the same as the router ID that was congured for Nortel Application Switch #1 in Step 2.
.
173
>> OSPF Interface 2 # /cfg/l3/ospf/virt 1 >> OSPF Virtual Link 1 # aindex 1 >> OSPF Virtual Link 1 # nbr 10.10.10.1 >> OSPF Virtual Link 1 # enable
(Specify a virtual link number) (Specify the transit area for the virtual link) (Specify the router ID of the recipient) (Enable the virtual link)
10

End
Other Virtual Link Options

You can use redundant paths by conguring multiple virtual links. Only the endpoints of the virtual link are congured. The virtual link path may traverse multiple routers in an area as long as there is a routable path between the endpoints.
Example 3: Summarizing Routes

By default, ABRs advertise all the network addresses from one area into another area. Route summarization can be used for consolidating advertised addresses and reducing the perceived complexity of the network. If the network IP addresses in an area are assigned to a contiguous subnet range, you can congure the ABR to advertise a single summary route that includes 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 IP addresses from 36.128.192.0 through 36.128.254.255 except for the routes in the range 36.128.200.0 through 36.128.200.255.
.
174 Part 2: IP Routing Summarizing Routes
Note: You can specify a range of addresses to prevent advertising by using the hide option. In this example, routes in the range 36.128.200.0 through 36.128.200.255 are kept private. Follow this procedure to congure OSPF support as shown in "Summarizing Routes" (page 174): Step 1 Action Congure IP interfaces for each network which is attached to OSPF areas.
>> # /cfg/l3/if 1 >> IP Interface 1 # addr 10.10.7.1 >> IP Interface 1 # mask 255.255.255.0 >> IP Interface 1 # ena >> IP Interface 1 # /cfg/l3/if 2 >> IP Interface 2 # addr 36.128.192.1 >> IP Interface 2 # mask 255.255.192.0 >> IP Interface 2 # ena (Select menu for IP interface 1) (Set IP address on backbone network) (Set IP mask on backbone network) (Enable IP interface 1) (Select menu for IP interface 2) (Set IP address on stub area network) (Set IP mask on stub area network) (Enable IP interface 2)
Enable OSPF.
>> IP Interface 2 # /cfg/l3/os pf/on (Enable OSPF on the Nortel Application Switch)
.
175
Dene the backbone.

Dene the stub area.


>> OSPF Area (index) 1 # /cfg/l3/ospf/if 1(Select OSPF menu for IP interface 1) >> OSPF Interface 1 # aindex 0 >> OSPF Interface 1 # enable (Attach network to backbone index) (Enable the backbone interface)

Congure route summarization by specifying the starting address and mask of the range of addresses to be summarized
.
>> OSPF Interface 2 # /cfg/l3/ospf/range 1 >> OSPF Summary Range 1 # addr 36.128.192.0 >> OSPF Summary Range 1 # mask 255.255.192.0 >> OSPF Summary Range 1 # aindex 0 >> OSPF Summary Range 1 # enable
(Select menu for summary range) (Set base IP address of summary range) (Set mask address for summary range) (Inject summary route into backbone) (Enable summary range)
Use the hide command to prevent a range of addresses from advertising to the backbone.
>> OSPF Interface 2 # /cfg/l3/ospf/range 2 >> OSPF Summary Range 2 # addr 36.128.200.0 >> OSPF Summary Range 2 # mask 255.255.255.0 >> OSPF Summary Range 2 # hide enable (Select menu for summary range) (Set base IP address) (Set mask address) (Hide the range of addresses)

>> OSPF Summary Range 2 # apply >> OSPF Summary Range 2 # save (Global command to apply all changes) (Global command to save all changes)
End
Example 4: Host Routes

The Nortel Application Switch Operating System implementation of OSPF includes host routes. Host routes are used for advertising network device IP addresses 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 "Conguring OSPF Host Routes" (page 177). Both Nortel Application Switches have access to servers with identical content and are congured with the same virtual server IP addresses: 10.10.10.1 and 10.10.10.2. Nortel Application Switch #1 is given a host
.
177
route with a low cost for virtual server 10.10.10.1 and another host route with a high cost for virtual server 10.10.10.2. Nortel Application Switch #2 is congured with the same hosts but with the costs reversed; one host route has a high cost for virtual server 10.10.10.1 and another has a low cost for virtual server 10.10.10.2. All four host routes are injected into the upstream router and advertised externally. Trafc comes in for both virtual server IP addresses (10.10.10.1 and 10.10.10.2). The upstream router sees that both addresses exist on both Nortel Application Switches and uses the host route with the lowest cost for each. Trafc for 10.10.10.1 goes to Nortel Application Switch #1 because its host route has the lowest cost for that address. Trafc for 10.10.10.2 goes to Nortel Application Switch #2 because its host route has the lowest cost. This effectively shares the load among ABRs. Both Nortel Application Switches then use standard server load balancing to distribute trafc among available real servers. In addition, if one of the Nortel Application Switches were to fail, the upstream routing device would forward the trafc to the ABR whose host route has the next lowest cost. In this example, the remaining Nortel Application Switch would assume the entire load for both virtual servers.
Conguring OSPF Host Routes
Conguring Host Routes on Nortel Application Switch 1

Step 1 Action Congure IP interfaces for each network that is attached to OSPF areas.
.
>> Virtual server 1 # /cfg/l3/if 1 >> IP Interface 1 # addr 10.10.10.5 >> IP Interface 1 # enable >> IP Interface 1 # /cfg/l3/if 2 >> IP Interface 2 # addr 100.100.100.40 >> IP Interface 2 # enable
(Select menu for IP interface 1) (Set IP address on backbone network) (Enable IP interface 1) (Select menu for IP interface 2) (Set IP address on stub area network) (Enable IP interface 2)
Congure basic SLB parameters. Nortel Application Switch 1 is connected to two real servers. Each real server is given an IP address and is placed in the same real server group.
>> # /cfg/slb/real 1 >> Real server 1 # rip 100.100.100.25 >> Real server 1 # ena >> Real server 1 # /cfg/slb/rea l 2 >> Real server 2 # rip 100.100.100.26 >> Real server 2 # ena >> Real server 2 # /cfg/slb/gr oup 1 >> Real server group 1 # add 1 >> Real server group 1 # add 2 >> Real server group 1 # enable >> Real server group 1 # /cfg/slb/on (Select menu for real server 1) (Set the IP address for real server 1) (Enable the real server) (Select menu for real server 2) (Set the IP address for real server 2) (Enable the real server) (Select menu for real server group 1) (Add real server 1 to group) (Add real server 2 to group) (Enable the group) (Turn SLB on)
Congure client and server processing on specic ports.

>> Layer 4# /cfg/slb/port 4 >> SLB Port 4 # client ena (Select switch port 4) (Enable client processing on Port 4)
.
179
>> SLB Port 4 # /cfg/slb/port 5 >> SLB Port 5 # server ena
(Select switch Port 5) (Enable server processing on Port 5)
Enable direct access mode.

>> Layer 4 Port 5# /cfg/slb/adv >> Layer 4 Advanced# direct ena >> Layer 4 Advanced# .. (Select the SLB advance menu) (Enable DAM) (Return to the SLB menu)
Congure the primary virtual server. Nortel Application Switch # 1 is preferred for virtual server 10.10.10.1.
>> Layer 4 # /cfg/slb/virt 1 >> Virtual server 1 # vip 10.10.10.1 >> Virtual server 1 # ena >> Virtual server 1 # service http >> Virtual server 1 http service # group 1 (Select menu for virtual server 1) (Set the IP address for virtual server 1) (Enable the virtual server) (Select menu for service on virtual server) (Use real server group 1 for http service)
Congure the backup virtual server. Nortel Application Switch # 1 acts as a backup for virtual server 10.10.10.2. Both virtual servers in this example are congured with the same real server group and provide identical services.
>> Virtual server 2 http service # /cfg/slb/virt 2(Select menu for virtual server 2) >> Virtual server 1 # vip 10.10.10.2 >> Virtual server 1 # ena >> Virtual server 1 # service http >> Virtual server 1 # group 1 (Set the IP address for virtual server 2) (Enable the virtual server) (Select menu for service on virtual server) (Use real server group 1 for http service)
.
Enable OSPF on Nortel Application Switch 1.

>> IP Interface 2 # /cfg/l3/osp f/ospf/on (Enable OSPF on Nortel Application Switch 1)
Dene the backbone.

Dene the stub area.

>> OSPF Area (index) 0 # /cfg/l3/ospf/aindex 1(Select menu for area index 1) >> OSPF Area (index) 1 # areaid 0.0.0.1 >> OSPF Area (index) 1 # type stub >> OSPF Area (index) 1 # enable (Set the ID for stub area 1) (Define area as stub type) (Enable the area)
10

11

>> OSPF Interface 1 # /cfg/l3/os pf/if 2 >> OSPF Interface 2 # aindex 1 >> OSPF Interface 2 # enable (Select OSPF menu for IP interface 2) (Attach network to stub area index) (Enable the stub area interface)
.
181
12
Congure host routes. One host route is needed for each virtual server on Nortel Application Switch 1. Since virtual server 10.10.10.1 is preferred for Nortel Application Switch 1, its host route has a low cost. Because virtual server 10.10.10.2 is used as a backup in case Nortel Application Switch 2 fails, its host route has a high cost. Note: You do not need to enable redistribution (/cfg/l3/ospf/redist) if you congure virtual server routes as host routes.
>> OSPF Interface 2 # /cfg/l3/ospf/host 1 >> OSPF Host Entry 1 # addr 10.10.10.1 >> OSPF Host Entry 1 # aindex 0 >> OSPF Host Entry 1 # cost 1 >> OSPF Host Entry 1 # enable >> OSPF Host Entry 1 # /cfg/l3/ospf/host 2 >> OSPF Host Entry 2 # addr 10.10.10.2 >> OSPF Host Entry 2 # aindex 0 >> OSPF Host Entry 2 # cost 100 >> OSPF Host Entry 2 # enable (Select menu for host route 1) (Set IP address same as virtual server 1) (Inject host route into backbone area) (Set low cost for preferred path) (Enable the host route) (Select menu for host route 2) (Set IP address same as virtual server 2) (Inject host route into backbone area) (Set high cost for use as backup path) (Enable the host route)
Note: When a service goes down, the corresponding host route is removed from advertising. 13 Apply and save the conguration changes.
>> OSPF Host Entry 2 # apply >> OSPF Host Entry 2 # save (Global command to apply all changes) (Global command to save all changes)
End
.
Conguring Host Routes on Nortel Application Switch 2

Step 1 Action Congure basic SLB parameters. Nortel Application Switch 2 is connected to two real servers. Each real server is given an IP address and is placed in the same real server group.
>> # /cfg/slb/real 1 >> Real server 1 # rip 100.100.100.27 >> Real server 1 # enable >> Real server 1 # /cfg/slb/real 2 >> Real server 2 # rip 100.100.100.28 >> Real server 2 # enable >> Real server 2 # /cfg/slb/grou p 1 >> Real server group 1 # add 1 >> Real server group 1 # add 2 >> Real server group 1 # enable >> Real server group 1 # /cfg/slb/on (Select menu for real server 1) (Set the IP address for real server 1) (Enable the real server) (Select menu for real server 2) (Set the IP address for real server 2) (Enable the real server) (Select menu for real server group 1) (Add real server 1 to group) (Add real server 2 to group) (Enable the group) (Turn SLB on)
Congure the virtual server parameters. The same virtual servers are congured as on Nortel Application Switch 1.
>> Layer 4 # /cfg/slb/virt 1 >> Virtual server 1 # vip 10.10.10.1 >> Virtual server 1 # enable >> Virtual server 1 # service http (Select menu for virtual server 1) (Set the IP address for virtual server 1) (Enable the virtual server) (Select menu for service on virtual server)
.
183
>> Virtual server 1 http service # group 1
(Use real server group 1 for http service)
>> Virtual server 2 http service # /cfg/slb/virt 2 (Select menu for virtual server 2) >> Virtual server 1 # vip 10.10.10.2 >> Virtual server 1 # enable >> Virtual server 1 # service http >> Virtual server 1 # group 1 (Set the IP address for virtual server 2) (Enable the virtual server) (Select menu for service on virtual server) (Use real server group 1 for http service)
Congure IP interfaces for each network that will be attached to OSPF areas.
>> Virtual server 1 # /cfg/l3/if 1 >> IP Interface 1 # addr 10.10.10.6 >> IP Interface 1 # enable >> IP Interface 1 # /cfg/l3/if 2 >> IP Interface 2 # addr 100.100.100.41 >> IP Interface 2 # enable (Select menu for IP Interface 1) (Set IP address on backbone network) (Enable IP interface 1) (Select menu for IP Interface 2) (Set IP address on stub area network) (Enable IP interface 2)
Enable OSPF on Nortel Application Switch #2.

>> IP Interface 2 # /cfg/l3/ospf /on (Enable OSPF on Nortel Application Switch #2)
Dene the backbone.

.
Dene the stub area.

>> OSPF Area (index) 0 # /cfg/l3/ospf/aindex 1(Select menu for area index 1) >> OSPF Area (index) 1 # areaid 0.0.0.1 >> OSPF Area (index) 1 # type stub >> OSPF Area (index) 1 # enable (Set the ID for stub area 1) (Define area as stub type) (Enable the area)


>> OSPF Interface 1 # /cfg/l3/os pf/if 2 >> OSPF Interface 2 # aindex 1 >> OSPF Interface 2 # enable (Select OSPF menu for IP interface 2) (Attach network to stub area index) (Enable the stub area interface)
Congure host routes. Host routes are congured just like those on Nortel Application Switch 1, except their costs are reversed. Since virtual server 10.10.10.2 is preferred for Nortel Application Switch 2, its host route has been given a low cost. Because virtual server 10.10.10.1 is used as a backup in case Nortel Application Switch 1 fails, its host route has been given a high cost.
>> OSPF Interface 2 # /cfg/l3/ospf/host 1 >> OSPF Host Entry 1 # addr 10.10.10.1 >> OSPF Host Entry 1 # aindex 0 (Select menu for host route 1) (Set IP address same as virtual server 1) (Inject host route into backbone area)
.
185
>> OSPF Host Entry 1 # cost 100 >> OSPF Host Entry 1 # enable >> OSPF Host Entry 1 # /cfg/l3/ospf/host 2 >> OSPF Host Entry 2 # addr 10.10.10.2 >> OSPF Host Entry 2 # aindex 0 >> OSPF Host Entry 2 # cost 1 >> OSPF Host Entry 2 # enable
(Set high cost for use as backup path) (Enable the host route) (Select menu for host route 2) (Set IP address same as virtual server 2) (Inject host route into backbone area) (Set low cost for primary path) (Enable the host route)
10

>> OSPF Host Entry 2 # apply >> OSPF Host Entry 2 # save (Global command to apply all changes) (Global command to save all changes)
End
Verifying OSPF Conguration

Use the following commands to verify the OSPF conguration on your switch: /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 Command Reference for information on the above commands.
.
.
187

Internet trafc consists of myriad services and applications which use the Internet Protocol (IP) for data delivery. IP, however, is not optimized for all the various applications. Application switching goes beyond IP and makes intelligent switching decisions based on the application and its data. This sections 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 congure the Nortel Application Switch to balance user session trafc among a pool of available servers that provide shared services. The following topics are addressed in this chapter: "Understanding Server Load Balancing" (page 188). This section discusses the benets of server load balancing and its operation. "Implementing Basic Server Load Balancing" (page 191). This section discusses how implementing SLB provides reliability, performance, and ease of maintenance on the network. "Content Intelligent Server Load Balancing" (page 210). This section discusses the implementation of content-based SLB. "Extending SLB Topologies" (page 227). This section discusses proxy IP addresses, mapping real to virtual ports, monitoring real server ports, and delayed binding. "Session Timeout Per Service" (page 245). This section discusses the conguration of the session timeout per service feature. "IPv6 and Server Load Balancing" (page 246). This section discusses the conguration and management of server load balancing and IPv6.
For additional information on SLB commands, Nortel Application Switch Operating System Command Reference.
Understanding Server Load Balancing

SLB benets your network in a number of ways: Increased efciency for server utilization and network bandwidth With SLB, your Nortel Application Switch is aware of the shared services provided by your server pool and can then balance user session trafc among the available servers. Important session trafc gets through more easily, reducing user competition for connections on overutilized servers. For even greater control, trafc is distributed according to a variety of user-selectable rules. Increased reliability of services to users If any server in a server pool fails, the remaining servers continue to provide access to vital applications and data. The failed server can be brought back up without interrupting access to services. Increased scalability of services
.
189
As users are added and the server pools capabilities are saturated, new servers can be added to the pool transparently.
Identifying Your Network Needs

SLB 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 servers capacity. When servers hold critical application data and must remain available even in the event of a server failure. Your Web site is being used as a way to do business and for taking orders from customers. It must not become overloaded or unavailable. You want to use multiple servers or hot-standby servers for maximum server uptime. You must be able to scale your applications to meet client and LAN request capacity. You cant afford to continue using an inferior load-balancing technique, such as DNS round robin or a software-only system.
How Server Load Balancing Works

In an average network that employs multiple servers without server load balancing, each server usually specializes in providing one or two unique services. If one of these servers provides access to applications or data that is in high demand, it can become overutilized. Placing this kind of strain on a server can decrease the performance of the entire network as user requests are rejected by the server and then resubmitted by the user stations. Ironically, over-utilization of key servers often happens in networks where other servers are actually available. The solution to getting the most from your servers is SLB. With this software feature, the switch is aware of the services provided by each server. The switch can direct user session trafc to an appropriate server, based on a variety of load-balancing algorithms.
.
190 Part 3: Application Switching Fundamentals Traditional Versus SLB Network Congurations
To provide load balancing for any particular type of service, each server in the pool must have access to identical content, either directly (duplicated on each server) or through a back-end network (mounting the same le system or database server). The Nortel Application Switch, with SLB software, acts as a front-end to the servers, interpreting user session requests and distributing them among the available servers. Load balancing in Nortel Application Switch Operating System can be done in the following ways: Virtual server-based load balancing This is the traditional load balancing method. The switch is congured to act as a virtual server and is given a virtual server IP address (or range of addresses) for each collection of services it distributes. Depending on your switch model, there can be as many as 1023 virtual servers on the switch, each distributing up to eight different services. Each virtual server is assigned a list of the IP addresses (or range of addresses) of the real servers in the pool where its services reside. When the user stations request connections to a service, they communicate with a virtual server on the switch. When the switch receives the request, it binds the session to the IP address of the best available real server and remaps the elds in each frame from virtual addresses to real addresses. HTTP, IP, FTP, RTSP, IDS, and static session WAP are examples of some of the services that use virtual servers for load balancing. Filtered-based load balancing A lter allows you to control the types of trafc permitted through the switch. Filters are congured to allow, deny, or redirect trafc according
.
191
to the IP address, protocol, or Layer 4 port criteria. In ltered-based load balancing, a lter is used to redirect trafc to a real server group. If the group is congured with more than one real server entry, redirected trafc is load balanced among the available real servers in the group. Firewalls, WAP with RADIUS snooping, IDS, and WAN links use redirection lters to load balance trafc. Content-based load balancing Content-based load balancing uses Layer 7 application data (such as URL, cookies, and Host Headers) to make intelligent load balancing decisions. URL-based load balancing, browser-smart load balancing, and cookie-based preferential load balancing are a few examples of content-based load balancing.
Implementing Basic Server Load Balancing

Consider a situation where customer Web sites are being hosted by a popular Web hosting company and/or Internet Service Provider (ISP). The Web content is relatively static and is kept on a single NFS server for easy administration. As the customer base increases, the number of simultaneous Web connection requests also increases.
Web Hosting Conguration 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
.
192 Part 3: Application Switching Fundamentals Web Hosting with SLB Solutions
All the issues can be addressed by adding an Nortel Application Switch with SLB software. Reliability is increased by providing multiple paths from the clients to the Nortel Application Switch and by accessing a pool of servers with identical content. If one server fails, the others can take up the additional load. Performance is improved by balancing the Web request load across multiple servers. More servers can be added at any time to increase processing power. For ease of maintenance, servers can be added or removed dynamically, without interrupting shared services.
Network Topology Requirements

When deploying SLB, there are a few key aspects to consider: In standard SLB, all client requests to a virtual server IP address and all responses from the real servers must pass through the switch, as shown in "SLB Client/Server Trafc Routing" (page 193). If there is a path between the client and the real servers that does not pass through the switch, the Nortel Application Switch can be congured to proxy requests in order to guarantee that responses use the correct path (see "Proxy IP Addresses" (page 228)).
.
Server Load Balancing SLB Client/Server Trafc Routing
193
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 in the pool. Each real server in the pool has access to the same data through use of a shared le system or back-end database server.
Some services require that a series of client requests go to the same real server so that session-specic state data can be retained between connections. Services of this nature include Web search results, multi-page forms that the user lls in, or custom Web-based applications typically created using cgi-bin scripts. Connections for these types of services must be congured as persistent (see "Persistence" (page 588) ") or must use the minmisses, hash, phash metrics (see "Metrics for 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 congured to process client requests, server trafc, or both. You can enable or disable processing on a port independently for each type of Layer 4 trafc. Layer 4 client processing: Ports that are congured to process client request trafc provide address translation from the virtual server IP to the real server IP address. Layer 4 server processing: Ports that are congured to process server responses to client requests provide address translation from the real server IP address to the virtual server IP address. These

.
ports require real servers to be connected to the Nortel Application Switch directly or through a hub, router, or another switch. Note: Switch ports congured for Layer 4 client/server processing can simultaneously provide Layer 2 switching and IP routing functions. Consider the following network topology:
Example Network for Client/Server Port Conguration
In "Example Network for Client/Server Port Conguration" (page 194), the switch load balances trafc to a Web server pool and to a Domain Name System (DNS) server pool. The switch port connected to the Web server pool (port 11) is asked to perform both server and client processing.
Conguring Server Load Balancing

This section describes the steps for conguring an SLB Web hosting solution. In the following procedure, many of the SLB options are left to their default values. See "Additional Server Load Balancing Options" (page 199) for more options. Before you start conguring, you must be connected to the switch CLI as the administrator. Note: For details about any of the menu commands described in this example, refer Nortel Application Switch Operating System Command Reference. Step 1 Action Assign an IP address to each of the real servers in the server pool.
.
195
The real servers in any given real server group must have an IP route to the switch that performs the SLB functions. This IP routing is most easily accomplished by placing the switches and servers on the same IP subnet, although advanced routing techniques can be used 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 the following IP addresses on the same IP subnet:
Web Host Example: Real Server IP Addresses Real Server Server A Server B Server C IP address 200.200.200.2 200.200.200.3 200.200.200.4
Note: An imask option can be used to dene a range of IP addresses for real and virtual servers (see "IP Address Ranges Using imask" (page 201)). 2 Dene an IP interface on the switch. The switch must have an IP route to all of the real servers that receive switching services. For SLB, the switch uses this path to determine the level of TCP/IP reach of the real servers. To congure an IP interface for this example, enter these commands from the CLI:
>> # /cfg/l3/if 1 >> IP Interface 1# addr 200.200.200.100 >> IP Interface 1# ena (Select IP interface 1) (Assign IP address for the interface) (Enable IP interface 1)
Note: The IP interface and the real servers must belong to the same VLAN, if they are in the same subnet. This example assumes that all ports and IP interfaces use default VLAN 1, requiring no special VLAN conguration for the ports or IP interface. 3 Dene each real server. For each real server, you must assign a real server number, specify its actual IP address, and enable the real server. For example:
.
>> IP Interface 1# /cfg/slb/real 1 >> Real server 1# rip 200.200.200.2 >> Real server 1# ena >> Real server 1# /cfg/slb/real 2 >> Real server 2# rip 200.200.200.3 >> Real server 2# ena >> Real server 2# /cfg/slb/real 3 >> Real server 3# rip 200.200.200.4 >> Real server 3# ena
(Server A is real server 1) (Assign Server A IP address) (Enable real server 1) (Server B is real server 2) (Assign Server B IP address) (Enable real server 2) (Server C is real server 3) (Assign Server C IP address) (Enable real server 3)
Dene a real server group and add the three real servers to the service group.
>> Real server 3# /cfg/slb/group 1 >> Real server group 1# add 1 >> Real server group 1# add 2 >> Real server group 1# add 3 (Select real server group 1) (Add real server 1 to group 1) (Add real server 2 to group 1) (Add real server 3 to group 1)
Dene a virtual server. All client requests is addressed to a virtual server IP address on a virtual server dened on the switch. Clients acquire the virtual server IP address through normal DNS resolution. In this example, HTTP is congured as the only service running on this virtual server, and this service is associated with the real server group. For example:
>> Real server group 1# /cfg/slb/virt 1 >> Virtual server 1# vip 200.200.200.1 >> Virtual server 1# ena (Select virtual server 1) (Assign a virtual server IP address) (Enable the virtual server)
.
197
>> Virtual server 1# service http >> Virtual server 1 http Service# group 1
(Select the HTTP service menu) (Associate virtual port to real group)
Note: This conguration is not limited to HTTP Web service. Other TCP/IP services can be congured in a similar fashion. For a list of other well-known services and ports, see "Well-Known Application Ports" (page 199). To congure multiple services, see "Conguring Multiple Services" (page 202). 6 Dene the port settings. In this example, the following ports are being used on the Nortel Application Switch:
Web Host Example: Port Usage Port 1 2 3 4 Host Server A serves SLB requests. Server B serves SLB requests. Server C serves SLB requests. Back-end NFS server provides centralized content for all three real servers. This port does not require switching features. Client router A connects the switch to the Internet where client requests originate. Client router B connects the switch to the Internet where client requests originate. L4 Processing Server Server Server None
5 6
Client Client
The ports are congured as follows:

>> Virtual server 1# /cfg/slb/port 1 >> SLB port 1# server ena >> SLB port 1# /cfg/slb/port 2 >> SLB port 2# server ena >> SLB port 2# /cfg/slb/port 3 >> SLB port 3# server ena (Select physical switch port 1) (Enable server processing on port 1) (Select physical switch port 2) (Enable server processing on port 2) (Select physical switch port 3) (Enable server processing on port 3)
.
>> SLB port 3# /cfg/slb/port 5 >> SLB port 5# client ena >> SLB port 5# /cfg/slb/port 6 >> SLB port 6# client ena
(Select physical switch port 5) (Enable client processing on port 5) (Select physical switch port 6) (Enable client processing on port 6)

>> SLB port 6# /cfg/slb >> Layer 4# on >> Layer 4# apply >> Layer 4# cur (Select the SLB Menu) (Turn Server Load Balancing on) (Make your changes active) (View current settings)
>> Layer 4# save (Save for restore after reboot)
Note: You must apply any changes in order for them to take effect, and you must save changes if you wish them to remain in effect 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 conguration changes and then check the information again. End
.
199
Additional Server Load Balancing Options

In the previous section ("Conguring Server Load Balancing" (page 194)), many of the SLB options are left to their default values. The following conguration options can be used to customize SLB on your Nortel Application 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) "Conguring 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/Overow Servers" (page 208) "Connection Pooling" (page 210)
Supported Services and Applications

Each virtual server can be congured 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/UDP applications can be specied: Note: The service number specied on the switch must match the service specied on the server.
Well-Known Application Ports Number 20 21 22 23 25 37 42 43 TCP/UDP Application ftp-data ftp ssh telnet smtp time name whois Number 79 80 109 110 119 123 143 144 TCP/UDP Application finger http pop2 pop3 nntp ntp imap news Number 179 194 389 443 520 554 1812 1813 TCP/UDP Application bgp irc ldap https rip rtsp RADIUS Radius Radiu s Accounting
.
Number 53 69
TCP/UDP Application domain tftp
Number 161 162
TCP/UDP Application snmp snmptrap
Number 1985
TCP/UDP Application hsrp
Note: Load balancing some applications (such as FTP and RTSP) require special conguration. See "Load Balancing Special Services" (page 254) for more information.
Disabling and Enabling Real Servers

If you need to reboot a server, make sure that new sessions are not sent to the real server and that current sessions are not discarded before shutting down the server. Use the following command with the n (none) option to suspend connection assignments to the real server:
>> # /oper/slb/dis <real server number> n
When the current session count on your server falls to zero, you can shut down your server. If you have congured persistence on the real server, use the following command with the p (persistent) option to suspend connection assignments (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 when persistent sessions for the real server have aged out (refer to the persistence parameters you have set for this real server), you can shut down your server. For more information (see "Persistence" (page 588) "). When maintenance is complete, use the following command to enable the real server:
>> # /oper/slb/ena <real server number>
The switch resumes assignment of connections to this real server immediately. Following table is the behavior comparison of >> # /oper/slb/dis and >> # /cfg/slb/dis.
.
201
Behavior Clearing all old sessions immediately after executing command Allowing persistent HTTP 1.0 sessions
>> # /oper/slb/dis No
>> # /cfg/slb/dis Yes
Yes/No
NA
The grace option is enabled only if the real server is in "failed" state and not 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 marked failed by health check, but the remaining sessions to the real server are still kept to maintain previous connections from client to the real server.
IP Address Ranges Using imask

The imask option lets you dene a range of IP addresses for the real and virtual servers congured under SLB. By default, the imask setting is 255.255.255.255, which means that each real and virtual server represents a single IP address. An imask setting of 255.255.255.0 would mean that each real and virtual server represents 256 IP addresses. Consider the following example: A virtual server is congured with an IP address of 172.16.10.1. Real servers 172.16.20.1 and 172.16.30.1 are assigned to service the virtual 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 to whichever 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 Servers

Determining health for each real server is a necessary function for SLB. By default for TCP services, the switch checks health by opening a TCP connection to each service port congured as part of each service. For more information, see "Conguring Multiple Services" (page 202). For UDP services, the switch pings servers to determine their status. The switch checks each service on each real server every two seconds. If the real server is busy processing connections, it may not respond to a health check. By default, if a service does not respond to four consecutive health 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 <real server number> >> Real server# inter 4 >> Real server# retry 6
(Select the real server) (Check real server every 4 seconds) (Declare down after 6 checks fail)
For more complex health-checking strategies, see "Health Checking" (page 463)."
Conguring Multiple Services

When you congure multiple services in the same group, their health checks are dependent on each other. If a real server fails a health check for a service, then the status of the real server for the second service appears as "blocked." Independent Services. If you are conguring two independent services such as FTP and SMTPwhere the real server failure on one service does not affect other services that the real server supports, then congure two groups with the same real servers, but with different services. If a real server congured for both FTP and SMTP fails FTP, the real server is still available for SMTP. This allows the services to act independently even though they are using the same real servers. Dependent Services. If you are conguring two dependent services such as HTTP and HTTPSwhere the real server failure on one service blocks the real server for other services, then congure a single group with multiple services. If a real server congured for both HTTP and HTTPS fails for the HTTP service, then the server is blocked from supporting any HTTPS requests. The switch blocks HTTPS requests, (even though HTTPS has not failed) until the HTTP service becomes available again. This helps in troubleshooting so you know which service has failed.
Metrics for Real Server Groups

Metrics are used for selecting which real server in a group receives the next client 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. The default metric is leastconns. To change a real server group metric to minmisses, for example, enter:
>> # /cfg/slb/group <group number> >> Real server group# metric minmisses (Select the real server group) (Use minmisses metric)
.
203
Minimum Misses
The minmisses metric is optimized for application redirection. It uses IP address information in the client request to select a server. When selecting a server, the switch calculates a value for each available real server based on the relevant IP address information. The server with highest value is assigned the connection. This metric attempts to minimize the disruption of persistency when servers are removed from service. This metric should be used only when persistence is a must. By default the minmiss algorithm uses the upper 24-bits of the source IP address to calculate the real server that the trafc should be sent to when the minmiss metric is selected. The Nortel Application Switch Operating System allows the selection of all 32-bits of the source IP address to hash to the real server. The source or destination IP address information used depends on the application: For application redirection, the client destination IP address is used. All requests for a specic IP destination address is sent to the same server. This metric is particularly useful in caching applications, helping to maximize successful cache hits. Best statistical load balancing is achieved when the IP address destinations of load-balanced frames are spread across a broad range of IP subnets. For SLB, the client source IP address and real server IP address are used. All requests from a specic client are sent to the same server. This metric is useful for applications where client information must be retained on the server between sessions. With this metric, server load becomes most evenly balanced as the number of active clients with different 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 in the wireless world. The minmisses metric cannot be used for rewall load balancing, since the real server IP addresses used in calculating the score for this metric are different on each side of the rewall.
Hash
The hash metric uses IP address information in the client request to select a server. The specic IP address information used depends on the application: For Application Redirection, the client destination IP address is used. All requests for a specic 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 from a specic client is sent to the same server. This option is useful for applications where client information must be retained between sessions. For FWLB, both the source and destination IP addresses are used to ensure that the two unidirectional ows of a given session are redirected to the same rewall.
When selecting a server, a mathematical hash of the relevant IP address information 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 be assigned to a subsequent session with the same IP address information even though the original server is still available. Open connections are not cleared. The phash metric can be used to maintain stable server assignment. For more information, see "Persistent Hash" (page 204). Note: The hash metric provides more distributed load balancing than minmisses at any given instant. It should be used if the statistical load balancing achieved using minmisses is not as optimal as desired. If the load balancing statistics with minmisses indicate that one server is processing signicantly more requests over time than other servers, consider using the hash metric. Persistent Hash The phash metric provides the best features of hash and minmisses metrics together. This metric provides stable server assignments like the minmiss metric and even load distribution like the hash metric. When you select the phash metric for a group, a baseline hash is assumed based on the congured real servers that are enabled for the group. If the server selected from this baseline hash is unavailable, then the old hash metric is used to nd an available server. If all the servers are available, then phash operates exactly like hash. When a congured server becomes unavailable, then clients bound to operational servers will continue to be bound to the same servers for future sessions and clients bound to unavailable servers are rehashed to an operational server using the old hash metric. With phash however, when more servers go down, then you will not have an even load distribution as you would with the standard hash metric.
.
205
Tunable Hash By default, the hash metric has used the clients source IP address as the parameter for directing a client request to a real server. In environments where multiple users are sharing the same proxy, and thus the same source IP address, a load balancing hash on the source IP address would direct all users to the same real server. Tunable hash allows the user to select the parameters (source IP, or source IP and source port) that are used when hashing is chosen as the load balancing metric.
Least Connections
With the leastconns metric, the number of connections currently open on each real server is measured in real time. The server with the fewest current connections is considered to be the best choice for the next client connection request. This option is the most self-regulating, with the fastest servers typically getting the most connections over time.
Round Robin
With the roundrobin metric, new connections are issued to each server in turn; that is, the rst real server in the group gets the rst connection, the second 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 one connection, the issuing process starts over with the rst real server.
Response Time
The response metric uses real server response time to assign sessions to servers. The response time between the servers and the switch is used as the weighting factor. The switch monitors and records the amount of time it takes for each real server to reply to a health check to adjust the real server weights. The weights are adjusted so they are inversely proportional to a moving average of response time. In such a scenario, a server with half the response time as another server receives a weight twice as large. Note: The effects of the response weighting apply directly to the real servers and are not necessarily conned to the real server group. When response time-metered real servers are also used in other real server groups that use the leastconns or roundrobin metrics, the response weights are applied on top of the leastconns or roundrobin calculations for the affected real servers. Since the response weight changes dynamically, this can produce uctuations in trafc distribution for the real server groups that use the leastconns or roundrobin metrics.
.
Bandwidth
The bandwidth metric uses real server octet counts to assign sessions to a server. The switch monitors the number of octets sent between the server and the switch. Then, the real server weights are adjusted so they are inversely proportional to the number of octets that the real server processes during the last interval. Servers that process more octets are considered to have less available bandwidth than servers that have processed fewer octets. For example, the server that processes half the amount of octets over the last interval receives twice 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 free bandwidth. 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 real servers and are not necessarily conned to the real server group. When bandwidth-metered real servers are also used in other real server groups that use the leastconns or roundrobin metrics, the bandwidth weights are applied on top of the leastconns or roundrobin calculations for the affected real servers. Since the bandwidth weight changes dynamically, this can produce uctuations in trafc distribution for the real server groups that use the leastconns or roundrobin metrics.
Weights for Real Servers

Weights can be assigned to each real server. These weights can bias load balancing to give the fastest real servers a larger share of connections. Weight is specied as a number from 1 to 48. Each increment increases the number of connections the real server gets. By default, each real server is given a weight setting of 1. A setting of 10 would assign the server roughly 10 times the number of connections as a server with a weight of 1. To set weights, enter the following commands:
>> # /cfg/slb/real <real server number> >> Real server# weight 10 (Select the real server) (10 times the number of connections)
Readjusting server weights based on SNMP health check response Nortel Application Switch Operating System can be congured to dynamically change weights of real servers based on a health check response using the Simple Network Management Protocol (SNMP). To enable dynamic assignment of weights based on the response to an SNMP health check, enter the following commands:
.
207
>> # /cfg/slb/adv/snmphc < SNMP health script number> >> SNMP Health Check 1# weight e (Enable weighting via SNMP health check)
For more information on conguring SNMP health checks, see "SNMP Health Check" (page 483).
Connection Time-outs for Real Servers

In some cases, open TCP/IP sessions might not be closed properly (for example, 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 from the session table in the switch. To change the time-out period, enter the following:
>> # /cfg/slb/real <real server number> >> Real server# tmout 4 (Select the real server) (Specify an even numbered interval)
The example above would change the time-out period of all connections on the designated real server to four minutes.
Maximum Connections for Real Servers

You can set the number of open connections each real server is allowed to handle for SLB. To set the connection limit, enter the following:
>> # /cfg/slb/real <real server number> >> Real server# maxcon 1600 (Select the real server) (Allow 1600 connections maximum)
Values average from approximately 500 HTTP connections for slower servers to 1500 for quicker, multiprocessor servers. The appropriate value also depends on the duration of each session and how much CPU capacity is occupied by processing each session. Connections that use a lot of Java or CGI scripts for forms or searches require more server resources and thus a lower maxcon limit. You may wish to use a performance benchmark tool to determine how many connections your real servers can handle. When a server reaches its maxcon limit, the switch no longer sends new connections to the server. When the server drops back below the maxcon limit, new sessions are again allowed.
.
Unlimited Connections to Real Servers

This feature allows an unlimited number of connections to be allocated to trafc accessing a real server. The CLI species a range of 0 to 200K connections per real server. A maxcon value of 0 allows the specied real server to handle up to its maximum number of connections, or the switchs maximum of 4 Million connections. Step 1 Action To congure unlimited connections, set the real server maxcon value to zero.
>> # Main# /cfg/slb/real <x> /maxcon Current max connections: 200000 Max connections 0 means unlimited connections Enter new max connections [0-200000]: 0 Current max connections: 200000 Pending max connections: 0

End
Backup/Overow Servers
A real server can backup other real servers and can handle overow trafc when the maximum connection limit is reached. Each backup real server must be assigned a real server number and real server IP address. It must then be enabled. Finally, the backup server must be assigned to each real server that it will back up. The following denes real server 4 as a backup/overow for real servers 1 and 2:
>> # /cfg/slb/real 4 >> Real server 4# rip 200.200.200.5 >> Real server 4# ena >> Real server 4# /cfg/slb/real 1 >> Real server 1# backup 4 >> Real server 1# /cfg/slb/real 2 >> Real server 2# backup 4 >> Real server 2# overflow enabled (Select real server 4 as backup) (Assign backup IP address) (Enable real server 4) (Select real server 1) (Real server 4 is backup for 1) (Select real server 2) (Real server 4 is backup for 2) (Overflow enabled)
.
209
In a similar fashion, a backup/overow server can be assigned to a real server group. If all real servers in a real server group fail or overow, the backup comes online.
>> # /cfg/slb/group <real server group number> >> Real server group# backup r4 (Select real server group) (Assign real server 4 as backup)
Real server groups can also use another real server group for backup/overow:
>> # /cfg/slb/group <real server group number> >> Real server group# backup g2 (Select real server group) (Assign real server group 2 as backup)
Backup Only Server

Unlike a Backup/Overow server, a Backup Only server is used to backup real servers only and not provide an overow capability. This provides for the enforcement of maximum session capacity while still providing resiliency. In this conguration, if the primary server reaches its maximum session capacity, the backup server does not take over sessions from the primary server. The backup server only comes into play if the primary server fails. The following denes real server 4 as a backup only server for real servers 1 and 2
>> # /cfg/slb/real 4 >> Real server 4# rip 200.200.200.5 >> Real server 4# ena >> Real server 4# /cfg/slb/real 1 >> Real server 1# backup 4 >> Real server 1# /cfg/slb/real 2 >> Real server 2# backup 4 (Select real server 4 as backup) (Assign backup IP address) (Enable real server 4) (Select real server 1) (Real server 4 is backup for 1) (Select real server 2) (Real server 4 is backup for 2)
In a similar fashion, a backup/overow server can be assigned to a real server group. If all real servers in a real server group fail the backup comes online.
>> # /cfg/slb/group <real server group number> >> Real server group# backup r4 (Select real server group) (Assign real server 4 as backup)
.
Real server groups can also use another real server group for backup:
>> # /cfg/slb/group <real server group number> >> Real server group# backup g2 (Select real server group) (Assign real server group 2 as backup)
Connection Pooling
The Nortel Application Switch Operating System supports connection pooling to the Nortel Application Switch. This feature multiplexes client and server connections and improves the throughput of server load balancing. It also helps the real server lower the needs of establishing and tearing down TCP connections. In a connection pooled environment, a pool of server connections in maintained for servicing client connections. When a client requests a connection, an unused connection is selected from the server pool and used to service the request. When the client request is complete, the server connection is returned to the pool and the client connection dropped. This feature only supports the HTTP and HTTPS protocols over TCP with delayed binding enabled. The following example enable s connection pooling for the HTTP protocol on virtual server 1:
>> Main# /cfg/slb/virt 1/service http/http/pooling enabled
The following example enables connection pooling for the HTTPS protocol on virtual server 1:
>> Main# /cfg/slb/virt 1/service https/http/pooling enabled
Connection pooling statistics can be displayed by issuing the following command:

>> Main# /stats/slb/layer7/pooling
Content Intelligent Server Load Balancing

Nortel Application Switch Operating System allows you to load balance HTTP requests based on different HTTP header information, such as "Cookie:" header for persistent load balancing, "Host:" header for virtual hosting, or "User-Agent" for browser-smart load balancing.
.
211
Note: When Layer 7 load balancing is congured, a Nortel Application Switch does not support IP fragments. If IP fragments were supported in this mode, the switch would have to buffer, re-assemble, and inspect packets 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 Balancing

URL-based SLB allows you to optimize resource access and server performance. Content dispersion can be optimized by making load-balancing decisions on the entire path and lename of each URL. Note: Both HTTP 1.0 and HTTP 1.1 requests are supported. For URL matching you can congure up to 1024 strings comprised of 40 bytes each. Each URL request is then examined against the URL strings dened for each real server. URL requests are load balanced among multiple servers matching the URL, according to the load balancing metric congured for the real server group (leastConns is the default). In "URL-Based Server Load Balancing" (page 212), the following criteria are specied 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 servers 1 and 2. Requests with URLs starting with "/product:" are sent to real servers 2, 3, and 5.
Requests containing URLs with anything else are sent to real servers 1, 2, 3, and 4. These servers have been dened with the "any" string.
.
212 Part 3: Application Switching Fundamentals URL-Based Server Load Balancing
Conguring URL-Based Server Load Balancing

To congure URL-based SLB, perform the following steps: Step 1 Action Before you can congure SLB string-based load balancing, ensure that the switch has already been congured for basic SLB with the following tasks: Note: When URL-based SLB is used in an active/active redundant setup, use a proxy IP address instead of Direct Access Mode (DAM) to enable the URL parsing feature. Assign an IP address to each of the real servers in the server pool. Dene an IP interface on the switch. Dene each real server. Dene a real server group and set up health checks for the group. Dene a virtual server on virtual port 80 (HTTP), and assign the real 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 congure your network for SLB, see "Server Load Balancing" (page 188).
.
213
Dene the string(s) to be used for URL load balancing.

>> # /cfg/slb/layer7/slb/addstr|remstr <l7lkup|patte rn>
addstr: Add string or a pattern. remstr: Remove string or a pattern.
A default string any indicates that the particular server can handle all URL 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 these requests:
/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 ( / ) indicates that the server will process any requests that contain the dened string. For example, with the "images" string, the server will process these 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 congured with the load balance string ( / ) only, it will only handle requests to the root directory. For example, the server handles any les in the root directory:
/ /index.htm /default.asp /index.shtm
3 4
Apply and save your conguration changes. Identify the dened string IDs.
>> # /cfg/slb/layer7/slb/cur
For easy conguration and identication, each dened string is assigned an ID number, as shown in the following example:
ID 1 2 3 4 5 6 SLB String any .gif /sales /xitami /manual .jpg
5 6
Congure one or more real servers to support URL-based load balancing. Add the dened string(s) to the real server using the following command:
>> # /cfg/slb/real 2/layer7/addlb <ID>
where ID is the identication number of the dened string. Note: If you dont add a dened string (or add the dened string any) the server will handle any request. A server can have multiple dened strings. For example: "/images" "/sales"
.
215
".gif"
With these dened strings, this particular server can handle requests that start with "/images" or "/sales" and any requests that contain ".gif". 7 Enable SLB on the switch.
>> # /cfg/slb/on (Turn SLB on)
Enable DAM on the switch or congure proxy IP addresses and enable proxy on the client port. DAM and proxy IPs allow you to perform port mapping for URL load balancing. Enable DAM
>> # /cfg/slb/adv/direct ena
Congure 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# type port >> # /cfg/slb/port 2/proxy ena (Use port-based proxy IP) (Enable proxy on client port)
For more information on proxy IP addresses, see "Proxy IP Addresses" (page 228). 9 Enable URL-based SLB on the virtual server(s).
>> # /cfg/slb/virt <virtual server number> /service 80/httpslb urlslb
End
Statistics for URL-Based Server Load Balancing

To show the number of hits to the SLB or cache server, use this command:
>> # /stats/slb/layer7/str
.
Sample Statistics:
ID 1 2 3 4 5 6 SLB String any .gif /sales /xitami /manual .jpg Hits 73881 0 0 162102 0 0
Virtual Hosting
Nortel Application Switch Operating System allows individuals and companies to have a presence on the Internet in the form of a dedicated Web 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 of unique IP addresses by dedicating an individual IP address for each home page they host. By supporting an extension in HTTP 1.1 to include the host header, Nortel Application Switch Operating System enables service providers to create a single virtual server IP address to host multiple Web sites 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 conguration information. An HTTP/1.0 request sent to an origin server (not a proxy server) is a partial URL instead of a full URL. An example of the request that the origin server would see as follows: GET /products/2424/ HTTP/1.0 User-agent: Mozilla/3.0 Accept: text/html, image/gif, image/jpeg The GET request does not include the host name. From the TCP/IP headers, the origin server knows the requests host name, port number, and protocol. With the extension to HTTP/1.1 to include the HTTP HOST: header, the above request to retrieve the URL " www.nortelnetworks.com/products/2424" would look like this:
GET /products/2424/ HTTP/1.1 Host: www.nortelnetworks.com User-agent: Mozilla/3.0
.
217
Accept:
text/html, image/gif, image/jpeg
The Host: header carries the hostname used to generate the IP address of the site. Based on the Host: header, the switch forwards the request to servers representing different customers Web sites. The network administrator needs to dene a domain name as part of the 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 Conguration Overview

The sequence of events for conguring virtual hosting based on HTTP Host: headers is described below: Step 1 Action The network administrator denes a domain name as part of the 128 supported URL strings. Both domain names "www.company-a.com" and "www.companyb.com" resolve to the same IP address. In this example, the IP address is for a virtual server on the switch. 2 3 "www.company-a.com" and "www.company-b.com" are dened as URL strings. Server Group 1 is congured with Servers 1 through 8. Servers 1 through 4 belong to "www.company-a.com" and Servers 5 through 8 belong to "www.company-b.com." 4 The network administrator assigns string "www.companya.com" to Servers 1 through 4 and string "www.company-b.com" to Servers 5 through 8. The application switch inspects the HTTP host header in requests received from the client. If the host header is "www.company-a.com," the switch directs requests to one of the Servers 1 through 4. If the host header is "www.company-b.com," the switch directs requests to one of the Servers 5 through 8. End
.
Conguring the Host Header for Virtual Hosting

To support virtual hosting, congure the switch for Host header-based load balancing with the following procedure: Step 1 Action Before you can congure host header-based server load balancing, ensure that the switch has already been congured for basic SLB: Assign an IP address to each of the real servers in the server pool. Dene an IP interface on the switch. Dene each real server. Assign servers to real server groups. Dene virtual servers and services.
For information on how to congure your network for server load balancing, see "Server Load Balancing" (page 188). 2 Turn on URL parsing for the virtual server for virtual hosting.
>> # /cfg/slb/virt 1 >> Virtual Server 1 # service 80 (Select the virtual IP for host header-based SLB) (Select the HTTP service)
>> Virtual Server 1 http Service # httpslb host
Dene 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"
Congure the real server(s) to handle the appropriate load balancing string(s). To add a dened string:
>> # /cfg/slb/real 2 >> Real Server 2 # Layer7 >> Real Server 2 Layer 7 Commands # addlb
(Select the real server) <ID>(Specify the string ID)

.
219
where ID is the identication number of the dened string. Note: If you dont add a dened string (or add the dened string any), the server will handle any request. End
Cookie-Based Preferential Load Balancing

Cookies can be used to provide preferential services for customers, ensuring that certain users are offered better access to resources than other users when site resources are scarce. For example, a Web server could authenticate a user via a password and then set cookies to identify them as "Gold," "Silver," or "Bronze" customers. Using cookies, you can distinguish individuals or groups of users and place them into groups or communities that get redirected to better resources and receive better services than all 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 other users by one of the following methods: Individual User Specic individual user could be distinguished by IP address, login authentication, or permanent HTTP cookie. User Communities Some set of users, such as "Premium Users" for service providers who pay higher membership fees than "Normal Users" could be identied by source address range, login authentication, or permanent HTTP cookie. Applications
.
Users could be identied by the specic application they are using. For example, priority can be given to HTTPS trafc that is performing credit card transactions versus HTTP browsing trafc. Content Users could be identied by the specic content they are accessing. Based on one or more of the criteria above, you can load balance requests to different server groups.
Conguring Cookie-Based Preferential Load Balancing

To congure cookie-based preferential load balancing, perform the following procedure. Step 1 Action Before you can congure header-based load balancing, ensure that the switch has already been congured for basic SLB with the following tasks: Assign an IP address to each of the real servers in the server pool. Dene an IP interface on the switch. Dene each real server. Assign servers to real server groups. Dene virtual servers and services.
For information on how to congure your network for SLB, see "Server Load Balancing" (page 188). 2 Turn on URL parsing for the virtual server.
>> # /cfg/slb/virt 1 >> Virtual Server 1 # service 80 >> Virtual Server 1 http Service # httpslb cookie Enter Cookie Name: sid Enter the starting point of the Cookie value [1-64]: 1 Enter the number of bytes to extract [1-64]: 6 Look for Cookie in URI [e|d]: d
where sid = cookie name 1 = offset (the starting position of the value to be used for hashing) 6 = length (the number of bytes in the cookie value)
.
221
d = looks for the cookie in the cookie header instead of the URI (disables searching for cookie in the URI) 3 Dene the cookie values.
>> # /cfg/slb/layer7/slb/addstr "Gold" >> # addstr "Silver" >> # addstr "Bronze"
Since a session cookie does not exist in the rst request of an HTTP session, a default server or any server is needed to assign cookies to 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 a cookie or matching cookie.
With servers dened to handle the requests listed above, here is what happens: Request 1 comes in with no cookie; it is forwarded to Real Server 4 to get cookie assigned. Request 2 comes in with "Gold" cookie; it is forwarded to Real Server 1. Request 3 comes in with "Silver" cookie; it is forwarded to Real Server 2. Request 4 comes in with "Bronze" cookie; it is forwarded to Real Server 3. Request 5 comes in with "Titanium" cookie; it is forwarded to Real Server 4, since it does not have an exact cookie match (matches with "any" congured at Real Server 4).
Congure the real server(s) to handle the appropriate load balance string(s). To add a dened string:
where ID is the identication number of the dened string.

.
Note: If you dont add a dened string (or add the dened string any), the server will handle any request. 5 Enable DAM on the switch or congure proxy IP addresses and enable proxy on the client port. To use cookie-based preferential load balancing without DAM, you must congure proxy IP addresses. Enable proxy load balancing on the port used for cookie-based preferential load balancing. If Virtual Matrix Architecture (VMA) is enabled on the switch, you can choose to congure the remaining ports with proxy disabled. End
Browser-Smart Load Balancing

HTTP requests can be directed to different servers based on browser type by inspecting the "User-Agent" header. For example,
GET /products/2424/ HTTP/1.0 User-agent: Mozilla/3.0 Accept: text/html, image/gif, image/jpeg
To allow the switch to perform browser-smart load balancing, perform the following procedure. Step 1 Action Before you can congure browser-based load balancing, ensure that the switch has already been congured for basic SLB with the following tasks: 2 Assign an IP address to each of the real servers in the server pool. Dene an IP interface on the switch. Dene each real server. Assign servers to real server groups. Dene virtual servers and services.
Turn on URL parsing for the virtual server for "User-Agent:" header.
>> # /cfg/slb/virt 1/service 80/httpslb browser
.
223

>> # /cfg/slb/layer7/slb/addstr "Mozilla" >> Server Loadbalance Resource# addstr "Internet Explorer" >> Server Loadbalance Resource# addstr "Netscape"
Congure the real server(s) to handle the appropriate load balancing string(s). Note: If you dont add a dened string (or add the dened string any), the server will handle any request. Use the following command to add a dened string:
where ID is the identication number of the dened string. End
URL Hashing for Server Load Balancing

By default, hashing algorithms use the IP source address and/or IP destination address (depending on the application area) to determine content location. The default hashing algorithm for SLB is the IP source address. By enabling URL hashing, requests going to the same page of an origin server are redirected to the same real server or cache server.
Load Balancing Nontransparent Caches

You can deploy a cluster of non-transparent caches and use the virtual server to load balance requests to the cache servers. The clients browser is congured to send Web requests to a nontransparent cache (the IP address of the congured virtual server). If hash is selected as the load-balancing algorithm, the switch hashes the 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 same proxy cache server. For example, requests made from a client to " http://www.nortelnetworks.com/products"from different clients may get sent to different caches.
.
224 Part 3: Application Switching Fundamentals Using URL hashing to Load Balance Nontransparent Caches
Conguring URL Hashing

You can direct the same URL request to the same cache or proxy server by using a virtual server IP address to load balance proxy requests. By conguring hash or minmisses as the metric, the switch uses the number of bytes in the URI to calculate the hash key. If the host eld exists and the switch is congured to look into the Host: header, the switch uses the Host: header eld to calculate the hash key. To congure URL hashing, perform the following procedure: Step 1 Action Before you can congure URL hashing, ensure that the switch has already been congured for basic SLB with the following tasks: Assign an IP address to each of the real servers in the server pool. Dene an IP interface on the switch. Dene each real server. Assign servers to real server groups. Dene virtual servers and services. Congure load-balancing algorithm for hash or minmiss. Enable SLB. For information on how to congure your network for SLB, see "Server Load Balancing" (page 188)." 2 Dene server port and client port.
Enable URL hashing.
.
225
>> # /cfg/slb/virt 1 >> Virtual Server 1 # service 80 >> Virtual Server 1 http Service # httpslb urlhash Enter new hash length [1-255]: 25
Hashing is based on the URL, including the HTTP Host: header (if present), 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 Balancing

Nortel Application Switch Operating System allows you to hash on any selected HTTP header. To congure the application switch for load balancing based on header hash, perform the following procedure: Step 1 Action Ensure that the switch has already been congured for basic SLB: 2 Assign an IP address to each of the real servers in the server pool. Dene an IP interface on the switch. Dene each real server. Assign servers to real server groups. Dene virtual servers and services.
Enable header hashing.

>> # /cfg/slb/virt 1 >> Virtual Server 1 # service 80 >> Virtual Server 1 http Service # httpslb headerhash Select Operation: none Enter new HTTP header name: User-agent Enter new hash length [1-255]: 25
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 Requests

Nortel Application Switch Operating System can insert the inclusion of the "X-Forwarded-For" header in client HTTP requests, in order to preserve client IP information. This feature is useful in proxy mode, where the client source IP information is replaced with the proxy IP address. However, it may also be used for all Layer 4, load balancing in both proxy and non-proxy mode, if there is a need to include the "X-Forwarded-For" header. This feature is not supported at Layer 7. To congure the application switch to insert the "X-Forwarded-For" header, perform the following procedure: Step 1 Action Ensure that the switch has already been congured for basic SLB: 2 Assign an IP address to each of the real servers in the server pool. Dene an IP interface on the switch. Dene each real server. Assign servers to real server groups. Dene virtual servers and services.
Enable client proxy operation mode on the real servers used in load balancing.
>> # /cfg/slb/real 1/proxy ena
On the virtual server attached to the real servers, enable the X-Forwarded-For header.
>> # /cfg/slb/virt 1/service 80/xforward ena

End
.
227
Extending SLB Topologies

For standard SLB, all client-to-server requests to a particular virtual server and all related server-to-client responses must pass through the same Nortel Application Switch. In complex network topologies, routers and other devices can create alternate paths around the Nortel Application Switch managing SLB functions (see "SLB Client/Server Trafc Routing" (page 193)). Under such conditions, the Nortel Application Switch with Nortel Application 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 Architecture

Virtual Matrix Architecture (VMA) is a hybrid architecture that takes full advantage of the distributed processing capability in Nortel Application Switches. With VMA, the switch makes optimal use of system resources by distributing the workload to multiple processors, thereby improving switch performance and increasing session capacity. VMA also removes the 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 approach was ineffective when mega proxies are used. To improve the distribution, there are two VMA congurable options.
VMA congurable options VMA with source port >> /cfg/slb/adv/vmasport Source IP and source port are used to determine the processor.
VMA with destination IP >> /cfg/slb/adv/vmadip
Source IP and destination IP are used to determine the processor. Both options can be enabled together wherein source IP, source port and destination IP are used to determine the processor.
.
Note: It is not advisable to change VMA option while switch is in operation since that may result in temporary disconnection of clients. Maintenance mode command /maint/debug/vmasp can be used to nd the processor for any combination of source IP, source port (if VMA with source port is enabled) and destination IP (if VMA with destination IP is enabled).
Miscellaneous Debug
When VMA with destination IP is enabled:
>> /cfg/slb/adv/vmadip ena Current VMA with destination IP: disabled New VMA with destination IP: enabled WARNING!! Changing VMA option may result in temporary disconnection of clients. Do you want to continue?[y/n] [n]
Proxy IP Addresses
In complex network topologies (see "SLB Client/Server Trafc Routing" (page 193)), SLB functions can be managed using a proxy IP address on the client switch ports. When the client requests services from the switchs virtual server, the client sends its own IP address for use as a return address. If a proxy IP address is congured for the client port on the switch, the switch replaces the clients source IP address with the switchs own proxy IP address before sending the request to the real server. This creates the illusion that the switch originated the request. The real server uses the switchs proxy IP address as the destination address for any response. SLB trafc is forced to return through the proper switch, regardless of alternate paths. Once the switch receives the proxied data, it puts the original client IP address into the destination address and sends the packet to the client. This process is transparent to the client. Note: Because requests appear to come from the switch proxy IP address rather than the client source IP address, the network administrator should be aware of this behavior during debugging and statistics collection. The proxy IP address can also be used for direct access to the real servers (see "Direct Access Mode" (page 239)).
.
229
Proxy IP Address Conguration

Proxy IP addresses are no longer tied to the switch processor. The proxy address can be associated with a port or VLAN. A proxy IP address can be based on a port or a VLAN. Up to 1024 proxy IP addresses in total can be congured per switch. When conguration is port-based, the Nortel Application Switch uses the ingress port to select a proxy IP address. When conguration is VLAN-based, the switch uses the ingress VLAN to 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 or VLAN)
Port-based Proxy IP Addresses

The creation of a port-based proxy IP address is a two step process. The type command is rst used to specify the address type:
/cfg/slb/pip/type port
The address is then specied using either the add or add6 command. The command is dependent on the IP protocol version in use. For an IPv4 address, 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 conguration of an IPv4 port-based proxy IP address. To congure an IPv6 address, substitute the add6 command for the add command and enter an IPv6 address.
>> # /cfg/slb/pip/type port >> # /cfg/slb/pip/add (Select port-based proxy IP address) (Add a proxy IP address) e.g. 1 2 3-10
Enter Proxy IP address: 10.10.10.1 Enter port <1 to 28> or block <first-last>: 1-3 New pending: 1:
(Add proxy IP address to ports 1-3) 10.10.10.1 port 1-3
.
Once enabled, the port-based proxy IP addressing is the active mode, and VLAN-based proxy IP addressing is inactive. Any VLAN-based proxy IP addresses that may have been congured are now inactive on the Nortel Application Switch. Note: WAN Link Load Balancing (see " WAN Link Load Balancing" (page 327)) requires use of port-based proxy IP addresses; VLAN-based proxy IP addresses cannot be used.
VLAN-based Proxy IP Addresses

Since trafc is usually segregated by VLANs, selection of proxy IP address can 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. The type command is rst used to specify the address type:
/cfg/slb/pip/type vlan
The address is then specied using either the add or add6 command. The command is dependent on the IP protocol version in use. For an IPv4 address, 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 conguration of an IPv4 VLAN-based proxy IP address. To congure an IPv6 address, substitute the add6 command for the add command and enter an IPv6 address
>> # /cfg/slb/pip/type vlan >> Proxy IP Address# add (Choose VLAN as the pip type) (Add a proxy IP address) e.g. 1 2
Enter Proxy IP address: 10.10.10.1 Enter VLAN <1 to 4090> or block <first-last>: 3-10 2 New Pending: 1: 10.10.10.1 vlan 2
(Assign proxy IP address to VLAN 2)
Selecting a Proxy IP Based on the Egress Port or VLAN

By default, the switch selects the proxy IP address based on the ingress port or VLAN. However, a proxy IP can also be selected based on the egress port or VLAN. Selection of the egress port or VLAN can be enabled on a virtual service, or on a lter. Egress port or VLAN-based proxy IP address should be applied only to Web Cache Redirection (WCR) ltering.
.
231
>> # /cfg/slb/virt <x> /service <y> /epip ena >> # /cfg/slb/filt <x> /adv/proxyad v/epip ena
(Select proxy IP based on egress port or VLAN for this virtual service) (Select proxy IP based on egress port or VLAN for a WCR filter)
Use of a port-based proxy IP or a VLAN-based proxy IP depends on whether you have selected the proxy IP type as port or VLAN.
Proxy IP Addresses in Filters

In previous releases of Nortel Application Switch Operating System, only four proxy IP addresses could be congured, and client proxy was enabled in the ltering advanced menu. The application switch used the congured proxy IP address for the VMA switch port (SP) to replace clients source IP address. Now you can congure a unique proxy IP address for a lter in the ltering advanced menu. To congure a proxy IP address on a lter, enter the following commands. Note: The lter proxy/proxyip function applies only when the lter action is NAT.
>> # /cfg/slb/filt <filter #> /adv/proxyip Current proxy IP address: any Enter new proxy IP address or any: <proxy IP address> (Add a proxy IP to this filter) >> Filter 2 Advanced# proxy ena (Enable use of proxy IP on this filter)
If no proxyip is congured in Filter Advanced menu then the Nortel Application Switch uses the proxy IP address congured in /cfg/slb/pip menu. If proxy IP addresses are congured in both the Filter Advanced menu and the /cfg/slb/pip menus, then the Proxy IP address in Filter Advanced menu takes precedence over the Proxy IP address in the /cfg/slb/pip menu.
Using a Virtual Server IP Address as the Proxy IP Address

For outgoing proxy servers that initiate ows from within the server farm, a virtual server IP address congured on the Nortel Application Switch can be substituted as the proxy servers source IP address. To do so, the Nortel Application Switch allows a virtual server IP address congured on the switch, to also be used as a proxy IP address.
.
Using a virtual server IP address as the proxy IP address allows conservation of public IP addresses. When proxy servers initiate requests to the web, they require a public IP address for their source IP address. In previous versions of Nortel Application Switch Operating System, this required Network Address Translation (NAT) to substitute the private source IP address of the proxy server, with one of only four available proxy IP addresses. The previous limitation of four proxy IP addresses meant that only four addresses were available as public IP addresses for outgoing proxy trafc. In the current release, Nortel Application Switch Operating System can mask real IP addresses of the servers in the server farm with the virtual server IP address congured on the Nortel Application Switch, when the real servers initiate trafc ows. The benet of using a virtual server IP address as the proxy IP address is that multiple proxy servers can share the same virtual server IP address and embed that address as their source IP address, thus conserving use of Public IP addresses. For example, if virtual server IP 50.50.50.1 is congured on the switch, and proxy servers are to share this address, congure both proxy and virtual server IPs with the same address:
>> # /cfg/slb/virt 1/vip 50.50.50.1 >> # /cfg/slb/pip/add 50.50.50.1
Conguring Proxy IP Addresses

The following procedure can be used for conguring proxy IP addresses: Step 1 Action Disable server processing on affected switch ports. When implementing proxies, switch ports can be recongured to disable server processing. Referring to the "Web Host Example: Port Usage" (page 197), the following revised port conditions are used:
Proxy Example: Port Usage Port 1 2 3 4 Host Server A Server B Server C Back-end NFS server provides centralized content for all three real servers. This port does not require switching features. L4 Processing None None None None
.
233
Port 5 6
Host Client router A connects the switch to the Internet where all client requests originate. Client router B also connects the switch to the Internet where all client requests originate.
L4 Processing Client Client
The following commands are used to disable server processing on ports 1-3:
>> # /cfg/slb/port 1 >> SLB port 1# server dis >> SLB port 1# /cfg/slb/port 2 >> SLB port 2# server dis >> SLB port 2# /cfg/slb/port 3 >> SLB port 3# server dis (Select switch port 1) (Disable server processing on port 1) (Select switch port 2) (Disable server processing on port 2) (Select switch port 3) (Disable server processing on port 3)
Congure a unique proxy address and enable proxy for the client ports. Congure a unique proxy IP address and enable proxy on the client ports:
>> Main # /cfg/slb/pip >> Proxy IP Address# type port (Select proxy IP menu) (Set proxy IP base type to port)
>> Proxy IP Address# add 200.200.200.68 5-6 (Set proxy IP address) >> Main # /cfg/slb/port 5/proxy ena >> SLB port 5# /cfg/slb/port 6 >> SLB port 6# proxy ena (Select network port 5 and enable proxy) (Select network port 6) (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 for them to take effect, and you must save them if you wish them to remain in effect after switch reboot. Also, the /info/slb
.
command is useful for checking the state of Server Load Balancing operations. End
Proxy IP Limitation
If a Proxy IP address is enabled, the Selected DAM feature should also be enabled. When Selective DAM is disabled for a service and trafc ingresses a port with a port or VLAN based Proxy IP, the client trafc still uses a proxy port. This causes client port network address translation (NAT). This in turn causes a failure when the trafc comes back to the switch from the server.
Mapping Ports
A Nortel Application Switch allows you to hide the identity of a port for security by mapping a virtual server port to a different real server port.
Mapping a Virtual Server Port to a Real Server Port

In addition to providing direct real server access in some situations (see "Mapping Ports" (page 241)), mapping is required when administrators choose to execute their real server processes on different ports than the well-known TCP/UDP ports. Otherwise, virtual server ports are mapped directly to real server ports by default and require no mapping conguration. Port mapping is congured from the Virtual Server Services menu. For example, to map the virtual server TCP/UDP port 80 to real server TCP/UDP port 8004, you could enter the following:
>> # /cfg/slb/virt 1/service 80 >> Virtual Server 1 http Service# rport 8004 (Select virtual server port 80) (Map to real port 8004)
Note: If ltering is enabled, a proxy IP address is congured, or URL parsing is enabled on any switch port, then port mapping is supported with Direct Access Mode (DAM). For information about DAM, refer to "Direct Access Mode" (page 239).
Mapping aVirtual Server Port to Multiple Real Server Ports

To take advantage of multi-CPU or multi-process servers, Nortel Application Switch Operating System can be congured to map a single virtual port to multiple real ports. This capability allows the site managers, for example, to differentiate users of a service by using multiple service ports to process client requests.
.
235
A Nortel Application Switch supports up to 16 real ports per server when multiple rports are enabled. This feature allows the network administrator to congure up to 16 real ports for a single service port. This feature is supported in Layer 4 and Layer 7 and in cookie-based and SSL persistence switching 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 mapping combination as a distinct real server. Note: For each real server, you can only congure one service with multiple real ports. Consider the following network:
Basic Virtual Port to Real Port Mapping Conguration
Domain Name www.abcxyz.c om
Virtual Server IP Address 192.168.2.100
Ports Activated 80 (HTTP)
Port Mapping Real Server IP Address 8001 (rport 1) 8002 (rport 2) 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 address 192.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 Metric

For each service, a real server is selected using the congured load balancing metric (hash, leastconns, minmisses, or roundrobin). To ensure even distribution, once an available server is selected, the switch uses the roundrobin metric to choose a real port to receive the incoming connection. If the algorithm is leastconns, the switch sends the incoming connections to the logical real server (real server IP address/port combination) with the least number of connections. The /cfg/slb/virt command denes the real server TCP or UDP port assigned to a service. By default, this is the same as the virtual port (service virtual port). If rport is congured to be different from the virtual port dened 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, congure this real server port option to be a value of 0. However, note that you cannot congure multiple services with multiple rports in the same server if the multiple rport feature is enabled.
Conguring Multiple Service Ports

Two commands, addport and remport, under the real server menu allow users to add or remove multiple service ports associated with a particular server. (A service port is a TCP or UDP port number.) For example: addport 8001 and remport 8001. Step 1 Action Congure the real servers.
.
237
>> >> >> >>
# # # #
/cfg/slb/real /cfg/slb/real /cfg/slb/real /cfg/slb/real
1/rip 2/rip 3/rip 4/rip
192.168.2.1/ena 192.168.2.2/ena 192.168.2.3/ena 192.168.2.4/ena
Add all four servers to a group.

>> >> >> >> >> # /cfg/slb/group 1 Real server Group 1# Real server Group 1# Real server Group 1# Real server Group 1#
add add add add
1 2 3 4
Congure a virtual server IP address.

>> # /cfg/slb/virt 1/vip 192.168.2.100/ena
Turn on multiple rport for Port 80.

>> # /cfg/slb/virt 1/service 80/rport 0
Add the ports to which the Web server listens.

>> # /cfg/slb/real 1/addport 8001 >> # addport 8002 >> # /cfg/slb/real 2/addport 8001 >> # addport 8002 >> # /cfg/slb/real 3/addport 8001 >> # addport 8002 >> # /cfg/slb/real 4/addport 8001 >> # addport 8002 (Add port 8001 to real server 1) (Add port 8002 to real server 1) (Add port 8001 to real server 2) (Add port 8002 to real server 2) (Add port 8001 to real server 3) (Add port 8002 to real server 3) (Add port 8001 to real server 4) (Add port 8002 to real server 4)
End
.
Direct Server Return

Some clients may need Direct Server Return (DSR) feature allows the server to respond directly to the client. This capability is useful for sites where large amounts of data are owing from servers to clients, such as with content providers or portal sites that typically have asymmetric trafc patterns. DSR and content-intelligent Layer 7 switching cannot be performed at the same time because content intelligent switching requires that all frames go back to the switch for connection splicing. Note: DSR requires that the server be set up to receive frames that have a destination IP address that is equal to the virtual server IP address.
How Direct Server Return Works

The sequence of steps that are executed in this scenario are shown in "Direct Server Return" (page 238):
Direct Server Return
Step 1 2
Action A client request is forwarded to the Nortel Application Switch. Because only MAC addresses are substituted, the switch forwards the request to the best server, based on the congured load-balancing policy. 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
.
239
End
Direct Access Mode

Direct Access Mode (DAM) allows any client to communicate with any real servers load-balanced service. Also, with DAM enabled, any number of virtual services can be congured to load balance a real service. Direct Access Mode enables both Client and Server processing on the same port to handle trafc that requires direct access to real servers.
Conguring Global Direct Access Mode

Direct access mode can be congured globally on the switch using the following command:
>> Main# /cfg/slb/adv/direct e Current Direct Access Mode: disabled New Direct Access Mode: enabled
When DAM (/cfg/slb/adv/direct) is enabled on a switch, any client can communicate with any real servers load-balanced service. Also, with DAM enabled, any number of virtual services can be congured to load balance a real service. With Direct Access Mode, trafc that is sent directly to real server IP addresses (instead of the virtual server IP address) is excluded from load balancing decisions. The same clients may also communicate to the virtual server 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 trafc to go to specic real servers based on inspection of HTTP headers, content identiers such as 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 default gateway load balancing is supported only when ltering is enabled, a proxy IP address is congured, or URL parsing is enabled on any switch port.
.
Blocking Direct Access Mode on Selected Services

When Direct Access Mode is enabled globally on the switch, it can also be disabled on selected virtual servers and virtual services. For example, you have enabled direct access mode on the switch so that it can support content-intelligent load balancing applications such as those described 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 switchs session table. In order to block use of DAM for the UDP protocol (service port 9200), enter the 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 command requires that DAM be enabled globally on the switch. If DAM is not enabled globally on the switch, the direct disable command has no effect. When direct access mode is enabled on the switch and disabled on a virtual server/virtual port pair, direct access to other real servers (those servers that are not servicing a virtual server/virtual port pair with direct access mode disabled) is still allowed. Note 2: DAM cannot be disabled for FTP and RTSP services.
Assigning Multiple IP Addresses

One way to provide both SLB access and direct access to a real server is to assign multiple IP addresses to the real server. For example, one IP address could be established exclusively for SLB and another could be used for direct access needs.
Using Proxy IP Addresses

Proxy IP addresses are used primarily to eliminate SLB topology restrictions in complex networks (see "Proxy IP Addresses" (page 228)). Proxy IP addresses can also provide direct access to real servers. If the switch is congured with proxy IP addresses and the client port is enabled for proxy, the client can access each real server directly using the real servers IP address. To directly access a real server, the switch port connected to the real server must have server processing disabled. However, if DAM is enabled (/cfg/slb/adv/direct ena), server processing must be enabled on the server port regardless of the proxy setting and SLB is still accessed using the virtual server IP address.
.
241
Mapping Ports
When SLB is used without proxy IP addresses and without DAM, the Nortel Application Switch must process the server-to-client responses. If a client were to access the real server IP address and port directly, bypassing client processing, the server-to-client response could be mishandled by SLB processing as it returns through the Nortel Application Switch, with the real server IP address getting remapped back to the virtual server IP address on the Nortel Application Switch. First, two port processes must be executed on the real server. One real server port handles the direct trafc, and the other handles SLB trafc. Then, the virtual server port on the Nortel Application Switch must be mapped to the proper real server port. In "Mapped and Nonmapped Server Access" (page 241), clients can access SLB services through well-known TCP port 80 at the virtual servers IP address. The Nortel Application Switch behaving like a virtual server is mapped to TCP port 8000 on the real server. For direct access that bypasses the virtual server and SLB, clients can specify well-known TCP port 80 as the real servers IP address.
Mapped and Nonmapped Server Access
Note: Port mapping is supported with DAM when ltering is enabled, a proxy IP address is congured, or URL parsing is enabled on any switch port. For more information on how to map a virtual server port to a real server port, see "Mapping Ports" (page 234).
.
Monitoring Real Servers

Typically, the management network is used by network administrators to monitor real servers and services. By conguring the mnet and mmask options of the SLB Conguration Menu (/cfg/slb/adv), you can access the real services being load balanced. Note: Clients on the management network do not have access to SLB services and cannot access the virtual services being load balanced. The mnet and mmask options are described below: mnet If dened, management trafc with this source IP address is allowed direct (non-SLB) access to the real servers. Only specify an IP address in dotted decimal notation. A range of IP addresses is produced when used with the mmask option. mmask This IP address mask is used with mnet to select management trafc that is allowed direct real server access only.
Delayed Binding
The delayed binding feature on the switch prevents SYN Denial-of-Service (DoS) attacks on the server. DoS occurs when the server or switch is denied servicing the client because it is saturated with invalid trafc. Typically, a three-way handshake occurs before a client connects to a server. The client sends out a synchronization (SYN) request to the server. The server allocates an area to process the client requests, and acknowledges the client by sending a SYN ACK. The client then acknowledges the SYN ACK by sending an acknowledgement (ACK) back to the server, thus completing the three-way handshake. "DoS SYN Attacks without Delayed Binding" (page 243) illustrates a classic type of SYN DoS attack. If the client does not acknowledge the servers SYN ACK with a data request (REQ) and, instead, sends another SYN request, the server gets saturated with SYN requests. As a result, all of the servers resources are consumed and it can no longer service legitimate client requests.
.
Server Load Balancing DoS SYN Attacks without Delayed Binding
243
Using a Nortel Application Switch with delayed binding, as illustrated in "Repelling DoS SYN Attacks With Delayed Binding" (page 244), the Nortel Application Switch intercepts the client SYN request before it reaches the server. The Nortel Application Switch responds to the client with a SYN ACK that contains embedded client information. The Nortel Application Switch does not allocate a session until a valid SYN ACK is received from the client or the three-way handshake is complete.
.
244 Part 3: Application Switching Fundamentals Repelling DoS SYN Attacks With Delayed Binding
Once the Nortel Application Switch receives a valid ACK or DATA REQ from the client, the Nortel Application Switch sends a SYN request to the server on behalf of the client, waits for the server to respond with a SYN ACK, and then forwards the clients DATA REQ to the server. Basically, the Nortel Application Switch delays binding the client session to the server until the proper handshakes are complete. Thus, with delayed binding, two independent TCP connections span a session: one from the client to the Nortel Application Switch and the second from the switch to the selected server. The switch temporarily terminates each TCP connection until content has been received, thus preventing the server from being inundated with SYN requests. Note: Delayed binding is automatically enabled when content intelligent switching features are used. However, if you are not parsing content, you must explicitly enable delayed binding if desired.
Conguring Delayed Binding

To congure your switch for delayed binding, use the following command:
.
245
>> # /cfg/slb/virt <virtual server number> /service <service type> /dbind
Note: Enable delayed binding without conguring any HTTP SLB processing or persistent binding types. To congure delayed binding for cache redirection, see "Delayed Binding for Cache Redirection" (page 417).
Detecting SYN Attacks

In Nortel Application Switch Operating System, SYN attack detection is enabled by default, whenever delayed binding is enabled. SYN attack detection: Provides a way to track half open connections Activates a trap notifying that the congured 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 sessions are being generated on the Nortel Application Switch. Half-open sessions show an incomplete three-way handshake between the server and the client. 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 the number of new half-open sessions for a set period of time. If the value exceeds the threshold, then a syslog message and an SNMP trap are generated. You can change the default parameters for detecting SYN attacks in the /cfg/slb/adv/synatk menu. You can specify how frequently you want to check for SYN attacks, from 2 seconds to a minute and modify the default threshold representing the number of new half-open sessions per second.
Session Timeout Per Service

The Nortel Application Switch Operating System implements a feature that allows for the conguration of session timeout based on a service timeout instead 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. Once the timeout value for the service is congured that will be used instead. This
.
is useful in instances where sessions need to be kept alive after their real server congured timeout expires. An FTP session could be kept alive after its server dened timeout period for example. The following is an example of how a timeout of 10 minutes would be congured for HTTP (service 80) on virtual server 1: Step 1 Action Select service 80.
>> Main# /cfg/slb/virt 1/service 80
Set the service timeout value.

>> Virtual Server 1 http Service# tmout 10
Save conguration.
>> Virtual Server 1 http Service# apply >> Virtual Server 1 http Service# save
End
IPv6 and Server Load Balancing

The Nortel Application Switch Operating System provides a full range of server load balancing options for IPv6. IPv6 virtual address trafc can either be load balanced to IPv4 or IPv6 real servers. In the case of IPv4 real servers, the Nortel Application Switch Operating System converts the IPv6 client packet to an IPv4 packet before it is forwarded to the server. This packet is transmitted directly to IPv4 servers. Note: Since IPv6 does not allow intermediary routers or switches to fragment packets, internal translation of the maximum IPv4 packet (MTU of 1500) cannot be translated without fragmenting. It is therefore a requirement for all IPv4 Real Servers using IPv6 SLB to be congured with a maximum MTU less than or equal to 1440. For example, in the Windows 2003 environment, run REGEDIT in the Windows platform real servers to add a new parameter to the registry with the keyword MTU, using REG_DWORD with a decimal value of 1440, in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces \XX where XX is the correct interface for the congured IP address.
.
247
To implement IPv6 server load balancing, real servers are set to be either IPv4 or IPv6 servers. Similarly, real server groups are set to contain either IPv4 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. Switch ports and VLANs can be assigned either one type or the other or both. The appropriate PIP is used in load balancing operations based on the IP version of the incoming packet. Note: Only basic Layer 4 server load balancing is supported and includes support for Direct Access Mode (DAM). For conceptual information on basic Layer 4 load balancing, refer to "Understanding Server Load Balancing" (page 188) and "Implementing Basic Server Load 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 and when the fragments are in order.
IPv6 to IPv4 Server Load Balancing

"IPv6 to IPv4 Layer 4 SLB Example" (page 248) demonstrates server load balancing between IPv6 clients and IPv4 servers.
.
248 Part 3: Application Switching Fundamentals IPv6 to IPv4 Layer 4 SLB Example
The following procedure is used to congure IPv6 support for load balancing IPv4 real servers. The specic commands, as presented in the example, would replicate the topology in "IPv6 to IPv4 Layer 4 SLB Example" (page 248). Step 1 Action Congure 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
Congure VLAN for Interface 1.
.
249
>> Main# /cfg/l2/vlan 3 >> VLAN 3# ena >> VLAN 3# add 13 Port 13 is an UNTAGGED port and 1. Confirm changing PVID from 1 to >> VLAN 3# add 14 Port 14 is an UNTAGGED port and 1. Confirm changing PVID from 1 to >> VLAN 3# add 15 Port 15 is an UNTAGGED port and 1. Confirm changing PVID from 1 to
its current PVID is 3 [y/n]: y
Congure 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
Congure IPv6 default gateway.

>> >> >> >> >> Main# /cfg/l3/gw 5 Default gateway 5# Default gateway 5# Default gateway 5# Default gateway 5#
ena ipver v6 addr 2005:0:0:0:0:0:0:24 vlan 1
Congure 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
Assign HTTP service to virtual server.

>> Main# /cfg/slb/virt 1/service http >> Virtual Server 1 http Service# group 1
Enable Server Load Balancing.
.
>> Main# /cfg/slb/on
Congure 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
Congure Client and Server Processing on Client and Server ports.

>> >> >> >> >> >> >> >> 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
Congure a proxy IP and enable it on the client port. The proxy IP address is used to converge the IPv4 and IPv6 trafc. Optionally, the proxy IP address can be assigned to a VLAN instead of the port. To enable it on the VLAN use the command /cfg/slb/pip/type vlan instead of /cfg/slb/pip/type port.
>> >> >> >> 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
11
.
251
>> Management Port# apply >> Management Port# save
End
IPv6 to IPv6 Server Load Balancing

"IPv6 to IPv6 Layer 4 SLB Example" (page 251) demonstrates load balancing between IPv6 clients and IPv6 servers.
IPv6 to IPv6 Layer 4 SLB Example
The following procedure is used to congure IPv6 support for load balancing IPv6 real servers. The specic commands, as presented in the example, would replicate the topology in "IPv6 to IPv6 Layer 4 SLB Example" (page 251).
.
Step 1
Action Congure 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
Globally enable load balancing.

>> Main# /cfg/slb >> Layer 4# on
Congure 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
Congure IPv6 real server groups.

>> >> >> >> Main# /cfg/slb/group Real Server Group 1# Real Server Group 1# Real Server Group 1# 1 ipver v6 add 1 add 2
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
Enable server processing on the SLB ports.

>> >> >> >> Main# /cfg/slb/port SLB Port 21# server Main# /cfg/slb/port SLB Port 22# server 21 ena 22 ena
.
253
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
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 Information

The following three commands are used to acquire IPv6 Layer 4 session information: 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 Checks

Health checking is supported for IPv6 real servers. ICMP, TCP, HTTP, and script health checking are supported. For information on the conguration and 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. The following topics are addressed in this chapter: "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 Application Switch Operating System Command Reference.
IP Server Load Balancing

IP server load balancing allows you to congure your Nortel Application Switch for server load balancing based on clients IP address only. Typically, the client IP address is used with the client port number to produce a session identier. When the Layer 3 option is enabled, the switch uses only the client IP address as the session identier. To congure 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 >
.
255
FTP Server Load Balancing

As dened in RFC 959, FTP uses two connectionsone for control information and another for data. Each connection is unique. Unless the client requests a change, the server always uses TCP port 21 (a well-known port) for control information, and TCP port 20 as the default data port. FTP uses TCP for transport. After the initial three-way handshake, a connection is established. When the client requests any data information from the server, it issues a PORT command (such as ls, dir, get, put, mget and 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. Because the client also initiates the connection to the control channel, the passive FTP mode does not pose a problem with rewalls and is the most common mode of operation.
Nortel Application Switch Operating System supports both active and passive modes of FTP operation. You can switch from active to passive or vice versa in the same FTP session.
Active FTP Conguration

To create an Active FTP conguration both the FTP and FTP-Data services must be enabled on the virtual server. Perform the following procedure to create an Active FTP conguration on the switch: Step 1 Action Add the FTP virtual service to the virtual server.
Add the FTP-Data virtual service to the virtual server.

Apply and save the conguration change.

>> Main# apply >> Main# save
End
.
FTP Network Topology Restrictions

FTP 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.
Conguring FTP Server Load Balancing

Step 1 2 Action Make sure that a proxy IP address is enabled on the client port(s) or DAM is enabled. Make sure the virtual port for FTP is set up for the virtual server.
>> Main# /cfg/slb/virt 1/service ftp
(Optional) Enable FTP parsing on the FTP service.

>> Main# /cfg/slb/virt 1/service 21/ftpp ena
To make your conguration changes active, enterapplyat any prompt in the CLI.
>> Virtual Server 1 ftp Service# apply
End
TFTP Server Load Balancing

As dened in RFC 1350, Trivial File Transfer Protocol (TFTP) can only read and write les from/to a remote server. TFTP uses UDP datagrams to transfer data. A transfer begins with a request to read or write a le, which also serves to request a connection. If the server grants the request, the connection is opened and the le is sent in xed length blocks of 512 bytes. Each data packet contains one block of data, and must be acknowledged by an acknowledgment packet before the next packet can be sent. A data packet of less than 512 bytes signals termination of a transfer. TFTP server load balancing server is similar to other types of server load balancing. It uses congured SLB metric to select TFTP server. No additional commands are required to load balance to TFTP servers.
.
257
Requirements
Load balancing service port 69 must be selected. DAM must be enabled. UDP must be enabled (/cfg/slb/virt <x> /service tftp/udp ena) PIP is not supported because the server port is changed. PIP uses server port for allocating a pport. Multiple rports are not supported.
Conguring TFTP Server Load Balancing

Step 1 2 Action Make sure that Direct Access Mode (DAM) is enabled. Make sure the virtual port for TFTP is set up for the virtual server.
>> # /cfg/slb/virt 1/service tftp
To make your conguration changes active, enter apply at any prompt in the CLI.
>> Virtual Server 1 ftp Service# apply
End
Lightweight Directory Access Server SLB

As dened in RFC 2251, Lightweight Directory Access Protocol (LDAP) is an application-level protocol between LDAP clients and servers, which allows clients to retrieve LDAP directory entries via the Internet. The client sends a protocol operation request to the server and the server responds with a response. If it is based on TCP, port 389 is used. Once a connection is setup between client and server, client issues operations to the server, and server sends responses back to the client. Before LDAP directory operations can be issued, in general a bind operation is issued, in which authorization is sent as well.
.
LDAP Operations and Server Types

There are two kinds of LDAP operations, read and write. Clients use read operations to browse directory on server, and use write operations to modify directory on server. LDAP servers are categorized into two kinds, read and write servers. Read servers only conduct read operations, and write servers perform both read and write operations.
How LDAP SLB Works

An LDAP connection is set up via L4 load balancing and is bound to a read server. After that, operation frames received by the switch are checked (at Layer 7) to determine if there are any write operations. The bind and write operation data frames are stored for potential later use. When a write operation arrives, the switch disconnects the connection to the read server and reinitiate another connection with the write server without the clients knowledge. Once the connection is set up with write server, all the later requests goes to the write server until unbind request is received by the switch. All these operations occur within one TCP connection. After the reset is sent to the old server, connection is set up to the new server. Stored data frames are forwarded to the server. After write operation is forwarded to the server, the connection is spliced.
Selectively Resetting a Real Server

If a long-lived LDAP connection exceeds the Nortel Application Switchs maximum session length (32,768) minutes, the session will age out before the LDAP connection is closed. The Nortel Application Switch may then create another session to accept the same connection data. To prevent this, Nortel Application Switch Operating System can be congured to send a reset to a real server whose session has timed out before the LDAP connection is closed. To enable a session reset for a virtual server that is running the LDAP service, enter the following command:
>> # /cfg/slb/virt 1/service ldap/reset enable
"Layer 4 DNS Load Balancing" (page 261) shows four LDAP servers load balancing LDAP queries.
.
Load Balancing Special Services LDAP Load Balancing
259
Conguring LDAP SLB

Step 1 Action Enable server load balancing.
>> # /cfg/slb/on
Congure the four real LDAP servers and their real IP addresses.
>> # /cfg/slb/real 20 >> Real server 20 # ena >> Real server 20 # rip 10.10.10.20 >> Real server 20 # layer7/ >> Real Server 20 Layer 7 Commands# ldapwr e (Enable real server 20) (Specify the IP address) (Select the Layer 7 menu) (Enable LDAP read-write)
/cfg/slb/real 21/ena/rip 10.10.10.21/layer7/ldapwr e (Configure and enable LDAP write server 21) /cfg/slb/real 22/ena/rip 10.10.10.22/layer7/ldapwr e (Configure and enable LDAP write server 21) /cfg/slb/real 26/ena/rip 10.10.10.26/layer7/ldapwr e (Configure and enable LDAP write server 21)
Congure group 1 for LDAP.
.
>> # /cfg/slb/group 1 >> Real server group 1 # metric roundrobin >> Real server group 1 # add 20 >> Real server group 1 # add 21 >> Real server group 1 # add 22 >> Real server group 1 # add 26
(Select real server group 1) (Specify the load balancing metric for group 1) (Add real server 20) (Add real server 21) (Add real server 22) (Add real server 26)
End
Step 1
Action Congure and enable a virtual server IP address 1 on the switch.

>> # /cfg/slb/virt 1/vip 20.20.20.20 >> Virtual Server 1# ena (Specify the virt server IP address) (Enable the virtual server)
Set up the LDAP service for the virtual server, and add real server group 1.
>> Virtual Server 1# service ldap >> Virtual Server 1 LDAP Service# group 1 (Specify the LDAP service) (Select the real server group)
Enable delayed binding. Delayed binding is required in order to process session requests with a TCP three-way handshake.
>> Virtual Server 1 LDAP Service# dbind ena (Enable delayed binding)
Enable LDAP load balancing.

>> # /cfg/slb/virt 1/service ldap/ldapslb ena (Enable LDAP balancing)
(Optional) Enable session reset for long LDAP connections.

>> # /cfg/slb/virt 1/service ldap/reset enable

.
261
Apply and save your conguration.

>> Virtual Server 1 LDAP Service# apply >> Virtual Server 1 LDAP Service# save
End
Domain Name Server (DNS) SLB

In Nortel Application Switch Operating System, DNS load balancing allows you to choose the service based on the two forms of DNS queries: UDP and TCP. This enables the switch to send TCP DNS queries to one group of real servers and UDP DNS queries to another group of real servers. The requests are then load balanced among the real servers in that group. "Layer 4 DNS Load Balancing" (page 261) shows four real servers load balancing UDP and TCP queries between two groups.
Layer 4 DNS Load Balancing
.
Note: You can congure both UDP and TCP DNS queries for the same virtual server IP address.
Preconguration Tasks
Step 1 Action Enable server load balancing.
>> # /cfg/slb/on
Congure the four real servers and their real IP addresses.

>> # /cfg/slb/real 20 >> Real server 20 # ena >> Real server 20 # rip 10.10.10.20 (Enable real server 20) (Specify the IP address)
>> Real server 20 # /cfg/slb/real 21 >> Real server 21 # ena >> Real server 21 # rip 10.10.10.21 (Enable real server 21) (Specify the IP address)
>> Real server 20 # /cfg/slb/real 22 >> Real server 22 # ena >> Real server 22 # rip 10.10.10.22 (Enable real server 22) (Specify the IP address)
>> Real server 20 # /cfg/slb/real 26
.
263
>> Real server 26 # ena >> Real server 26 # rip 10.10.10.26
(Enable real server 26) (Specify the IP address)
Congure group 1 for UDP and group 2 for TCP.

>> Main # /cfg/slb/group 1 >> Real server group 1 # metric roundrobin >> Real server group 1 # health udpdns >> Real server group 1 # add 20 >> Real server group 1 # add 21 (Select real server group 1) (Specify the load balancing metric for group 1) (Set the health check to UDP) (Add real server 20) (Add real server 21) (Specify the load balancing metric for group 2) (Set the health check to TCP) (Add real server 22) (Add real server 26)
>> Real server group 1 # /cfg/slb/group 2 >> Real server group 2 # metric roundrobin >> Real server group 2 # health dns >> Real server group 2 # add 22 >> Real server group 2 # add 26
For more information on conguring health check, see "UDP-Based DNS Health Checks" (page 481). 4 Dene and enable the server ports and the client ports. For more information, see step 6 step 6. Some DNS servers initiate upstream requests and must be congured both as server and client. End
Conguring UDP-based DNS Load Balancing

Step 1 Action Congure and enable a virtual server IP address 1 on the switch.
.
Set up the DNS service for the virtual server, and add real server group 1.
>> Virtual Server 1# service dns >> Virtual Server 1 DNS Service# group 1 (Specify the DNS service) (Select the real server group)
Disable delayed binding. Delayed binding is not required because UDP does not process session requests with a TCP three-way handshake.
>> Virtual Server 1 DNS Service# dbind dis (Disable delayed binding)
Enable UDP DNS queries.

>> Virtual Server 1 DNS Service# udp ena (Enable UDP balancing)

>> Virtual Server 1 DNS Service# apply >> Virtual Server 1 DNS Service# save
End
Conguring TCP-based DNS Load Balancing

Step 1 Action Congure and enable the virtual server IP address 2 on the switch.
Set up the DNS service for virtual server, and select real server group 2.
.
265
>> Virtual Server 2# service dns >> Virtual Server 2 DNS Service# group 2
(Specify the DNS service) (Select the real server group)
Enable delayed binding.

>> Virtual Server 2 DNS Service# dbind ena (Enable delayed binding)
As this is TCP-based load balancing, make sure to disable UDP DNS queries.
>> Virtual Server 2 DNS Service# udp dis (Disable UDP balancing)

>> Virtual Server 2 DNS Service# apply >> Virtual Server 2 DNS Service# save
End
Layer 7 DNS Load Balancing

The Internet name registry has become so large that a single server cannot keep track of all the entries. This is resolved by splitting the registry and saving it on different servers. If you have large DNS server farms, Nortel Application Switch Operating System allows you to load balance trafc based on DNS names. To load balance DNS names, the host name is extracted from the query, processed by the regular expressions engine, and the request is sent to the appropriate real server. For example, "Load Balancing DNS Queries" (page 266) shows a DNS server farm load balancing DNS queries based on DNS names. Requests with DNS names beginning with A through G are sent to Server 1; DNS names beginning with H through M are sent to Server 2; DNS names beginning with N through T are sent to Server 3; DNS names beginning with U through Z are sent to Server 4.
.
266 Part 3: Application Switching Fundamentals Load Balancing DNS Queries
To congure the switch for DNS load balancing, perform the following procedure: Step 1 Action Before you can congure DNS load balancing, ensure that the switch has already been congured for basic SLB with the following tasks: Assign an IP address to each of the real servers in the server pool. Dene an IP interface on the switch. Dene each real server (DNS server address). Assign servers to real server groups. Dene virtual servers and services. Enable SLB. For information on how to congure your network for SLB, see "Server Load Balancing" (page 188)." 2 Dene server port and client port.
Enable DNS load balancing.

>> # /cfg/slb/virt 1 >> Virtual Server 1 # service 53 >> Virtual Server 1 DNS Service # dnsslb ena (Select the virtual server) (Select the DNS service) (Enable DNS SLB)
.
267
If using a TCP-based DNS server, enable delayed binding (if using a UDP-based DNS server, do not enable delayed binding).
>> Virtual Server 1 DNS Service# dbind ena

>> >> >> m >> # /cfg/slb/layer7/slb/addstr [abcdefg]+\.com Server Loadbalance Resource# addstr [hijklm]+\.com Server Loadbalance Resource# addstr [nopqrst]+\.co Server Loadbalance Resource# addstr [uvwxyz]+\.com
5 6
For easy conguration and identication, each dened string has an ID attached, as shown in the following example:
ID 1 2 3 4 5 SLB String any, cont 1024 www.[abcdefg]*.com, cont 1024 www.[hijklm]*.com, cont 1024 www.[nopqrst]*.com, cont 1024 www.[uvwxyz]*.com, cont 1024
Add the dened string IDs to the real server using the following command:
>> # /cfg/slb/real 1/layer7/addlb 2 >> # /cfg/slb/real 2/layer7/addlb 3 >> # /cfg/slb/real 3/layer7/addlb 4
Note: If you dont add a dened string (or add the dened string any) the server handles any request. End
.
Real Time Streaming Protocol SLB

Real Time Streaming ProtocolRTSP) is an application-level protocol for control over the delivery of data with real-time properties as documented in RFC 2326. RTSP is the proposed standard for controlling streaming data over the Internet. RTSP uses RTP (Real-Time Transport Protocol) to format packets of multimedia content. RTSP is designed to efciently broadcast audio-visual data to large groups. Typically, a multimedia presentation consists of several streams of data (for example, video stream, audio stream, and text) that must be presented in a synchronized fashion. A multimedia client like Real Player or Quick Time Player downloads these multiple streams of data from the multimedia servers and presents them on the player screen. RTSP is used to control the ow of these multimedia streams. Each presentation uses one RTSP control connection and several other connections to carry the audio/video/text multimedia streams. In this document, the term RTSP server refers to any multimedia server that implements the RTSP protocol for multimedia presentation. Note: RTSP Server Load Balancing cannot be set to None for the RTSP service 554.
How RTSP Server Load Balancing Works

The objective of RTSP server load balancing is to intelligently switch an RTSP request, and the other media streams associated with a presentation, to a suitable RTSP server based on the congured load-balancing metric. Typically, an RTSP client establishes a control connection to an RTSP server over TCP port 554 and the data ows over UDP or TCP. This port can be changed however. Nortel Application Switch Operating System supports two layer 7 metrics (URL hashing and URL pattern matching) and all layer 4 load-balancing metrics. This section discusses load balancing RTSP servers for layer 4; 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 Cache Redirection" (page 417). Note: This feature is not applicable if the streaming media (multimedia) servers use HTTP protocol to tunnel RTSP trafc. To ensure that RTSP server load balancing works, make sure the streaming media server is congured for RTSP protocol.
.
269
Supported RTSP Servers

In a typical scenario, the RTSP client issues several sequences of commands to establish connections for each component stream of a presentation. There are several variations to this procedure, depending upon the RTSP client and the server involved. For example, there are two prominent RTSP server and client implementations. The RTSP stream setup sequence is different for these two servers, and the switch handles each differently as shown below: Real Server Real Server from RealNetworks Corporation supports both UDP and TCP transport protocols for the RTSP streams. The actual transport is negotiated during the initialization of the connection. If TCP transport is selected, then all streams of data will ow in the TCP control connection itself. If UDP transport is chosen, the client and server negotiate a client UDP port, which is manually congurable. The real media les that the Real Server plays have the extension ".rm", ".ram" or ".smil". QuickTime Streaming Server QuickTime Streaming Server from Apple Incorporated supports a QuickTime presentation that typically has two streams and therefore uses four UDP connections exclusively for transport and one TCP control connection. QuickTime clients use a UDP port, which is manually congurable. The QuickTime les have the extension ".mov". Nortel Application Switch Operating System can also support other RTSP-compliant applications such as Microsoft Windows Media Server 9.
RTSP Port Conguration

Nortel Application Switch Operating System 24.0 features the ability to congure RTSP to use a port other than the default of 554. The following sample conguration outlines the steps necessary for RTSP port conguration: Step 1 Action Select a non-standard port to use for RTSP.
Configure RTSP load balancing on the selected port.
.
>> Main# /cfg/slb/virt 1/service 808/rtsp >> Main# /cfg/slb/virt 1/service 808/rtsp/rtspslb hash Note: The rtspslb options are: hash, pattern, l4hash, and none.
End
Conguring RTSP Load Balancing

In this example, the Nortel Application Switch is load balancing RTSP trafc between two media server farms as shown in "Load Balancing RTSP Servers" (page 270). One group of media servers consist of QuickTime servers and the other group of servers consist of RealNetworks servers. Each group has its own virtual server IP address. For example, three Real Networks servers host media les for NortelNews; similarly, another three QuickTime servers host media les for AlteonNews. The content is duplicated among the servers in each group. Depending on the client request type, the Nortel Application Switch is congured to load balance in the following way: Retrieving les from the Real Networks server group RTSP://www.NortelNews.com/*.ram, RTSP://www.NortelNews.com/*.rm, and RTSP://www.NortelNews.com/*.smil are load balanced among the Real Networks media servers using virtual IP address 30.30.30.100. Retrieving les from the QuickTime server group RTSP://www.NortelNews.com/*.mov is load balanced among the Quick Time media servers using virtual IP address 40.40.40.100.
Load Balancing RTSP Servers
.
271
Follow this procedure to congure the topology illustrated in "Load Balancing RTSP Servers" (page 270): Step 1 Action At the Nortel Application Switch, before you start conguring RTSP load balancing: 2 Connect each QuickTime server to the layer 2 switch Connect each RealNetworks server to the layer 2 switch Congure the IP addresses on all devices connected to the Nortel Application Switch Congure the IP interfaces on the switch Enable Direct Access Mode (DAM) Disable Bandwidth Management Disable proxy IP addressing
Enable server load balancing.

>> # /cfg/slb/on
Congure IP addresses for the real servers.

>> # /cfg/slb/real 1/rip 30.30.30.10/ena >> # /cfg/slb/real 2/rip 30.30.30.20/ena >> # /cfg/slb/real 3/rip 30.30.30.30/ena >> # /cfg/slb/real 4/rip 40.40.40.10/ena >> # /cfg/slb/real 5/rip 40.40.40.20/ena >> # /cfg/slb/real 6/rip 40.40.40.30/ena (Define IP address for Real server 1) (Define IP address for Real server 2) (Define IP address for Real server 3) (Define IP address for Real server 4) (Define IP address for Real server 5) (Define IP address for Real server 6)
Create a group to support RealNetworks servers.

>> # /cfg/slb/group 100 >>Real Server Group 100# add 1 (Define a group) (Add real server 1)
.
>>Real Server Group 100# add 2 >>Real Server Group 100# add 3
(Add real server 2) (Add real server 3)
Create a group to support QuickTime servers.

>> # /cfg/slb/group 200 >>Real Server Group 200# add 4 >>Real Server Group 200# add 5 >>Real Server Group 200# add 6 (Define a group) (Add real server 4) (Add real server 5) (Add real server 6)
Create a virtual server for the RealNetworks servers. To congure a virtual server for layer 4 load balancing of RTSP, select rtsp or port 554 as a service for the virtual server.
>> # /cfg/slb/virt 1 >>Virtual Server 1# vip 30.30.30.100 >>Virtual Server 1# service 554 >>Virtual Server 1 rtsp Service# group 100 (Select the virtual server) (Set IP address for the virtual server (Add the RTSP service for the virtual server) (Set the real server group)
>>Virtual Server 1 rtsp Service# /cfg/slb/virt 1/ena (Enable virtual server)
Create a virtual server for the QuickTime servers. To congure a virtual server for Layer 4 load balancing of RTSP, select rtsp or port 554 as a service for the virtual server.
>> # /cfg/slb/virt 2 >>Virtual Server 2# vip 40.40.40.100 >>Virtual Server 2# service 554 >>Virtual Server 2 rtsp Service# group 200 (Select the virtual server) (Set IP address for the virtual server (Add the RTSP service for the virtual server) (Set the Quicktime server group)
>>Virtual Server 2 rtsp Service# /cfg/slb/virt ena (Enable virtual server)
Enable server and client processing at the port level.
.
273
>> # /cfg/slb/port 25 >>SLB port 25# client ena >>SLB port 1# /cfg/slb/port 2 >>SLB port 2# server ena >>SLB port 2# /cfg/slb/port 3 >>SLB port 3# server ena >>SLB port 3# /cfg/slb/port 4 >>SLB port 4# server ena >>SLB port 4# /cfg/slb/port 13 >>SLB port 13# server ena >>SLB port 13# /cfg/slb/port 14 >>SLB port 14# server ena >>SLB port 14# /cfg/slb/port 15 >>SLB port 15# server ena
(Select the client port) (Enable client processing) (Select the server port) (Enable server processing) (Select the server port) (Enable server processing) (Select the server port) (Enable server processing) (Select the server port) (Enable server processing) (Select the server port) (Enable server processing) (Select the server port) (Enable server processing)

>> SLB port 15# apply >> SLB port 15# save
Clients retrieving les of type RTSP://nortelnews.com/headlines.ram use virtual IP address 30.30.30.100 of the RealNetworks server group and clients retrieving les of type RTSP://nortelnews.com/headlines.mov use virtual IP address 40.40.40.100 of the QuickTime server group. End
Content-Intelligent RTSP Load Balancing

Nortel Application Switch Operating System supports RTSP load balancing based on URL hash metric or string matching to load balance media servers that contain multimedia presentations. Because multimedia presentations consume a large amount of Internet bandwidth, and their correct presentation depends upon the real time delivery of the data over the Internet, several media servers contain the same multimedia data. For more conceptual information on RTSP, refer to "Real Time Streaming Protocol SLB" (page 268).
.
"Layer 7 RTSP Load Balancing" (page 275) shows two groups of media servers: Group 1 is congured for URL hashing and group 2 is congured for string matching. The media servers are cache servers congured in reverse proxy mode.
URL Hash
Use the URL hash metric to maximize client requests to hash to the same media server. The original servers push the content to the cache servers ahead of time. For example in "Layer 7 RTSP Load Balancing" (page 275), an ISP is hosting audio-video les for NortelNews on media servers 1, 2, 3, and 4. The domain name nortelnews.com associated with the virtual IP address 120.10.10.10 is congured for URL hash. The rst request for http://nortelnews.com/saleswebcast.rm hashes to media server 1. Subsequent requests for http://nortelnews.com/saleswebcast.rm from other clients or from client 1 will hash to the same server 1. Similarly, another request for http://nortelnews.com/marketingwebcast.rm may hash to media server 2, provided saleswebcast and marketingwebcast media les are located in the origin servers. Typically, a set of related les (audio, video, and text) of a presentation are usually placed under the same directory (called container directory). Nortel Application Switch Operating System URL hashing ensures that the entire container is cached in a single cache by using the entire URL to compute the hash value and omitting the extension (for example, .ram, .rm, .smil) occurring at the end of the URL.
String Matching
Use the string matching option to populate the RTSP servers with content-specic information. For example, you have clients accessing audio-video les on Nortel1 and clients accessing audio-video les on Nortel2. You can host theNortel1 media les on media servers 5 and 6 and host Nortel2 media les on media servers 7 and 8.
.
Load Balancing Special Services Layer 7 RTSP Load Balancing
275
Follow this procedure to congure the topology illustrated in "Layer 7 RTSP Load Balancing" (page 275): Step 1 Action Before you start conguring RTSP load balancing, congure the application switch for standard server load balancing as described in "Conguring Server Load Balancing" (page 194): Connect each Media server to the application switch Congure the IP addresses on all devices connected to the switch Congure the IP interfaces on the switch Enable server load balancing (/cfg/slb/on) Enable client processing at the client port (/cfg/slb/port 1/client ena) Enable server processing at the server ports 2 and 7 (for example, /cfg/slb/port 2/server ena) Enable Direct Access Mode (DAM) Disable Bandwidth Management
.
Disable proxy IP addressing
Congure IP addresses for the real servers.

>> # /cfg/slb/real 1/rip 10.10.10.1/ena >> # /cfg/slb/real 2/rip 10.10.10.2/ena >> # /cfg/slb/real 3/rip 10.10.10.3/ena >> # /cfg/slb/real 4/rip 10.10.10.4/ena >> # /cfg/slb/real 5/rip 10.10.10.5/ena >> # /cfg/slb/real 6/rip 10.10.10.6/ena >> # /cfg/slb/real 7/rip 10.10.10.7/ena >> # /cfg/slb/real 8/rip 10.10.10.8/ena (Define IP address for Real server 1) (Define IP address for Real server 2) (Define IP address for Real server 3) (Define IP address for Real server 4) (Define IP address for Real server 5) (Define IP address for Real server 6) (Define IP address for Real server 7) (Define IP address for Real server 8)
Create a group to support RealNetworks servers.

>> # /cfg/slb/group 100 >>Real Server Group 100# add 1 >>Real Server Group 100# add 2 >>Real Server Group 100# add 3 >>Real Server Group 100# add 4 (Define a group) (Add real server 1) (Add real server 2) (Add real server 3) (Add real server 4)
Create a group to support QuickTime servers.

>> # /cfg/slb/group 200 >>Real Server Group 200# add 5 >>Real Server Group 200# add 6 >>Real Server Group 200# add 7 >>Real Server Group 100# add 8 (Define a group) (Add real server 5) (Add real server 6) (Add real server 7) (Add real server 8)
Create a virtual server for group 1 media servers. Congure a virtual server and select rtsp or port 554 as a service for the virtual server.
.
277
>> # /cfg/slb/virt 1 >>Virtual Server 1# vip 120.10.10.10 >>Virtual Server 1# service 554 >>Virtual Server 1 rtsp Service# group 100
(Select the virtual server) (Set IP address for the virtual server (Add the RTSP service for the virtual server) (Set the real server group)
>>Virtual Server 1 rtsp Service# /cfg/slb/virt 1 ena (Enable virtual server)
Congure URL hash-based RTSP load balancing for group 1 servers. URL hashing maintains persistency by enabling the client to hash to the same media server.
>> Virtual Server 1 rtsp Service# rtspslb hash
Create another virtual server for group 2 media servers. Congure a virtual server and select rtsp or port 554 as a service for the virtual server.
>> # /cfg/slb/virt 2 >>Virtual Server 2# vip 120.10.10.20 >>Virtual Server 2# service 554 >>Virtual Server 2 rtsp Service# group 200 (Select the virtual server) (Set IP address for the virtual server) (Add the RTSP service for the virtual server) (Set the real server group)
>>Virtual Server 2 rtsp Service# /cfg/slb/virt 2 ena (Enable virtual server)
Congure string matching-based RTSP load balancing for group 2 servers. Enable layer 7 pattern matching
>> Virtual Server 2 rtsp Service# rtspslb pattern (Enable Layer 7 pattern matching)
Add URL strings.
.
>> # /cfg/slb/layer7/slb/adds tr nortel1.mov
(Add URL strings)
>> Server Loadbalance Resource# addstr nortel2.mov

>> Server Loadbalance Resource# apply >> Server Loadbalance Resource# save
Identify the dened string IDs.

>> Server Loadbalance Resource# cur
For easy conguration and identication, each dened string has an ID attached, as shown in the following example: Number of entries: three
ID 1 2 3 SLB String any, cont 1024 nortel1.mov, cont 1024 nortel2.mov, cont 1024
Add the dened string IDs to the real servers as shown in "Layer 7 RTSP Load Balancing" (page 275).
>> >> >> >> >> >> >> >> # /cfg/slb/real 5/layer7 Real server 5 Layer 7 Commands# addlb Real server 5# /cfg/slb/real 6/layer7 Real server 6 Layer 7 Commands# addlb Real server 6# /cfg/slb/real 7/layer7 Real server 7 Layer 7 Commands# addlb Real server 7# /cfg/slb/real 8/layer7 Real server 8 Layer 7 Commands# addlb
2 2 3 3

>> Real server 8# apply >> Real server 8# save
Clients retrieving RTSP://nortelnews.com/saleswebcast.rm hash to the same media server1, 2, 3, or 4.
.
279
A client request of the form RTSP://120.10.10.20/../nortel1.mov is load balanced between RTSP servers 5 and 6 using string matching. A client request of the form RTSP://120.10.10.20/../nortel2.mov is load balanced between RTSP servers 7 and 8. End
Wireless Application Protocol SLB

Wireless Application Protocol ( WAP) is an open, global specication for a suite of protocols designed to allow wireless devices to communicate and interact with other devices. It empowers mobile users with wireless devices to easily access and interact with information and services instantly by allowing non-voice data, such as text and images, to pass between these devices 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 operating systemswith the goal of inter-operability. A WAP Gateway translates Wireless Markup Language (WML)which is a WAP version of HTMLinto HTML/HTTP so that requests for information can be serviced by traditional Web servers. To load balance WAP trafc among available parallel servers, the switch must provide persistency so that the clients can always go to the same WAP gateway to perform WAP operation. "Load Balancing WAP Gateways" (page 279) shows the user is rst authenticated by the remote access server. In this example the RADIUS servers are integrated with the WAP gateways.
Load Balancing WAP Gateways
.
Nortel Application Switch Operating System allows you to congure the Nortel Application Switch to select a WAP gateway for each client request based 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 Entries

RADIUS, a proposed IETF standard is a client/server protocol that enables remote access servers to communicate with a central server to authenticate dial-in users and authorize their access to the requested network or service. RADIUS allows a company to maintain user proles in a central database that all remote servers can share. It provides better security, allowing a company to set up a policy that can be applied at a single administered network point. The RADIUS server uses a static session entry to determine which real WAP gateway should receive the client sessions. Typically, each WAP gateway is integrated with a RADIUS server on the same host, and a RADIUS request packet is allowed to go to any of the RADIUS servers. Upon receiving a request from a client, the RADIUS server instructs the switch to create a static session entry in the switch via Transparent Proxy Control Protocol (TPCP). TPCP is an Nortel proprietary protocol that is used to establish communication between the RADIUS servers and the Nortel Application Switch. It is UDP-based and uses ports 3121, 1812, and 1645. The RADIUS servers use TPCP to add or delete static session entries on the switch. Typically, a regular session entry is added or removed by the switch itself. A static session entry, like a regular session entry, contains information such as the client IP address, the client port number, real port number, 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 balancing methods, the entries will continue to age out. Because TPCP is UDP-based, the Add/Delete Session requests may get lost during transmission. The WAP gateway issues another Add Session request on detecting that it has lost a request. The WAP gateway detects this situation when it receives WAP trafc that does not belong to that WAP gateway. If a Delete Session request is lost, it is overwritten by another Add Session request.
.
281
How WAP SLB Works with Static Session Entries

1. On dialing, the user is rst authenticated by the Remote Access Server (RAS). 2. The RAS sends a RADIUS authentication request to one of the RADIUS servers, which can be integrated with a WAP gateway. 3. If the user is accepted, the RADIUS server determines which WAP gateway is right for this user and informs the switch of the decision via TPCP. 4. The switch receives a request from the RADIUS server and adds a session entry to its session table to bind a WAP gateway with that 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 trafc for that user. 7. If the user disconnects, the RAS detects it and sends this information to the RADIUS server. 8. The RADIUS server removes the session entry for that user.
Conguring WAP SLB using Static Session Entries

Follow this procedure to congure the topology illustrated in "Load Balancing WAP Gateways" (page 279): Step 1 Action Before you start conguring 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
Congure for RADIUS services 1812, 1813, and 1645.

Note: The radius service number specied on the switch must match with the service specied on the server.
.
At the Nortel Application Switch, congure the switch for basic SLB.
>> # /cfg/slb/on
Congure IP addresses for the RADIUS/WAP Gateways.

>> # /cfg/slb/real 1/rip 1.1.1.100 >> Real server 1# ena >> # /cfg/slb/real 2/rip 2.2.2.100 >> Real server 2# ena >> # /cfg/slb/real 3/rip 3.3.3.100 >> Real server 3# ena (Define address for WAP Gateway1) (Enable real server 1) (Define address for WAP Gateway 2) (Enable real server 2) (Define address for WAP Gateway 3) (Enable real server 3)
Create a group to load balance the WAP Gateways.

Enable the external notication from WAP gateway to add and delete session request if you are using static session via TPCP.
>> # cfg/slb/adv/tpcp ena
Enable TPCP for adding and deleting WAP sessions.

>> # cfg/slb/wap/tpcp ena

>> WAP Options# apply >> WAP Options# save
End
.
283
WAP SLB with RADIUS Snooping

RADIUS snooping is similar to the static session entry method in the way that a static session entry is added to (or removed from) the switch for the WAP trafc for a user; it is different from the static session entry method in the way that RADIUS accounting packets are snooped by the Nortel Application Switch instead of by the RADIUS server using TPCP. Radius snooping allows the Nortel Application Switch to examine RADIUS accounting packets for client information. This information is needed to add to or delete static session entries in the switchs session table so that it can perform the required persistency for load balancing. A static session entry does not age out. Such an entry, added using RADIUS snooping, will only be deleted using RADIUS snooping. The switch load balances both the RADIUS and WAP gateway trafc using the same virtual server IP address.
How WAP SLB Works with RADIUS Snooping

Before the RAS allows the WAP trafc for a user to pass in and out of the gateway, it sends a RADIUS Accounting Start message to one of the RADIUS servers. The switch then snoops on the packet to extract the required information. It needs to know the type of the RADIUS Accounting message, the client IP address, the caller ID, and the users name. If it nds 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 action to handle the session entry. When the client ends the WAP connection, RAS sends RADIUS Accounting Stop packet. If the switch nds the needed information in a RADIUS Accounting Stop packet, it removes the corresponding session entry from its table. The following steps occur for RADIUS snooping: Step 1 2 Action The user is authenticated on dialing. The RAS establishes a session with the client and sends a RADIUS Accounting Start message with the client IP address to the RADIUS server. The switch snoops on the RADIUS accounting packet and adds a session entry if it nds enough information in the packet. The switch load balances the WAP trafc to a specic WAP gateway. When the client terminates the session, the RAS sends an Accounting Stop message to the RADIUS server, and the session entry is deleted from the switch.
3 4 5
.
Consider the following items before conguring RADIUS snooping: The same virtual server IP address must be used when load balancing both the RADIUS accounting trafc and WAP trafc. All the RADIUS servers must use the same UDP port for RADIUS accounting services. Before a session entry is recorded on the switch, WAP packets for a user can go to any of the real WAP gateways. If a session entry for a client cannot be added because of resource constraints, the subsequent WAP packets for that client will not be load balanced correctly. The client will need to drop the connection and then reconnect to the wireless service. The persistence of a session cannot be maintained if the number of healthy real WAP gateways changes during the session. For example, if a new WAP server comes into service or some of the existing WAP servers are down, the number of healthy WAP gateway changes and, in this case, the persistence for a user cannot be maintained. Persistence cannot be maintained if the user moves from one ISP to another, or if the base of the users session changes (that is, from CALLING_STATION_ID to USER_NAME, or vice versa). For example, if a user moves out of a roaming area, it is possible that his/her CALLING_STATION_ID is not available in the RADIUS Accounting packets. In such a case, the switch uses USER_NAME to choose a WAP server instead of CALLING_STATION_ID. Thus, persistence cannot be maintained. End
Conguring WAP SLB using Radius Snooping

Follow this procedure to congure the topology illustrated in "Load Balancing WAP Gateways" (page 279): Step 1 Action Before you start conguring 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.

.
285
Congure for RADIUS services 1812, 1813, and 1645.

Note: The radius service number specied on the switch must match with the service specied on the server. 2 At the Nortel Application Switch, congure the switch for basic SLB.
>> # /cfg/slb/on


Enable the external notication from WAP gateway to add and delete session request if you are using static session via TPCP.
>> # cfg/slb/adv/tpcp ena
Enable TPCP for adding and deleting WAP sessions.
.
>> # cfg/slb/wap/tpcp ena
Congure the following lter on the switch to examine a RADIUS accounting packet. Set the basic lter parameters
>> # /cfg/slb/filt 1 >> Filter 1 >> Filter 1 # ena # dip 10.10.10.100 (Select the filter) (Enable the filter) (Set the destination IP address) (Set the destination IP mask) (Set the protocol to UDP) (Set the destination port) (Set the action to redirect) (Set the group for redirection) (Set server port for redirection)
>> Filter 1 # dmask 255.255.255.255 >> Filter 1 >> Filter 1 >> Filter 1 >> Filter 1 >> Filter 1 # proto udp # dport 1813 # action redir # group 1 # rport 1813
Enable proxy and RADIUS snooping.

>> Filter 1 # adv (Select the advanced filter menu) (Enable proxy) (Select the Layer 7 advanced menu) (Enable RADIUS snooping)
>> Filter 1 Advanced# proxy ena >> Filter 1 Advanced# layer7 >> Layer 7 Advanced# rdsnp ena

>> Layer 7 Advanced# apply >> Layer 7 Advanced# save
Note: Nortel Application Switch Operating System supports Virtual Router Redundancy Protocol (VRRP) and stateful failover, using both static session entries and RADIUS snooping. However, active-active conguration with Stateful Failover is not supported. End
.
287
WAP SLB with Radius/WAP Persistence

This feature allows for RADIUS and WAP persistence by binding both (RADIUS accounting and WAP) sessions to the same server. A WAP client is rst authenticated by the RADIUS server on UDP port 1812. The server replies with a Radius Accept or Reject frame. The switch forwards this reply to the RAS. After the RAS receives the Radius accept packet, it sends a RADIUS accounting start packet on UDP port 1813 to the bound server. The application switch snoops on the RADIUS accounting start 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 1 Action The user is authenticated on dialing. The RAS sends a RADIUS authentication request on UDP port 1812 to one of the servers. The switch receives the authentication request. If there is no session corresponding to this request, a new session is allocated and the client is bound to a server. The switch then relays the authentication request to the bound server. 2 The RAS establishes a session with the client and sends a RADIUS Accounting Start message to the RADIUS server on UDP port 1813. The switch snoops on the RADIUS accounting start packet for the "framed IP address" attribute. This attribute in a RADIUS accounting packet contains the IP address of the specic client (the IP address of the wireless device). Note: The RADIUS accounting packet and the RADIUS accounting service must share the same rport. 4 The "framed IP address" attribute is used to rebind the RADIUS session to a new server. The application switch hashes on the framed IP address to select a real server for the RADIUS accounting session. If the "framed IP address" is not found in the Radius accounting packet, then persistence is not maintained for the Radius/WAP session. The load balancing metric of the real server group has to be hash for Radius/WAP Persistence 5 When the client begins to send WAP requests to the WAP gateways on ports 92009203, a new session is allocated and a server is bound to the WAP session.
.
The RADIUS session and the WAP session are now both bound to the same server because both sessions are using the same source IP address. End
Conguring WAP SLB using Radius/WAP Persistence

Follow this procedure to congure the topology illustrated in "Load Balancing WAP Gateways" (page 279): Step 1 Action At the Nortel Application Switch, congure the switch for basic SLB.
>> # /cfg/slb/on


>> # /cfg/slb/group 100 >>Real Server Group 100# metric hash >>Real Server Group 100# add 1 >>Real Server Group 100# add 2 >>Real Server Group 100# add 3 (Define a group) (Select hash as load balancing metric) (Add real server 1) (Add real server 2) (Add real server 3)
Congure a virtual server.
.
289
>> # cfg/slb/virt 1/vip 10.10.10.10 >>Virtual Server 1# ena (Enable virtual server 1)
Congure the services for virtual server 1. Note: The radius service number specied on the switch must match with the service specied on the server.
>>Virtual >>Virtual >>Virtual 1/service >>Virtual >>Virtual 1/service >>Virtual >>Virtual 1/service >>Virtual >>Virtual 1/service >>Virtual >>Virtual 1/service >>Virtual Server Server Server 1813 Server Server 9200 Server Server 9201 Server Server 9202 Server Server 9203 Server 1# service 1812 1 radius-auth service# udp ena 1 radius-auth service# /cfg/slb/virt 1 radius-acc service# udp ena 1 radius-auth service# /cfg/slb/virt 1 9200 service# udp ena 1 radius-auth service# /cfg/slb/virt 1 9201 service# udp ena 1 radius-auth service# /cfg/slb/virt 1 9202 service# udp ena 1 radius-auth service# /cfg/slb/virt 1 9203 service# udp ena
Congure the following lter on the switch to examine a RADIUS accounting packet. Set the basic lter parameters.
>> # /cfg/slb/filt 1 >> Filter 1 >> Filter 1 # ena # dip 10.10.10.10 (Select the filter) (Enable the filter) (Set the destination IP address) (Set the destination IP mask) (Set the protocol to UDP) (Set the destination port) (Set the action to redirect) (Set the group for redirection) (Set server port for redirection)
>> Filter 1 # dmask 255.255.255.255 >> Filter 1 >> Filter 1 >> Filter 1 >> Filter 1 >> Filter 1 # proto udp # dport 1813 # action redir # group 100 # rport 1813
Enable RADIUS/WAP persistence.


.
>> # /cfg/slb/filt 1 >> Layer 7 Advanced# rdswap ena
(Select the filter) (Enable RADIUS/WAP persistence)
Enable client and server ports and enable ltering on client ports.
>> # /cfg/slb/port 1/client ena >> SLB port 1# filt ena >> >> >> >> >> >> SLB SLB SLB SLB SLB SLB port port port port port port 1# 2# 1# 3# 3# 4# (Enable filtering on port 1)
/cfg/slb/port 2 /cfg/slb/server ena /cfg/slb/port 3 /cfg/slb/server ena /cfg/slb/port 4 /cfg/slb/server ena

End
Intrusion Detection System SLB

Intrusion Detection System (IDS) is a type of security management system for computers and networks. An Intrusion Detection System gathers and analyzes information from various areas within a computer or a network to identify possible security breaches, which include both intrusions (attacks from outside the organization) and misuse (attacks from within the organization). Intrusion detection functions include: Monitoring and analyzing both user and system activities Analyzing system congurations and vulnerabilities Assessing system and le integrity Recognizing patterns typical of attacks Analyzing abnormal activity patterns Tracking user policy violations
.
291
Intrusion detection devices inspect every packet before it enters a network, looking for any signs of an attack. The attacks are recorded and logged in an attempt to guard against future attacks and to record the information about the intruders. IDS server load balancing helps scale intrusion detection systems since it is not possible for an individual server to scale information being processed at Gigabit speeds.
How Intrusion Detection Server Load Balancing Works

Nortel Application Switch Operating System allows the switch to forward a copy of the IP packets to an Intrusion Detection server. IDS SLB must be enabled on the incoming ports and enabled for the groups containing the IDS real servers. The IDS SLB-enabled switch copies packets entering IDS-enabled ports. An SLB session is created on the switch to a group of intrusion detection servers. The IDS server is selected based on the IDS group metric. The following list summarizes the primary steps involved in conguring IDS load balancing: Step 1 Action 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 about setting up IDS servers. 2 Create the IDS groups. Create real server groups for the IDS servers. You may create multiple IDS groups to segregate incoming trafc 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 trafc that is captured by the group by dening the IDS rport value. (The default for IDS rport is any). If multiple groups are congured for the same rport then only ONE 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 Switch to make a copy of the frames ingressing the port and forward the copy to the IDS server group.
.
Congure lter processing on the incoming ports with the IDS hash metric. This allows a session entry to be created for frames ingressing the port. IDS load balancing requires a session entry to be created in order to store the information regarding which IDS server to send the request. If the allow lter is congured to hash on both the client and server IP address, then this ensures that both client and server trafc belonging to the same session is sent to the same IDS server. For more information, see "Example 2: Load Balancing to Multiple IDS Groups" (page 298). If the port is congured for client processing only, 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 Application Switch can be congured depending on the type of IDS server.
Setting Up IDS Servers IDS Server Configurati on Hea lth Che ck Type Link Port Configuration Explanation
Stealth mod e (without IP addresses or dummy IP addresses)
IDS servers must directly connect to separate physical ports on the switch. Real server # of IDS server must match the physical port # (1 to 26) on the switch
To send packets to different IDS servers you must connect IDS servers to separate switch ports and associate them with different VLANs and tag the packets accordingly. Because unmodified frames are sent to the IDS servers, the switch does not use the L2 destination field of the packet to direct it to the correct IDS server. The switch port or the VLAN tag is used to identify the destination IDS server. However, if the ingress packet is already tagged, then you must use different switch ports for different IDS servers.
.
293
IDS Server Configurati on
Hea lth Che ck Type SNM P
Port Configuration
Explanation
Stealth mod e (without IP addresses or dummy IP addresses)
IDS servers need not be directly connected to the application switch.The IDS servers may be connected to another switch via an interswitch link between it and the application switch. SNMP health checks are used to check the status of a port on the remote switch, that is connected to an IDS server.
To send packets to different IDS servers you must connect IDS servers to separate switch ports and associate them with different VLANs. Because unmodified frames are sent to the IDS servers, the switch does not use the L2 destination field of the packet to direct it to the correct IDS server. The VLAN tag is used to identify the destination IDS server. However, if the ingress packet is already tagged, then you must use different VLANs for different IDS servers. The data packet is modified, so that it is addressed to the IDS servers. Destination MAC address is changed to Real server MAC address.
With IP addresses
ICM P or ARP
IDS servers need not be directly connected to the application switch.The IDS servers may be connected via an Nortel Application Switch or a Layer 2 switch.
IDS Load Balancing Congurations

The following three examples illustrate IDS load balancing in two different network environments. In "Example 1: Load Balancing to a Single IDS Group" (page 294), one switch is dedicated to load balancing two IDS servers in a single group and a second switch is performing standard server load balancing. In "Example 2: Load Balancing to Multiple IDS Groups" (page 298), a single switch is performing both IDS load balancing and standard server load balancing. In example 2, two IDS groups are conguredIDS group 51 is for HTTP trafc only and IDS group 52 is for all other trafc. In "Example 3: Load Balancing IDS Servers Across Multiple Switches" (page 303), two switches in a high availability conguration are connected to each other via a trunked interswitch link that is associated with all VLANs congured on the switch. Each switch is connected to IDS servers that are each on different VLANs but belong to the same IDS group.
.
A feature to disable source MAC address learning across the interswitch link, allows trafc to reach real servers even when one switch goes into the Standby state.
Example 1: Load Balancing to a Single IDS Group

"Server Load Balancing and IDS Load Balancing to a Single Group" (page 294) illustrates a basic conguration for load balancing client and server trafc to the IDS servers. Nortel Application Switch 1 (an Nortel Application Switch 2424) is performing IDS load balancing and Nortel Application Switch 2 is performing standard server load balancing. IDS is enabled on the client port (port 25) and both the rewall ports (ports 26 and 27). Note: While this example assumes use of an Nortel Application Switch 2424, you may adapt this example according the ports available on your particular 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, the switch makes a copy of the packet. The switch load balances the copied packet between the two IDS servers based on the congured load balancing metric (hash). The original data packet however, enters Nortel Application Switch 2 through the rewall and Nortel Application Switch 2 performs standard server load balancing on the client data between the three real servers. The client request is processed and returned to Nortel Application
.
295
Switch 1 via the rewall. An allow lter at ports 26 and port 27 causes the Nortel Application Switch to make a copy of the request and directs the copy to the IDS server group. Follow this procedure to congure the topology illustrated in "Server Load Balancing and IDS Load Balancing to a Single Group" (page 294): Step 1 Action Set up the IDS servers. To congure the IDS servers as real servers you must consider the setup of the IDS servers and the selection of the health check. Typically, most IDS servers are setup in stealth mode (without IP addresses); but, they can also be set up with non-routable IP addresses. See "Setting Up IDS Servers" (page 292) for more information about setting up IDS servers. 2 At the Nortel Application Switch, congure the IDS servers as real servers. In "Server Load Balancing and IDS Load Balancing to a Single Group" (page 294) the IDS servers are congured in stealth mode. Match the real server number with the physical port number to which the IDS servers are connected, and congure dummy IP addresses. The real servers must be numbered between 1-63.
>> # /cfg/slb/real 6/rip 6.6.6.6/ena >> # /cfg/slb/real 7/rip 7.7.7.7/ena (Define a dummy IP address for IDS server 6) (Define a dummy IP address for IDS server 7)
Create a group and add the IDS servers. The group must be numbered between 163.
>> # /cfg/slb/group 50 >>Real Server Group 50# add 6 >>Real Server Group 50# add 7 (Define a group) (Add IDS server 6) (Add IDS server 7)
Dene the group metric for the IDS server group. IDS server load balancing supports the hash metric only.
>>Real Server Group 50# metric hash (Set the metric to hash)
Dene the health check for the group.


.
Congure link health check which is specically developed for IDS servers set up in stealth mode (without IP addresses).
>>Real Server Group 50# health link (Set the health check to link)
Dene the group for IDS server load balancing.

>>Real Server Group 50# ids ena (Enable IDS for the server group)
Select the rport for the IDS group.

>>Real Server Group 50# idsrprt any
Enable IDS on the client and server ports. This enables frames ingressing the port to be copied to the IDS servers.
>># /cfg/slb/port 25/ids ena >>SLB port 25# /cfg/slb/port 26/ids ena >>SLB port 26# /cfg/slb/port 27/ids ena (Enable IDS processing for port 25) (Enable IDS processing for port 26) (Enable IDS processing for port 27)
In addition to enabling IDS at the port level, a lter must be congured to create a session entry for non-SLB frames ingressing the port. IDS load balancing requires a session entry to be created to store the information regarding which IDS server to send to. 9 Create an allow lter and congure the lter with the idshash metric.
>> # /cfg/slb/filt 2048 >> Filter 2048# sip any >> Filter 2048# dip any >> Filter 2048# action allow (Select the menu for Filter 2048) (From any source IP address) (To any destination IP address) (Allow matching traffic to pass)
.
297
>> Filter 2048# ena >> Filter 2048# adv/idshash both
(Enable the filter) (Set the hash metric parameter)
The IDS hash metric is set to hash on both the source and destination IP addresses. Hashing on both source and destination IP address ensures that the returning trafc goes to the same IDS server. If the port is congured for client processing only, then the switch hashes on the source IP address. By default, the IDS hash metric hashes on the source IP address only. 10 Apply the allow lter to ports 25, 26, and 27. The allow lter must be applied on all ports that require layer 4 trafc to be routed to the IDS servers.
>> Filter 2048# /cfg/slb/port 25 >> SLB Port 25# add 2048 >> SLB Port 25# filt ena >> SLB Port 25# /cfg/slb/port 26 >> SLB Port 26# add 2048 >> SLB Port 26# filt ena >> SLB Port 26# /cfg/slb/port 27 >> SLB Port 27# add 2048 >> SLB Port 27# filt ena (Select the client port) (Apply the filter to the client port) (Enable the filter) (Select port 26) (Apply the filter to port 26) (Enable the filter) (Select port 27) (Apply the filter to port 27) (Enable the filter)
All ingressing trafc at these ports that match any of the lters congured for that port will be load balanced to the IDS groups. The allow lter is used at the end of the lter list to make sure that all trafc matches a lter. A deny all lter could also be used as the nal lter instead of an allow all lter. 11 Apply and save your changes.
>> SLB Port 25# apply >> SLB Port 25# save
12
Congure Nortel Application Switch 2 to load balance the real servers as described in "Conguring Server Load Balancing" (page 194) .

.
Congure the IP interfaces on the switch Congure the SLB real servers and add the real servers to the group Congure the virtual IP address Congure the SLB metric Enable SLB
A copy of layer 4 trafc from clients A, B, and C and from the real servers are directed to the IDS servers and load balanced between IDS servers 6 and 7. End
Example 2: Load Balancing to Multiple IDS Groups

"Server Load Balancing and IDS Load Balancing" (page 298) illustrates a single Nortel Application Switch performing both standard server load balancing and IDS server load balancing. In this example, two IDS groups are conguredIDS group 51 is for HTTP trafc only and IDS group 52 is for all other trafc.
Server Load Balancing and IDS Load Balancing
When the same Nortel Application Switch is congured to load balance real servers and IDS servers as shown in "Server Load Balancing and IDS Load Balancing" (page 298), lter processing is not required on the client processing port (port 25). To maintain session persistency however, if you
.
299
add the lter to the client port, the switch can be congured to hash on both the client IP and virtual server IP. This ensures that both client and server trafc belonging to the same session is sent to the same IDS server. If you do not add the lter on port 25, then the switch hashes on the client IP address only. Note: While this example assumes use of an Nortel Application Switch 2424, you may adapt this example according the ports available on your particular Nortel Application Switch model. Follow this procedure to congure the topology illustrated in "Server Load Balancing and IDS Load Balancing" (page 298): Step 1 Action Set up the IDS servers. Refer to "Setting Up IDS Servers" (page 292) for information on setting up the IDS servers. To congure the IDS servers as real servers you must consider the following: Connecting the IDS servers Choosing the health check Conguring the IP addresses
For more information on each of the above items, see step 1 on step 1. 2 Congure the IDS servers as real servers. In "Server Load Balancing and IDS Load Balancing" (page 298) the IDS servers are setup with non-routable IP addresses. The real servers must be numbered 1-63.
>> # /cfg/slb/real 6/rip 10.20.20.1/ena >> # /cfg/slb/real 7/rip 10.20.20.2/ena >> # /cfg/slb/real 8/rip 10.20.20.3/ena (Specify IP address for IDS server 6) (Specify IP address for IDS server 7) (Specify IP address for IDS server 8)
Create two IDS groups and add the IDS servers. Dene the two IDS groups 51 and 52. The IDS group numbers must be between 1 to 63.
.
>> # /cfg/slb/group 51 >>Real Server Group 51# add 6 >>Real Server Group 51# add 7 >>Real Server Group 51# /cfg/slb/group 52 >>Real Server Group 52# add 8
(Define a group) (Add IDS server 6) (Add IDS server 7) (Define another group) (Add IDS server 8)
Dene the group metric for the IDS server groups. IDS server load balancing supports the hash metric only.
>>Real Server Group 51# metric hash >>Real Server Group 51# /cfg/slb/group 52 >>Real Server Group 52# metric hash (Set the metric to hash) (Select the other IDS group) (Set the metric to hash)
The hash metric is implemented in two ways. For more information, see step 4 on step 4. 5 Dene the health check for the group. Congure ICMP health check for the group.
>>Real Server Group 51# health icmp >>Real Server Group 51# /cfg/slb/group 52 >>Real Server Group 52# health arp (Set the health check to ICMP) (Select the other IDS group) (Set the health check to ARP)

>>Real Server Group 51# idslb ena >>Real Server Group 51# /cfg/slb/group 52 >>Real Server Group 52# idslb ena (Enable IDS for the IDS server group) (Select the other IDS group) (Enable IDS for the IDS server group)
.
301
>> # /cfg/slb/group 51 >>Real Server Group 51# idsrprt http >>Real Server Group 51# /cfg/slb/group 52
(Select the IDS group) (Select HTTP traffic for IDS group) (Select the IDS group)
>>Real Server Group 52# idsrprt any (Select non-HTTP traffic for IDS group)
Enable IDS on the client and server processing ports. This enables frames ingressing the port to be copied to the IDS servers.
>># /cfg/slb/port 25/idslb ena >>SLB port 25# /cfg/slb/port 2/idslb ena >>SLB port 2# /cfg/slb/port 3/idslb ena >>SLB port 3# /cfg/slb/port 4/idslb ena (Enable IDS SLB for port 25) (Enable IDS SLB for port 2) (Enable IDS SLB for port 3) (Enable IDS SLB for port 4)
In addition to enabling IDS at the port level, a lter must be congured to create a session entry for non-SLB frames ingressing the port. IDS load balancing requires a session entry to be created to store the information regarding which IDS server to send to. 9 Create an allow lter and congure the lter with the idshash metric.
>> # /cfg/slb/filt 2048 >> Filter 2048# sip any >> Filter 2048# dip any >> Filter 2048# action allow >> Filter 2048# ena >> Filter 2048# adv/idshash both (Select the menu for Filter 2048) (From any source IP address) (To any destination IP address) (Allow matching traffic to pass) (Enable the filter) (Set the hash metric parameter)
.
The IDS hash metric is set to hash on both the source and destination IP addresses. Hashing on both source and destination IP address ensures that the returning trafc goes to the same IDS server. By default, the IDS hash metric hashes on the source IP address only. 10 Apply the lter to ports 2, 3, 4 and 25 only. Enable lter processing on all ports that have IDS enabled. If you add the allow lter to the client port 25, the switch will hash on client IP and virtual server IP address for both client and server frames. This ensures that both client and server trafc belonging to the same session is sent to the same IDS server. If you do not add the allow lter on port 25, then the switch hashes on client IP only for client frames and hashes on client IP and virtual server IP address for server frames.
>> # /cfg/slb/port 2 >> SLB Port 2# add 2048 >> SLB Port 2# filt ena >> SLB Port 2# /cfg/slb/port 3 >> SLB Port 3# add 2048 >> SLB Port 3# filt ena >> SLB Port 3# /cfg/slb/port 4 >> SLB Port 4# add 2048 >> SLB Port 4# filt ena >> SLB Port 4# /cfg/slb/port 25 >> SLB Port 25# add 2048 >> SLB Port 25# filt ena (Select the port menu) (Apply the filter to port 2) (Enable the filter) (Select port 3) (Apply the filter to port 3) (Enable the filter) (Select port 4) (Apply the filter to port 4) (Enable the filter) (Select port 25) (Apply the filter to port 25) (Enable the filter)
11
Apply and save your changes.

A copy of layer 4 Web trafc from clients A, B, and C and from the real servers 1, 2, and 3 is load balanced between IDS servers 6 and 7. A copy of all non-HTTP trafc is directed to IDS server 8. 12 Congure the switch for server load balancing the real servers as described in "Conguring Server Load Balancing" (page 194). Congure the IP interfaces on the switch
.
303
Congure and create a group for the SLB real servers Congure the virtual IP address Congure the SLB metric Enable SLB End
Example 3: Load Balancing IDS Servers Across Multiple Switches

Nortel Application Switch Operating System supports load balancing IDS servers across multiple Application switches in a high availability conguration. By allowing the administrator to disable learning of client and server source MAC addresses over the interswitch link, client request packets are able to reach the real servers when switch failover occurs. In "Load Balancing IDS Servers Across Two Switches" (page 303), the switches are connected to each other via a trunked interswitch link (ports 25 and 26) that is associated with all VLANs congured on the switch. Each switch is connected to IDS servers that are each on different VLANs but belong to the same IDS group. For VLAN-based IDS load balancing, the ingress packets are copied by the master switch and ooded to the IDS servers for monitoring through the path associated with an IDS VLAN. Since the inter-switch link is also associated with this IDS VLAN, the copied packet passes through the inter-switch link and is ooded to the IDS VLAN on the standby switch.
Load Balancing IDS Servers Across Two Switches
.
Normally, the standby switch will learn the source MAC address of clients in the 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 when the server response packets enter the master switch and are ooded to the IDS VLAN over the interswitch link. In a high availability conguration, the standby switch becomes the master if the current master switch fails. The new master switch forwards trafc between clients and servers. Because the MAC addresses of the real servers are learned via the inter-switch link port, the request packets from clients are forwarded to the inter-switch link port on the new master switch, and are received by the new standby switch. Because the standby switch does not forward trafc, the request packets would not normally reach the real servers. Nortel Application Switch Operating System remedies this situation by allowing the administrator to disable learning of client and server source MAC addresses over the interswitch link, thus ensuring that when switch failover occurs, the client request packets reach the real servers. Note: While this example assumes use of an Nortel Application Switch 2424, you may adapt this example according the ports available on your particular Nortel Application Switch model. Follow this procedure to congure the topology illustrated in "Load Balancing IDS Servers Across Two Switches" (page 303): Step 1 Action Set up the IDS servers. Refer to "Setting Up IDS Servers" (page 292) for information on setting up the IDS servers. To congure the IDS servers as real servers you must consider the following: Connecting the IDS servers Choosing the health checkin this case, use SNMP health check Conguring the IP addresses
For more information on each of the above items, see step 1 on step 1. 2 On the Nortel Application Switch, congure the interswitch link ports for the IDS VLAN.
/cfg/port 25/tag ena/pvid 1000 /cfg/port 26/tag ena/pvid 1000
Congure trunk groups.


.
305
/cfg/l2/trunk 1/ena/add 25/add 26 /cfg/l2/trunk 2/ena/add 27/add 28
(Add ports 25, 26 to trunk group 1) (Add ports 27, 28 to trunk group 2)
Congure an IP interface for the SNMP health check to the other switch.
/cfg/l3/if 3/addr 11.11.11.1/mask 255.255.255.255/v lan 1000
Congure VLANs. Make sure to disable source MAC address learning only on the IDS VLANs. The following VLANS are congured on the switch: VLAN 1: for load balancing trafc to the real servers VLAN 1000: for performing SNMP health check on switch 2 VLAN 1001: for IDS server 1 VLAN 1002: for IDS server 2 VLAN 1003: for IDS server 3 VLAN 1004: for IDS server 4.
>> Main# /cfg/l2/vlan 1001/ena >> VLAN 1001# learn dis : >> VLAN 1001# add 25/add 26 Port 25 1. Confirm Port 26 1. Confirm (Set port members of the VLAN) (Disable source MAC learning on the IDS VLAN)
is an UNTAGGED port and its current PVID is changing PVID from 1 to 1001 [y/n]: y is an UNTAGGED port and its current PVID is changing PVID from 1 to 1001 [y/n]: y
>> Layer 2# 25/add 26 >> Layer 2# 25/add 26 >> Layer 2# 25/add 26 >> Layer 2# 25/add 26
/cfg/l2/vlan 1001/ena/learn dis/add /cfg/l2/vlan 1002/ena/learn dis/add /cfg/l2/vlan 1003/ena/learn dis/add /cfg/l2/vlan 1004/ena/learn dis/add
.
Congure the IDS servers as real servers. In "Server Load Balancing and IDS Load Balancing" (page 298) the IDS servers are setup with non-routable IP addresses. The real servers must be numbered 1-63. SNMP health checks are congured to check the status of the ports on switch 2 that are connected to the IDS servers.
>> # /cfg/slb/real 1/rip 11.11.11.1/ena >> Real server 1 # ids/idsvlan 1001 >> Real Server 1 IDS# idsport 25 (Set IP address for IDS server 1) (Set IDS VLAN for IDS server 1) (Set IDS VLAN port)
>> Real Server 1 IDS# oid 1.3.6.1.2.1.2.2.1.8.257 (Set OID to health check port 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 check port 2) >> # /cfg/slb/real 3/rip 11.11.11.100/ena (Set the IP interface for switch 2)
>> Real server 3 # ids/idsvlan 1003 >> Real Server 3 IDS# idsport 25 >> Real Server 3 IDS# oid 1.3.6.1.2.1.2.2.1.8.259 (Set OID 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# idsport 25 >> Real Server 4 IDS# oid 1.3.6.1.2.1.2.2.1.8.260 (Set OID to health check port 4 on switch 2)
Create an IDS group and add the IDS servers. Dene the IDS group. The IDS group numbers must be between 1 to 63.
>> # /cfg/slb/group 53 >>Real Server Group 53# add 1 (Define a group) (Add IDS server 1)
.
307
>>Real Server Group 53# add 2 >>Real Server Group 53# add 3 >>Real Server Group 53# add 4
(Add IDS server 2) (Add IDS server 3) (Add IDS server 4)
Dene the group metric for the IDS server group. IDS server load balancing supports the hash metric only.
>>Real Server Group 53# metric hash (Set the metric to hash)
Dene the health check for the group.

>>Real Server Group 50# health snmp1 (Set the health check to link)
10

>>Real Server Group 50# ids ena (Enable IDS for the server group)
11

>>Real Server Group 50# idsrprt 80 (Set for service HTTP)
12
Enable IDS on the client and server ports. This enables frames ingressing the trafc ports to be copied to the IDS servers.
/cfg/slb/port 4/ids ena >>SLB port 4# /cfg/slb/port 7 ids ena >>SLB port 7# /cfg/slb/port 8 ids ena >>SLB port 7# /cfg/slb/port 27/ids ena >>SLB port 27# /cfg/slb/port 28/ids ena (Enable IDS processing for port 4) (Enable IDS processing for port 7) (Enable IDS processing for port 8) (Enable IDS processing for port 27) (Enable IDS processing for port 28)
.
In addition to enabling IDS at the port level, a lter must be congured to create a session entry for non-SLB frames ingressing the port. IDS load balancing requires a session entry to be created to store the information regarding which IDS server to send to. 13 Congure an integer value for the switch to accept the SNMP health check. If the value returned by the real server for the MIB variable does not match the expected value congured in the rcvcnt eld, then the server is marked down; the server is marked back up when it returns the expected value. In this step, the server is marked down if the switch receives a value 1; the real server is considered as health check failed.
>>SLB port 27# /cfg/slb/advhc/snmphc 1/rcvcnt "1"
14
Create an allow lter and congure the lter with the idshash metric. The IDS hash metric is set to hash on both the source and destination IP addresses. Hashing on both source and destination IP address ensures that the returning trafc goes to the same IDS server. If the port is congured for client processing only, then the switch hashes on the source IP address. By default, the IDS hash metric hashes on the source IP address only.
15
Apply the allow lter to ports 4, 7, 8, 27, and 28, to enable lter processing on all ports that have IDS enabled. If you add the allow lter to the client port 4, the switch will hash on client IP and virtual server IP address for both client and server frames. This ensures that both client and server trafc belonging to the same session is sent to the same IDS server. If you do not add the allow lter on port 5, then the switch hashes on client IP only for client frames and hashes on client IP and virtual server IP address for server frames. The allow lter must be applied on all ports that require layer 4 trafc to be routed to the IDS servers.
>> Filter 2048# /cfg/slb/port 4 >> SLB Port 4# add 2048 >> SLB Port 4# filt ena >> SLB Port 4# /cfg/slb/port 7 >> SLB Port 7# add 2048 (Select the client port) (Apply the filter to the IDS port) (Enable the filter) (Select the IDS server 7 port) (Apply the filter to the IDS port)
.
309
>> SLB Port 7# filt ena >> SLB Port 7# /cfg/slb/port 8 >> SLB Port 2# add 2048 >> SLB Port 2# filt ena >> SLB Port 2# /cfg/slb/port 27 >> SLB Port 27# add 2048 >> SLB Port 27# filt ena >> SLB Port 27# /cfg/slb/port 28 >> SLB Port 28# add 2048 >> SLB Port 28# filt ena
(Enable the filter) (Select the IDS server 8 port) (Apply the filter to the client port) (Enable the filter) (Select the interswitch link for IDS) (Apply the filter to traffic port 27) (Enable the filter) (Select the interswitch link for IDS) (Apply the filter to traffic port 28) (Enable the filter)
All ingressing trafc at these ports that match any of the lters congured for that port will be load balanced to the IDS groups. The allow lter is used at the end of the lter list to make sure that all trafc matches a lter. A deny all lter could also be used as the nal lter instead of an allow all lter. 16 Apply and save your changes.
17
Congure Nortel Application Switch 2 to load balance the real servers as described in "Conguring Server Load Balancing" (page 194). Congure the IP interfaces on the switch Congure the SLB real servers and add the real servers to the group Congure the virtual IP address Congure the SLB metric Enable SLB End
.
Session Initiation Protocol Server Load Balancing

Session Initiation Protocol (SIP) is an application-level control (signalling) protocol for Internet multimedia conferencing, telephony, event notication, 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 parties are at), determine user capability (what type of protocol TCP, UDP, and other capabilities the user can support), user availability, call setup (how to create the call), and call handling (how to keep the call up and how to bring down the call). This feature load balances SIP proxy servers such as Nortel MCS (Multimedia Communications Server) and TCP based implementations like Microsoft LCS (Live Communications Server).
SIP Processing on the Switch

SIP over UDP processing provides the capability to scan and hash calls based on a SIP Call-ID header to a SIP server. The Call-ID uniquely identies a specic SIP session. Future messages from the same Call-ID is switched to the same SIP server. This involves stateful inspection of SIP messages. SIP is a text based protocol with header lines preceding the content. Like HTTP, the rst header line has the method specication followed by other header lines that specify other parameters like Call-ID etc.
TCP based SIP Servers

SIP processing provides the capability to hash calls based on the metric congured in the group. TCP Health Check is new in this Release. It enhances TCP load balancing with SIP ports.
Conguring SIP Server Load Balancing

"Server Load Balancing and IDS Load Balancing" (page 298) illustrates an Nortel Application Switch performing TCP-based SIP server load balancing. In this example, three SIP proxy servers are congured in a Real Server Group 100. The application switch is congured for SIP service (port 5060) for virtual server 40.40.40.100.
.
Load Balancing Special Services SIP Load Balancing
311
Follow this procedure to congure the topology illustrated in "SIP Load Balancing" (page 311): Step 1 Action At the Nortel Application Switch, before you start conguring SIP load balancing: 2 Connect each SIP proxy server to the application switch Congure the IP addresses on all devices connected to the application switch Congure the IP interfaces on the application switch Enable Direct Access Mode (DAM) Disable proxy IP addressing

>> # /cfg/slb/on
Congure IP addresses for the SIP proxy servers.

>> # /cfg/slb/real 1/rip 10.10.10.1 >> Real server 1# ena >> # /cfg/slb/real 2/rip 10.10.10.2 (Define address for MCS 1) (Enable real server 1) (Define address for MCS 2)
.
>> Real server 2# ena >> # /cfg/slb/real 3/rip 10.10.10.3 >> Real server 3# ena
(Enable real server 2) (Define address for MCS 3) (Enable real server 3)
Create a group to load balance the SIP proxy servers.

Dene 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# metric minmiss (Set the metric to minmisses)
Dene the health check for the group. The health check is TCP for TCP based SIP load balancing.
>>Real Server Group 100# health tcp (Set the health check to tcp)
Congure a virtual server for Layer 4 SIP load balancing.

>> # /cfg/slb/virt 1 >>Virtual Server 1# vip 40.40.40.100 >>Virtual Server 1# virt ena (Select virtual server 1) (Set IP address for the virtual server) (Enable virtual server)
Congure the SIP service 5060 for virtual server 1.

>> # /cfg/slb/virt 1/service 5060 >> # /cfg/slb/virt 1/service 5060 Group 100 (Add the SIP service for virt 1) (Add the real server group to the service)
Congure the SIP TLS service 5061 for virtual server 1.
.
313
>> # /cfg/slb/virt 1/service 5061/Group 100
(Configure the SIP TLS service)
10
Enable DAM.
11
Increase the timeout for idle sessions. SIP sessions are quite long and data may be owing while the signalling path is idle. Because the switch resides in the signalling path, it is recommended to increase the Real server session timeout value to 30 minutes (default value is 10 minutes).
>> # /cfg/slb/real 1/tmout 30 >> # /cfg/slb/real 2/tmout 30 >> # /cfg/slb/real 3/tmout 30 (Increase Real 1 session timeout) (Increase Real 2 session timeout) (Increase Real 3 session timeout)
12
Congure Virtual service for RPC load balancing

>> /cfg/slb/virt/service 135 >>Virtual Server 1 135 service #group 1
13
Enable server and client processing at the port level.

>> # /cfg/slb/port 25 >>SLB port 25# client ena >>SLB port 25# /cfg/slb/port 5 >>SLB port 5# server ena >>SLB port 5# /cfg/slb/port 6 >>SLB port 6# server ena >>SLB port 6# /cfg/slb/port 7 >>SLB port 7# server ena (Select the client port) (Enable client processing) (Select the server port) (Enable server processing) (Select the server port) (Enable server processing) (Select the server port) (Enable server processing)
14

.
End
UDP based SIP servers

SIP processing provides the capability to scan and hash calls based on a SIP Call-ID header to a SIP server. The Call-ID uniquely identies a specic SIP session. Future messages from the same Call-ID is switched to the same SIP server. This involves stateful inspection of SIP messages. SIP is a text based protocol with header lines preceding the content. Like HTTP, the rst header line has the method specication followed by the other header lines that specify other parameters like Call-ID etc.
Conguring SIP Server Load Balancing

"Server Load Balancing and IDS Load Balancing" (page 298) illustrates an Nortel Application Switch performing UDP-based SIP server load balancing. In this example, three SIP proxy servers are congured in a Real Server Group 100. The application switch is congured for SIP service (port 5060) for virtual server 40.40.40.100.
SIP Load Balancing
Follow this procedure to congure the topology illustrated in "SIP Load Balancing" (page 311): Step 1 Action At the Nortel Application Switch, before you start conguring SIP load balancing: Connect each SIP proxy server to the application switch
.
315
Congure the IP addresses on all devices connected to the application switch Congure the IP interfaces on the application switch Enable Direct Access Mode (DAM) Disable proxy IP addressing

>> # /cfg/slb/on
Congure IP addresses for the SIP proxy servers.

>> # /cfg/slb/real 1/rip 10.10.10.1 >> Real server 1# ena >> # /cfg/slb/real 2/rip 10.10.10.2 >> Real server 2# ena >> # /cfg/slb/real 3/rip 10.10.10.3 >> Real server 3# ena (Define address for MCS 1) (Enable real server 1) (Define address for MCS 2) (Enable real server 2) (Define address for MCS 3) (Enable real server 3)
Create a group to load balance the SIP proxy servers.

Dene the group metric for the server group. Because SIP load balancing is done based on Call-ID, minmisses metric only is supported to ensure persistency.
>>Real Server Group 100# metric minmiss (Set the metric to minmisses)
Dene the health check for the group. Congure SIP PING request health check which is specically developed for SIP-enabled servers.
.
>>Real Server Group 100# health sip
(Set the health check to sip)
Congure a virtual server for Layer 4 SIP load balancing.

>> # /cfg/slb/virt 1 >>Virtual Server 1# vip 40.40.40.100 >>Virtual Server 1# virt ena (Select virtual server 1) (Set IP address for the virtual server) (Enable virtual server)
Congure the SIP service 5060 for virtual server 1.

>>> # /cfg/slb/virt 1/service 5060 >> # /cfg/slb/virt 5060 Group 100 1/service (Add the SIP service for virt 1) (Add the real server group to the service)
Enable SIP server load balancing.

>>Virtual Server 1 sip Service # sip/sip ena Enable SIP for virtual server 1)
10
Enable DAM.
>>Virtual Server 1 sip Service # direct ena
11 12
Enable UDP load balancing Increase the timeout for idle sessions. SIP sessions are quite long and data may be owing while the signalling path is idle. Because the switch resides in the signalling path, it is recommended to increase the Real server session timeout value to 30 minutes (default value is 10 minutes). When the call terminates with a BYE command, the application switch releases the session entry immediately.
>> # /cfg/slb/real 1/tmout 30 >> # /cfg/slb/real 2/tmout 30 >> # /cfg/slb/real 3/tmout 30 (Increase Real 1 session timeout) (Increase Real 2 session timeout) (Increase Real 3 session timeout)
.
317
When the call terminates with a BYE command, the application switch releases the session entry immediately. 13 Enable server and client processing at the port level.
>> # /cfg/slb/port 25 >>SLB port 25# client ena >>SLB port 25# /cfg/slb/port 5 >>SLB port 5# server ena >>SLB port 5# /cfg/slb/port 6 >>SLB port 6# server ena >>SLB port 6# /cfg/slb/port 7 >>SLB port 7# server ena (Select the client port) (Enable client processing) (Select the server port) (Enable server processing) (Select the server port) (Enable server processing) (Select the server port) (Enable server processing)
14

End
Enhancements to SIP Server Load Balancing

Nortel Application Switch Operating System 24.0 supports the following enhancements to SIP server load balancing: User-dened SIP port Allows you to modify the SIP port (previously, SIP port was supported on UDP 5060 only). To dene the SIP port, enter the command:
>> Main# /cfg/slb/virt <Virtual Server> /service 5060/rport <Port>
Session persistency using the refer method The refer method of load balancing SIP servers is required for call transfer services. The refer method indicates that the recipient should contact a third party using the contact information provided in the request. To maintain session persistency, the new request from the recipient to the third party should also hash the same real server. To maintain

.
persistency, whenever the switch receives a session congured for refer method, Nortel Application Switch Operating System 24.0 creates a persistent session. When creating a session for a new request Nortel Application Switch Operating System looks up the session table and selects the correct real server. If there is a persistent session, then the real server specied in the session entry is used if that real server is up, otherwise the normal minmiss method is used to select the real server. Supports standard health check options Nortel Application Switch Operating System 24.0 supports the standard method to health check SIP servers. The options method (like HTTP and RTSP) is supported by all RFC 3261 compliant proxies. The application switch sends an options request to the SIP server when congured to use the SIP options health check. If the response from the server is a "200 OK," then the server is operational, otherwise the server is marked down. To congure the SIP options health check, use the following command:
>> Main# /cfg/slb/virt<Virtual Server>/service 5060/rport<Port>>> Main# /cfg/slb/group <Real Server Group> /health sipoptions
Support for RTP (SDP) Media Portal NAT This feature is useful if you have several media portal servers with private IP addresses. When the proxy servers respond to an INVITE request, the private IP address of the Media Portal is embedded in the SDP. The switch translates this private IP address to a public IP address. The private media portal address is sent in the response to an INVITE request. The switch replaces the private IP with the public IP address in the SDP. To support media portal NAT, you must congure the following:
Step 1
Action Congure the private to public address mapping

>> Main# /cfg/slb/layer7 >> Layer 7 Resource Definition# sdp >> SDP Mapping# add <private_IP> <public_IP>
Enable SDP Media Portal NAT.
.
319
>> >> >> >>
Main# /cfg/slb/virt 1 Virtual Server 1# service 14 Virtual Server 1 14 Service# sip SIP Load Balancing# sdpnat
Create static NAT lters. This allows RTP trafc destined for the public media portal address to be translated to the actual private media portal address. Create static NAT lters to operate in both directions; one to translate the public address to the private address and one to translate the private address to the public address. For more information on static NAT lters, refer to "Static NAT" (page 386). End
SoftGrid Load Balancing

Softricity SoftGrid platform is used to provide sequenced applications from a SoftGrid Server to a SoftGrid Client. The Nortel Application Switch Operating System supports load balancing tailored to the SoftGrid suite for the delivery of sequenced applications and the maintaining of persistency while applications are launched from SoftGrid Client. Once an application is delivered to SoftGrid Client it can be run on the client computer. "SoftGrid Load Balancing Network Topology" (page 320) illustrates an example of a SoftGrid Load Balancing network topology.
.
320 Part 3: Application Switching Fundamentals SoftGrid Load Balancing Network Topology
The SoftGrid platform supports TCP unicast connections using the following protocols: Step 1 Action Real Time Streaming Protocol (RTSP) RTSP is an application level protocol that is responsible for controlling the transport of multimedia content, session announcements, and tear downs. 2 Real Time Transport Protocol (RTP) RTP is used to transport the application data between server and client. 3 Real Time Control Protocol (RTCP) RTCP is used to control the streaming of the application data that is transported by RTP. The SoftGrid platform uses three channels to complete the application delivery process. Initially, the SoftGrid Client uses the RTSP channel to create a connection with the SoftGrid Server.
.
321
The SoftGrid Server then opens two ports for the RTP and RTCP channels and sends these port numbers to the Client. The Client then opens TCP connections to the ports created on the Server. The requested application is then streamed over the RTP channel while the RTCP channel provides control over the RTP channel. End
Conguring SoftGrid Load Balancing

To congure the SoftGrid Load Balancing feature, perform this procedure: Step 1 Action Congure a host name for the Virtual IP address on the DNS server. Note: This step is performed on the network domain controller. Make an entry in the network domain controller for the SoftGrid Server. For example, <sw_name> 10.10.10.10 where <sw_name> was congured on the switch using the command cfg/slb/virt 1/vname <sw_name>. 2 Edit the SoftGrid Server OSD les. When the SoftGrid Platform is set up for load balancing, the .OSD les in SoftGrid Servers must be changed to point to the virtual IP address or virtual server name of the Nortel Application Switch in the following manner:
rtsp:// <Switch VIP> :554/DefaultApp.sft OR rtsp:// <Switch Virtual NAME> :554/DefaultApp.sft
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 mode performs the RTSP server load balancing for that service. End
.
Workload Manager Support

Nortel Application Switch Operating System 24.0 supports the Server/Application State Protocol (SASP) used by the Enterprise Workload Management (WLM). The Workload Manager feature is used to monitor server resources and provide additional input on load balancing decisions. The Workload Manager takes into account a servers CPU, storage capacity, and network trafc in any nal weighting decisions. The Workload Manager uses an implementation of the SASP protocol to perform this task. The WLM software developed by IBM allows you to specify end-to-end performance goals for distributed requests. WLM runs on an entity responsible for reporting or managing a group of members. This entity is known as the Domain Manager (DM). DM recommends a weight for each application/server in the group. This weight recommendation is based on the business importance, topology and ability of the system to meet its business goals. This recommended weights helps the application switch make intelligent server load balancing decisions. Nortel Application Switch Operating System 24.0 also supports WLM in the redirect lter environment. The SASP protocol enables the application switch to receive trafc 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 DM

The application switch initiates a TCP connection with the GWM for all the congured IP address and port numbers. After establishing the connection, the application switch registers various WLM-congured groups of real servers with the GWM. In case of application load balancing, the representation of a member is the real serverss IP address and the applications port and protocol. When the members are registered, the GWM starts monitoring and computes the weight. The DM periodically sends the weights for all the registered groups. When a real server is disabled/enabled operationally the switch sends a request to temporarily remove the server from the weight calculation.
Conguring WLM Support

Before you start conguring for WLM support, make sure you have congured the following on the switch for all the groups and real servers participating in dynamic weights with WorkLoad Managers (WLM): switch name (/cfg/sys/ssnmp/name)
.
323
group name (/cfg/slb/group #/name) real server names (/cfg/slb/real #/name)
You can congure up to 16 Work Load Managers (WLM). Step 1 Action Congure the IP address and the TCP port number to connect to the WLM.
>> Main# /cfg/slb/wlm 11 >> Workload Manager 1# addr 10.10.10.10 >> Workload Manager 1# port 10 (IP address of the WLM) (TCP port to connect to the WLM)
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 specied, then this group is not registered with the WLM. As a result, dynamic weights are not used for this group. 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 Conguration

Verify WLM conguration with one or more of the following commands: Display WLM information.
.
>> Main# /info/slb/wlm Workload Manager Information: ID IP address Port 1 47.81.25.66 3860 10 47.80.23.245 3860
State Connected Not Connected
Display statistics on Work Load Manager 11.

>> Main# /stats/slb/wlm 11 Workload Manager 11 Statistics: Registration Requests: Registration Replies: Registration Reply Errors: Deregisteration Requests: Deregisteration Replies: Deregisteration Reply Errors: Set LB State Requests: Set LB State Replies: Set LB State Reply Errors: Set Member State Requests: Set Member State Replies: Set Member State Reply Errors: Send Weights Messages received: Send Weights Message Parse Errors: Total Messages with Invalid LB Name: Total Messages with Invalid Group Name: Total Messages with Invalid Real Server Name: Messages with Invalid SASP Header: Messages with parse errors: Messages with Unsupported Message Type:
1 1 0 1 1 0 1 1 0 0 0 0 47 0 0 0 0 0 0 0
Display weights updates for the WLM-congured group.
.
325
>> Main# /stats/slb/group 2 Real server group 2 stats: Total weight updates from WorkLoad Manager : Current Total Highest Real IP address Sessions Sessions Octets ---- ----------------- ---------------- -------1 1.1.1.1 0 2 2.2.2.2 0 3 3.3.3.3 0 4 4.4.4.4 0 ---- ----------------- ---------------- -------group 2 0 Sessions -------0 0 0 0 -------0 0 0 0 0 0 0 0 0 10
(Application load balancing) Display the current weight for the real servers 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:8e virtual ports: http: rport http, group 1, backup none, slowstart real servers: 1: 192.168.2.11, backup none, 0 ms, group ena, up dynamic weight 20 2: 192.168.2.12, backup none, 0 ms, group ena, up dynamic weight 40
(Application Redirection) Display the current weight for the real server.
.
>> Main# /info/slb >> Server Load Balancing Information# filt 224 224: action allow group 1, health 3, backup none, vlan any, content web.gif thash auto, idsgrp 1 proxy: enabled layer 7 parse all packets: enabled real servers: 1: 192.168.2.11, backup none, 0 ms, group ena, up dynamic weight 40
Clear WLM SASP statistics.

>> Main# /stats/slb/wlm <#> clear
Limitations for WLM Support

Nortel Application Switch Operating System 24.0 does not support SASP over SSL Real server weights per service If multiple services are congured to use the same group, then changing the weight for one service affects the weight of real server for all other services. Workload manager deregistration after L2/L3 change If you make any changes to the VLAN or IP Interface as the eWLM environment, 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 allows you to congure the Nortel Application Switch to balance user session trafc among a pool of available WAN Links. The following sections in this chapter provides conceptual information on WAN Link Load balancing: "Multi-homing" (page 327). This section provides an overview of the product and benets of WAN link load balancing. "How WAN Link Load Balancing Works" (page 330). This section discusses in detail the path of the outbound and inbound trafc in a WAN link load balancing environment. "Conguring WAN Link Load Balancing" (page 336). This section provides step-by-step procedures to congure the Nortel Application Switch 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 Application Switch Operating System Command Reference. Although WAN Link Load Balancing supports most IPv4 protocols, the following protocols may not be supported by this feature in typical implementations: IPv6-related protocols IP-within-IP Encapsulation Protocol (IPIP) Generic Routing Encapsulation (GRE) Encap Security Payload/Authentication Header (ESP/AH)
Multi-homing
WAN link load balancing enables the Nortel Application Switch to provide Fast Ethernet and Gigabit connectivity from corporate resources to multiple ISP links to the Internet. To handle the high volume of data on the Internet, corporations are using more than one Internet Service provider (ISP) as a way to increase reliability of Internet connections. Such enterprises with more than one ISP are referred to as being multi-homed. In addition to reliability, a multi-homed network architecture enables enterprises to distribute load among multiple connections and to provide more optimal routing.
.
Multi-homing is becoming essential for reliable networks, providing customers with protection against connectivity outages and unforeseen ISP failures. Multi-homing also presents other clear opportunities for enterprises to intelligently manage how WAN links are used. With link load balancing organizations have greater exibility to scale bandwidth and reduce spending for corporate connectivity. Nortel Application Switch software provides a solution for enterprises that wish to optimize utilization of Internet connectivity. This comprehensive solution helps enterprises to direct trafc over the best connection to maximize performance, maximize corporate bandwidth investments, and effectively remove existing deployment and management barriers for multi-homed networks.
Benets of WAN Link Load Balancing

Traditionally, corporations have used Border Gateway Protocol (BGP) to determine the optimal path of the WAN link for load balancing trafc. However, "WAN Link Load Balancing versus BGP" (page 328) shows the advantages 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 go down, then the other ISP link takes over) backup (you can use a low speed ISP link as a backup for a high speed ISP link) ISP reaches its session limit, then Nortel Application Switch automatically deletes it from the group easy to manage complex to implement laborious to manage difficult to get an autonomous system number does not allow you to monitor the WAN links for load, speed or health of devices on the other end of the link.
WAN link load balancing benets your network in a number of ways: Performance is improved by balancing the request load across multiple WAN links. More WAN links can be added at any time to increase processing power. Increased efciency for WAN link utilization and network bandwidth Your Nortel Application Switch is aware of the shared services provided by your WAN link pool and can then balance user trafc among the available WAN links. Important WAN link trafc gets through more
.
329
easily, reducing user competition for connections on overutilized links. For even greater control, trafc is distributed according to a variety of user-selectable rules. Increased reliability Reliability is increased by providing multiple paths from the clients to the Nortel Application Switch and by accessing a pool of WAN links. If one WAN link fails, the others can take up the additional load. Increased scalability of services As trafc increases and the WAN link pools capabilities are saturated, new WAN links can be added to the pool transparently. For ease of maintenance, WAN links can be added or removed dynamically, without interrupting trafc.
Identifying Your Network Needs

WAN Link Load balancing may be the right option for addressing these vital network concerns: A single WAN link no longer meets the demand for increased trafc. The connection from your LAN to the Internet overloads the WAN links capacity. 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 taking orders from customers. It must not become overloaded or unavailable. You want to use multiple WAN links or hot-standby WAN links for maximum server uptime. You must be able to scale your applications to meet client and LAN request capacity. You cant 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 available WAN links. Load balancing in Nortel Application Switch Operating System can be done in the following ways: Filtered-based load balancing A lter allows you to control the types of trafc permitted through the Nortel Application Switch. Filters are congured to allow, deny, or redirect trafc according to the IP address, protocol, or Layer 4 port criteria. In ltered-based load balancing, a lter is used to redirect trafc to a real server group. If the group is congured with more than one real
.
server entry, redirected trafc is load balanced among the available real servers in the group. WAN links use redirection lters to load balance outbound trafc. For more information, see "Outbound Trafc" (page 330). Virtual server-based load balancing This is the traditional load balancing method. The Nortel Application Switch is congured to act as a virtual server and is given a virtual server IP address (or range of addresses) for each collection of services it will distribute. Depending on your application switch model, there can be as many as 1024 virtual servers, each distributing up to 8 different services (up to a total of 1023 services). Each virtual server is assigned a real server. When the user stations request connections to a service, they will communicate with a virtual server on the Nortel Application Switch. When the application switch receives the request, it binds the session to the IP address of the corresponding real server and remaps the elds in each frame from virtual addresses to real address. This method of load balancing is used to load balance inbound trafc. For more information, see "Inbound Trafc" (page 332).
How WAN Link Load Balancing Works

To effectively use multiple ISP links, it is recommended that both trafcoutbound and inbound is load balanced on the Nortel Application Switch. Nortel Application Switch Operating System can be congured to load balance up to 8 ISP links. The Nortel Application Switch regularly checks the health of the upstream routers and measures the condition of the link. When trafc is to be sent to the link, the Nortel Application Switch chooses the most optimal link for that session. The next two sections explain how WAN link load balancing works differently for outbound trafc versus inbound trafc.
Outbound Trafc
Outbound trafc is data from the intranet that accesses content across the Internet. Nortel Application Switch Operating System load balances outbound trafc using redirection lters to redirect trafc initiated from within the users network to a group of devices that exist at the other end of the WAN link. These lters determine which link is the best at the time the request is generated.
.
331
The design of outbound WAN link load balancing is identical to standard redirection, except that Nortel Application Switch Operating System substitutes the source IP address of each frame with the proxy IP address of the port to which the WAN link is connected. This substitution ensures that the returning response traverse the same link. In "Outbound Trafc" (page 331), client 1 at IP address 1.1.1.2 sends a HTTP request to the Internet. Outbound trafc from client 1 reaches port 5 on the Nortel Application Switch which is congured with a redirection lter for link load balancing. The trafc is load balanced between ports 2 and 7 depending on the metric of the WAN group (congured as real server 1 and 2).
Outbound Trafc
The outbound trafc resolution in "Outbound Trafc" (page 331) is described in detail in the following section: Step 1 2 Action Client 1 makes a data request for content on the Internet. When the request reaches port 5, the redirection lter is triggered and the Nortel Application Switch selects the optimal WAN link. Before the packets leave the WAN link ports, the client IP address is substituted with the congured proxy IP address on port 2 or 7. Proxy IP address maintains persistency for the returning request. The Nortel Application Switch sends the request to the destination IP address. The returning request from the Internet uses the same WAN link because the destination IP address responds to the proxy IP address, thereby maintaining persistency. The selected ISP processes the packet.
4 5
.
The Application Switch converts the proxy IP address to the client IP address and the request is returned to the client. End
Inbound Trafc
Inbound trafc is data from an external client on the Internet that enters the Nortel Application Switch to access an internal service, such as corporate Web servers or FTP servers. Nortel Application Switch Operating System allows you to load balance the inbound trafc by providing access to the external client with the best available WAN link. This is implemented by conguring the Nortel Application Switch as an authoritative name server. The application switch dynamically determines the best ISP link to use at the time the request is generated. The best link is determined by the congured metric, the load on the ISP, and periodic health checks on the upstream routers. For more information on load balancing metrics, see "Metrics for Real Server Groups" (page 202). Real server weighting can also be used to determine the best link when using the hash metric for load balancing inbound WAN links. For more information on real server weighting, see "Weights for Real Servers" (page 206). When the external client makes a DNS request, the application switch responds with the IP address of the best available WAN link (ISP).
Return-to-Sender
Enabling Return-to-Sender (RTS) allows the application switch to associate the session with the MAC address of the WAN router. This ensures that the returning trafc takes the same ISP path as the incoming trafc. RTS is enabled on the incoming WAN ports (port 2 and 7) to maintain persistence for the returning trafc. Data leaves the Nortel Application Switch from the same WAN link that it used to enter, thus maintaining persistency. If you want the incoming DNS request to go through the same ISP, then congure VLAN for gateways as described in "VLANs and Default Gateways" (page 75).
Tracing the Data Path

In "Inbound Trafc for non-SLB server" (page 333), the client request enters the Nortel Application Switch via ISP A or ISP B. ISP A is congured as real server 1 and ISP B is congured as real server 2. A virtual server IP address is congured for each ISP and each domain. The virtual server IP addresses for each ISP must be congured in the ISPs address range.
.
333
As shown in "Inbound Trafc for non-SLB server" (page 333), two virtual server IP addressesvirtual server IP address 1 and virtual server IP address 2 are congured for nortelnetworks.com in each of the ISPs address range. Once the application switch responds with the best virtual server IP address, all subsequent trafc from the clients to this Domain is sent to the same virtual server IP address, thereby passing through the same 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 Trafc for non-SLB server" (page 333), a client request for http://www.nortelnetworks.com enters the Nortel Application Switch via an ISP. The non-SLB server (real server 3) can be directly or indirectly connected to the application switch. A real server 4 is congured on the Nortel Application Switch with the IP address of real server 3. Real server 4 is added to a server group and that group is advertised in VIP 1 and VIP 2.
Inbound Trafc for non-SLB server
The inbound trafc resolution in "Inbound Trafc for non-SLB server" (page 333) is described in detail in the following section:
.
Step 1 2
Action Client makes a request to www.nortel.com. The client query does not exist in local DNS database. Local DNS queries the Domain Name Server on the Nortel Application Switch. The Nortel Application Switch monitors WAN links and responds with the virtual IP address of the optimal ISP. Default gateways for each ISP VLAN is recommended to avoid asymmetric routing.
4 5
Client again requests www.nortel.com with the provided virtual IP address. The server responds to the content request. An allow lter at port 5 processes the data for the services congured on the server. For example, if the client sends HTTP request to server 3, then the allow lter should be congured for source port 80. Similarly, if the client sends SMTP request to server 3, then the allow lter should be congured for source port 25.
The RTS feature on the WAN ports maintains persistency, so that the trafc 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 load balanced between SLB servers 5 and 6.
.
WAN Link Load Balancing Inbound Trafc for SLB group
335
The inbound trafc resolution in "Inbound Trafc for SLB group" (page 335) is described in detail in the following section: Step 1 2 Action Client makes a request to www.nortel.com. The client query does not exist in local DNS database. Local DNS queries the Domain Name Server on the Nortel Application Switch. The Nortel Application Switch monitors WAN links and responds with the virtual IP address of the optimal ISP. Client makes the request again to www.nortel.com with the provided virtual IP address. The SLB servers responds to the content request, because real server 7 IP address on the Nortel Application Switch is the virtual server address of www.nortel.com. The session request egresses from port 1 and port 11 of the Nortel Application Switch where it is then load balanced between the SLB servers. The virtual server IP address for the SLB servers on the
.
3 4 5
application switch is congured as a real server IP address (Real 7 IP: 30.30.30.2) on the Nortel Application Switch. Real 7 is added to a group on the Nortel Application Switch. 6 The returning data from the SLB server reaches port 1, which is enabled for server processing. For information on server processing, see "Network Topology Requirements" (page 192). The RTS feature on the WAN ports maintains persistency, so that the trafc returns via the same ISP. End
Conguring WAN Link Load Balancing

This section provides step-by-step procedures to congure the Nortel Application Switch for load balancing the WAN links in different environments: "Before You Begin" (page 336) "Conguration 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 Begin

The following is required prior to conguration: You must be connected to the Nortel Application Switch Command Line Interface (CLI) as the administrator. Connect each WAN link to a separate port on the Nortel Application Switch. Do not connect two or more WAN links to the same Nortel Application Switch port using a layer 2 switch. WAN link load balancing uses the proxy IP address of the destination port when translating the source IP address of the requests. Do not congure your WAN link ports into trunk groups.
Conguration Summary
"Conguration Summary" (page 337) summarizes the steps involved to congure the Nortel Application Switch for WAN link load balancing.
.
WAN Link Load Balancing Conguration Summary Configuring Outbound Traffic 1. Configure the basic parameters. This includes configuring VLAN, IP interfaces, and defining gateways per VLAN. 2. Configure the load balancing parameters for the ISP WAN links. Configuring Inbound Traffic
337
1. Configure the basic parameters. This includes configuring VLAN, IP interfaces, and defining gateways per VLAN. 2. Configure the load balancing parameters for the ISP WAN links.
Configure the ISP routers as real servers Add it to a group Define the metric and health Enable SLB
Configure the ISP routers as real servers (Optional) assign weight to real servers Add it to a group Define the metric and health Enable SLB
3. Configure the WAN link ports.
3. Configure the WAN link ports.
Configure proxy IP address
Enable client processing Enable RTS Enable DAM
4. Configure the outbound client ports.
4. Configure the inbound server ports.
Configure the redirection filter and enable it for link load balancing Apply the filter to the client ports
Create a group with the real server(s) Enable server processing Enable link load balancing Enable filter processing
A real server is configured for every SLB group on the Nortel Application Switch. 5. Configure virtual server IP addresses and services for each ISP. For each ISP link, configure a virtual server IP address per domain.
.
Configuring Outbound Traffic
Configuring Inbound Traffic 6. Configure the Nortel Application Switch to behave like a Domain Name Server. This involves defining the domain record name and mapping the virtual server and real server addresses (ISP router) for each WAN link.
Note: For details about any of the menu commands described in the examples, refer Nortel Application Switch Operating System Command Reference. In the following procedure, many of the load balancing options are left to their default values. See "Additional Server Load Balancing Options" (page 199) for details on other options.
Example 1: Simple WAN Link Load Balancing

"Simple WAN Link Load Balancing" (page 339) illustrates a simple topology with two WAN links. Two ISPs, a server, and a client are directly connected to the Nortel Application Switch. The Nortel Application Switch load balances trafc between the two WAN links for both inbound and outbound trafc. The server hosting www.nortel.comis directly connected to a port on the application switch. To illustrate outbound trafc, a client is directly connected to another port on the application switch.
.
WAN Link Load Balancing Simple WAN Link Load Balancing
339
"Conguring Simple WAN Link Load Balancing" (page 339) gives an overview of the steps described in the following procedure.
Conguring 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): Configure the WAN link ports" (page 343) "Step 4a (outbound traffic): Configure the client ports" (page 345) "Step 3b (inbound traffic): Configure the WAN link ports" (page 344) "Step 4b (inbound traffic): Configure server ports" (page 346) "Step 5: Configure the virtual server IP address and the services for each ISP" (page 346)
.
For outbound traffic
For inbound traffic "Step 6: Configure the Application Switch as a Domain Name Server" (page 348)
"Step 7: Apply and save your changes" (page 349)
To congure the topology illustrated in "Simple WAN Link Load Balancing" (page 339), follow this procedure on the Nortel Application Switch: Step 1: Congure basic parameters on the Nortel Application Switch This includes conguring VLAN, IP interfaces, and dening gateways per VLAN. Gateways per VLAN is recommended if you have not congured other routing protocols. For each ISP, congure a default gateway for each VLAN. Step 1 Action Assign an IP address to each of the ISP links. The WAN links in any given real server group must have an IP route to the application switch that performs the load balancing functions. For this example, the two ISP links must be given the following IP addresses on different IP subnets:
ISP links: Real Server IP Addresses WAN links ISP 1 ISP 2 IP address 50.1.1.1 80.1.1.1
Congure the IP interfaces on the Nortel Application Switch. The Nortel Application Switch must have an IP route to all of the real servers that receive switching services. For load balancing the trafc, the Nortel Application Switch uses this path to determine the level of TCP/IP reach of the WAN links.
>> Main # /cfg/l3/if 2 >> IP Interface 2# ena >> IP Interface 2# addr 80.1.1.2 >> IP Interface 2# mask 255.255.255.0 (Define interface 2 for ISP 1) (Enable interface 2) (Define the IP address for interface 2) (Define the mask for interface 2)
.
341
>> IP Interface 2# broad 50.1.1.255 >> IP Interface 2# vlan 2 >> Main # /cfg/l3/if 7 >> IP Interface 7# ena >> IP Interface 7# addr 50.1.1.2 >> IP Interface 7# mask 255.255.255.0 >> IP Interface 7# broad 80.1.1.255 >> IP Interface 7# vlan 7 >> Main # /cfg/l3/if 1 >> IP Interface 1# ena >> IP Interface 1# addr 1.1.1.1 >> IP Interface 1# mask 255.255.255.0 >> IP Interface 1# broad 1.1.1.255 >> IP Interface 1# vlan 1 >> Main # /cfg/l3/if 5 >> IP Interface 5# ena >> IP Interface 5# addr 2.2.2.1 >> IP Interface 5# mask 255.255.255.0 >> IP Interface 5# broad 2.2.2.255 >> IP Interface 5# vlan 5
(Define the broadcast for interface 2) (Specify the VLAN for interface 2) (Define interface 7 for ISP 2) (Enable interface 7) (Define the IP address for interface 7) (Define the mask for interface 7) (Define the broadcast for interface 7) (Specify the VLAN for interface 7) (Define interface 1 for Real server 3) (Enable interface 1) (Define the IP address for interface 1) (Define the mask for interface 1) (Define the broadcast for interface 1) (Specify the VLAN for interface 1) (Define interface 5 for internal client) (Enable interface 5) (Define the IP address for interface 5) (Define the mask for interface 5) (Define the broadcast for interface 5) (Specify the VLAN for interface 5)
Congure VLANs.
.
The real server IP addresses (WAN links and real server 3) and the respective IP interfaces must be on different VLANs. The pvid command sets the default VLAN number which is used to forward frames which are not VLAN tagged. The default number is 1.
>> # /cfg/port 25/pvid 2 >> # /cfg/port 26/pvid 7 >> # /cfg/port 1/pvid 1 >> # /cfg/port 5/pvid 5 >> # /cfg/vlan 2/ena >> # /cfg/vlan 2/def 25 >> # /cfg/vlan 7/ena >> # /cfg/vlan 7/def 26 >> # /cfg/vlan 1/ena >> # /cfg/vlan 1/def 1 >> # /cfg/vlan 5/ena >> # /cfg/vlan 5/def 5 >> # /cfg/l2/stg 1/off >> # /cfg/l2/stg 1/clear >> # /cfg/l2/stg 1/port 1 2 5 7 (Sets the default VLAN number) (Sets the default VLAN number) (Sets the default VLAN number) (Sets the default VLAN number) (Enable VLAN 2) (Add port 25 to VLAN 2) (Enable VLAN 7) (Add port 26 to VLAN 7) (Enable VLAN 2) (Add port 1 to VLAN 1) (Enable VLAN 5) (Add port 5 to VLAN 5) (Disable STG) (Clear STG) (Add ports 1, 2, 5, and 7 to STG 1)
End
Step 2: Congure the load balancing parameters for ISP routers On the Nortel Application Switch, congure the ISP routers with load balancing parameters: real servers, group, metric, and health. Step 1 Action At the Nortel Application Switch, congure IP addresses for WAN link routers. Proxy is disabled on the real servers, so that the original destination IP address is preserved.
.
343
>> # /cfg/slb/real 1/rip 50.1.1.1 >> Real server 1# ena >> Real server 1# proxy dis >> # /cfg/slb/real 2/rip 80.1.1.1 >> Real server 2# ena >> Real server 2# proxy dis
(Define IP address for WAN link 1) (Enable real server 1) (Disable proxy) (Define IP address for WAN link 2) (Enable real server 2) (Disable proxy)
Create a group to load balance the WAN link routers.

>> # /cfg/slb/group 100 >>Real Server Group 100# add 1 >>Real Server Group 100# add 2 (Define a group) (Add real server 1) (Add real server 2)
Assign the response metric for the WAN link group.

>>Real Server Group 100# metric response (Set the metric to response)
Any of the server load balancing metrics may be used, but response or bandwidth metric is recommended. 4 Congure health check for the WAN link group.
>>Real Server Group 100# health icmp (Set health check to ICMP)
Enable SLB.
>> # /cfg/slb/on (Enable load balancing)
End
Step 3a (outbound trafc): Congure the WAN link ports Step 1 Action Congure proxy IP addresses on ports 25 and 26 for WAN link load balancing.
.
>> # /cfg/slb/pip/type port >> # /cfg/slb/pip >> Proxy IP Address# add 50.1.1.3 25 >> Proxy IP Address# add 80.1.1.7 26
(Set base type of proxy IP address) (Set proxy IP address for port 25) (Set proxy IP address for port 26)
Each proxy IP address must be unique on your network. End
Step 3b (inbound trafc): Congure the WAN link ports Step 1 Action Enable client processing for ports 25 and 26. This enables inbound trafc to access the virtual server IP address.
>> # /cfg/slb/port 25/client ena >> # /cfg/slb/port 26/client ena (Enable client processing for port 25) (Enable client processing for port 26)
Enable the Return to Sender (RTS) feature for ports 25 and 26. Enable RTS to ensure the returning trafc from all servers to go back to the same ISP router.
>> # /cfg/slb/port 25/rts ena >> # /cfg/slb/port 26/rts ena (Enable rts for port 25) (Enable rts for port 26)
Enable WAN link load balancing

>> # /cfg/slb/linklb >> # /cfg/slb/linklb/group 100 >> # /cfg/slb/linklb/ena (Select the link load balancing menu) (Specify the ISP group of real servers) (Enable link load balancing)
Enable Direct Access Mode (DAM).
.
345
Typically, you have two or more virtual server IP addresses representing the same real service. On the return path, DAM ensures that the real server IP address is mapped to the correct virtual IP address.
For information about DAM, refer to "Direct Access Mode" (page 239). End
Step 4a (outbound trafc): Congure the client ports Congure the redirection lter and enable the lter for link load balancing. This is required to translate (NAT) the client IP address to the proxy IP address. Step 1 Action Dene the WAN link load balancing redirection lter.
>> # /cfg/slb/filt 100 >> Filter 100# ena >> Filter 100# action redir >> Filter 100# group 100 (Select the ISP group of real servers)
Enable WAN link load balancing for the redirection lter.

>> Filter 100# adv >> Filter 100 Advanced# linklb ena
Add the link load balancing lter 100 to the outbound client port
>> # /cfg/slb/port 5 >> SLB Port 5# add 100 >> SLB Port 5# filt ena (Select port 5) (Add filter 100 to port 5) (Enable the filter)
If you are conguring link load balancing for outbound trafc only, then go to "Step 7: Apply and save your changes" (page 349). The remaining steps in this procedure are used for load balancing of inbound trafc only. End
.
Step 4b (inbound trafc): Congure server ports For each real server connected to the Nortel Application Switch, assign a real server number, specify its IP address and enable the real server. Dene a real server group and add the real server to the group. Step 1 Action Congure real server and create a group.
>> # /cfg/slb/real 3/rip 1.1.1.2 >> Real server 3# ena >> # /cfg/slb/group 3 >> Real server Group 3# add 3 (Define IP address for real server 3) (Enable real server 3) (Define a group) (Add Real server 3)
Enable server processing.

>> # /cfg/slb/port 1/server ena (Enable server processing for port 1)
Enable lter on server port 1. Filter is enabled on port 1, because you want the Nortel Application Switch to look up the session table for the RTS entry.
>> # /cfg/slb/port 1 >> SLB Port 1# filt ena (Select port 1) (Enable the filter)
End
Step 5: Congure the virtual server IP address and the services for each ISP All client requests is addressed to a virtual server IP address dened on the Nortel Application Switch. Clients acquire the virtual server IP address through normal DNS resolution. In this example, HTTP and FTP are congured as the services running on this virtual server, and this service is associated with the real server group. Other TCP/IP services can be congured in a similar fashion. For a list of other well-known services and ports, see "Well-Known Application Ports" (page 199). To congure multiple services, see "Conguring Multiple Services" (page 202).
.
347
Note: Dene a virtual server IP address for each ISP. Step 5a: Congure the virtual server IP address and the services for ISP 1 Dene a virtual server and add the services and real server group for ISP 1. Step 1 Action Congure a virtual server for ISP 1.
>> # /cfg/slb/virt 1 >>Virtual Server 1# vip 50.1.1.100 >>Virtual Server 1# ena (Select the virtual server) (Set IP address from the ISP 1 subnet) (Enable virtual server)
Add HTTP and FTP services for the virtual server.

>> # /cfg/slb/virt 1 >>Virtual Server 1# service 80 >>Virtual Server 1 HTTP Service# group 3 >>Virtual Server 1 HTTP Service# .. >>Virtual Server 1# service ftp >>Virtual Server 1 ftp Service# group 3 (Select the virtual server) (Add the HTTP service) (Add real server group) (Go to the virtual server menu) (Add the FTP service) (Add real server group)
End
Step 5b: Congure the virtual server IP address and the services for ISP 2 Dene a virtual server and add the services and real server group for ISP 2. Step 1 Action Congure a virtual server for ISP 2.
.

>> # /cfg/slb/virt 2 >>Virtual Server 2# service 80 >>Virtual Server 2 HTTP Service# ena >>Virtual Server 2 HTTP Service# group 3 >>Virtual Server 2 HTTP Service# .. >>Virtual Server 2# service ftp >>Virtual Server 2 ftp Service# ena >>Virtual Server 2 ftp Service# group 3 (Select the virtual server) (Add the HTTP service) (Enable the service) (Add real server group) (Go to the virtual server menu) (Add the FTP service) (Enable the service) (Add real server group)
End
Step 6: Congure the Application Switch as a Domain Name Server Dene the domain record name and map the virtual server and real server (ISP router) for each WAN link. Step 1 Action Congure the Domain record for the application switch to behave as a Domain Name Server.
>> # /cfg/slb/linklb/drecord 1 (Select the Domain record menu)
>> Domain record 1# domain nortelnetworks.com (Define the Domain name) >> Domain Record 1# ena (Enable the Domain)
Congure an entry for each ISP and specify the virtual server and real server (ISP router). You must map the domain record, nortelnetworks.com to each ISP. Each ISP has two parametersvirtual IP address and real server IP address. The virtual IP address is used to respond to the DNS query for the nortelnetworks.com domain. The real server IP address is used to measure the ISP load and ISP health. These commands map the two parameters to the ISP link
.
349
>> Domain record 1# entry 1/ena >> Virt Real Mapping# virt 1 >> Virt Real Mapping# real 1 >> Domain record 1# entry 2/ena >> Virt Real Mapping# virt 2 >> Virt Real Mapping# real 2
(Define entry for ISP 1) (Select virtual server 1 for ISP 1) (Select real server for ISP 1) (Define entry for ISP 2) (Select virtual server 2 for ISP 2) (Select real server for ISP 2)
End
Step 7: Apply and save your changes You must apply in order for these changes to take effect, and you must save changes if you wish them to remain in effect after reboot. Step 1 Action Apply and verify the conguration.
>> Layer 4# apply >> Layer 4# cur (Make your changes active) (View current settings)
Check the load balancing information.

Check that all load balancing parameters are working according to expectation. If necessary, make any appropriate conguration changes and then check the information again. End
.
Example 2: WAN Link Load Balancing with Server Load Balancing

In this example (shown in "WAN Link Load Balancing with SLB" (page 350)), the Nortel Application Switch is congured for standard server load balancing. The Nortel Application Switch is congured to load balance the WAN links for both outbound and inbound trafc and perform server load balancing for inbound trafc. The conguration is similar to Example 1 except that the virtual server IP addresses on the application switch is congured as real server IP addresses and are added to a group.
WAN Link Load Balancing with SLB
"Conguring WAN Link Load Balancing with SLB" (page 351) gives an overview of the steps described in the following procedure.
.
WAN Link Load Balancing Conguring WAN Link Load Balancing with SLB For outbound traffic For inbound traffic
351
"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): Configure the WAN link ports" (page 354) "Step 4a (outbound traffic): Configure the internal network port" (page 356) "Step 3b (inbound traffic): Configure the WAN link ports" (page 355) "Step 4b (inbound traffic): Configure the internal network" (page 356) "Step 5: Configure the virtual server IP address and the services for each ISP" (page 358) "Step 6: Configure the Application Switch as a Domain Name Server" (page 360) "Step 7: Apply and save your changes" (page 361)
To congure the topology illustrated in "WAN Link Load Balancing with SLB" (page 350), follow this procedure on the Nortel Application Switch: Step 1: Congure basic parameters on the Nortel Application Switch This includes conguring VLAN, interfaces, and dening gateways per VLAN. Gateways per VLAN is recommended if you have not congured other routing protocols. Congure a default gateway per VLAN for each ISP. Step 1 Action Assign an IP address to each of the ISP links. The WAN links in any given real server group must have an IP route to the application switch that performs the load balancing functions. For this example, the two ISP links must be given the following IP addresses on different IP subnets:
ISP links: Real Server IP Addresses WAN links ISP 1 ISP 2 IP address 80.1.1.1 30.1.1.1
Congure the IP interfaces on the Nortel Application Switch. The Nortel Application Switch must have an IP route to all of the real servers that receive switching services. For load balancing the trafc, the Nortel Application Switch uses this path to determine the level of TCP/IP reach of the WAN links.

.
Congure the IP interfaces on the Nortel Application Switch.

>> # /cfg/if 1 >> IP Interface 1# ena >> IP Interface 1# addr 1.1.1.1 >> IP Interface 1# mask 255.255.255.0 >> IP Interface 1# broad 1.1.1.255 >> IP Interface 1# vlan 1 >> # /cfg/if 2 >> IP Interface 2# ena >> IP Interface 2# addr 50.1.1.2 >> IP Interface 2# mask 255.255.255.0 >> IP Interface 2# broad 50.1.1.255 >> IP Interface 2# vlan 2 >> # /cfg/if 7 >> IP Interface 7# ena >> IP Interface 7# addr 80.1.1.2 >> IP Interface 7# mask 255.255.255.0 >> IP Interface 7# broad 80.1.1.255 >> IP Interface 7# vlan 7 (Define interface 1) (Enable interface 1) (Define the IP address for interface 1) (Define the mask for interface 1) (Define the broadcast for interface 1) (Specify the VLAN for interface 1) (Define interface 2) (Enable interface 2) (Define the IP address for interface 2) (Define the mask for interface 2) (Define the broadcast for interface 2) (Specify the VLAN for interface 2) (Define interface 7) (Enable interface 7) (Define the IP address for interface 7) (Define the mask for interface 7) (Define the broadcast for interface 7) (Specify the VLAN for interface 7)
On the Nortel Application Switch, congure VLANs.

>> # /cfg/port 25/pvid 2 >> # /cfg/port 26/pvid 7 >> # /cfg/port 1/pvid 1 (Sets the default VLAN number) (Sets the default VLAN number) (Sets the default VLAN number)
.
353
>> # /cfg/port 5/pvid 5 >> # /cfg/vlan 2/ena >> # /cfg/vlan 2/def 25 >> # /cfg/vlan 7/ena >> # /cfg/vlan 7/def 26 >> # /cfg/vlan 1/ena >> # /cfg/vlan 1/def 1 >> # /cfg/vlan 5/ena >> # /cfg/vlan 5/def 5 >> # /cfg/stp 1/off >> # /cfg/stp 1/clear >> # /cfg/stp 1/add 1 25 26 5
(Sets the default VLAN number) (Enable VLAN 2) (Add port 25 to VLAN 2) (Enable VLAN 7) (Add port 26 to VLAN 7) (Enable VLAN 1) (Add port 1 to VLAN 1) (Enable VLAN 5) (Add port 5 to VLAN 5) (Disable STP) (Clear STP) (Add ports 1, 25, 26, 5 to STP 1)
End
Step 2: Congure the load balancing parameters for ISP routers On the Nortel Application Switch, congure the ISP routers as if they were real servers, with SLB parameters: real servers, group, metric, and health. Step 1 Action Congure IP addresses for WAN link routers.
>> # /cfg/slb/real 1/rip 50.1.1.1 >> Real server 1# ena >> Real server 1# proxy dis >> # /cfg/slb/real 2/rip 80.1.1.1 >> Real server 2# ena >> Real server 2# proxy dis (Define IP address for WAN link 1) (Enable real server 1) (Disable proxy) (Define IP address for WAN link 2) (Enable real server 2) (Disable proxy)
Proxy is disabled on the real servers, because link load balancing and full NAT cache redirection cannot coexist. 2 Create a group to load balance the WAN link routers.
.
>> # /cfg/slb/group 100 >>Real Server Group 100# add 1 >>Real Server Group 100# add 2
(Define a group) (Add real server 1) (Add real server 2)
Assign the response metric for the WAN link group.

>>Real Server Group 100# metric response (Set the metric to response)
Any of the server load balancing metrics may be used, but response or bandwidth metric is recommended. 4 Congure health check for the WAN link group.
>>Real Server Group 100# health icmp (Set health check to ICMP)
Enable SLB.
>> # /cfg/slb/on (Enable load balancing)
End
Step 3a (outbound trafc): Congure the WAN link ports Step 1 Action Congure proxy IP addresses on ports 25 and 26.
>> # /cfg/slb/pip/type port >> # /cfg/slb/pip >> Proxy IP Address# add 50.1.1.2 25 >> Proxy IP Address# add 80.1.1.7 26 (Set proxy IP address for port 25) (Set proxy IP address for port 26) (Set base type of proxy IP address)
Each proxy IP address must be unique on your network. End
.
355
Step 3b (inbound trafc): Congure the WAN link ports Step 1 Action Enable client processing at ports 25 and 26.
>> # /cfg/slb/port 25/client ena >> # /cfg/slb/port 26/client ena (Enable client processing for port 25) (Enable client processing for port 26)
This enables inbound trafc to access the virtual server IP address. 2 Enable RTS for ports 25 and 26. Enable RTS to ensure the returning trafc from all servers to go back to the same ISP router.
>> # /cfg/slb/port 25/rts ena >> # /cfg/slb/port 26/rts ena (Enable rts for port 25) (Enable rts for port 26)
Enable WAN link load balancing.

>> # /cfg/slb/linklb >> # /cfg/slb/linklb/group 100 >> # /cfg/slb/linklb/ena (Select the link load balancing menu) (Specify the ISP group of real servers) (Enable link load balancing)
Enable Direct Access Mode (DAM). Typically, you have two or more virtual server IP addresses representing the same real service. On the return path, DAM ensures that the real server IP address is mapped to the correct virtual IP address.
For information about DAM, refer to "Direct Access Mode" (page 239). End
.
Step 4a (outbound trafc): Congure the internal network port Congure the redirection lter and enable the lter for link load balancing. This is required to translate (NAT) the client IP address to the proxy IP address. Step 1 Action Dene the WAN link load balancing redirection lter.
>> # /cfg/slb/filt 100 >> Filter 100# ena >> Filter 100# action redir >> Filter 100# group 100 (Select the ISP group of real servers)
Enable WAN link load balancing for the redirection lter

>> Filter 100# adv >> Filter 100 Advanced# linklb ena
Add the link load balancing lter 100 to the outbound client port.
If you are conguring link load balancing for outbound trafc only, then go to "Step 7: Apply and save your changes" (page 349). The remaining steps in this procedure are for load balancing inbound trafc only. End
Step 4b (inbound trafc): Congure the internal network Congure the virtual server IP addresses on the Nortel Application Switch as real server IP addresses. In this example, you will congure two real server IP addresses for each of the two virtual server IP addresses. Then, dene a real server group and add the real servers to the group. Step 1 Action Congure real server and create a group. The real server IP address must be the virtual server IP address of the SLB servers that are hosting abc.com.
.
357
>> # /cfg/slb/real 7/rip 1.1.1.100 >> Real server 7# ena >> # /cfg/slb/group 3 >> Real server Group 3# add 3
(Define IP address for www.abc.com) (Enable real server 3) (Define a group) (Add Real server 7)
Congure real server and create a group. The real server IP address must be the virtual server IP address of the SLB servers that are hosting xyz.com.
>> # /cfg/slb/real 8/rip 1.1.1.200 >> Real server 8# ena >> # /cfg/slb/group 4 >> Real server Group 4# add 4 (Define IP address for xyz.com) (Enable real server 8) (Define a group) (Add Real server 8)
Enable lter on server port 1. Filter is enabled on port 1, because you want the Nortel Application Switch to look up the session table for the RTS entry.
>> # /cfg/slb/port 1 >> SLB Port 1# filt ena (Select port 1) (Enable the filter)
Enable server processing on port 1.

>> # /cfg/slb/port 1/server ena (Enable server processing for port 1)
Congure an allow lter for health checks to occur. If you have enabled link load balancing lter and server processing on the same port, then an allow lter must be congured for health checks. The allow lter is activated before the link load balancing lter, so that the health check trafc does not get redirected to the WAN links.
>> # /cfg/slb/filt 50 >> Filter 50# sip 1.1.1.0 >> Filter 50# smask 255.255.255.0 (From server subnet)
.
>> Filter 50# dip 1.1.1.1 >> Filter 50# action allow >> Filter 50# ena
(To IF 1 on the Nortel Application Switch)
For more information on health checking, see "Health Checks for Real Servers" (page 201). 6 Add the allow lter 50 to port 1.
Note: If you are using two Nortel Application Switches for redundancy, then must add allow lters for VRRP before the redirection lter. For more information on VRRP, see "High Availability" (page 508)" End
Step 5: Congure the virtual server IP address and the services for each ISP All client requests is addressed to a virtual server IP address on a virtual server dened on the Nortel Application Switch. Clients acquire the virtual server IP address through normal DNS resolution. In this example, HTTP and FTP are congured as the services running on this virtual server, and this service is associated with the real server group. Other TCP/IP services can be congured in a similar fashion. For a list of other well-known services and ports, see "Well-Known Application Ports" (page 199). To congure multiple services, see "Conguring Multiple Services" (page 202). Note: Dene a virtual server IP address for each ISP. Step 5a: Congure the virtual server IP address and the services for ISP 1 Dene a virtual server and add the services and real server group for ISP 1. Step 1 Action Congure a virtual server for ISP 1.
.
359
>> # /cfg/slb/virt 1 >>Virtual Server 1# vip 50.1.1.100 >>Virtual Server 1# ena
(Select the virtual server) (Set IP address from the ISP 1 subnet) (Enable virtual server)

>> # /cfg/slb/virt 1 >>Virtual Server 1# service 80 >>Virtual Server 1 HTTP Service# ena >>Virtual Server 1 HTTP Service# group 3 >>Virtual Server 1 HTTP Service#.. >>Virtual Server 1# service ftp >>Virtual Server 1 ftp Service# ena >>Virtual Server 1 ftp Service# group 3 (Select the virtual server) (Add the HTTP service) (Enable the service) (Add real server group) (Go to the virtual server menu) (Add the FTP service) (Enable the service) (Add real server group)
Step 5b: Congure the virtual server IP address and the services for ISP 2 Dene a virtual server and add the services and real server group for ISP 2. 3 Congure a virtual server for ISP 2.

>> # /cfg/slb/virt 2 >>Virtual Server 2# service 80 >>Virtual Server 2 HTTP Service# group 3 >>Virtual Server 2 HTTP Service#.. (Select the virtual server) (Add the HTTP service) (Add real server group) (Go to the virtual server menu)
.
>>Virtual Server 2# service ftp >>Virtual Server 2 ftp Service# group 3
(Add the FTP service) (Add real server group)
Note: Repeat Steps 5a and 5b for virtual server 3 and 4 and add group 4 for each of the services. This allows inbound trafc to access SLB servers hosting the XYZ.com. End
Step 6: Congure the Application Switch as a Domain Name Server This involves conguring the domain record name and mapping the virtual server and real server (ISP router) for each WAN link.
You must map the domain record, nortelnetworks.com to each ISP. Each ISP has two parametersvirtual IP address and real server IP address. The virtual IP address is used to respond to the DNS query for the nortelnetworks.com domain. The real server IP address is used to measure the ISP load and ISP health. These commands map the two parameters to the ISP link Step 1 Action Congure the Domain record for abc.com .
>> # /cfg/slb/linklb/drecord 1 >> Domain Record 1# ena >> Domain record 1# domain abc.com (Select the Domain record menu) (Enable the Domain) (Define the Domain name)
Congure an entry for each ISP and specify the virtual and real server (ISP router).
.
361
>> Domain record 1# entry 1/ena >> Virt Real Mapping# virt 1 >> Virt Real Mapping# real 1 >> Domain record 1# entry 2/ena >> Virt Real Mapping# virt 2 >> Virt Real Mapping# real 2
(Define entry for ISP 1) (Select virtual server 1 for ISP 1) (Select real server for ISP 1) (Define entry for ISP 2) (Select virtual server 2 for ISP 2) (Select real server for ISP 2)
Congure the Domain record for xyz.com .

>> # /cfg/slb/linklb/drecord 2 >> Domain Record 2# ena >> Domain record 2# domain xyz.com (Select the Domain record menu) (Enable the Domain) (Define the Domain name)
Congure an entry for each ISP and specify the virtual and real server (ISP router).
>> Domain record 2# entry 1/ena >> Virt Real Mapping# virt 3 >> Virt Real Mapping# real 1 >> Domain record 1# entry 2/ena >> Virt Real Mapping# virt 4 >> Virt Real Mapping# real 2 (Define entry for ISP 1) (Select virtual server 3 for ISP 1) (Select real server for ISP 1) (Define entry for ISP 2) (Select virtual server 4 for ISP 2) (Select real server for ISP 2)
End
Step 7: Apply and save your changes You must apply in order for these changes to take effect, and you must save changes if you wish them to remain in effect after reboot.
.
Step 1
Action Apply and verify the conguration.

>> Layer 4# apply >> Layer 4# cur (Make your changes active) (View current settings)
Check the load balancing information.

Check that all load balancing parameters are working according to expectation. If necessary, make any appropriate conguration changes and then check the information again. End
Health Checking and Multi-homing

Instances can arise during WAN link load balancing where the disruption of service on one link may not be readily evident through the use of health checking. This is due to the nature of the health checking mechanism and how it interacts with the load balanced WAN environment. Consider a Nortel Application Switch 2424 that is mult-homed to two service providers. The switch has WAN link load balancing congured for incoming and outgoing trafc. If the link to the rst service provider is removed, the health check for this link does not fail eventhough the corresponding interface is down. This is due to the fact that the health check packet is still being sent and received through the connection to the second service provider. This is a by-product of the tendency of any routing protocol to re-route a packet to an active link.
.
363
To overcome this problem, two lters can be used to on the two load balanced ports to suppress the ICMP echo-reply which makes the health check fail if the link fails. The following commands would apply Filter 10 to the link to the rst service provider:
/c/slb/filt 10 ena action deny sip 80.1.1.1 smask 255.255.255.255 dip 50.1.1.2 dmask 255.255.255.255 proto icmp vlan any /c/slb/filt 10/adv icmp echorep
After the lter is applied to the rst link, the lter on the second link would be applied. The following commands would apply Filter 20 to the link to the second service provider:
/c/slb/filt 20 ena action deny sip 50.1.1.1 smask 255.255.255.255 dip 80.1.1.2 dmask 255.255.255.255 proto icmp vlan any /c/slb/filt 20/adv icmp echorep
In addition to the application of the lters, usage of a static route is recommended.
.
Filtering
This chapter provides a conceptual overview of lters and includes conguration examples showing how lters can be used for network security and Network Address Translation (NAT). The following topics are addressed in this chapter: Note: IPv6 lters support the allow, deny, and redirection actions. "Overview" (page 365). This section describes the benets and ltering criteria to allow for extensive ltering at the IP and TCP/UDP levels. "Filtering Benets" (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 any hash parameter for lter redirection. " Filter-based Security" (page 378). This section provides an example of conguring lters for providing the best security. "Network Address Translation" (page 385). This section provides two examples: Internal client access to the Internet and external client access to the server. "Matching TCP Flags" (page 394) and "Matching ICMP Message Types" (page 399). Describes the ACK lter criteria which provides greater ltering exibility and lists ICMP message types that can be ltered respectively. "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
Overview
Nortel Application Switch are used to deliver content efciently and secure your servers from unauthorized intrusion, probing, and Denial-of-Service (DoS) attacks. Nortel Application Switch Operating System includes extensive ltering capabilities at the Layer 2 (MAC), Layer 3 (IP) and Layer 4 (TCP/UDP) levels.
Filtering Benets
Filtering give the network administrator a powerful tool with the following benets: Filtering of Layer 2 non-IP frames. In the Nortel Application Switch Operating System, a lter can specify only source MAC and destination MAC addresses, and capture and apply an allow. Increased security for server networks Filtering gives the administrator control over the types of trafc permitted through the switch. Filters can be congured to allow or deny trafc from Layer 2 - Layer 7: MAC address, IP address, protocol, and Layer 4 port, and Layer 7 string or pattern content. Layer 2 only lters, as described in "MAC-Based Filters for Layer 2 Trafc" (page 372) can be congured to allow or deny non-IP trafc. You can also secure your switch from further virus attacks by allowing you to congure the switch with a list of potential offending string patterns. For more information, see "Deny Filter Based on Layer 7 Content Lookup" (page 400). Any lter can be optionally congured to generate system log messages for increased security visibility. Used to map the source or destination IP addresses and ports Generic Network Address Translation (NAT) can be used to map the source or destination IP addresses and the ports of private network trafc to or from advertised network IP addresses and ports.
Filtering Criteria
Up to 2048 lters can be congured on the Nortel Application Switch. Descriptive names can be used to dene lters. Each lter can be set to perform "Filtering Actions" (page 366), based on any combination of the following lter 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 Protocol Types" (page 366).
Well-Known Protocol Types Number 1 2 6 17 89 112 Protocol Name icmp igmp tcp udp ospf vrrp
sport: TCP/UDP application or source port as shown in "Well-Known Application Ports" (page 199), or source port range (such as 31000-33000) Note: The service number specied on the switch must match the service specied on the server.
dport: TCP/UDP application or destination port as shown in "Well-Known Application Ports" (page 199), or destination port range (such as 31000-33000) invert: reverse the lter logic in order to activate the lter whenever the specied conditions are not met. Advanced ltering options such as TCP ags ("Matching TCP Flags" (page 394)) or ICMP message types ("Matching ICMP Message Types" (page 399)) are also available.
Using these lter criteria, you could create a single lter that blocks external Telnet trafc to your main server except from a trusted IP address. Another lter could warn you if FTP access is attempted from a specic IP address. Another lter could redirect all incoming e-mail trafc to a server where it can be analyzed for spam. The options are nearly endless.
Filtering Actions
A ltering action (/cfg/slb/filt/action) instructs the lter what to do once the ltering criteria are matched. allowAllow the frame to pass (by default). denyDiscard frames that t this lters prole. This can be used for building basic security proles.
.
Filtering
367
redirRedirect frames that t this lters prole, such as for web cache redirection. In addition, Layer 4 processing must be activated using the /cfg/slb/on command). natPerform generic Network Address Translation (NAT). This can be used to map the source or destination IP address and port information of a private network scheme to/from the advertised network IP address and ports. This is used in conjunction with the nat option (mentioned in this table) and can also be combined with proxies. gotoAllows the user to specify a target lter ID that the lter search should jump to when a match occurs. The "goto" action causes lter processing to jump to a designated lter, effectively skipping over a block of lter IDs. Filter searching then continues from the designated lter ID. To specify the new lter to goto, use the /cfg/slb/filt/adv/goto command.
Stacking Filters
Stacking lters are assigned and enabled on a per-port basis. Each lter can be used by itself or in combination with any other lter on any given switch port. The lters are numbered 1 through 2048 on Nortel Application Switches. When multiple lters are stacked together on a port, the lters number determines its order of precedence: the lter with the lowest number is checked rst. When trafc is encountered at the switch port, if the lter matches, its congured action takes place and the rest of the lters are ignored. If the lter criteria do not match, the next lter is tried. As long as the lters do not overlap, you can improve lter performance by making sure that the most heavily utilized lters are applied rst. For example, consider a lter system where the Internet is divided according to destination IP address:
Assigning Filters According to Range of Coverage
Assuming that trafc is distributed evenly across the Internet, the largest area would be the most utilized and is assigned to Filter 1. The smallest area is assigned to Filter 4.
Overlapping Filters
Filters are permitted to overlap, although special care should be taken to ensure the proper order of precedence. When overlapping lters are present, the more specic lters (those that target fewer addresses or ports) should be applied before the generalized lters.
.
Example:
Assigning Filters to Overlapping Ranges
In this example, Filter 2 must be processed prior to Filter 3. If Filter 3 was permitted to take precedence, Filter 2 could never be triggered.
The Default Filter

Before ltering can be enabled on any given port, a default lter should be congured. This lter handles any trafc not covered by any other lter. All the criteria in the default lter must be set to the full range possible (any). For example:
Assigning a Default Filter
In this example, the default lter is dened as Filter 2048 in order to give it the lowest order of precedence. All matching criteria in Filter 2048 are set to the any state. If no other lter acts on the trafc, Filter 2048 processes it, denying and logging unwanted trafc.
(Select the default filter) >> # /cfg/slb/filt 2048 >> Filter 2048# sip any >> Filter 2048# dip any >> Filter 2048# proto any >> Filter 2048# action deny >> Filter 2048# name deny unwanted traffic >> Filter 2048# ena >> Filter 2048# adv >> Filter 2048 Advanced# log enable (From any source IP addresses) (To any destination IP addresses) (For any protocols) (Deny matching traffic) (Provide a descriptive name for the filter) (Enable the default filter) (Select the advanced menu) (Log matching traffic to syslog)
.
Filtering
369
Default lters are recommended (but not required) when conguring lters for IP trafc control and redirection. Using default lters can increase session performance but takes some of the session binding resources. If you experience an unacceptable number of binding failures, as shown in the Server Load Balancing Maintenance Statistics (/stats/slb/maint), you may wish to remove some of the default lters.
Optimizing Filter Performance

Filter efciency can be increased by placing lters that are used most often near the beginning of the ltering list. It is a recommended practice to number lters in small increments (5, 10, 15, 20, etc.) to make it easier to insert lters into the list at a later time. However, as the number of lters increases, you can improve performance by minimizing the increment between lters. For example, lters numbered 2, 4, 6, and 8 are more efcient than lters numbered 20, 40, 60, and 80. Peak processing efciency is achieved when lters are numbered sequentially beginning with 1.
IP Address Ranges
You can specify a range of IP addresses for ltering both the source and/or destination IP address for trafc. When a range of IP addresses is needed, the source IP (sip) address or destination IP (dip) address denes the base IP address in the desired range. The source mask (smask) or destination mask (dmask) is the mask that is applied to produce the range. For example, to determine if a client requests destination IP address should be redirected to the cache servers attached to a particular switch, the destination IP address is masked (bit-wise AND) with the dmask and then compared to the destination IP address. As another example, the switch could be congured with two lters so that each would handle trafc ltering for one half of the Internet. To do this, you could dene the following parameters:
Filtering IP Address Ranges Filter 1 2 Internet Address Range 0.0.0.0 - 127.255.255.255 128.0.0.0 - 255.255.255.255 dip 0.0.0.0 128.0.0.0 dmask 128.0.0.0 128.0.0.0
Filter Logs
To provide enhanced troubleshooting and session inspection capability, packet source and destination IP addresses are included in lter log messages. Filter log messages are generated when a Layer 3/Layer 4
.
lter is triggered and has logging enabled. The messages are output to the console port, system host log (syslog), and the Web-based interface message window. Example: A network administrator has noticed a signicant number of ICMP frames on one portion of the network and wants to determine the specic sources of the ICMP messages. The administrator uses the Command Line Interface (CLI) to create and apply the following lter:
(Select filter 15) >> # /cfg/slb/filt 15 >> Filter 15# sip any >> Filter 15# dip any >> Filter 15# action allow >> Filter 15# name allow matching traffic >> Filter 15# proto icmp >> Filter 15# ena >> Filter 15# adv/log enable >> Filter 15 Advanced# /cfg/slb/po rt 7 >> SLB port 7# add 15 >> SLB port 7# filt ena >> SLB port 7# apply >> SLB port 7# save (From any source IP address) (To any destination IP address) (Allows matching traffic to pass) (Provide a descriptive name for the filter) (For the ICMP protocol) (Enable the filter) (Log matching traffic to syslog) (Select a switch port to filter) (Add the filter to the switch port) (Enable filtering on the switch port) (Apply the configuration changes) (Save the configuration changes)
When applied to one or more switch ports, this simple lter rule produces log messages that show when the lter is triggered, and what the IP source and destination addresses were for the ICMP frames traversing those ports. Example: Filter log message output is shown below, displaying the lter number, 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 Filters

To improve efciency, by default, the Nortel Application Switch performs lter processing only on the rst frame in each session. Subsequent frames in the session are assumed to match the same criteria and are automatically treated in the same way as the initial frame. These lters create a session entry in the application switch and are known as cached. Some types of ltering (TCP ag and ICMP message type ltering) require each frame in the session to be ltered separately. These lters are known as non-cached. A Layer 2 lter, which species only smac and dmac criteria, is a non-cached lter. All lters are cached by default. To change the status of a lter, use the following commands:
(Select the advanced filter menu) (Enable or disable filter caching)
>> # /cfg/slb/filt <filter number> /adv >> Filter 1 Advanced # cache ena|dis
Note: Cache-enabled lters should not be applied to the same ports as cache-disabled lters. Otherwise, the cache-disabled lters could potentially be bypassed for frames matching the cache-enabled criteria.
Logging Non-Cached Filter Hits

A non-cached lter hit occurs when a session entry is not cached. Cache-disabled lters are used when a session is either very short-lived or contains minimal data. In order to log cache-disabled lters without generating an excess amount of syslog messages, the log message displays only a single NC lter message within a given window of time, which includes the number of times the cache-disabled lter has red. Step 1 Action To enable logging of both cached and cache-disabled lters, use the existing command:
>> # /cfg/slb/filt <#> /adv/log enable
Apply and save the conguration change.
.
>> 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: fired on port 1 repeated 4 times.
NON-cached filter 1
End
MAC-Based Filters for Layer 2 Trafc

In the Nortel Application Switch Operating System, lters can be congured based on MAC addresses to capture non-IP frames. The benets of a MAC-based ltering solution is that now a lter can be applied to allow or deny non-IP trafc such as ARP, AppleTalk. While ltering has always allowed MAC address criteria, only IP trafc was supported. To congure a lter for non-IP trafc, specify only the source MAC (smac) and destination MAC (dmac) addresses. Do not enter source or destination IP addresses on a MAC-based lter. MAC-based ltering of non-IP frames is supported for non-cached lters only. Even if caching is enabled on this type of lter, it does not create a session entry. To congure a MAC-based lter, specify only smac and dmac criteria without any IP-related parameters. The only ltering actions supported for MAC-based lters are allow and deny. MAC-based lters are supported for VLAN-based lters("VLAN-based Filtering" (page 373)), and 802.1p bit ltering ("Filtering on 802.1p Priority Bit in a VLAN Header" (page 376)). For example:
(Select the menu for Filter 23)>> (From any source MAC address) (To this MAC destination address) (Deny matching traffic) (Enable this filter)
>> # /cfg/slb/filt 23 Filter 23# smac any >> Filter 23# dmac 00:60:cf:40:56: 00 >> Filter 23# action deny >> Filter 23# ena
.
Filtering
373
VLAN-based Filtering
Filters are applied per switch, per port, or per VLAN. VLAN-based ltering allows a single application switch to provide differentiated services for multiple customers, groups, or departments. For example, you can dene separate lters for Customers A and B on the same application switch on two different VLANs. If VLANs are assigned based on data trafc, for example, ingress trafc on VLAN 1, egress trafc on VLAN 2, and management trafc on VLAN 3, lters can be applied accordingly to the different VLANs. In the following example shown in "VLAN-based Filtering" (page 373), Filter 2 is congured to allow local clients on VLAN 20 to browse the Web, and Filter 3 is congured to allow local clients on VLAN 30 to Telnet anywhere outside the local intranet. Filter 2048 is congured to deny ingress trafc from VLAN 70.
VLAN-based Filtering
Note: While the following example is based on IP trafc, VLAN-based ltering can also be used for non-IP trafc by specifying smac and dmac criteria instead of sip and dip.
Conguring VLAN-based Filtering

Step 1 Action Congure lter 2 to allow local clients to browse the Web and then assign VLAN 20 to the lter.
.
The lter must recognize and allow TCP trafc from VLAN 20 to reach the local client destination IP addresses if originating from any HTTP source port:
(Select the menu for Filter 2) (From any source IP address) (To base local network dest. address) (For entire subnet range) (For TCP protocol traffic) (From any source HTTP port) (To any destination port) (Allow matching traffic to pass) (Assign VLAN 20 to Filter 2) (Enable the filter)
>> # /cfg/slb/filt 2 >> Filter 2# sip any >> Filter 2# dip 205.177.15.0 >> Filter 2# dmask 255.255.255 .0 >> Filter 2# proto tcp >> Filter 2# sport http >> Filter 2# dport any >> Filter 2# action allow >> Filter 2# vlan 20 >> Filter 2# ena
All clients from other VLANs are ignored. 2 Congure lter 3 to allow local clients to Telnet anywhere outside the local intranet and then assign VLAN 30 to the lter. The lter must recognize and allow TCP trafc to reach the local client destination IP addresses if originating from a Telnet source port:
(Select the menu for Filter 3) (From any source IP address) (To base local network dest. address) (For entire subnet range) (For TCP protocol traffic) (From a Telnet port) (To any destination port)
>> # /cfg/slb/filt 3 >> Filter 3# sip any >> Filter 3# dip 205.177.15.0 >> Filter 3# dmask 255.255.255 .0 >> Filter 3# proto tcp >> Filter 3# sport telnet >> Filter 3# dport any
.
Filtering
375
>> Filter 3# action allow >> Filter 3# name allow clients to telnet >> Filter 3# vlan 30 >> Filter 3# ena
(Allow matching traffic to pass) (Provide a descriptive name for the filter) (Assign VLAN 30 to Filter 3) (Enable the filter)
Congure Filter 2048 to deny trafc and then assign VLAN 70 to the lter. As a result, ingress trafc from VLAN 70 is denied entry to the switch.
(Select the menu for Filter 2048) (From any source IP address) (To base local network dest. address) (For entire subnet range) (For TCP protocol traffic) (From a Telnet port) (To any destination port) (Allow matching traffic to pass) (Assign VLAN 70 to Filter 2048) (Enable the filter)
>> # /cfg/slb/filt 2048 >> Filter 2048# sip any >> Filter 2048# dip 205.177.15 .0 >> Filter 2048# dmask 255.255.255.0 >> Filter 2048# proto tcp >> Filter 2048# sport http >> Filter 2048# dport any >> Filter 2048# action deny >> Filter 2048# vlan 70 >> Filter 2048# ena
Assign VLAN-based lters to an SLB port. Before the lters can be used, they must be assigned to an SLB port.
>> # /cfg/slb/port 10 >> SLB Port 10# add 2 >> SLB Port 10# add 3 >> SLB Port 10# add 2048 (Select the menu for the port in use) (Add Filter 2 to SLB Port 10) (Add Filter 3 to SLB Port 10) (Add Filter 2048 to SLB Port 10)
End
.
Filtering on 802.1p Priority Bit in a VLAN Header

Nortel Application Switch Operating System allows you to lter based on the priority bits in a packets VLAN header. (The priority bits are dened by the 802.1p standard within the IEEE 802.1Q VLAN header.) The 802.1p bits, if present in the packet, specify the priority that should be given to packets during forwarding. Packets with a higher (non-zero) priority bits should be given forwarding preference over packets with numerically lower priority bit value.
802.1p Priorities
The IEEE 802.1p standard uses eight levels of priority, 0-7, with priority 7 being assigned to highest priority network trafc such as OSPF or RIP routing table updates, priorities 5-6 being for delay-sensitive applications such as voice and video, and lower priorities for standard applications. A value of zero indicates a "best effort" trafc prioritization, and this is the default when trafc priority has not been congured on your network. The Nortel Application Switch can only lter packets based on the 802.1p values already present in the packets. It does not assign or overwrite the 802.1p values in the packet.
Classifying Packets Based on 802.1p Priority Bits

Trafc is easily classied based on their 802.1p priority by applying a lter based on the priority bit value. The ltering advanced menu in Nortel Application Switch Operating System provides the option to lter based on the priority bit value. The lter matches if it nds the corresponding 802.1p bit value in the packet. If the packet does not have the 802.1p bits the lter will not match.
Conguring a Filter to Classify Trafc

To match on the 802.1p priority bit, go to the Filtering Advanced Menu. Then choose the 802.1p priority bit value (0-7). Step 1 Action Congure a lter and an action.
(Enable the filter) >> # /cfg/slb/filt <x> /ena >> Filter 1 # action allow (Set filter action)
Go to the ltering advanced menu and select the 802.1p priority value.
.
Filtering
377
>> # /cfg/slb/filt <x> >> 802.1p Advanced# adv/8021p/ >> 802.1p Advanced# match ena >> # 802.1p Advanced# value 1 (Select the 802.1p Advanced Menu) (Enable matching of 802.1p value) (Set the 802.1p priority value to match)
Apply a BWM Contract to the Prioritized Filter. You can apply an 802.1p-prioritized lter to a Bandwidth Management contract to establish the rule for how the trafc that matches the dened 802.1p priority value.
(Apply BWM contract 1 to this filter)
>> # /cfg/slb/filt <x> /adv/cont 1
For more information on conguring a Bandwidth Management contract, see "Contracts" (page 770). End
Tunable Hash for Filter Redirection

Nortel Application Switch Operating System allows you to choose a number of options when using the hash parameter for lter redirection. Hashing can be based on source IP address, destination IP address, both, or source IP address and source port. For example: Step 1 Action Congure hashing based on source IP address:
(Enable the filter) >> # /cfg/slb/filt 10/ena >> Filter 10 # action redir >> Filter 10 # proto tcp >> Filter 10 # group 1 >> Filter 10 # rport 3128 >> Filter 10 # vlan any
.
(Specify the redir action) (Specify the protocol) (Specify the group of real servers) (Specify the redirection port) (Specify the VLAN)
>> Filter 10 # adv >> TCP advanced menu # thash sip
(Select the advanced filter menu) (Select source IP address for hashing)
Hashing on the 24-bit source IP address ensures that client requests access 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 either of the two metrics.
(Select the group of real servers) (Set the metric to minmiss or hash)
>> # /cfg/slb/group 1 >> Real server group 1 # metric minmiss
Note: If rewall load balancing is enabled on the switch, the rewall load balancing lter which hashes on source and destination IP addresses will override the tunable hash lter. End
Filter-based Security
This section provides an example of conguring lters for providing the best security. It is recommended that you congure lters to deny all trafc except for those services that you specically wish to allow. Consider the following sample network:
Security Topology Example
.
Filtering
379
In this example, the network is made of local clients on a collector switch, a Web server, a mail server, a domain name server, and a connection to the Internet. All the local devices are on the same subnet. In this example, the administrator wishes to install basic security lters to allow only the following trafc: 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 trafc
All other trafc is denied and logged by the default lter. Note: Since IP address and port information can be manipulated by external sources, ltering does not replace the necessity for a well-constructed network rewall.
Conguring a Filter-Based Security Solution

Before you begin, you must be connected to the switch CLI as the administrator. In this example, all lters are applied only to the switch port that connects to the Internet. If intranet restrictions are required, lters can be placed on switch ports connecting to local devices. Also, ltering is not limited to the few protocols and TCP or UDP applications shown in this example. See "Well-Known Application Ports" (page 199) for a list of well-known applications ports and "Well-Known Protocol Types" (page 366) for a list of supported protocols. Step 1 Action Assign an IP address to each of the network devices. For this example, the network devices have the following IP addresses on the same IP subnet:
Web Cache Example: Real Server IP Addresses Network Device Local Subnet Web Server Mail Server Domain Name Server IP address 205.177.15.0 - 205.177.15.255 205.177.15.2 205.177.15.3 205.177.15.4
.
At the Application Switch, create a default lter to deny and log unwanted trafc. The default lter is dened as Filter 2048 in order to give it the lowest order of precedence:
(Select the default filter) >> # /cfg/slb/filt 2048 >> Filter 2048# sip any >> Filter 2048# dip any >> Filter 2048# proto any >> Filter 2048# action deny >> Filter 2048# name deny unwanted traffic >> Filter 2048# ena >> Filter 2048# adv/log enable (From any source IP addresses) (To any destination IP addresses) (For any protocols) (Deny matching traffic) (Provide a descriptive name for the filter) (Enable the default filter) (Log matching traffic to syslog)
Note: Because the proto parameter is not tcp or udp, the source port ( sport) and destination port ( dport) values are ignored and may be excluded from the lter conguration. 3 Create a lter that will allow external HTTP requests to reach the Web server. The lter must recognize and allow TCP trafc with the Web servers destination IP address and HTTP destination port:
(Select the menu for filter 1) >> Filter 2048# /cfg/slb/filt 1 >> Filter 1# sip any >> Filter 1# dip 205.177.15.2 >> Filter 1# dmask 255.255.255 .255 >> Filter 1# proto tcp >> Filter 1# sport any >> Filter 1# dport http (From any source IP address) (To Web server dest. IP address) (Set mask for exact dest. address) (For TCP protocol traffic) (From any source port) (To an HTTP destination port)
.
Filtering
381
>> Filter 1# action allow >> Filter 1# name allow matching traffic >> Filter 1# ena
(Allow matching traffic to pass) (Provide a descriptive name for the filter) (Enable the filter)
Create a pair of lters to allow incoming and outgoing mail to and from the mail server. Filter 2 allows incoming mail to reach the mail server, and Filter 3 allows outgoing mail to reach the Internet:
(Select the menu for filter 2) >> Filter 1# /cfg/slb/filt 2 >> Filter 2# sip any >> Filter 2# dip 205.177.15.3 >> Filter 2# dmask 255.255.255 .255 >> Filter 2# proto tcp >> Filter 2# sport any >> Filter 2# dport smtp >> Filter 2# action allow >> Filter 2# ena >> Filter 2# /cfg/slb/filt 3 >> Filter 3# sip 205.177.15.3 >> Filter 3# smask 255.255.255 .255 >> Filter 3# dip any >> Filter 3# proto tcp >> Filter 3# sport smtp >> Filter 3# dport any >> Filter 3# action allow >> Filter 3# ena (From any source IP address) (To mail server dest. IP address) (Set mask for exact dest. address) (For TCP protocol traffic) (From any source port) (To a SMTP destination port) (Allow matching traffic to pass) (Enable the filter) (Select the menu for filter 3) (From mail server source IP address) (Set mask for exact source address) (To any destination IP address) (For TCP protocol traffic) (From a SMTP port) (To any destination port) (Allow matching traffic to pass) (Enable the filter)
.
Create a lter that will allow local clients to browse the Web. The lter must recognize and allow TCP trafc to reach the local client destination IP addresses if trafc originates from any HTTP source port:
>> Filter 3# /cfg/slb/filt 4 >> Filter 4# sip any >> Filter 4# dip 205.177.15.0 >> Filter 4# dmask 255.255.255 .0 >> Filter 4# proto tcp >> Filter 4# sport http >> Filter 4# dport any >> Filter 4# action allow >> Filter 4# name allow clients Web browse >> Filter 4# ena (Select the menu for Filter 4) (From any source IP address) (To base local network dest. address) (For entire subnet range) (For TCP protocol traffic) (From any source HTTP port) (To any destination port) (Allow matching traffic to pass) (Provide a descriptive name for the filter) (Enable the filter)
Create a lter that will allow local clients to Telnet anywhere outside the local intranet. The lter must recognize and allow TCP trafc to reach the local client destination IP addresses if originating from a Telnet source port:
(Select the menu for Filter 5) (From any source IP address) (To base local network dest. address) (For entire subnet range) (For TCP protocol traffic) (From a Telnet port) (To any destination port)
>> Filter 4# /cfg/slb/filt 5 >> Filter 5# sip any >> Filter 5# dip 205.177.15.0 >> Filter 5# dmask 255.255.255 .0 >> Filter 5# proto tcp >> Filter 5# sport telnet >> Filter 5# dport any
.
Filtering
383
>> Filter 5# action allow >> Filter 5# ena
(Allow matching traffic to pass) (Enable the filter)
Create a series of lters to allow Domain Name System (DNS) trafc. DNS trafc requires four lters; one pair is needed for UDP trafc (incoming and outgoing) and another pair for TCP trafc (incoming and outgoing). For UDP:
(Select the menu for Filter 6) (From any source IP address) (To local DNS Server) (Set mask for exact dest. address) (For UDP protocol traffic) (From any source port) (To any DNS destination port) (Allow matching traffic to pass) (Enable the filter) (Select the menu for Filter 7) (From local DNS Server) (Set mask for exact source address) (To any destination IP address) (For UDP protocol traffic) (From a DNS source port) (To any destination port) (Allow matching traffic to pass) (Enable the filter)
>> Filter 5# /cfg/slb/filt 6 >> Filter 6# sip any >> Filter 6# dip 205.177.15.4 >> Filter 6# dmask 255.255.255 .255 >> Filter 6# proto udp >> Filter 6# sport any >> Filter 6# dport domain >> Filter 6# action allow >> Filter 6# ena >> Filter 6# /cfg/slb/filt 7 >> Filter 7# sip 205.177.15.4 >> Filter 7# smask 255.255.255 .255 >> Filter 7# dip any >> Filter 7# proto udp >> Filter 7# sport domain >> Filter 7# dport any >> Filter 7# action allow >> Filter 7# ena
Similarly, for TCP:

.
>> Filter 7# /cfg/slb/filt 8 >> Filter 8# sip any >> Filter 8# dip 205.177.15.4 >> Filter 8# dmask 255.255.255 .255 >> Filter 8# proto tcp >> Filter 8# sport any >> Filter 8# dport domain >> Filter 8# action allow >> Filter 8# ena >> Filter 8# /cfg/slb/filt 9 >> Filter 9# sip 205.177.15.4 >> Filter 9# smask 255.255.255 .255 >> Filter 9# dip any >> Filter 9# proto tcp >> Filter 9# sport domain >> Filter 9# dport any >> Filter 9# action allow >> Filter 9# ena
(Select the menu for Filter 8) (From any source IP address) (To local DNS Server) (Set mask for exact dest. address) (For TCP protocol traffic) (From any source port) (To any DNS destination port) (Allow matching traffic to pass) (Enable the filter) (Select the menu for Filter 9) (From local DNS Server) (Set mask for exact source address) (To any destination IP address) (For TCP protocol traffic) (From a DNS source port) (To any destination port) (Allow matching traffic to pass) (Enable the filter)
Assign the lters to the switch port that connects to the Internet.
(Select the SLB port 5 to the Internet) (Add filters 1-9 to port 5) (Add the default filter to port 5) (Enable filtering for port 5)
>> Filter 9# /cfg/slb/port 5 >> SLB Port 5# add 1-9 >> SLB Port 5# add 2048 >> SLB Port 5# filt enable
Nortel Application Switch Operating System allows you to add and remove a contiguous block of lters with a single command.
.
Filtering
385

(Make your changes active) >> SLB Port 5# apply >> SLB Port 5# cur (View current settings)
Examine the resulting information. If any settings are incorrect, make appropriate changes. 10 Save your new conguration changes.
(Save for restore after reboot)
>> SLB Port 5# save
11
Check the server load balancing information.

(View SLB information) >> SLB Port 5# /info/slb/dump
Check that all SLB parameters are working according to expectation. If necessary, make any appropriate conguration changes and then check the information again. Note: Changes to lters on a given port do not take effect until the ports session information is updated (every two minutes or so). To make lter changes take effect immediately, clear the session binding table for the port (see the /oper/slb/clear command in the Nortel Application Switch Operating System Command Reference). End
Network Address Translation

Network Address Translation (NAT) is an Internet standard that enables an Nortel Application Switch to use one set of IP addresses for internal trafc and a second set of addresses for external trafc. Nortel Application Switches use lters to implement NAT. NAT serves two main purposes: Provides a type of rewall by hiding internal IP addresses and increases network security. Enables a company to use more internal IP addresses. Since theyre used internally only, theres no possibility of conict with public IP addresses used by other companies and organizations.
.
In the following NAT examples, a company has congured its internal network with private IP addresses. A private network is one that is isolated from the global Internet and is, therefore, free from the usual restrictions requiring the use of registered, globally unique IP addresses. With NAT, private networks are not required to remain isolated. NAT capabilities within the switch allow internal, private network IP addresses to be translated to valid, publicly advertised IP addresses and back again. NAT can be congured in one of the following two ways: Static NAT provides a method for direct mapping of one predened IP address (such as a publicly available IP address) to another (such as a private 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 conserve publicly advertised IP addresses)
Static NAT
The static NAT (non-proxy) example requires two lters: one for the external client-side switch port, and one for the internal, server-side switch port. The client-side lter translates incoming requests for the publicly advertised server IP address to the servers internal private network address. The lter for the server-side switch port reverses the process, translating the servers private address information to a valid public address. In this example, clients on the Internet require access to servers on the private network:
Static Network Address Translation
Conguring Static NAT

>> # /cfg/slb/filt 10 >> Filter 10# action nat (Select the menu for outbound filter) (Perform NAT on matching traffic)
.
Filtering
387
>> Filter 10# nat source >> Filter 10# sip 10.10.10.0 >> Filter 10# smask 255.255.255.0 >> Filter 10# dip 205.178.13.0 >> Filter 10# dmask 255.255.255.0 >> Filter 10# ena >> Filter 10# adv/proxy disable >> Filter 10 Advanced# /cfg/slb/f ilt 11 >> Filter 11# action nat >> Filter 11# nat dest >> Filter 11# sip 10.10.10.0 >> Filter 11# smask 255.255.255.0 >> Filter 11# dip 205.178.13.0 >> Filter 11# dmask 255.255.255.0 >> Filter 11# ena >> Filter 11# adv/proxy disable >> Filter 11 Advanced# /cfg/slb/po rt 1 >> SLB port 1# add 10 >> SLB port 1# filt enable >> SLB port 1# /cfg/slb/port 2 >> SLB port 2# add 11 >> SLB port 2# filt enable >> SLB port 2# apply >> SLB port 2# save
(Translate source information) (From the clients private IP address) (For the entire private subnet range) (To the public network address) (For the same subnet range) (Enable the filter) (Override any proxy IP settings) (Select the menu for inbound filter) (Use the same settings as outbound) (Reverse the translation direction) (Use the same settings as outbound) (Use the same settings as outbound) (Use the same settings as outbound) (Use the same settings as outbound) (Enable the filter) (Override any proxy IP settings) (Select server-side port) (Add the outbound filter) (Enable filtering on port 1) (Select the client-side port) (Add the inbound filter) (Enable filtering on port 2) (Apply configuration changes) (Save configuration changes)
Note the following important points about this conguration: Within each lter, the smask and dmask values are identical.
.
All parameters for both lters 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 dynamic NAT lters (following example). Static lters should be given lower lter numbers.
Dynamic NAT
Dynamic NAT is a many-to-one solution: multiple clients on the private subnet take advantage of a single external IP address, thus conserving valid IP addresses. In this example, clients on the internal private network require TCP/UDP access to the Internet:
Dynamic Network Address Translation
You may directly connect the clients to the application switch if the total number of clients is less than or equal to the switch ports. Note: Dynamic NAT can also be used to support ICMP trafc for PING. This example requires a NAT lter to be congured on the switch port that is connected to the internal clients. When the NAT lter is triggered by outbound client trafc, the internal private IP address information on the outbound packets is translated to a valid, publicly advertised IP address on the switch. In addition, the public IP address must be congured as a proxy IP address on the switch port that is connected to the internal clients. The proxy performs the reverse translation, restoring the private network addresses on inbound packets.
Conguring Dynamic NAT

>> # /cfg/slb/filt 14 >> Filter 14# invert ena >> Filter 14# dip 10.10.10.0 (Select the menu for client filter) (Invert the filter logic) (If the destination is not private)
.
Filtering
389
>> Filter 14# dmask 255.255.255.0 >> Filter 14# sip any >> Filter 14# action nat >> Filter 14# nat source >> Filter 14# ena >> Filter 14# adv/proxy enable
(For the entire private subnet range) (From any source IP address) (Perform NAT on matching traffic) (Translate source information) (Enable the filter) (Enable client proxy on this filter)
>> Filter 14 Advanced# proxyip 205.178.17.12 (Set the filters proxy IP address) >> Filter 14 Advanced# /cfg/slb/po rt 1 >> SLB port 1# add 14 >> SLB port 1# filt enable >> SLB port 1# proxy ena >> SLB port 1# apply >> SLB port 1# save (Select SLB port 1) (Add the filter 14 to port 1) (Enable filtering on port 1) (Enable proxies on this port) (Apply configuration changes) (Save configuration changes)
For more information on proxy IP address, see "Proxy IP Addresses" (page 228). Note 1: The invert option in this example lter makes this specic conguration easier, but is not a requirement for dynamic NAT. Note 2: Filters for dynamic NAT should be given a higher numbers than any static NAT lters (see "Static NAT" (page 386)).
FTP Client NAT

Nortel Application Switches provide NAT services to many clients with private IP addresses. In Nortel Application Switch Operating System, an FTP enhancement provides the capability to perform true FTP NAT for dynamic NAT. Because of the way FTP works in active mode, a client sends information on the control channel, information that reveals their private IP address, out to the Internet. However, the switch lter only performs NAT translation on the TCP/IP header portion of the frame, preventing a client with a private IP address from doing active FTP.
.
The switch can monitor the control channel and replace the client s private IP address with a proxy IP address dened on the switch. When a client in active FTP mode sends a port command to a remote FTP server, the switch will look into the data part of the frame and modify the port command as follows: The real server (client) IP address will be replaced by a public proxy IP 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 total number of servers is less than or equal to the switch ports.
Conguring Active FTP Client NAT

Note: The passive mode does not need this feature. Step 1 2 Action Make sure that a proxy IP address is enabled on the lter port. Make sure that a source NAT lter is set up for the port.:
>> # /cfg/slb/filt 14 >> Filter 14# invert ena >> Filter 14# dip 10.10.10.0 >> Filter 14# dmask 255.255.25 5.0 >> Filter 14# sip any (Select the menu for client filter) (Invert the filter logic) (If the destination is not private) (For the entire private subnet range) (From any source IP address)
.
Filtering
391
>> Filter 14# action nat >> Filter 14# nat source >> Filter 14# ena >> Filter 14# adv/proxy enable
(Perform NAT on matching traffic) (Translate source information) (Enable the filter) (Allow proxy IP translation)
>> Filter 14 Advanced# proxyip 205.178.17.12 (Set the filters proxy IP address) >> Proxy IP Address# /cfg/slb/p ort 1 >> SLB port 1# add 14 >> SLB port 1# filt enable >> SLB port 1# proxy ena >> SLB port 1# apply >> SLB port 1# save (Select SLB port 1) (Add the filter to port 1) (Enable filtering on port 1) (Enable proxies on this port) (Apply configuration changes) (Save configuration changes)
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/ftpa ena
Apply and save the switch conguration. End
Overlapping NAT
The Nortel Application Switch Operating System supports the presence of overlapping or duplicate source IP addresses on different VLANs in a source NAT lter. This is accomplished by extending the session table lookup algorithm to include the session VLAN. In instances where an overlapping source IP address is present for different VLANs, the switch will create different sessions. For the source NAT, the switch substitutes the source IP address with the congured proxy IP address. A proxy IP address for the VLAN must be congured for this to function properly.
.
In instances where an overlapping NAT is present the switch will not use the routing table to route the packet back to the sender, due to the overlapping source address, in Layer 3 mode. Instead, the switch will use the VLAN gateway to forward the packet back to the sender. VLAN gateway conguration is necessary to make this feature function properly. Layer 2 mode is supported however.
Conguring Overlapping NAT

Step 1 Action Congure Gateway per VLAN Default Gateway 5 or above must be used for the VLAN gateway as gateways 1 through 4 are reserved for default gateways.
>> Main# /cfg/l3/gw 5 >> Default Gateway 5# addr <IP address> >> Default Gateway 5# vlan 100
Congure source NAT lter Select the appropriate lter for usage. In this example, lter 2 is used.
>> Main# /cfg/slb/filt 2/action na
Enable Overlapping NAT

>> Main# /cfg/slb/adv/pvlantag enable
End
SIP NAT and Gleaning Support

The IP end points on a network are typically assigned private addresses. Voice calls from and to the public network need to reach end points on the private network. As a result, NAT is required to allow proper routing of media to end points with private addresses. The SIP carries the identication of the IP end point (IP address/Port) within the body of the message. The voice media which gets directed to the private IP address identied in the signaling message cannot be routed and results in a one way path. Therefore, Nortel Application Switch Operating System 24.0 allows you to NAT the SDP and create sessions for the media communication.
.
Filtering
393
How SIP NAT Works

All occurrences of the internal clients private IP address and port in the outgoing SIP message is replaced with the translated address. This procedure is reversed when the SIP messages come from the outside, in which case the public IP is replaced with the private clients IP and port. Nortel Application Switch Operating System 24.0 translates the IP address and port.
Setting Up SIP NAT

To set up SIP NAT, congure a NAT lter and enable SIP parsing. The SIP NAT modies the signaling to reect the public IP addresses and ports. These pinholes and NAT bindings are assigned dynamically based on stateful inspection. The SIP NAT performs the necessary translation of the IP addresses embedded in the SIP messages and updates the SIP message before sending the packet out. To support SIP NAT and gleaning, you must congure the following: Step 1 2 Action Enable VMA. Congure a NAT lter. Dynamic NAT is supported only.
>> Main# /cfg/slb/filt 14 >> Filter 14# action nat >> Filter 14# nat source
Enable SIP parsing.

>> >> >> >> >> Main# /cfg/slb/filt 14 Filter 14# adv Filter 14 Advanced# Layer7 Layer 7 Advanced# sip Layer 7 SIP# sipp ena
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 MCS PC client will create message digests using the clients private address. These digests are sent back to the MCS server for authentication during the invite stage. Call setup will fail with MCS proxy authentication enabled as the switch does not regenerate these message digests with the public address. End
Matching TCP Flags

Nortel Application Switch Operating System supports packet ltering based on any of the following TCP ags.
Flag URG ACK PSH RST SYN FIN Description Urgent Acknowledgement Push Reset Synchronize Finish
Any lter may be set to match against more than one TCP ag at the same time. If there is more than one ag enabled, the ags are applied with a logical AND operator. For example, by setting the switch to lter SYN and ACK, the switch lters all SYN-ACK frames. Note: TCP ag lters must be cache-disabled. Exercise caution when applying cache-enabled and cache-disabled lters to the same switch port. For more information, see "Cached versus Non-cached Filters" (page 371).
Conguring the TCP Flag Filter

Note: By default, all TCP lter options are disabled. TCP ags will not be inspected unless one or more TCP options are enabled. Consider the following network:
.
Filtering TCP ACK Matching Network
395
In this network, the Web servers inside the LAN must be able to transfer mail 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 trafc uses well-known TCP Port 25. The Web servers will originate TCP sessions to the SMTP server using TCP destination Port 25, and the SMTP server will acknowledge each TCP session and data transfer using TCP source Port 25. Creating a lter with the ACK ag closes one potential security hole. Without the lter, the switch would permit a TCP SYN connection request to reach any listening TCP destination port on the Web servers inside the LAN, as long as it originated from TCP source Port 25. The server would listen to the TCP SYN, allocate buffer space for the connection, and reply to the connect request. In some SYN attack scenarios, this could cause the servers buffer space to ll, crashing the server or at least making it unavailable. A lter with the ACK ag enabled prevents external devices from beginning a TCP connection (with a TCP SYN) from TCP source Port 25. The switch drops any frames that have the ACK ag turned off. The following lters are required: Step 1 Action An allow lter for TCP trafc from LAN that allows the Web servers to pass SMTP requests to the Internet.
>> # /cfg/slb/filt 10 >> Filter 10# sip 203.122.186.0 >> Filter 10# smask 255.255.25 5.0 >> Filter 10# sport any >> Filter 10# proto tcp >> Filter 10# dip any (Select a filter for trusted SMTP requests) (From the Web servers source IP address) (For the entire subnet range) (From any source port) (For TCP traffic) (To any destination IP address)
.
>> Filter 10# dport smtp >> Filter 10# action allow >> Filter 10# ena
(To well-known destination SMTP port) (Allow matching traffic to pass) (Enable the filter)
A lter that allows SMTP trafc from the Internet to pass through the switch only if the destination is one of the Web servers, and the frame is an acknowledgment (SYN-ACK) of a TCP session.
>> Filter 10# /cfg/slb/filt 15 >> Filter 15# sip any >> Filter 15# sport smtp >> Filter 15# proto tcp >> Filter 15# dip 203.122.186.0 >> Filter 15# dmask 255.255.25 5.0 >> Filter 15# dport any >> Filter 15# action allow >> Filter 15# ena >> Filter 15# adv/tcp >> Filter 15 Advanced# ack ena >> Filter 15 Advanced# syn ena (Select a filter for Internet SMTP ACKs) (From any source IP address) (From well-known source SMTP port) (For TCP traffic) (To the Web servers IP address) (To the entire subnet range) (To any destination port) (Allow matching traffic to pass) (Enable the filter) (Select the advanced TCP menu) (Match acknowledgments only) (Match acknowledgments only)
A lter that allows SMTP trafc from the Internet to pass through the switch only if the destination is one of the Web servers, and the frame is an acknowledgment (ACK-PSH) of a TCP session.
>> Filter 15# /cfg/slb/filt 16 >> Filter 16# sip any >> Filter 16# sport smtp (Select a filter for Internet SMTP ACKs) (From any source IP address) (From well-known source SMTP port)
.
Filtering
397
>> Filter 16# proto tcp >> Filter 16# dip 203.122.186.0 >> Filter 16# dmask 255.255.25 5.0 >> Filter 16# dport any >> Filter 16# action allow >> Filter 16# ena >> Filter 16# adv/tcp >> Filter 16 Advanced# ack ena >> Filter 16 Advanced# psh ena
(For TCP traffic) (To the Web servers IP address) (To the entire subnet range) (To any destination port) (Allow matching traffic to pass) (Enable the filter) (Select the advanced TCP menu) (Match acknowledgments only) (Match acknowledgments only)
A lter that allows trusted HTTP trafc from the Internet to pass through the switch to the Web servers.
>> Filter 16 Advanced# /cfg/slb/filt 17 >> Filter 17# sip any >> Filter 17# sport http >> Filter 17# proto tcp >> Filter 17# dip 203.122.186.0 >> Filter 17# dmask 255.255.25 5.0 >> Filter 17# dport http >> Filter 17# action allow >> Filter 17# ena (Select a filter for incoming HTTP traffic) (From any source IP address) (From well-known source HTTP port) (For TCP traffic) (To the Web servers IP address) (To the entire subnet range) (To well-known destination HTTP port) (Allow matching traffic to pass) (Enable the filter)
A lter that allows HTTP responses from the Web servers to pass through the switch to the Internet.
.
>> Filter 17# /cfg/slb/filt 18 >> Filter 18# sip 203.122.186.0 >> Filter 18# smask 255.255.25 5.0 >> Filter 18# sport http >> Filter 18# proto tcp >> Filter 18# dip any >> Filter 18# dport http >> Filter 18# action allow >> Filter 18# ena
(Select a filter for outgoing HTTP traffic) (From the Web servers source IP address) (From the entire subnet range) (From well-known source HTTP port) (For TCP traffic) (To any destination IP address) (To well-known destination HTTP port) (Allow matching traffic to pass) (Enable the filter)
A default lter is required to deny all other trafc.

>> Filter 18# /cfg/slb/filt 2048 >> Filter 2048# sip any >> Filter 2048# dip any >> Filter 2048# action deny (Select a default filter) (From any source IP address) (To any destination IP address) (Block matching traffic)
>> Filter 2048# name deny matching traffic (Provide a descriptive name for the filter) >> Filter 2048# ena (Enable the filter)
Apply the lters to the appropriate switch ports.

>> Filter 2048# /cfg/slb/port 1 >> SLB port 1# add 15 >> SLB port 1# add 16 >> SLB port 1# add 17 (Select the Internet-side port) (Add the SMTP ACK filter to the port) (Add the incoming HTTP filter) (Add the incoming HTTP filter)
.
Filtering
399
>> SLB port 1# add 2048 >> SLB port 1# filt ena >> SLB port 1# /cfg/slb/port 2 >> SLB port 2# add 10 >> SLB port 2# add 18 >> SLB port 2# add 2048 >> SLB port 2# filt ena >> SLB port 2# /cfg/slb/port 3 >> SLB port 3# add 10 >> SLB port 3# add 18 >> SLB port 3# add 2048 >> SLB port 3# filt ena >> SLB port 3# apply >> SLB port 3# save
(Add the default filter to the port) (Enable filtering on the port) (Select the first Web server port) (Add the outgoing SMTP filter to the port) (Add the outgoing HTTP filter to the port) (Add the default filter to the port) (Enable filtering on the port) (Select the other Web server port) (Add the outgoing SMTP filter to the port) (Add the outgoing HTTP filter to the port) (Add the default filter to the port) (Enable filtering on the port) (Apply the configuration changes) (Save the configuration changes)
End
Matching ICMP Message Types

Internet Control Message Protocol (ICMP) is used for reporting TCP/IP processing errors. There are numerous types of ICMP messages, as shown in "ICMP Message Types" (page 400). Although ICMP packets can be ltered using the proto icmp option, by default, the application switch ignores the ICMP message type when matching a packet to a lter. To perform ltering based on specic ICMP message types, ICMP message type ltering must be enabled. Nortel Application Switch Operating System software supports ltering on the following ICMP message types:
.
400 Part 3: Application Switching Fundamentals ICMP Message Types Type # 0 3 4 5 8 9 10 11 12 13 14 15 16 17 18 Message Type echorep destun quench redir echoreq rtradv rtrsol timex param timereq timerep inforeq inforep maskreq maskrep Description ICMP echo reply ICMP destination unreachable ICMP source quench ICMP redirect ICMP echo request ICMP router advertisement ICMP router solicitation ICMP time exceeded ICMP parameter problem ICMP timestamp request ICMP timestamp reply ICMP information request ICMP information reply ICMP address mask request ICMP address mask reply
The command to enable or disable ICMP message type ltering is entered from the Advanced Filtering menu as follows:
>> # /cfg/slb/filt <filter number> /adv >> Filter 1 Advanced# icmp <message type|number|any|list>
For any given lter, only one ICMP message type can be set at any one time. The any option disables ICMP message type ltering. The list option displays a list of the available ICMP message types that can be entered. Note: ICMP message type lters must be cache-disabled. Exercise caution when applying cache-enabled and cache-disabled lters to the same switch port. For more information, see "Cached versus Non-cached Filters" (page 371).
Deny Filter Based on Layer 7 Content Lookup

Nortel Application Switch Operating System allows you to secure your switch from virus attacks or invalid data requests by conguring the switch with lters containing potential offending string patterns. Examples of such strings include those embedded in an HTTP URL request, SOAPAction request bound to an HTTP header, or certain strings contained in the data portion of UDP trafc. The switch examines theHTTP or UDP content of
.
Filtering
401
the incoming client request for the matching string pattern. If the matching virus pattern is found, then the packet is dropped and a reset frame is sent to the offending client. SYSLOG messages and SNMP traps are generated warning operators of a possible attack. A layer string 7 deny lter works just like a basic deny lter, except that the deny action is delayed until the string content is examined to see if the packet should be denied. "Conguring a Deny Filter with Layer 7 Lookup for HTTP URL, HTTP Header, or UDP Strings" (page 401) shows an incoming client requests with offending content. The application switch is congured with a deny lter combined with the Layer 7 lookup feature. The lter blocks the incoming packet with the offending string or pattern, and prevents it from entering the network.
Conguring a Deny Filter with Layer 7 Lookup for HTTP URL, HTTP Header, or UDP Strings
Denying HTTP URL Requests

Step 1 Action Before creating a deny lter with Layer 7 lookup, ensure that the switch has already been congured for basic switch functions: Assign an IP address to each of the real servers in the server pool. Dene an IP interface on the switch.
For information on how to congure your network for the above tasks, see "Server Load Balancing" (page 188)."
.
Dene the virus string patterns or offending HTTP URL request to be blocked.
>> # /cfg/slb/layer7/slb/addstr ida >> Server Loadbalance Resource# add %c1%9c >> Server Loadbalance Resource# add %c0%af (Define the code red virus string) (Define the code blue virus string) (Define the code blue virus string)
>> Server Loadbalance Resource# add playdog.com (Define offending URL request)
Identify the IDs of the dened strings.

>> Server Loadbalance resource# cur
Number of entries: 4
ID 1 2 3 4 SLB String ida %c1%9c %c0%af playdog.com
Assign the URL string IDs from step 2 to the lter.

>> /cfg/slb/filt 1/adv/layer7 >> Layer 7 Advanced# addstr 1 >> Layer 7 Advanced# addstr 2 >> Layer 7 Advanced# addstr 3 >> Layer 7 Advanced# addstr 4 (Select the Filt. 1 L7 Advanced menu) (Add the code red virus string) (Add the code blue virus string) (Add the code blue virus string) (Add the offending URL request)
Enable Layer 7 lookup. This feature, when combined with the lter deny action, will match and deny any trafc containing the strings you just added in step 4 .
.
Filtering
403
>> /cfg/slb/filt 1/adv/layer7/l 7lkup ena
(Enable the Layer 7 lookup feature)
Select the lter and enable the lter action to deny.

>> # /cfg/slb/filt 1 >> Filter 1 # action deny (Select the filter) (Set the filter action to deny)

>> Filter 1 Advanced# apply >> Filter 1 Advanced# save (Apply the filter) (Save the configuration)
End
Denying HTTP Headers

Layer 7 deny lters can be congured to match and deny on any HTTP headers. 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=*
Congure a lter as described in "Denying HTTP URL Requests" (page 401). Step 1 Action Dene the HTTP header strings to be blocked.
>> /cfg/slb/layer7/slb/ (Select the Serverloadbalance Resource menu)
>> Server Loadbalance Resource# add Enter type of string [l7lkup|pattern]: Configure HTTP header string? [y/n] y l7lkup
.
(Define HTTP header name Host) Enter HTTP header name: Host Enter SLB header value string: www.playdog.com (Define offending header content) Configure URL string? Enter URL string: [y/n] y www.playdog.com
>> Server Loadbalance Resource# add Enter type of string [l7lkup|pattern]: Configure HTTP header string? Enter HTTP header name: SoapAction=* Enter SLB header value string: Configure URL string? [y/n] n [y/n] y l7lkup
(Define SOAPAction header)

The strings in bold are used in this example. Number of entries: 7

ID 1 2 3 4 6 7 SLB String ida %c1%9c %c0%af playdog.com HTTPHDR:Host:www.playdog.com HTTPHDR:SoapAction=*
Assign the HTTP host header string IDs from step 1 to the lter.
.
Filtering
405
>> /cfg/slb/filt 1/adv/layer7 >> Layer 7 Advanced# addstr 6 >> Layer 7 Advanced# addstr 7
(Select the Filt. 1 L7 Advanced menu) (Add the HTTP header host string) (Add the HTTP header SoapAction string)
Enable Layer 7 lookup. This feature, when combined with the lter deny action, will match and deny any trafc containing the strings you just added in step 3.
/cfg/slb/filt 1/adv/layer7/l7l kup ena (Enable the Layer 7 lookup feature)
Set the lter action to deny.

>> # /cfg/slb/filt 1 >> Filter 1 # action deny (Select the filter) (Set the filter action to deny)

>> Filter 1 Advanced# apply >> Filter 1 Advanced# save (Apply the filter) (Save the configuration)
End
Multicast Filter Redirection

Multicast Filter Redirection is used to redirect multicast packets based on ltering criteria. Before packets get redirected to the lter specied server, the switch substitutes the destination MAC address with the server MAC address. The modied packets are then sent to the port where the specied server is connected. Multicast packets are redirected without substituting the destination MAC address. Since the destination MAC address and destination IP address need to be in same cast category, the redirected multicast or broadcast packets should keep the multicast type destination MAC address. In redirection lter processing, the switch checks cast type of destination MAC address in the received packet. If the received packet is a unicast packet, the destination MAC address is substituted to the specied servers MAC address. Then the redirected unicast packet is sent to the port where the server connected
.
to. If the received packet is a multicast packet, the destination MAC address is not substituted. Then the redirected multicast packet is sent to the port that the server connected to.
IPv6 Filtering
IPv6 support in Nortel Application Switch Operating System includes support for ALLOW and DENY lters only; IPv6 ltering does not support REDIR, NAT, or GOTO lters. IPv6 ltering operates in a similar fashion to IPv4 ltering with the exception that IPv6 ltering is only supported in bridging mode. Routed packets will be passed through without being ltered. Connectivity is maintained in IPv6 through the regular exchange of Neighbors Solicitation (NSol) packets. These packets are sent to nd the link layer address of a neighbor in the link and to nd the reachability of a neighboring node. It is usually necessary to congure an additional ALLOW lter for these multicast packets so that link neighbors can be learnt. If this is not 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 conguration of IPv4 lters are available for the conguration of IPv6 lters. The commands outlined in "IPv6 Filter Conguration Commands" (page 406) are used to congure IPv6 lters.
IPv6 Filter Conguration Commands Command Menu /cfg/slb/filt <filter number> Supported Commands sip <IPv6 Address> dip <IPv6 Address> smask <IPv6 Prefix Length> dmask <IPv6 Prefix Length> proto <Protocol Name | Number | any> sport <Port> dport <Port> length <IP packet length (in bytes), 64-65535 | any> urg ack psh syn rst fin ackrst cur <enable | disable> <enable | disable> <enable | disable> <enable | disable> <enable | disable> <enable | disable> <enable | disable>
/cfg/slb/filt <filter number> /adv/ip /cfg/slb/filt <filter number> /adv/tcp
The following example creates two IPv6 lters for Port 1. Filter 1 will allow the exchange Neighbors Solicitation packets and Filter 2 will allow the movement of bridged HTTP trafc.
.
Filtering
407
Step 1
Action Globally enable Layer 4 load balancing. Layer 4 load balancing must be enabled to allow lter processing to take place.
Create Filter 1 to allow the passage of Neighbors Solicitation packets.

>> Main# /cfg/slb/filt 1/ena >> Filter 1# action allow >> Filter 1# ipver v6 >> Filter 1# sip 2001:0:0:0:0: 0:0:0 >> Filter 1# smask 64 >> Filter 1# dip ff00:0:0:0:0: 0:0:0 >> Filter 1# dmask 8 >> Filter 1# vlan any (Enable Filter 1) (Specify an ALLOW filter) (Specify an IPv6 filter) (Specify Source IP) (Specify IPv6 Source Prefix) (Specify Destination IP) (Specify IPv6 Destination Prefix) (Specify VLAN Settings)
Create Filter 2 to allow the movement of bridged HTTP trafc.

>> Main# /cfg/slb/filt 2/ena >> Filter 2# action allow >> Filter 2# ipver v6 >> Filter 2# sip 2001:0:0:0:0: 0:0:1 >> Filter 2# smask 128 >> Filter 2# dip 2001:0:0:0:0: 0:0:8 >> Filter 2# dmask 128 >> Filter 2# proto tcp >> Filter 2# sport any >> Filter 2# dport http >> Filter 2# vlan any (Enable Filter 2) (Specify an ALLOW filter) (Specify an IPv6 filter) (Specify Source IP) (Specify IPv6 Source Prefix) (Specify Destination IP) (Specify IPv6 Destination Prefix) (Specify filter protocol) (Specify Source Port) (Specify Destination Port) (Specify VLAN Settings)
.
Add the two lters to Port 1.

>> Main# /cfg/slb/port 1 >> Port 1# filt ena >> Port 1# add 1-2 (Select Port 1) (Enable port filtering) (Add Filters 1 and 2 to Port 1)
End
.
Application Redirection
409
Application Redirection improves network bandwidth and provides unique network solutions. Filters can be created to redirect trafc to cache and application servers improving speed of access to repeated client access to common Web or application content and free valuable network bandwidth. The following topics are addressed in this chapter: "Overview" (page 409). Application redirection helps reduce the trafc congestion during peak loads by accessing locally cached information. This section also discusses how performance is improved by balancing cached requests across multiple servers. "Cache Redirection Conguration Example" (page 411). This section provides a step-by-step procedure on how to intercept all Internet bound HTTP requests (on default TCP port 80) and redirect them to the cache servers. "RTSP Cache Redirection" (page 417). This section explains how to congure the switch to redirect data (multimedia presentations) to the cache servers, and how to balance the load among the cache servers. "IP Proxy Addresses for NAT" (page 421). This section discusses the benets of transparent proxies when used with application redirection. "Excluding Noncacheable Sites" (page 423). This section describes how to lter out applications that prevent real-time session information from being redirected to cache servers. "Content Intelligent Cache Redirection" (page 423). This section describes how to redirect cache requests based on different Layer 7 content. "HTTP Redirection" (page 444). This section describes how use lters to redirect HTTP requests to different gateways or servers. "Peer-to-Peer Cache Load Balancing" (page 461) Note: To access Application Redirection functionality, the optional Layer 4 software must be enabled on the application switch (see "Filtering and Layer 4" in the Nortel Application Switch Operating System Command Reference).
Overview
Most of the information downloaded from the Internet is not unique, as clients will often access the Web page many times for additional information or to explore other links. Duplicate information also gets requested as the components 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 apparent that redundant requests can consume a considerable amount of your available bandwidth to the Internet. Application redirection can help reduce the trafc congestion during peak loads. When Application redirection lters are properly congured for the Nortel Application Switch Operating System-powered switch, outbound client requests for Internet data are intercepted and redirected to a group of application or cache servers on your network. The servers duplicate and store inbound Internet data that has been requested by your clients. If the servers recognize a clients outbound request as one that can be lled with cached information, the servers supply the information rather than send the request across the Internet. In addition to increasing the efciency of your network, accessing locally cached information can be much faster than requesting the same information across the Internet.
Cache Redirection Environment

Consider a network where client HTTP requests begin to regularly overload the 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 recongure all the clients browsers to use proxy servers.
.
Application Redirection Network with Cache Redirection
411
If you have more clients than application switch ports, then connect the clients to a layer 2 switch. Adding an Nortel Application Switch with optional Layer 4 software addresses these issues: Cache servers can be added or removed dynamically without interrupting services. Performance is improved by balancing the cached request load across multiple servers. More servers can be added at any time to increase processing power. The proxy is transparent to the client. Frames that are not associated with HTTP requests are normally passed to the router.
Additional Application Redirection Options

Application redirection can be used in combination with other Layer 4 options, such as load balancing metrics, health checks, real server group backups, and more. See "Additional Server Load Balancing Options" (page 199) for details.
Cache Redirection Conguration Example

The following is required prior to conguration: 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 the menu commands described in this example, see the Nortel Application Switch Operating System Command Reference.
.
In this example, an Nortel Application Switch is placed between the clients and the border gateway to the Internet. The application switch will be congured to intercept all Internet bound HTTP requests (on default TCP port 80), and redirect them to the cache servers. The application switch will distribute HTTP requests equally to the cache servers based on the destination IP address of the requests. If the cache servers do not have the requested information, then the cache servers behave like the client and forwards the request out to the internet. Also, lters are not limited to the few protocols and TCP or UDP applications shown in this example. See "Well-Known Application Ports" (page 199) for a list of well-known applications ports and "Well-Known Protocol Types" (page 366) for a list of supported protocols. Step 1 Action Assign an IP address to each of the cache servers. Similar to server load balancing, the cache real servers are assigned an IP address and placed into a real server group. The real servers must be in the same VLAN and must have an IP route to the application switch that will perform the cache redirection. In addition, the path from the application switch to the real servers must not contain a router. The router would stop HTTP requests from reaching the cache servers and, instead, direct them back out to the Internet. More complex network topologies can be used if conguring IP proxy addresses (see "IP Proxy Addresses for NAT" (page 421)). For this example, the three cache real servers have the following IP addresses on the same IP subnet:
Cache Redirection Example: Real Server IP Addresses Cache Server Server A Server B Server C IP address 200.200.200.2 200.200.200.3 200.200.200.4
2 3
Install transparent cache software on all three cache servers. Dene an IP interface on the application switch. The application switch must have an IP interface on the same subnet as the three cache servers because, by default, the application switch only remaps destination MAC addresses. To congure an IP interface for this example, enter this command from the CLI:
.
413
>> # /cfg/l3/if 1 >> IP Interface 1# addr 200.200.200.100 >> IP Interface 1# ena
(Select IP interface 1) (Assign IP address for the interface) (Enable IP interface 1)
Note: The IP interface and the real servers must be in the same subnet. This example assumes that all ports and IP interfaces use default VLAN 1, requiring no special VLAN conguration for the ports or IP interface. 4 Dene 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. For example:
>> # /cfg/slb/real 1 >> Real server 1# rip 200.200.200.2 >> Real server 1# ena >> Real server 1# /cfg/slb/real 2 >> Real server 2# rip 200.200.200.3 >> Real server 2# ena >> Real server 2# /cfg/slb/real 3 >> Real server 3# rip 200.200.200.4 >> Real server 3# ena (Server A is real server 1) (Assign Server A IP address) (Enable real server 1) (Server B is real server 2) (Assign Server B IP address) (Enable real server 2) (Server C is real server 3) (Assign Server C IP address) (Enable real server 3)
Dene a real server group. This places the three cache real servers into one service group:
>> Real server 3# /cfg/slb/grou p 1 >> Real server group 1# add 1 >> Real server group 1# add 2 >> Real server group 1# add 3 (Select real server group 1) (Add real server 1 to group 1) (Add real server 2 to group 1) (Add real server 3 to group 1)
.
Set the real server group metric to minmisses. This setting helps minimize cache misses in the event real servers fail or are taken out of service:
>> Real server group 1# metric minmisses (Metric for minimum cache misses.)
Verify that server processing is disabled on the ports supporting application redirection. Note: Do not use the "server" setting on a port with Application Redirection enabled. Server processing is used only with server load balancing. To disable server processing on the port, use the commands on the /cfg/slb/port menu, as described in the Nortel Application Switch Operating System Command Reference.
Create a lter that will intercept and redirect all client HTTP requests. The lter must be able to intercept all TCP trafc for the HTTP destination port and must redirect it to the proper port on the real server group:
>> SLB port 6# /cfg/slb/filt 2 >> Filter 2# sip any >> Filter 2# dip any >> Filter 2# proto tcp >> Filter 2# sport any >> Filter 2# dport http >> Filter 2# action redir >> Filter 2# rport http >> Filter 2# group 1 >> Filter 2# ena (Select the menu for Filter 2) (From any source IP addresses) (To any destination IP addresses) (For TCP protocol traffic) (From any source port) (To an HTTP destination port) (Set the action for redirection) (Set the redirection port) (Select real server group 1) (Enable the filter)
.
415
The rport (redirection) parameter must be congured whenever TCP/UDP protocol trafc is redirected. The rport parameter denes the real server TCP or UDP port to which redirected trafc will be sent. The port dened by the rport parameter is used when performing 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 congured for all application redirection lters. Take care to use the proper port designation with rport: if the transparent proxy operation resides on the host, the well-known port 80 (or HTTP) is probably required. If the transparent proxy occurs on the application switch, make sure to use the service port required by the specic software package. See "IP Proxy Addresses for NAT" (page 421) for more information on IP proxy addresses. 9 Create a default lter. In this case, the default lter will allow all noncached trafc to proceed normally:
>> Filter 2# /cfg/slb/filt 2048 >> Filter 2048# sip any >> Filter 2048# dip any >> Filter 2048# proto any >> Filter 2048# action allow >> Filter 2048# ena (Select the default filter) (From any source IP addresses) (To any destination IP addresses) (For any protocols) (Set the action to allow traffic) (Enable the default filter)
Note: When the proto parameter is not TCP or UDP, then sport and dport are ignored. 10 Assign the lters to the client ports. Assuming that the redirected clients are connected to physical switch ports 5 and 6, both ports are congured to use the previously created lters as follows:
>> Filter 2048# /cfg/slb/port 5 >> SLB Port 5# add 2 >> SLB Port 5# add 2048 >> SLB Port 5# filt enable (Select the client port 5) (Add filter 2 to port 5) (Add the default filter to port 5) (Enable filtering for port 5)
.
>> SLB Port 5# /cfg/slb/port 6 >> SLB Port 6# add 2 >> SLB Port 6# add 2048 >> SLB Port 6# filt enable
(Select the client port 6) (Add filter 2 to port 6) (Add the default filter to port 6) (Enable filtering for port 6)
11
Activate layer 4 services. Apply, and verify the conguration.

>> SLB Port 6# /cfg/slb >> Layer 4# on >> Layer 4# apply >> Layer 4# cur (Select Server Load Balancing Menu) (Activate Layer 4 software services) (Make your changes active) (View current settings)
Note: SLB must be turned on in order for application redirection to work properly. The on command is valid only if the optional Layer 4 software is enabled on your application switch (see "Activating Optional Software" in the Nortel Application Switch Operating System Command Reference). 12 13 Examine the resulting information from the cur command. If any settings are incorrect, make appropriate changes. Save your new conguration changes.
14
Check the SLB information.

>> Layer 4# /info/slb (View SLB information)
Check that all SLB parameters are working according to expectation. If necessary, make any appropriate conguration changes and then check the information again. Note: Changes to lters on a given port only effect new sessions. To make lter changes take effect immediately, clear the session binding table for the port (see the /oper/slb/clear command in the Nortel Application Switch Operating System Command Reference). End
.
417
Delayed Binding for Cache Redirection

To congure delayed binding on your application switch for cache redirection only, 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 Redirection

Nortel Application Switch Operating System supports cache redirection for Real Time Streaming Protocol (RTSP). RTSP cache redirection is similar to HTTP cache redirection in conguration and in concept. Multimedia presentations consume a lot of Internet bandwidth. The quality of these presentations depends upon the real time delivery of the data. To ensure the high quality of multimedia presentations, several caching servers are needed to cache the multimedia data locally. This data is then made available quickly from the cache memory as required. RTSP cache redirection redirects cached data transparently and balances the load among the cache servers. If there is no cache server, the request is directed to the origin server. Internet Service Providers use this feature to cache the multimedia data of a customer site locally. Since the requests for this data are directed to the local cache, they are served faster. This section explains Layer 4 support for RTSP Streaming Cache Redirection. For detailed information on two prominent commercial RTSP serversReal Player and QuickTimesee "Real Time Streaming Protocol SLB" (page 268). You can also congure the application switch to redirect client request based on URL content. For information on layer 7 RTSP Streaming Cache Redirection, see "RTSP Streaming Cache Redirection" (page 439).
.
418 Part 3: Application Switching Fundamentals RTSP Cache Redirection
Follow this procedure to congure to load balance RTSP cache servers for the topology illustrated in "RTSP Cache Redirection" (page 418): Step 1 Action Before conguring RTSP, do the following: 2 Connect each cache server to the application switch Congure the IP addresses on all devices connected to the switch Congure the IP interfaces on the switch
At the application switch, congure RTSP cache servers and the IP addresses
>> # /cfg/slb/real 1 >> Real server 1# rip 1.1.1.1 >> Real server 1# ena >> Real server 1# /cfg/slb/real 2 >> Real server 2# rip 1.1.1.2 (Configure RTSP cache server 2) (Configure RTSP cache server 1) (Enable RTSP cache server 1)
.
419
>> Real server 2# ena >> Real server 2# /cfg/slb/real 3 >> Real server 3# rip 1.1.1.3 >> Real server 3# ena >> Real server 3# /cfg/slb/real 4 >> Real server 4# rip 1.1.1.4 >> Real server 4# ena
(Enable RTSP cache server 2) (Configure RTSP cache server 3) (Enable RTSP cache server 3) (Configure RTSP cache server 4) (Enable RTSP cache server 4)
Dene a group to load balance the RTSP cache servers.

>> # /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 (Add RTSP cache server 1 to group 1) (Add RTSP cache server 2 to group 1) (Add RTSP cache server 3 to group 1) (Add RTSP cache server 4 to group 1)
Dene the group metric for the RTSP cache servers. RTSP supports all the standard load balancing metrics.
>>Real Server Group 1# metric leastconn (Set the metric to leastconn)
Congure an RTSP redirection lter to cache data and balance the load among the cache servers.
>> # /cfg/slb/filt 1 >> Filter 1# action redir >> Filter 1# proto tcp >> Filter 1# dport rtsp (Select the menu for filter 1) (Set the action for redirection) (Enter TCP protocol) (Enter service port for RTSP)
.
>> Filter 1# rport rtsp >> Filter 1# group 1 >> Filter 1# adv >> Filter 1# Advanced# proxy disable
(Enter redirection port for RTSP) (Select RTSP cache server group 1) (Select advanced menu for filter 1) (Disable proxy)
Congure a default allow lter to facilitate trafc.

>> # /cfg/slb/filt 2048 >> Filter 2048# sip any >> Filter 2048# dip any >> Filter 2048# ena >> Filter 2048# action allow (Select a default allow filter 2048) (From any source IP addresses) (To any destination IP addresses) (Enable a default allow filter) (Set the action to allow normal traffic)
Add and enable the redirection lter on the port to support basic cache redirection.
>> # /cfg/slb/port 25 >> SLB Port 25# add 1 >> SLB Port 25# add 2048 >> SLB Port 25# filt ena (Select the menu for port 25) (Add RTSP filter 1 to port 25) (Add default filter 2048 to port 25) (Enable filtering on port 25)

End
.
421
IP Proxy Addresses for NAT

Transparent proxies provide the benets listed below when used with application redirection. Application redirection is automatically enabled when a lter with the redir action is applied on a port. With proxy IP addresses congured on ports that use redirection lters, the application switch can redirect client requests to servers located on any subnet. The application switch can perform transparent substitution for all source and destination addresses, including destination port remapping. This provides support for comprehensive, fully-transparent proxies. No additional client conguration is needed.
The following procedure can be used for conguring proxy IP addresses: Step 1 Action Congure proxy IP addresses and enable proxy for the redirection ports. Each of the ports using redirection lters require proxy IP addresses. For more information on proxy IP addresses, see "Proxy IP Addresses" (page 228). In this example, proxy IP addresses are congured:
>> SLB port 3# /cfg/slb/pip >> Proxy IP address# type port >> Proxy IP Address# add 200.200.200.68 >> Proxy IP Address# add 200.200.200.69 >> Proxy IP Address# add 200.200.200.70 >> Proxy IP Address# add 200.200.200.71 >> Proxy IP Address# /cfg/slb/p ort 1 >> SLB port 1# proxy ena >> SLB port 1# /cfg/slb/port 2 >> SLB port 2# proxy ena >> SLB port 2# /cfg/slb/port 3 >> SLB port 3# proxy ena (Select proxy IP address menu) (Use port-based proxy IP) (Set proxy IP address) (Set proxy IP address) (Set proxy IP address) (Set proxy IP address) (Select port 1) (Enable proxy port 1) (Select port 2) (Enable proxy port 2) (Select port 3) (Enable proxy port 3)
.
>> SLB port 3# /cfg/slb/port 4 >> SLB port 4# proxy ena >> SLB port 4# /cfg/slb/port 5 >> SLB port 5# proxy ena >> SLB port 5# /cfg/slb/port 6 >> SLB port 6# proxy ena
(Select port 4) (Enable proxy port 4) (Select port 5) (Enable proxy port 5) (Select port 6) (Enable proxy port 6)
Congure the application redirection lters. Once proxy IP addresses are established, congure each application redirection lter (Filter 2 in our example) with the real server TCP or UDP port to which redirected trafc will be sent. In this case, the requests are mapped to a different destination port (8080). You must also enable proxies on the real servers:
>> # /cfg/slb/filt 2 >> Filter 2# rport 8080 >> Filter 2# /cfg/slb/real 1/proxy enable (Select the menu for Filter 2) (Set proxy redirection port) (Enable proxy on real servers)
>> Real server 1# /cfg/slb/real 2/proxy enable (Enable proxy on real servers) >> Real server 2# /cfg/slb/real 3/proxy enable (Enable proxy on real servers)
Note: This conguration is not limited to HTTP (Web) service. Other TCP/IP services can be congured in a similar fashion. For example, if this had been a DNS redirect, rport would be sent to well-known port 53 (or the service port you want to remap to). For a list of other well-known services and ports, see the "Well-Known Application Ports" (page 199). 3 4 Apply and save your changes. Check server statistics to verify that trafc has been redirected based on ltering criteria:
>> # /info/slb/group <group number> /filter <filter number>
End
.
423
Excluding Noncacheable Sites

Some sites provide content that is not well suited for redirection to cache servers. Such sites might provide browser-based games or applications that keep real-time session information or authenticate by client IP address. To prevent such sites from being redirected to cache servers, create a lter that allows this specic trafc to pass normally through the application switch. This lter must have a higher precedence (a lower lter number) than the application redirection lter. For example, if you want to prevent a popular Web-based game site on subnet 200.10.10.* from being redirected, you could add the following to the previous example conguration:
>> # /cfg/slb/filt 1 >> Filter 1# dip 200.10.10.0 >> Filter 1# dmask 255.255.255.0 >> Filter 1# sip any >> Filter 1# proto tcp >> Filter 1# dport http >> Filter 1# sport any >> Filter 1# action allow >> Filter 1# ena >> Filter 1# /cfg/slb/port 5 >> SLB port 5# add 1 >> SLB port 5# /cfg/slb/port 6 >> SLB port 6# add 1 >> SLB port 6# apply >> SLB port 6# save (Select the menu for filter 1) (To the sites destination IP address) (For entire subnet range) (From any source IP address) (For TCP traffic) (To an HTTP destination port) (From any source port) (Allow matching traffic to pass) (Enable the filter) (Select SLB port 5) (Add the filter to port 5) (Select SLB port 6) (Add the filter to port 6) (Apply configuration changes) (Save configuration changes)
Content Intelligent Cache Redirection

Nortel Application Switch Operating System allows you to redirect cache requests based on different Layer 7 content such as HTTP header information, such as "Host:" header or "User-Agent" for browser-smart load balancing. The No Cache/Cache Control for cache redirection feature in Nortel Application Switch Operating System allows you to off load the processing of non-cacheable content from cache servers by sending only appropriate requests to the cache server farm. When a Cache-Control header is present in a HTTP 1.1 request, it indicates a clients special request with respect
.
to caching, such as to guarantee up-to-date data from the origin server. If this feature (Cache-Control: no cache directive) is enabled, HTTP 1.1 GET requests are forwarded directly to the origin servers. Note: The term origin server refers to the server originally specied in the request. The HTTP 1.0 Pragma: no-cache header is equivalent to the HTTP 1.1 Cache-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 is supported 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 Redirection

URL parsing for cache redirection operates in a manner similar to URL-based server load balancingexcept that in cache redirection, a virtual server on the switch is the target of all IP/HTTP requests. For information on URL-based server load balancing, see "URL-Based Server Load Balancing" (page 211). By separating static and dynamic content requests via URL parsing, Nortel Application Switch Operating System enables you to send requests with specic URLs or URL strings to designated cache servers. The URL-based cache redirection option allows you to off load overhead processing from the cache servers by only sending appropriate requests to the cache server farm. 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, or HTTP with cookies, it is not sent to the cache. If the request is an ASP or CGI request or a dynamically generated page, it is not sent to the cache. If the request contains a Cookie, it can optionally bypass the cache.
.
425
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 congure the switch to add to, delete, or modify are: Dynamic content les: Common gateway interface les (.cgi) cold fusion les (.cfm), ASP les (.asp) BIN directory CGI-BIN directory SHTML (scripted html) Microsoft HTML extension les (.htx) executable les (.exe) Dynamic URL parameters: +, !, %, =, &
.
426 Part 3: Application Switching Fundamentals URL-Based Cache Redirection
Requests matching the URL are load balanced among the multiple servers, depending on the metric specied for the real server group (leastconns is the default).
Network Address Translation Options

URL-based cache redirection supports three types of Network Address Translation (NAT): No NAT, Half NAT, and Full NAT. No NAT In this NAT method, the trafc is redirected to the cache with the destination MAC address of the virtual server replaced by the MAC address of the cache. The destination IP address remains unchanged, and no modications are made to the IP address or the MAC address of the source or origin server. This works well for transparent cache servers, which process trafc destined to their MAC address but use the IP address of some other device. Half NAT In this most commonly used NAT method, the destination IP address is replaced by the IP address of the cache, and the destination MAC
.
427
address is replaced by the MAC address of the cache. Both the IP address and the MAC address of the source remain unchanged. Full NAT In this NAT method, the source IP address and the source MAC address are replaced by the IP address and MAC address of the cache. This method works well for proxy cache servers.
Conguring URL-Based Cache Redirection

To congure URL-based cache redirection, perform the following steps: Step 1 Action Before you can congure URL-based cache redirection, congure the switch for basic Server Load Balancing (SLB) with the following tasks: Assign an IP address to each of the real servers in the server pool. Dene an IP interface on the switch. Dene each real server.
For information on how to congure your network for SLB, see "Server Load Balancing" (page 188). 2 Congure the switch to support basic cache redirection. For information on cache redirection, refer to "Application Redirection" (page 409). 3 Congure the parameters and le extensions that bypass cache redirection. 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 origin server.
.
Dis: The switch compares all requests against the expression table to determine whether the request should be redirected to 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 expression table to determine whether the request should be redirected to 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 origin server.
>> # /cfg/slb/layer7/redir/nocache {ena|dis}
Ena: The switch redirects all 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 origin server. Dis: The switch compares the URL against the expression table to determine whether the request should be redirected to a cache server or the origin server.
Dene the string(s) to be used for cache SLB. Refer to the parameters 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 all URL or cache requests. Refer to the following examples: Example 1: String Starting with the Forward slash (/)
.
429
A string that starts with a forward slash ( / ), such as "/images," indicates that the server will process requests that start out with the "/images" string only. For example, with the "/images" string, the server will handle these requests:
/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 ( / ) indicates that the server will process any requests that contain the dened string. For example, with the "images" string, the server will process these 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 congured with the load balance string ( / ) only, it will only handle requests to the root directory. For example, the server will handle any les in the ROOT directory:
/ /index.htm /default.asp /index.shtm
5 6
For easy conguration and identication, each dened string has an ID attached, as shown in "SLB Strings" (page 430).
.
430 Part 3: Application Switching Fundamentals SLB Strings ID 1 2 3 4 5 6 SLB String any .gif /sales /xitami /manual .jpg
Congure the real server(s) to support cache redirection. Note: If you dont add a dened string (or add the dened string any), the server will handle any request. Add the dened string(s) to the real servers:
where ID is the identication number of the dened string. The server can have multiple dened strings. For example: "/images", "/sales", ".gif" With these dened strings, the server can handle requests that begin with "/images" or "/sales" and any requests that contain ".gif". 8 Dene a real server group and add real servers to the group. The following conguration combines three real servers into a group:
>> # /cfg/slb/group 1 >> Real server group 1# add 1 >> Real server group 1# add 2 >> Real server group 1# add 3 (Select real server group 1) (Add real server 1 to group 1) (Add real server 2 to group 1) (Add real server 3 to group 1)
Congure a lter to support basic cache redirection. The lter must be able to intercept all TCP trafc for the HTTP destination port and must redirect it to the proper port in the real server group:
.
431
>> # /cfg/slb/filt <filter number> >> Filter <filter number> # sip any >> Filter <filter number> # dip any >> Filter <filter number> # proto tcp >> Filter <filter number> # sport any >> Filter <filter number> # dport http >> Filter <filter number> # action redir >> Filter <filter number> # rport http >> Filter <filter number> # group 1 >> Filter <filter number> # ena
(Select the menu for Filter #x) (From any source IP addresses) (To any destination IP addresses) (For TCP protocol traffic) (From any source port) (To an HTTP destination port) (Set the action for redirection) (Set the redirection port) (Select real server group 1) (Enable the filter)
10
Enable URL-based cache redirection on the same lter.

>> # /cfg/slb/filt <filter number> /adv/layer7/l7lkup ena
11
Select the appropriate NAT option. The three NAT options are listed below. For more information about each 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 >> Proxy IP Address# add 12.12.12.12 (Configure proxy IP address)
.
>> # /cfg/slb/filt <filter number> >> Filter <filter number> # rport 3128 (Specify redirection port)
>> Filter <filter number> # adv (Select the advance menu) >> Filter <filter number> Advanced# proxy ena (Enable proxy IP address)
For more information on proxy IP addresses, see "Proxy IP Addresses" (page 228). 12 Create a default lter for noncached trafc on the switch.
>> # /cfg/slb/filt <filter number> >> Filter <filter number> # sip any >> Filter <filter number> # dip any >> Filter <filter number> # proto any >> Filter <filter number> # action allow >> Filter <filter number> # ena >> Filter <filter number> # port <port number> (Select the default filter) (From any source IP addresses) (To any destination IP addresses) (For any protocol traffic) (Set the action to allow traffic) (Enable the default filter) (Assign the default filter to a port)
Note: When the proto parameter is not tcp or udp, then sport and dport are ignored. 13 Turn on ltering for the port.
>> SLB <port number> # filt ena
14
Add the lters 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
.
433
16

>> # /cfg/slb >> # on >> # apply >> # cur (Select the SLB Menu) (Turn SLB on) (Make your changes active) (View current settings)
End
Viewing Statistics for URL-Based Cache Redirection

To show the number of hits to the cache server or origin server, use this command:
>> # /stats/slb/layer7/redir Total URL based Web cache redirection stats: Total cache server hits: 73942 Total origin server hits: 2244 Total none-GETs hits: 53467 Total Cookie: hits: 729 Total no-cache hits: 43
HTTP Header-Based Cache Redirection

To congure the switch for cache direction based on the "Host:" header, use the following procedure: Step 1 Action Congure basic SLB. Before you can congure header-based cache redirection, ensure that the switch has already been congured for basic SLB (see "Server Load Balancing" (page 188)) with the following tasks: 2 Assign an IP address to each of the real servers in the server pool. Dene an IP interface on the switch. Dene each real server. Assign servers to real server groups. Dene virtual servers and services.
Turn on Layer 7 lookup for the lter.

>> # /cfg/slb/filt 1/adv/layer7/l7lkup ena

.
Enable header load balancing for the Host: header.

>> # /cfg/slb/layer7/redir/header ena host
Dene the host names

>> # /cfg/slb/layer7/slb/addstr ".com" >> Server Load Balance Resource# add ".org" >> Server Load Balance Resource# add ".net"
5 6
Apply and save your conguration changes. Identify the string ID numbers with this command.
Each dened string has an associated ID number.

SLB Strings ID 1 2 3 4 SLB String any .com .org .net
Congure the real server(s) to handle the appropriate load balance string(s). Add the dened string IDs to the real servers:
where ID is the identication number of the dened string. Note: If you dont add a dened string (or add ID=1), the server will handle any request. End
Browser-Based Cache Redirection

Browser-based cache redirection uses the User-agent: header. To congure browser-based cache redirection, perform the following procedure.
.
435
Step 1
Action Before you can congure header-based cache redirection, ensure that the switch is already congured for basic SLB with the following tasks: Assign an IP address to each of the real servers in the server pool. Dene an IP interface on the switch. Dene each real server. Assign servers to real server groups. Dene virtual servers and services.

>> # /cfg/slb/filt 1/adv/layer7/l7lkup enable
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 "Internet Explorer" >> Server Load Balance Resource# add "Netscape"
5 6
Apply and save your conguration changes. Identify the string ID numbers with this command.
Each dened string has an ID number. Number of entries: four

SLB Strings ID 1 2 SLB String any Mozilla
.
ID 3 4
SLB String Internet Explorer Netscape
Add the dened string IDs to congure the real server(s) to handle the appropriate load balance string(s).
where ID is the identication number of the dened string. Note: If you dont add a dened string (or add the ID 1), the server will handle any request. End
URL Hashing for Cache Redirection

By default, hashing algorithms use the source IP address and/or destination IP address (depending on the application area) to determine content location. For example, rewall load balancing uses both source and destination IP addresses, cache redirection uses only the destination IP address, 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 the hashing algorithm to redirect client requests going to the same page of an origin server to a specic cache server. For example the switch could use the string "nortelnetworks.com/products/2424/" for hashing the following request:
GET http://products/2424/ HTTP/1.0 HOST:www.nortel.com
To congure the switch for cache redirection based on a hash key, use the following procedure: Step 1 Action Congure basic SLB. Before you can congure header-based cache redirection, ensure that the switch has already been congured for basic SLB (see "Server Load Balancing" (page 188)) with the following tasks: Assign an IP address to each of the real servers in the server pool.
.
437
Dene an IP interface on the switch. Dene each real server. Assign servers to real server groups. Dene virtual servers and services. Congure the load-balancing algorithm to hash or minmiss.

>> # /cfg/slb/filt 1/adv/layer7/l7lkup enable
Enable hash to direct a cacheable URL request to a specic cache server. By default, the host header eld is used to calculate the hash key and URL hashing is disabled. hash ena: Enables hashing based on the URL and the host header if it is present. Specify the length of the URL to hash into the cache server.
>> # /cfg/slb/layer7/redir/hash ena Enter new hash length [1-255]: 24
hash disable: Disables hashing based on the URL. Instead, the host header eld to calculate the hash key. If the host header eld does not exist in the HTTP header, then the switch uses the source IP address as the hash key. End
Example 1: Hashing on the URL

In this example, URL hashing is enabled. If the Host eld does not exist, the specied length of the URL is used to hash into the cache server as shown in "URL Hashing for Application Redirection" (page 438). If the Host eld exists, the specied length of both the Host eld and the URL is used to hash into the cache server. The same URL request goes to the same cache server as shown below: Client 1 request http://www.nortelnetworks.com/sales/index.htm is directed to cache server 1. Client 2 request http://www.nortelnetworks.com/sales/index.htm is directed to cache server 1.
.
Client 3 request http://www.nortelnetworks.com/sales/index.htm is directed to cache server 1.
URL Hashing for Application Redirection
Example 2: Hashing on the Host Header Field Only

In this example, URL hashing is disabled. If you use the Host header eld to calculate the hash key, the same URL request goes to the same cache server: Client 1 request http://www.nortelnetworks.com is directed to cache server 1. Client 2 request http://www.nortelnetworks.com is directed to cache server 1. Client 3 request http://www.nortelnetworks.com is directed to cache server 1.
Example 3: Hashing on the Source IP address

In this example, URL hashing is disabled. Because the host header eld does not exist in the HTTP header, the source IP address is used as the hash key and requests from clients 1, 2, and 3 are directed to three different cache servers as shown below. Client 1 request http://www.nortelnetworks.com is directed to cache server 1. Client 2 request http://www.nortelnetworks.com is directed to cache server 2. Client 3 request http://www.nortelnetworks.com is directed to cache server 3.
.
439
RTSP Streaming Cache Redirection

RTSP load balancing with the URL hash metric can be used to load balance cache servers that cache multimedia presentations. Since multimedia presentations consume a large amount of Internet bandwidth, and their correct presentation depends upon the real time delivery of the data over the 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 URL to the same cache server, ensuring that no data is duplicated across the cache servers. All the stream connections and the control connections are switched to the same cache server to facilitate caching of entire presentations. This section explains Layer 7 support for RTSP Streaming Cache Redirection. For conceptual information on RTSP Streaming Cache Redirection, see "RTSP Cache Redirection" (page 417). For detailed information on two prominent commercial RTSP serversReal Player and QuickTimesee "Real Time Streaming Protocol SLB" (page 268). In the scenario illustrated in "Load Balancing RTSP Cache Servers" (page 439), the cache servers are congured for forward proxy mode. The cache servers process the client request even though the destination IP address is not destined for the cache servers.
Load Balancing RTSP Cache Servers
.
Follow this procedure to congure to load balance RTSP cache servers for the topology illustrated in "Load Balancing RTSP Cache Servers" (page 439): Step 1 Action Before you start conguring the application switch do the following: 2 Connect each cache server to the application switch Congure the IP addresses on all devices connected to the switch Congure the IP interfaces on the switch
At the application switch, congure RTSP cache servers and the IP addresses.
>> # /cfg/slb/real 1 >> Real server 1# rip 1.1.1.1 >> Real server 1# ena >> Real server 1# /cfg/slb/real 2 >> Real server 2# rip 1.1.1.2 >> Real server 2# ena >> Real server 2# /cfg/slb/real 3 >> Real server 3# rip 1.1.1.3 >> Real server 3# ena >> Real server 3# /cfg/slb/real 4 >> Real server 4# rip 1.1.1.4 >> Real server 4# ena (Configure RTSP cache server 4) (Enable RTSP cache server 4) (Configure RTSP cache server 3) (Enable RTSP cache server 3) (Configure RTSP cache server 2) (Enable RTSP cache server 2) (Configure RTSP cache server 1) (Enable RTSP cache server 1)
Dene a group to load balance the RTSP cache servers.
.
441
>> # /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 (Add RTSP cache server 1 to group 1) (Add RTSP cache server 2 to group 1) (Add RTSP cache server 3 to group 1) (Add RTSP cache server 4 to group 1)
Congure a redirection lter.

(Select the menu for filter 100) (Set the action for redirection) (Enter TCP protocol) (Enter service port for RTSP) (Enter redirection port for RTSP) (Select RTSP cache server group 1) (Select advanced menu for filter 100) (Disable proxy)
>> # /cfg/slb/filter 100 >> Filter 100# action redir >> Filter 100# proto tcp >> Filter 100# dport rtsp >> Filter 100# rport rtsp >> Filter 100# group 1 >> Filter 100# adv >> Filter 100# Advanced# proxy disable
Enable Layer 7 lookup for the redirection lter 100.

(Enable Layer 7 lookup) >> Filter 100 Advanced# layer7/l7lkup ena
Congure a default allow lter to facilitate trafc.

(Select a default allow filter 2048) (From any source IP addresses)
>> # /cfg/slb/filt 2048 >> Filter 2048# sip any
.
>> Filter 2048# dip any >> Filter 2048# ena >> Filter 2048# action allow
(To any destination IP addresses) (Enable a default allow filter) (Set the action to allow normal traffic)
Add and enable the redirection lter to the port.

(Select the menu for port 25) (Add RTSP filter 100 to port 25) (Add default filter 2048 to port 25) (Enable filtering on port 25)
>> # /cfg/slb/port 25 >> SLB Port 25# add 100 >> SLB Port 25# add 2048 >> SLB Port 25# filt ena
Congure the parameters and le extensions that will bypass RTSP streaming cache redirection. This is for user-dened non-cacheable content. For example, QuickTime les are non-cacheableRTSP les with the extension *.mov must bypass the streaming cache redirection. Similarly, you can add other RTSP le extensions (such as *.smil, *.rm, *.ram, and so forth) to bypass the redirection.
(Select the SLB resource menu) (Add non-cacheable RTSP strings)
>> # /cfg/slb/layer7/slb >> # addstr *.mov
A client request of the form RTSP://*.mov bypasses the cache servers and instead is routed directly to the original servers. 9 Under the lter menu, add the string IDs that need to be excluded.
(Select the Filtering L7 Adv. menu) (Add the string ID for *.mov)
>> /cfg/slb/filt 20/adv/layer7 >> Layer 7 Advanced# addstr 2
10
Dene the RTSP le extensions to load balance among the cache servers.
.
443
>> # /cfg/slb/layer7/slb/addstr condor.rm >> Server Load Balance Resource# addstr tiger.rm
11 12
Apply and save your conguration changes. Identify the associated ID number for each of the dened RTSP le extension.
>> # /cfg/slb/layer7/slb/cur SLB Strings ID 1 2 3 4 SLB String any *.mov condor.rm tiger.rm
13
Assign the URL string ID to the cache servers.

(Select the real server 1) >> # /cfg/slb/real 1 >> Real Server 1# Layer 7/addlb 3 (Add the URL string ID 3)
>> Real Server 1 Layer 7 Commands# cfg/slb/real 2 >> Real Server 2# Layer 7/addlb 3 (Add the URL string ID 3)
Note: If no string is assigned to the server, the server will handle all requests. 14 Apply and save the conguration.
.
>> 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 local cache servers 1 or 2 and 3 or 4 respectively; however, a client request cheetah.mov bypasses the local cache servers and is forwarded to the original server. End
HTTP Redirection
Filters can be used to redirect HTTP requests to different gateways or servers. The following HTTP redirection types are supported: IP redirectionThe application switch redirects client requests to different service gateways based on the address range of the client device and requested URL. For details, see "IP based HTTP redirection" (page 447). Port redirectionThe application switch examines trafc entering on a TCP service port (such as HTTP port 80) and sends that trafc to a user-specied IP address on a different service port (such as 9090). For details, see "TCP Service Port Based HTTP Redirection" (page 450). MIME type redirectionThe application switch examines the HTTP header or URL of an incoming request for a specic Multipurpose Internet Mail Extensions (MIME) type, and replaces the URL with another URL. For details, see "MIME Type Header-Based Redirection" (page 452). URL redirectionThe application switch examines a URL and redirects it to a precongured IP address or URL. For details, see "URL-Based Redirection" (page 454). Note: The HTTP header redirection feature is not limited to the types of HTTP headers listed below.
Congure SLB Strings for HTTP Redirection

All of the following HTTP ltering redirection examples require the following server load balancing (SLB) strings to be congured. Each dened string has an associated ID number. A lter is then congured to redirect from one congured string ID to another. "Example HTTP Redirection Strings" (page 445) shows the ID numbers and SLB string content for the strings used in the following examples. Not all strings are used in each example.
.
Application Redirection Example HTTP Redirection Strings ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 SLB String any, cont 256 HTTPHDR=Host:wap.example.com HTTPHDR=Host:wap.yahoo.com HTTPHDR=Host:wap.google.com HTTPHDR=Host:wap.p-example.com HTTPHDR=Host:10.168.224.227=/top jad, cont 256 jar, cont 256 HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL HTTPHDR=Host:any HTTPHDR=Host:any:90 HTTPHDR=Host:any:8080 HTTPHDR=X-Foo-ipaddress:10.168.100.* HTTPHDR=Host:www.abc.com, cont 256 HTTPHDR=Host:any:443, cont 256
445
HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST/nava/ toggle.jad, nre, cont 1024 HTTPHDR=Host:mobile.example.com=/4g/w?url=dev.example .com/$URL, nre, cont 1024
Step 1
Action Congure the switch with the basic Server Load Balancing requirements as described in "HTTP Header-Based Cache Redirection" (page 433). Congure the lter strings.
>> # /cfg/slb/layer7/slb/ >> Server Loadbalance Resource# addstr (Add the first SLB string) l7lkup
Enter type of string [l7lkup|pattern]: Configure HTTP header string? Enter HTTP header name: Host
(y/n) [n] y
Enter SLB header value string:
wap.example.com
.
Configure URL string?
(y/n) [n] n (Select the Serverloadbala nce Resource menu) (Add the second SLB string) [y/n] y (Define HTTP header name Host) wap.yahoo.com
>> # /cfg/slb/layer7/slb/ >> Server Loadbalance Resource# add Configure HTTP header string? Enter HTTP header name: Host Enter SLB header value string:
Use the same commands as step 2 to congure the rest of the lter strings shown in "Example HTTP Redirection Strings" (page 445). Identify the ID numbers of the dened strings.
>> # /cfg/slb/layer7/slb/cur Number of entries: 14 1: any, cont 256 2: HTTPHDR=Host:wap.example.com, cont 256 3: HTTPHDR=Host:wap.yahoo.com, cont 256 4: HTTPHDR=Host:wap.google.com, cont 256 5: HTTPHDR=Host:wap.p-example.com, cont 256 6: HTTPHDR=Host:10.168.224.227=/top, cont 256 7: jad, cont 256 8: jar, cont 256 9: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor, cont 256 10: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST _URL, cont 256 11: HTTPHDR=Host:any, cont 256 12: HTTPHDR=Host:any:90, cont 256 13: HTTPHDR=Host:any:8080, cont 256 14: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 256 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.ex ample.com/$URL, nre, cont 1024
Congure a port for client trafc. This conguration assumes client trafc enters the application switch on port 1. Enabled ltering on the client port.

.
447
>> /cfg/slb/port 1 >> SLB port 1# filt en Current port 1 filtering: New port 1 filtering:
(Select the SLB port 1 menu) (Enable filtering on the port) disabled enabled
The basic HTTP redirection conguration is now complete and can be used for each of the redirection options described in the following sections. End
IP based HTTP redirection

In this example, the application switch will redirect Web pages requested from a mobile phone, to a specic gateway based on the clients IP address. A mobile phone is set to access its home page via the default device gateway. Example client phone conguration:
Device Gateway IP address 10.168.107.101 Home page: http://wap.example.com WAP port 9001, CSD number as 18881234567 username: john
Conguration rules
The following lter rules on the Application switch to lter client requests from different WAP gateways: Filter 1: If the client IP address is between 10.168.43.0-255 and the requested URL is http://wap.example.com, then redirect the client request to http://wap.yahoo.com. Filter 2: If the Client IP address is between 10.46.6.0.0-255 and the requested URL is http://wap.example.com then redirect the client request to http://wap.google.com. Filter 3: If the client IP address is between 10.23.43.0- 255 and the requested URL is http://wap.p-example.com, then redirect the client request to http://10.168.224.227/top.
Assuming that each client is in a different subnet, congure the switch with three lters to redirect client requests from each subnet, to the URLs specied above. Use the string index numbers in "Example HTTP Redirection Strings" (page 445) to congure a redirection map for each lter.
.
Step 1
Action Identify the ID numbers of the dened strings. The strings in bold are used in this example.
Congure lter 1.
>> /cfg/slb/filt 1 >> Filter 1 # sip 10.168.43.0 Current source address: New pending source address: any 10.168.43.0 (From this source IP address range)
>> Filter 1 # smask 255.255.255.0 Current source mask: New pending source mask: >> Filter 1 # proto tcp 0.0.0.0 255.255.255.0 (For TCP protocol traffic)
.
449
Current protocol: Pending new protocol: tcp
any
>> Filter 1 # dport http
(To destination port HTTP) any http
Current destination port or range: Pending new destination port or range: >> Filter 1 # action redir Current action: allow redir
(Redirect the traffic)
Pending new action:
>> Filter 1 # /cfg/slb/filt/adv /layer7 >> Layer 7 Advanced# addrd Enter filtering string ID (1-1024) to redirect from: Enter filtering string ID (2-1024) to redirect to:
(Access advanced Layer 7 menu) 2(Redirect string 2 ..) 3(to string 3)
Congure lter 2.
>> /cfg/slb/filt 2 >> Filter 2 # sip 10.46.6.0.0 Current source address: any New pending source address: 10.46.6.0.0 >> Filter 2 # smask 255.255.255.0 Current source mask: 0.0.0.0 New pending source mask: 255.255.255.0 >> Filter 2 # proto tcp Current protocol: any Pending new protocol: tcp >> Filter 2 # dport http Current destination port or range: any Pending new destination port or range: http >> Filter 2 # action redir Current action: allow Pending new action: redir >> Filter 2 # /cfg/slb/filt/adv/layer7 >> Layer 7 Advanced# addrd Enter filtering string ID (1-1024) to redirect from: 2 Enter filtering string ID (2-1024) to redirect to: 4
Congure Filter 3.
.
>> /cfg/slb/filt 3 >> Filter 3 # sip 10.23.43.0 Current source address: any New pending source address: 10.23.43.0 >> Filter 3 # smask 255.255.255.0 Current source mask: 0.0.0.0 New pending source mask: 255.255.255.0 >> Filter 3 # proto tcp Current protocol: any Pending new protocol: tcp >> Filter 3 # dport http Current destination port or range: Pending new destination port or range: >> Filter 3 # action redir Current action: allow Pending new action: redir >> Filter 3 # /cfg/slb/filt/adv/layer7 >> Layer 7 Advanced# addrd Enter filtering string ID (1-1024) to redirect from: 5 Enter filtering string ID (2-1024) to redirect to: 6
any http
TCP Service Port Based HTTP Redirection

In this example, the switch will redirect trafc entering the switch on one TCP service port, and redirect it through another service port. Use the string index numbers in "Example HTTP Redirection Strings" (page 445) to congure a redirection map for each lter. Filter 4: Congure a lter on the switch to examine the URL request http://10.46.6.231:80/Connect1.jad on TCP service port 80, and redirect that URL to TCP service port 90. Filter 5: Congure a lter on the switch that intercepts all trafc entering on TCP service port 80, and send it to 10.168.120.129 on TCP service port 8080. Action Identify the ID numbers of the dened strings. The strings in bold are used in this example.
Step 1
.
451
>> # /cfg/slb/layer7/slb/cur Number of entries: 14 1: any, cont 256 2: HTTPHDR=Host:wap.example.com, cont 256 3: HTTPHDR=Host:wap.yahoo.com, cont 256 4: HTTPHDR=Host:wap.google.com, cont 256 5: HTTPHDR=Host:wap.p-example.com, cont 256 6: HTTPHDR=Host:10.168.224.227=/top, cont 256 7: jad, cont 256 8: jar, cont 256 9: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor , cont 256 10: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST _URL, cont 256 11: HTTPHDR=Host:any, cont 256 12: HTTPHDR=Host:any:90, cont 256 13: HTTPHDR=Host:any:8080, cont 256 14: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 256 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.ex ample.com/$URL, nre, cont 1024
Congure lter 4.
>> /cfg/slb/filt 4 >> Filter 4 # sip 10.46.6.231 Current source address: any New pending source address: 10.46.6.231 >> Filter 4 # smask 255.255.255.255 Current source mask: 0.0.0.0 New pending source mask: 255.255.255.255 >> Filter 4 # proto tcp Current protocol: any Pending new protocol: tcp >> Filter 4 # dport http Current destination port or range: any Pending new destination port or range: http >> Filter 4 # action redir Current action: allow Pending new action: redir >> Filter 4 # /cfg/slb/filt/adv/layer7 >> Layer 7 Advanced# addrd Enter filtering string ID (1-1024) to redirect from: 11
.
Enter filtering string ID (2-1024) to redirect to: 12
Congure lter 5.
>> /cfg/slb/filt 5 >> Filter 5 # sip 10.46.6.231 Current source address: any New pending source address: 10.46.6.231 >> Filter 5 # smask 255.255.255.255 Current source mask: 0.0.0.0 New pending source mask: 255.255.255.255 >> Filter 5 # proto tcp Current protocol: any Pending new protocol: tcp >> Filter 5 # dport http Current destination port or range: any Pending new destination port or range: http >> Filter 5 # action redir Current action: allow Pending new action: redir >> Filter 5 # /cfg/slb/filt/adv/layer7 >> Layer 7 Advanced# addrd Enter filtering string ID (1-1024) to redirect from: 11 Enter filtering string ID (2-1024) to redirect to: 13
MIME Type Header-Based Redirection

In this example, the switch receives a URL request from a mobile client and examines the Multipurpose Internet Mail Extensions ( MIME) type header in the URL. If the URL contains a pre-dened MIME type, text, or URL, the switch will replace the URL. Use the string index numbers in "Example HTTP Redirection Strings" (page 445) to congure a redirection map for the lter. Filter 6: The mobile client executes a request for a URL http://dev.example.com/java/ toggle.jad. If the MIME type is text/vnd.foo.j2me.app-descriptor, or if the URL contains jad or jar as an extension, it will replace the URL with: http://mobile.example.com/4g/w?url=dev.example.com/nava/toggle.jad.
.
453
Step 1
>> # /cfg/slb/layer7/slb/cur Number of entries: 14 1: any, cont 256 2: HTTPHDR=Host:wap.example.com, cont 256 3: HTTPHDR=Host:wap.yahoo.com, cont 256 4: HTTPHDR=Host:wap.google.com, cont 256 5: HTTPHDR=Host:wap.p-example.com, cont 256 6: HTTPHDR=Host:10.168.224.227=/top, cont 256 7: jad, cont 256 8: jar, cont 256 9: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor , cont 256 10: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL, cont 256 11: HTTPHDR=Host:any, cont 256 12: HTTPHDR=Host:any:90, cont 256 13: HTTPHDR=Host:any:8080, cont 256 14: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 256 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
Congure lter 6. The lter intercepts string 7, 8, and 9 and then redirects them based on strings 10, 17, and 18 information. The $HOST_URL is replaced with the incoming request from HOST and URL string. The $HOST is replaced with the incoming request from HOST string. The $URL is replaced with the incoming request from the URL string.
.
>> /cfg/slb/filt 6 >> Filter 6 # sip 10.46.6.231 Current source address: any New pending source address: 10.46.6.231 >> Filter 6 # smask 255.255.255.255 Current source mask: 0.0.0.0 New pending source mask: 255.255.255.255 >> Filter 6 # proto tcp Current protocol: any Pending new protocol: tcp >> Filter 6 # dport http Current destination port or range: any Pending new destination port or range: http >> Filter 6 # action redir Current action: allow Pending new action: redir >> Filter 6 # /cfg/slb/filt/adv/layer7 >> Layer 7 Advanced# addrd Enter filtering string ID (1-1024) to redirect from: 7 Enter filtering string ID (2-1024) to redirect to: 10 >> Layer 7 Advanced# addrd Enter filtering string ID (1-1024) to redirect from: 8 Enter filtering string ID (2-1024) to redirect to: 17 >> Layer 7 Advanced# addrd Enter filtering string ID (1-1024) to redirect from: 9 Enter filtering string ID (2-1024) to redirect to: 18 >> Layer 7 Advanced# apply >> Layer 7 Advanced# save
URL-Based Redirection
A request for a URL can be redirected to another URL as follows: Filter 7: URL http://wap.example.com is redirected to http://10.168.224.227/top.
.
455
Step 1
Congure lter 7 to redirect the URL as described above.

>> /cfg/slb/filt 7 >> Filter 7 # sip 10.46.6.231 Current source address: any New pending source address: 10.46.6.231 >> Filter 7 # smask 255.255.255.255 Current source mask: 0.0.0.0 New pending source mask: 255.255.255.255 >> Filter 7 # proto tcp Current protocol: any Pending new protocol: tcp >> Filter 7 # dport http Current destination port or range: any Pending new destination port or range: http >> Filter 7 # action redir Current action: allow

.
Pending new action: redir >> Filter 7 # /cfg/slb/filt/adv/layer7 >> Layer 7 Advanced# addrd Enter filtering string ID (1-1024) to redirect from: 2 Enter filtering string ID (2-1024) to redirect to: 6 >> Layer 7 Advanced# apply >> Layer 7 Advanced# save
Source IP from HTTP header and Host Header-Based Redirection

In this example, a lter is congured as follows: Filter 8: If X-Foo-ipaddress: 10.168.100.* and the request is to http://wap.example.com, then redirect the request to wap.yahoo.com. Action Identify the ID numbers of the dened strings. The strings in bold are used in this example.
Step 1
>> # /cfg/slb/layer7/slb/cur Number of entries: 14 1: any, cont 256 2: HTTPHDR=Host:wap.example.com, cont 256 3: HTTPHDR=Host:wap.yahoo.com, cont 256 4: HTTPHDR=Host:wap.google.com, cont 256 5: HTTPHDR=Host:wap.p-example.com, cont 256 6: HTTPHDR=Host:10.168.224.227=/top, cont 256 7: jad, cont 256 8: jar, cont 256 9: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor , cont 256 10: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST _URL, cont 256 11: HTTPHDR=Host:any, cont 256 12: HTTPHDR=Host:any:90, cont 256 13: HTTPHDR=Host:any:8080, cont 256 14: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 256 15: HTTPHDR=Host:www.abc.com, cont 256 16: HTTPHDR=Host:any:443, cont 256
.
457
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.ex ample.com/$URL, nre, cont 1024
End
Step 1
Action Congure lter 8 redirect URL as described above.

>> /cfg/slb/filt 8 >> Filter 8 # sip 10.46.6.231 Current source address: any New pending source address: 10.46.6.231 >> Filter 8 # smask 255.255.255.255 Current source mask: 0.0.0.0 New pending source mask: 255.255.255.255 >> Filter 8 # proto tcp Current protocol: any Pending new protocol: tcp >> Filter 8 # dport http Current destination port or range: any Pending new destination port or range: http >> Filter 8 # action redir Current action: allow Pending new action: redir >> Filter 8 # /cfg/slb/filt/adv/layer7 >> Layer 7 Advanced# addrd Enter filtering string ID (1-1024) to redirect from: 2 Enter filtering string ID (2-1024) to redirect to: 14 >> Layer 7 Advanced# apply >> Layer 7 Advanced# save
.
HTTP to HTTPS Redirection

In this example, a lter is congured to redirect any HTTP requests to an HTTP connection as follows: Filter 9: Congure a lter on the switch that intercepts HTTP trafc to http://www.abc.com and redirects it to https://www.abc.com. Action Identify the ID numbers of the dened strings. The strings in bold are used in this example.
>> # /cfg/slb/layer7/slb/cur Number of entries: 14 1: any, cont 256 2: HTTPHDR=Host:wap.foo.com, cont 256 3: HTTPHDR=Host:wap.yahoo.com, cont 256 4: HTTPHDR=Host:wap.google.com, cont 256 5: HTTPHDR=Host:wap.p-foo.com, cont 256 6: HTTPHDR=Host:10.168.224.227=/top, cont 256 7: jad, cont 256 8: jar, cont 256 9: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor , cont 256 10: HTTPHDR=Host:mobile.foo.com=/4g/w?url=$HOST_URL, cont 256 11: HTTPHDR=Host:any, cont 256 12: HTTPHDR=Host:any:90, cont 256 13: HTTPHDR=Host:any:8080, cont 256 14: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 256 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.ex ample.com/$URL, nre, cont 1024
Step 1
Congure lter 9.
>> /cfg/slb/filt 9 >> Filter 9 # proto tcp Current protocol: any Pending new protocol: tcp >> Filter 9 # dport http Current destination port or range: any Pending new destination port or range: http >> Filter 9 # action redir Current action: allow Pending new action: redir >> Filter 9 # /cfg/slb/filt/adv/layer7

.
459
>> Layer 7 Advanced# addrd >> Layer 7 Advanced# l7lkup en Current layer 7 lookup: disabled New layer 7 lookup: enabled Enter filtering string ID (1-1024) to redirect from: 15 Enter filtering string ID (2-1024) to redirect to: 16
IPv6 Redirection Filter

The following conguration example demonstrates an IPv6 redirection lter. The following illustration shows the topology for this example.
IPv6 Redirection Filter Conguration Example
Take the following steps to replicate the conguration illustrated above: Step 1 Action Congure the client VLAN.
>> Main# /cfg/l2/vlan 2/en/name "Client_VLAN"/add 1
Congure the client interface.
.
>> Main# /cfg/l3/if 2/en/vlan 2/ipv v6/add 2001::1/mask 64
Congure the cache server VLAN.
>> Main# /cfg/l2/vlan 3/en/name "Cache_VLAN"/add 10/add 20
Congure the cache server interface.
Congure the original server VLAN (VLAN to Internet).
>> Main# /cfg/l2/vlan 4/en/name "Internet_VLAN"/add 24
Congure the interface to the Internet.
Congure cache server 1.
>> Main# /cfg/slb/re 1/en/ipv v6/rip 2002::11
Congure cache server 2.
>> Main# /cfg/slb/re 2/en/ipv v6/rip 2002::12
10
Add the 2 cache servers to the real group.
.
461
>> Main# /cfg/slb/gr 1/ipv v6/add 11/add 12
11
Congure the IPv6 redirection lter to redirect all HTTP trafc to the cache servers.
>> Main# /cfg/slb/fi 1/en/name "IPv6_HTTP_Redir_Filter"/ipv v6/act redir/proto tcp/dport http/group 1/
12
Congure IPv6 default lter to allow other trafc.
>> Main# /cfg/slb/fi 2048/en/name "IPv6_Allow_Filter"/ipv v6/act allow
13
Enable lter processing on client ports and add the 2 lters to the client ports.
>> Main# /cfg/slb/po 1/fi en/add 1/add 2048
14
Apply the conguration.
>> Main# apply >> Main# save
End
Peer-to-Peer Cache Load Balancing

The pattern matching lter redirection feature load balances peer-to-peer caches. Previously the Nortel Application Switch Operating System had a pattern matching lter that only supported ALLOW and DENY actions for the lter. The Nortel Application Switch Operating System now enhances this pattern matching support by including a REDIR action. For more information on this topic, refer to "Filtering" (page 364) ". There are two instances where a packet will be redirected because of a pattern matching lter:
.
Step 1
Action The packet matches a congured lter. The packet matches a previously congured lter with a REDIR action.
A packet earlier in the session was matched. A packet earlier in the session was matched against a lter congured with a REDIR action and the session has been converted to a redirect session. In this instance, subsequent packets after the initial match are not subjected to pattern matching. Packet redirection is accomplished by substituting the original destination MAC address with the real server MAC address. Some applications, however, require that all of the Layer 2 information remain unmodied in the redirected packet. To support instances where this is the case, an option has been added to disable destination MAC address substitution on a real server by real server basis. With this option enabled, all packets will be transparently redirected and no destination MAC address substitution will take place. Note: Disabling destination MAC address substitution is only available for lter redirection. To disable destination MAC address substitution, issue the following command:
>> 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 server farms, exible, customizable content health checks are critical to ensure end-to-end availability. The following Nortel Application Switch Operating System health-checking topics are described in this chapter. "Real Server Health Checks" (page 465). This section explains the switchs default health check, which checks the status of each service on 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 IP address when the server is in Direct Server Return (DSR) mode. "Link Health Checks" (page 468). This section describes how to perform Layer 1 health checking on an Intrusion Detection Server (IDS). "TCP Health Checks" (page 469). TCP health checks help verify the TCP applications that cannot be scripted. "ICMP Health Checks" (page 470). This section explains how ICMP health checks are used for UDP services. "Script-Based Health Checks" (page 470). This section describes how to congure the switch to send a series of health-check requests to real servers or real server groups and monitor the responses. Health checks are supported for TCP and UDP protocols, using either Binary or ASCII content. Application-based health checks: "HTTP Health Checks" (page 479). This section provides examples of HTTP-based health checks using hostnames. "UDP-Based DNS Health Checks" (page 481). This section explains the functionality of the DNS Health Checks using UDP packets. "TFTP Health Check" (page 482). This section explains how to health check a real server using the TFTP protocol. "SNMP Health Check" (page 483). This section explains how to perform SNMP health checks to real servers running SNMP Agents. "FTP Server Health Checks" (page 485). This section describes how the File Transfer Protocol (FTP) server is used to perform health checks and explains how to congure the switch to perform FTP health checks.
.
"POP3 Server Health Checks" (page 486). This section explains how to use Post Ofce Protocol Version 3 (POP3) mail server to perform health checks between a client system and a mail server and how to congure the switch for POP3 health checks. "SMTP Server Health Checks" (page 487). This section explains how to use Simple Mail Transfer Protocol (SMTP) mail server to perform health checks between a client system and a mail server and how to congure the switch for SMTP health checks. "IMAP Server Health Checks" (page 488). This section describes how the mail server Internet Message Access Protocol (IMAP) protocol is used to perform health checks between a client system and a mail server. "NNTP Server Health Checks" (page 488). This section explains how to use Network News Transfer Protocol (NNTP) server to perform health checks between a client system and a mail server and how to congure the switch for NNTP health checks "RADIUS Server Health Checks" (page 489). This section explains how the RADIUS protocol is used to authenticate dial-up users to Remote Access Servers (RASs). "HTTPS/SSL Server Health Checks" (page 492). This section explains how the switch queries the health of the SSL servers by sending an SSL client "Hello" packet and then veries the contents of the servers "Hello" response. "WAP Gateway Health Checks" (page 492). This section discusses how the application switch provides connectionless and connection-oriented WSP health check for WAP gateways. "LDAP Health Checks" (page 499). This section describes how to congure the switch to perform Lightweight Directory Access Protocol (LDAP) health checks for the switch to determine whether or not the LDAP server is running. "ARP Health Checks" (page 501). This section describes how to perform health checks on Intrusion Detection Servers (IDS) that do not have full TCP/IP stack support. "Buddy Server Health Checks" (page 503). This section describes how to congure buddy server health checking. "Failure Types" (page 506). This section explains the service failed and server failed states. Note: IPv6 health checking currently supports ICMP, TCP, HTTP, and script-based health checks.
.
Health Checking
465
Real Server Health Checks

Nortel Application Switches running Server Load Balancing (SLB) monitor the 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, it will not direct any new connection requests to that server. When a service fails, an Nortel Application Switch can remove the individual service from the load-balancing algorithm without affecting other services provided by that server. By default, the application switch checks the status of each service on each real server every two seconds. Sometimes, the real server may be too busy processing connections to respond to health checks. If a service does not respond to four consecutive health checks, the switch, by default, declares the service unavailable. You can modify both the health check interval and the number of retries.
>> # /cfg/slb/real <real server number> >> Real server# inter 4 >> Real server# retry 6 (Select the real server) (Check real server every 4 seconds) (If 6 consecutive health checks fail, declare real server down)
Note: Health checks are performed sequentially when used in conjunction with a virtual server congured with multiple services and groups. As a result, the actual health-check interval could vary signicantly 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 health checking methods: link, advanced SNMP, or ARP. You may use the LDAP health check method to health check LDAP servers.
Advanced Group Health Check

Nortel Application Switch Operating System allows you to congure an expression to ne tune the selected health check for a real server group. For example, you have congured a real server group with four real servers. Two of the real servers are handling the contents of the Web site and the other two real servers are handling audio les. If the two content servers fail due to trafc distribution, then you want the two audio servers to fail automatically. However, you want the audio servers up if at least one of the content servers is up.
.
The advanced group health check feature allows you to create a boolean expression to health check the real server group based on the state of the virtual services. This feature supports two boolean operators, AND and OR. The two boolean operators are used to manipulate TRUE/FALSE values as follows: 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 if both of its operands is TRUE. Using parenthesis with the boolean operators, you can create a boolean expression to state the health of the server group. The following two boolean expressions show two examples with real servers 1, 2, 3, and 4 in two different groups: (1|2)&(3|4) Real servers 1, 2, 3, and 4 are congured in group 1 and assigned to virtual service x in virtual server 1. The boolean expression is used to calculate the status of a virtual service using group 1 based on the status of the real servers. Virtual service x of virtual server 1 is marked UP if real servers 1 or 2 and real servers 3 or 4 are health checked successfully.
>> # /cfg/slb/group 1 >> Real server group 1# advhlth (1|2)&(3|4)(Configure a boolean expression for health check) >> # /cfg/slb/virt 1/service x/group 1 >> Virtual Server 1 Service# apply >> Virtual Server 1 Service# save (Assign the real server group 1) (Apply the changes) (Save the changes) (Select the real server group 1)
(1&2)|(2&3)|(1&3) Real servers 1, 2, and 3 are congured in group 2 and assigned to virtual service x in virtual server 1. The boolean expression is used to calculate the status of the virtual service using group 2 based on the status of the real servers. Virtual service x of virtual server 1 is marked UP only if at least two of the real servers are health checked successfully.
.
Health Checking
467
>> # /cfg/slb/group 2
(Select the real server group 2)
>> Real server group 2# advhlth (1&2)|(2&3)|(1&3) (Configure a boolean expression for health check) >> # /cfg/slb/virt 1/service x/group 2 >> Virtual Server 1 Service# apply >> Virtual Server 1 Service# save (Assign the real server group 2) (Apply the changes) (Save the changes)
Disabling the Fast Link Health Check

By default, the Nortel Application Switch sets the real server as operationally down as soon as the physical connection to it is downwithout waiting for the health check to fail. This behavior may not be advantageous in certain congurations in which a link may go down and then be quickly restoredsuch as in VPN load balancing. By disabling this "fast health check" behavior, the real server will be marked as "down" only after the congured health check interval, thus allowing the possibility of the server re-establishing itself before the next health check. To enable or disable fast link health checks, enter the following command:
>> # /cfg/slb/real <real-server-#> /fasthc ena|dis
DSR Health Checks

Direct Server Return (DSR) health checks are used to verify the existence of a server-provided service where the server replies directly back to the client without responding through the virtual server IP address. In this conguration, the server will be congured with a real server IP address and virtual server IP address. The virtual server IP address is congured to be the same address as the users virtual server IP address. When DSR health checks are selected, the specied health check is sent originating from one of the switchs congured IP interfaces, and is destined to the virtual server IP address with the MAC address that was acquired from the real server IP addresss Address Resolution Protocol (ARP) entry. Nortel Application Switch Operating System allows you to perform health checks for DSR congurations. For more information, see "Direct Server Return" (page 238). The switch is able to verify that the server correctly responds to requests made to the virtual server IP address as required in DSR congurations. To perform this function, the real server IP address is replaced with the virtual server IP address in the health check packets
.
that are forwarded to the real servers for health checking. With this feature enabled, the health check will fail if the real server is not properly congured with the virtual server IP address. Note: viphlth is enabled by default. This has no effect on the health check unless the real server is congured with DSR.
Conguring the Switch for DSR Health Checks

Step 1 Action Select the health check menu for a real server group.
>> # /cfg/slb/group 1 (Select the Real Server Group 1 menu)
Enable DSR VIP health checks for a real server group. For more information on DSR, see "Direct Server Return" (page 238).
>> Real server group 1# viphlth enable|disable

>> DSR VIP Health Check# apply
End
Link Health Checks

Link health checks are performed at the Layer 1 (physical) level, and are used 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, and down when the link is absent. Many IDSs have two physical interfaces. One is used to detect intrusions, and the other is used to generate logging. The rst interface detects intrusions but it does not have TCP/IP stack. So it is not possible to perform any health check other than Layer 1 health checking on the IDS. As long as the physical link between the switch and the IDS is up, it indicates the IDS is alive.
.
Health Checking
469
To perform this health check, a link option has been added to the real server group health command. The real server number is used to determine which port the server is connected to. For example, real server 1 is assumed to be connected to port 1. The valid IDS real server numbers are from 1 to 26 when health check is in use.
Conguring Link Health Checks

Congure the switch to verify if the IDS server is alive by performing the following tasks: Step 1 Action Select the health check menu for real server group 1.
Set the health check type to link for real server group 1.
>> # Real server group 1# health Current health check type: tcp Enter health check type: link

>> # Real server group 1# apply >> # Real server group 1# save
End
TCP Health Checks

TCP health checks are useful in verifying user-specic TCP applications that cannot be scripted. Session switches monitor the health of servers and applications by sending Layer 4 connection requests (TCP SYN packets) for each load-balanced TCP service to each server in the server group on a regular basis. The rate at which these connection requests are sent is a user-congurable parameter. These connection requests identify both failed servers and failed services on a healthy server. When a connection request succeeds, the session switch quickly closes the connection by sending a TCP FIN (nished) packet. Note: TCP health check is a default health check after you have congured the switch for a particular service.
.
ICMP Health Checks

Congure the switch with ICMP health check to verify if the real server is alive. The Layer 3 echo-echo reply health check is used for UDP services or when ICMP health checks are congured. Step 1 Action Select the health check menu for group 1.
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 Checks

Health check scripts dynamically verify application and content availability by executing a sequence of tests based on send and expect commands.
Conguring Script-Based Health Checks

You can congure the switch to send a series of health check requests to real servers or real server groups and monitor the responses. Both ASCII and Binary-based scripts, for TCP and UDP protocols, can be used to verify application and content availability. The benets 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 capacity for a single switch: 6K bytes per script 64 scripts per switch
.
Health Checking
471
A simple command line interface controls the addition and deletion of commands to each script. New commands are added and removed from the end of the script. Commands exist to open a connection to a specic TCP or UDP port, send a request to the server, expect an ASCII string or Binary pattern, and, for TCP-based health checks only, to close a connection. The string or pattern congured with an expect (or in the case of binary, bexpect) command is searched for in each response packet. If it is not seen anywhere in any response packet before the real server health check interval expires, the server does not pass the expect (or bexpect) step and fails 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 line interface, but once entered, can be assigned as the health-check method using SNMP or the Browser-Based Interface (BBI).
Script Formats
Health check script formats use different commands based on whether the content to be sent is ASCII-based or Binary-based. And, remember, the close command is used only to close a TCP connection, and is not required if health checking a UDP-based protocol. Each script should start with the command open <protocol port number>,<protocol-name>. The next line can be either a send or expect (for ASCII-based), or bsend or bexpect (Binary-based).
ASCII-based Health Check

The 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 1 send request 2 expect response 2 send request 3 expect response 3 close (used in TCP-based health checks only)
Binary Based Health Check

The 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-continued bexpect response 1 nexpect response 1-continued expect response 3 offset offset count depth number of packets from offset to count close (used in TCP-based health checks only)
A Binary-based TCP Health Check

The bsend and bexpect commands are used to specify binary content. The offset and depth commands are used to specify where in the packet to start looking for the binary content. For example, if your script is congured to look for an HTTP 200 (ok) response, this typically appears starting from the 7th byte in the packet, so an offset value of 7 can be specied.
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 Binary patterns. The close command shown above is not required for a health check on UDP protocol.
Notes on TCP-based Health Checks for HTTP Protocol

If you are doing HTTP 1.1 pipelining, you need to individually open and close each response in the script. For HTTP-based health checks, the rst word is the method. The method is usually the get command. However, HTTP also supports several other commands, including put and head. The second word indicates the content desired, or request-URI, and the third word represents the version of the protocol used by the client. If you supplied HTTP/1.1 for the protocol version, you would also have to 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 most Web sites now require it for proper processing. Host headers were optional in HTTP/1.0 but are required when you use HTTP/1.1+. In order to tell the application server you have nished entering header information, a blank line of input is needed after all headers. At this point, the URL will be processed and the results returned to you. Note: If you make an error, enter rem to remove the last typed script line entered. If you need to remove more than one line, enter rem for each line that needs to be removed. The switch provides the "\" prompt, which is one enter key stroke. When using the send command, note what happens when you type the send command with the command string. When you type send, press enter and allow the switch to format the command string (that is, \ versus \\).
Scripting Commands
Listed below are the currently available commands for building a script-based health check: OPEN: specify which destination real server UDP port to be used; for example, OPEN 9201. After entering the destination port, you will be prompted to specify a protocol; choose udp. CLOSE (for TCP-based health checks only): This command is used to close a TCP connection. It is not necessary to use this command for UDP services. SEND: specify the send content in raw hexadecimal format. BSEND (for binary content only): This command is used to specify binary content (in hex format) for the request packet. NSEND (for binary content only): can be used to specify an additional binary send value (in hexadecimal format) at the end of a UDP based health check script. The NSEND command allows the user to append additional 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 more than 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 the binary content (in hex format) to be expected from the server response packet. NEXPECT (for binary content only): Similar to NSEND, this command allows the user to specify additional binary content to be appended to the original content specied by the BEXPECT command. OFFSET (for binary content only): can be used to specify the offset from the beginning of the binary data area to start matching the content specied in the EXPECT command. The OFFSET command is supported for both UDP and TCP-based health checks. Specify the OFFSET command after an EXPECT command if an offset is desired. If this command is not present, an offset of zero is assumed. DEPTH (for binary content only): can be used to specify the number of bytes in the IP packet that should be examined. If no OFFSET value is specied, Depth is specied from the beginning of the packet. If an OFFSET value is specied, the Depth counts the number of bytes starting from the offset value. WAIT: can be used to specify a wait interval before the expected response is returned. The wait window begins when the SEND string is sent from the switch. If the expected response is received within the window, the WAIT step passes. Otherwise, the health check fails. The WAIT command should come after an EXPECT command in the script, or the OFFSET command if one exists after an EXPECT command. The wait window is in units of milliseconds. Wildcard character (*): can be used to trigger a match as long as a response is received from the server. The wildcard character is allowed with the BEXPECT command, as in BEXPECT *. Any NEXPECT, OFFSET, or DEPTH commands that follow a wildcard character will be ignored.
Scripting Guidelines
Use generic result codes that are standard and dened by the RFC, as applicable. This helps ensure that if the server software changes, the servers wont start failing unexpectedly. Avoid tasks that may take a long time to perform or the health check will fail. For example, avoid tasks that exceed the interval for load balancing.
Script Conguration Examples Script Example 1: A Basic ASCII TCP-Based Health Check
Congure the switch to check a series of Web pages (HTML or dynamic CGI 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 must use quotes (") to indicate the beginning and end of each command string.
>> /cfg/slb/group x/health script1/content none >> /cfg/slb/advhc/script 1 open 80 send "GET /index.html HTTP/1.1\\r\\nHOST:www.hostname.com \\r\\n\\r\\n" expect "HTTP/1.1 200" close open 80 send "GET /script.cgi HTTP/1.1\\r\\nHOST:www.hostname.com \\r\\n\\r\\n" expect "HTTP/1.1 200" close open 443 ... close
Note: When you are using the command line interface to enter the send string as an argument to the send command, you must type two "\"s before an "n" or "r." If you are instead prompted for the line, that is, the text string is entered after hitting <return>, then only one "\" is needed before the "n" or "r."
Script Example 2: GSLB URL Health Check

In earlier Nortel Application Switch Operating System releases, each remote Global Server Load Balancing sites virtual server IP address was required to be a real server of the local switch. Each switch sends a health check request to the other switchs virtual servers that are congured on the local switch. The health check is successful if there is at least one real server on the remote switch that is up. If all real servers on the remote switch are down, the remote real server (a virtual server of a remote switch) will respond with an HTTP Redirect message to the health check. Using the scriptable health check feature, you can set up health check statements 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 80 send "GET /images/default.asp HTTP/1.1\\r\\nHOST: 192.192.1.2\\r\\n\\r\\n" expect "HTTP/1.1 200" close open 80 send "GET /install/default.html HTTP/1.1\\r\\nHOST: 192.192.1.2\\r\\n\\r\\n" expect "HTTP/1.1 200" close open 80 send "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 the appropriate requests to the relevant servers. In the example above, the rst GET statement will only be sent to Real Server 1 and Real Server 2. Going through the health-check statements serially will ensure that all content is available by at least one real server on the remote site. Congure the remote real server IP address (the virtual server IP address of the remote site) to accept "any" URL requests. The purpose of the rst GET is to check if Real Server 1 or Real Server 2 is upthat is, to check if the remote site has at least one server for "images" content. Either Real Server 1 or Real Server 2 will respond to the rst GET health check.
.
Health Checking
477
If all the real server IP addresses are down, Real Server 7 (the virtual server IP address of the remote site) will respond with an HTTP Redirect (respond code 302) to the health check. Thus, the health check will fail as the expected response code is 200, ensuring that the HTTP Redirect messages will not cause a loop.
Script Example 3: A UDP-Based Health Check using Binary Content

Health checks scripts can be designed to be sent over the UDP protocol with a few minor differences from a TCP-based health check script. Due to the stateless nature of the UDP protocol, the CLOSE command is not supported. A sample UDP-based script that uses Binary content to health check the UDP port on a real server is shown below.
>> /cfg/slb/group <x> /health script3/content none >> /cfg/slb/advhc/script 3 open "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 switch command line. If your send or expect content is lengthy, you may remove spaces in between the numbers to save space on the command line. For example, type 000101 instead of 00 01 01. Or, continue the content using the nsend and nexpect commands.
Script Example 4: A TCP-Based Health Check using Binary Content

Health check scripts can also be sent over the TCP protocol using Binary content. A sample of a TCP-based script that uses Binary content to send an HTTP GET request, and expect an HTTP 200 response, is shown below.
.
>> /cfg/slb/group <x> /health script 4/content none >> /cfg/slb/advhc/script4 open "80,tcp" bsend "474554202F746573742E68746D20" nsend "485454502F312E300D0A0D0A" bexpect "203230" nexpect "3020" offset "7" depth "10" wait "100" close
Verifying Script-Based Health Checks

If a script fails, the expect line in the script that is not succeeding is displayed under the /info/slb/real <real server number> command:
>> # /info/slb/real 1 1: 205.178.13.225, 00:00:00:00:00:00, vlan 1, port 0, health 4, FAILED real ports: script 2, DOWN, current send GET / HTTP/1.0\r\n\r\n expect 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, the following information is displayed:
>> # /info/slb/real 1 1: 205.178.13.223, 00:00:5e:00:01:24, vlan 1, port 2, health 4, up real ports: script 2, up, current
Application-Specic Health Checks

Application-specic 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) "Conguring WSP Health Checks" (page 494) "Conguring WTP Health Checks" (page 496) "Conguring WTLS Health Checks" (page 498)
"LDAP Health Checks" (page 499)
HTTP Health Checks

HTTP-based health checks can include the hostname for HOST: headers. The HOST: header and health check URL are constructed from the following components:
Item Virtual server hostname Domain name Option hname dname Configured Under /cfg/slb/virt/service /cfg/slb/virt /cfg/slb/group Max. Lengt h 9 characters 35 characte rs 34 characte rs
Server group health conte nt check field
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 get a return code of 200.
Example 1: hname= everest dname= alteonwebsystems.com content= index.html
Health check is performed using: GET /index.html HTTP/1.1 Host: everest.alteonwebsystems.com Note: If the content is not specied, the health check will revert back to TCP on the port that is being load balanced.
Example 2: hname= (none) dname= raleighduram.cityguru.com content= /page/gen/?_template=alteon
.
Health check is performed using: GET /page/gen/?_template=alteon HTTP/1.1 Host: raleighduram.cityguru.com

Example 3: hname= (none) dname= jansus content= 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 is required)
Example 5: hname= (none) dname= (none) content= //everest/index.html
Health check is performed using: GET /index.html HTTP/1.1 Host: everest
Conguring the Switch for HTTP Health Checks

Perform the following on the switch to congure the switch for HTTP health checks: Step 1 Action Select the real server group.
>> # /cfg/slb/group 1 (Select a real server group)
Set the health check type to FTP for the real server group.
>> # /cfg/slb/group 1/health http
Congure the health check content.

>> # /cfg/slb/group 1/content <filename>
.
Health Checking
481

End
UDP-Based DNS Health Checks

Nortel Application Switch Operating System supports UDP-based health checks along with TCP health checks, and performs load-balancing based on TCP and UDP protocols. DNS servers can be based on both TCP and UDP protocols. With UDP-based DNS health checks enabled, you can send TCP-based queries to one real server group and UDP-based queries to another real server group. The health check may be performed by sending a UDP-based query (for example, for http://www.nortel.com/), and watching for the servers reply. The domain name to be queried may be modied by specifying the content command if you need to change the domain name.
Conguring the Switch for UDP-based Health Checks

Congure the switch to verify if the DNS server is alive. Step 1 Action Select the real server group.
Set the health check type to UDP for the real server group.
>> # Real server group 1# health udpdns
Set the content to domain name.

>> # Real server group 1# content <filename> |// <host><filename> |none


.
Note: If no host name is congured, the health check is performed by sending a UDP-based query from a dummy host and watching for the servers reply. The reply, even though negative (for example, "Server not found" since the query is from a dummy host), serves the purpose of a health check, nonetheless. End
TFTP Health Check

Nortel Application Switch Operating System supports the Trivial File Transfer Protocol (TFTP) health check which utilizes the TFTP protocol to request a le from the server. At regular intervals, the switch transmits TFTP read requests (RRQ) to all the servers in the group. The health check is successful if the server successfully responds to the RRQ. The health check fails if the switch receives an error packet from the real server. To congure TFTP health check, do the following: Step 1 Action Select the real server group.
Set the health check type to TFTP for the real server group.
>> # Real server group 1# health tftp
Specify the le name that the switch requests from the real servers. Make sure the le is less than 512 bytes, so you dont incur additional trafc between the server and the switch. Depending on the implementation of the TFTP daemon on the real servers being health-checked, you may have to specify the full pathname of the le (/tftpboot/<filename>) on some systems and on others a lename is sufcient. By default, the switch checks the /tftpboot folder.
>> # Real server group 1# content test
If full pathname is specied, add quotation marks for example, "/tftpboot/test". 4 Apply and save the conguration.
.
Health Checking
483
End
SNMP Health Check

Nortel Application Switch Operating System supports SNMP health checks by sending an SNMP GET request to the real server running an SNMP-based agent. SNMP health checks can be used on any real servers, provided they have an SNMP agent. The SNMP health check is performed by polling a single variable within the MIB. For each SNMP health check, you congure the Object Identier (OID) and community string to be queried. These values are obtained by using a MIB Browser and a MIB compiler to nd 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 conguration. The SNMP health check per real server is used to health check IDS servers only. Nortel Application Switch Operating System also allows you to congure the real server weights to dynamically readjust, based on the SNMP health check response. To adjust the server weights based on the SNMP health check response, use the command /cfg/slb/advhc/snmphc <x> /weight ena. The switch will then use the value sent in the SNMP health 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 as the weight. To congure SNMP health check for a real server group, do the following: Step 1 Action Select the SNMP health check menu and enter an index number. You can congure up to ve SNMP health checks and assign it to a group or per real server.
>> # /cfg/slb/advhc/snmphc 1 (Specify an index number)
Specify the object identier (OID). The OID is obtained from the MIB le of the switch. For example, you may enter the OID for checking the status of a physical port on the 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
.
Set the community string on the switch which noties the SNMP agent on the real server to accept the SNMP packet from the switch. This community string must match the community string specied on the real server.
>> SNMP Health Check 1# comm real1
Congure an integer value for the switch to accept the health check. If the value returned by the real server for the MIB variable does not match the expected value congured in the rcvcnt eld, then the server is marked down; the server is marked back up when it returns the 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 as health check failed
>> SNMP Health Check 1# rcvcnt 0
Enable the real server weights to dynamically change based on the SNMP health check response
>> SNMP Health Check 1# weight ena (Update weights for the real servers)
Enable the invert eld if you want the switch to invert the health check. By enabling the invert eld, it is possible to reverse your conguration in Step 4. Then, the server is marked down if the switch receives the expected value in Step 4. In this example, the real server is marked up if the switch receives any value other than 0.
>> SNMP Health Check 1# invert ena
Add the SNMP health check to a real server group. When you assign a group to use the SNMP health check, all the real servers in the group must use the same OID and community string.
>> # /cfg/slb/group 10 >> Real Server Group 10# health snmp1
(Select the real server group)

.
Health Checking
485
End
FTP Server Health Checks

The Internet File Transfer Protocol (FTP) provides facilities for transferring les to and from remote computer systems. Usually the user transferring a le needs authority to login and access les on the remote system. This protocol is documented in RFC 1123. In normal Internet operation, the FTP server listens on the well-known port number 21 for control connection requests. The client sends a control message which indicates the port number on which the client is prepared to 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 with transferring user requested les, the data transfer mechanism is also used for transferring directory listings from server to client. Note: To congure the switch for FTP health checks, the FTP server must accept anonymous user login.
Conguring the Switch for FTP Health Checks

Create any le name from an FTP server under FTP server directory, for example, .txt, .exe, .bin. To congure the switch for FTP health checks: Step 1 Action Select the real server group.
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 Checks

The Post Ofce Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host. The POP3 protocol is used to allow a workstation to retrieve mail that the server is holding for it. This protocol is documented in RFC 1939. When the user on a client host wants to enter a message into the transport system, it establishes an SMTP connection to its relay host and sends all mail to it. Initially, the server host starts the POP3 service by listening on TCP port 110. When a client host wants to make use of the service, it establishes a TCP connection with the server host.
Conguring the Switch for POP3 Health Checks

To support health checking on the UNIX POP3 server, the network administrator must congure a username:password value in the switch, using the content option on the SLB real server group menu (/cfg/slb/group) To congure the switch for POP3 health checks: Step 1 Action Select the real server group.
Set the health check type to POP3 for the real server group.
>> # /cfg/slb/group 1/health pop3
Congure the health check content

>> # /cfg/slb/group 1/content <username>:<password>
.
Health Checking
487
End
SMTP Server Health Checks

Simple Mail Transfer Protocol is a protocol to transfer e-mail messages between servers reliably and efciently. This protocol traditionally operates over TCP, port 25 and is documented in RFC 821. Most e-mail systems that send mail over the Internet use SMTP to send messages from one server to another; the messages can then be retrieved with an e-mail client using either POP or IMAP.
Conguring the Switch for SMTP Health Checks

To support SMTP health checking, the network administrator must congure a username:password value in the switch, using the content option on the SLB real server group menu (/cfg/slb/group). To congure the switch for SMTP health checks: Step 1 Action Select the health check menu for the real server group.
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 Checks

Internet Message Access Protocol (IMAP) is a mail server protocol used between a client system and a mail server that allows a user to retrieve and manipulate mail messages. IMAP is not used for mail transfers between mail servers. IMAP servers listen to TCP port 143.
Conguring the Switch for IMAP Health Check

To support IMAP health checking, the network administrator must congure a username:password value in the switch, using the content option on the SLB Real Server Group Menu (/cfg/slb/group). To congure the switch for IMAP health checks: Step 1 Action Select the health check menu for the real server group.
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 species the username:passwordvalue that the server tries to match in its user database. In addition to verifying the user name and password, the database may specify the client(s) or port(s) the user is allowed to access. 4 Apply and save your conguration.
End
NNTP Server Health Checks

Net News Transfer Protocol (NNTP) is a TCP/IP protocol based upon text strings sent bidirectionally over 7 bit ASCII TCP channels, and listens to port 119. It is used to transfer articles between servers as well as to read and post articles. NNTP species 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 news articles are stored in a central database allowing a subscriber to select only those items he wishes to read. NNTP is documented in RFC977. Articles are transmitted in the form specied by RFC1036.
Conguring the Switch for NNTP Health Checks

To congure the switch for NNTP health checks: Step 1 Action Select the real server group.
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. 4 Apply and save your conguration.
End
RADIUS Server Health Checks

Nortel Application Switch Operating System allows you to use the Remote Authentication Dial-In User Service (RADIUS) protocol to health check the RADIUS accounting and authentication services on RADIUS servers. RADIUS is stateless and uses UDP as its transport protocol. Before you start conguring RADIUS health checks, make sure of the following: Congure the Network-attached storage (NAS) IP parameter on the RADIUS server This parameter is the IP address of the switch interface connected to the RADIUS server. The Nortel Application Switch will provide the NAS IP
.
parameter while performing RADIUS content health checks. The switch uses the IP address of the IP interface that is on the same subnet as the RADIUS server or the default gateway as the NAS IP. Congure 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 listening on for RADIUS authentication (1812) or RADIUS accounting (1813). To congure the rport, use the /cfg/slb/virt <#> / service menu.
Conguring RADIUS Authentication Health Checks

Follow this procedure to health check RADIUS authentication service. Step 1 Action Select the real server group.
Set the health check type for the real server group.
>> Real server group 1# health radius-auth
Congure the health check content. The content option species the username:password value that the server tries to match in its user database. In addition to verifying the 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>
Congure the RADIUS code value. The secret value is a eld of up to 32 alphanumeric characters used by the switch to encrypt a password during the RSA Message Digest Algorithm (MD5) and by the RADIUS server to decrypt the password during verication. This value must be identical to the value specied on the RADIUS server.
>> # /cfg/slb/advhc/secret <RADIUS-coded value>

.
Health Checking
491
End
Conguring RADIUS Accounting Health Checks

RADIUS accounting packets are sent over UDP to port 1813 or 1646 on the server. Follow this procedure to health check RADIUS accounting service. Step 1 Action Select the real server group.
>> Real server group 1# health radius-acc
Note: Nortel Application Switch Operating System allows you to couple the Radius Accounting Health check with the WAP health checks. If you enable the couple command (/cfg/slb/advhc/waphc/couple) and one of the WAP health checks fail, then the Radius Accounting service is disabled. End
Conguring Combined RADIUS Health Checks

Instead of conguring separate RADIUS authentication and accounting health checks, the Nortel Application Switch Operating System provides the ability 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 task queries the service port. If the service port is detemined to be representing a RADIUS Authentication service, then a RADIUS Authentication health check is performed. If a RADIUS Accounting service is detected, a RADIUS Accounting 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 check both types of service. If one service should fail, the other will go into a blocking state. To congure a combined RADIUS health check, perform the following procedure:
.
Step 1
Action Select the real server group.

>> Real server group 1# health radius-aa (Set the health check type)
Congure the content of the group so that it contains the RADIUS user name and password separated by a colon.
>> Real server group 1# content radadmin:radpassword
End
HTTPS/SSL Server Health Checks

The sslh health check option on the Real Server Group Menu (/cfg/slb/group <#>) allows the switch to query the health of the SSL servers by sending an SSL client "Hello" packet and then verify the contents of the servers "Hello" response. SSL health check is performed using the real server port congured, 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 veries elds in the response and marks the service "Up" if the elds are OK.
During the handshake, the user and server exchange security certicates, negotiate an encryption and compression method, and establish a session ID for each session.
WAP Gateway Health Checks

Wireless Application Protocol or WAP is a specication for wireless devices that uses TCP/IP and HTTP as part of a standards-based implementation. The translation from HTTP/HTML to WAP/WML (Wireless Markup Language) is implemented by servers known as WAP gateways on the land-based part of the network.
.
Health Checking
493
Wireless Session Protocol (WSP) is used within the WAP suite to manage sessions between wireless devices and WAP content servers or WAP gateways. Nortel Application Switch Operating System provides a content-based health check mechanism where customized WSP packets are sent to the WAP gateways, and the switch veries the expected response, in a manner similar to scriptable health checks. WSP content health checks can be congured in two modes: connectionless and connection-oriented. Connectionless WSP runs on UDP/IP protocol, ports 9200/9202. Connection-oriented trafc runs on ports 9201 and 9203. Nortel Application Switches can be used to load balance the gateways in both modes of operation. Nortel Application Switch Operating System allows you to congure three WAP gateway health check types for all four WAP services (default ports 9200, 9201, 9202, and 9203) deployed on WAP gateway/servers.
WAP Gateway Health Checks Health Check Type WSP Type of Traffic Health Check Mode connectionless WSP WAP Service 9200 To configure, see "Configuring WSP Health Checks" (page 494) "Configuring WTP Health Checks" (page 496) "Configuring WTLS Health Checks" (page 498) "Configuring WTLS Health Checks" (page 498)
WTPa
connection-oriented WTP + WSP encrypted connectionless WTLS + WSP
9201
WTLSb
9202
WTLS
9203 encrypted connection-oriented WTLS + WTP + WSP
a. Wireless Transaction Protocol b. Wireless Transport Layer Security
Note: In the Nortel Application Switch Operating System, all four WAP services are grouped together. If a health check to one of the services fail, 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 specically for the wireless environment, is needed because the client and the server must be authenticated in order for wireless transactions
.
to remain secure and because the connection needs to be encrypted. For example, a user making a transaction with a bank over a wireless device needs to know that the connection is secure and private and not subject to a security breach during transfer. WTLS is needed because mobile networks do not provide complete end-to-end security.
How WAP Health Check Works

The content of the WSP/UDP packet that is sent to the gateway is congured as a hexadecimal string, which is encapsulated in a UDP packet and shipped to the server. Hence, this byte string should include all applicable WSP headers. The content that the switch expects to receive from the gateway is also specied in the form of hexadecimal byte string. The switch matches each byte of this string with the received content. If there is a mismatch of even a single byte on the received content, the gateway fails the health check. You can also congure an offset for the received WSP packet: a byte index to the WSP response content from where the byte match can be performed. Offset value (WSP or WTP) is for the receiving content only, and is the number of bytes from the beginning of the UDP Data Area, at which the comparison begins to match with the expected receive content.
Coupling with Radius Accounting Health Check

Nortel Application Switch Operating System allows you to couple the WAP health checks with the Radius Accounting health check. If you enable the couple command (/cfg/slb/advhc/waphc/couple) and the Radius Accounting health check fails, then all four of the WAP services are brought down. Similarly, if one of the WAP health checks fail, then all the WAP services and the Radius Accounting service fails.
Conguring WSP Health Checks

Follow this procedure to congure the health check for connectionless and unencrypted WAP trafc. Step 1 Action Select the WAP Health Check Menu.
>> # /cfg/slb/advhc/waphc
Enter the WSP port. By default, the health check is sent to the UDP port 9200.
>> WAP Health Check# wspport 9200

.
Health Checking
495
Select the WAP Health Check Menu.

>> WAP Health Check# wspcnt
Use the sndcnt command to enter the content to be sent to the WSP gateway.
>> WSP Health Check Content# sndcnt Current Send content: Enter new Send content: 01 42 15 68 74 74 70 3a 2f 77 77 77 2e 6e 6f 6b 61 6d 00 .
Enter the content that the switch expects to receive from the WSP gateway.
>> WSP Health Check Content# rcvcnt Current Receive content: Enter new Receive content: 01 04 60 0e 03 94
Note: A maximum of 255 bytes of input are allowed on the switch command line. You may remove spaces in between the numbers to save space on the command line. For example, type 010203040506 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 the UDP Data Area, at which the comparison begins to match with the expected receive content. For 9200 service, the UDP data area is the WSP response content.
>> WSP Health Check Content# offset 0
Because WAP gateways are UDP-based and operate on a UDP port, congure UDP service in the virtual server menu.
>> # /cfg/slb/virt 1 >> Virtual Server 1# service Enter virtual port: 9200 (Configure virtual service 1) (On the default WSP port) (Set the real server group number)
>> Virtual Server 1 9200 Service# group 1
.
>> Virtual Server 1 9200 Service# udp ena >> Virtual Server 1 9200 Service# apply
(Enable UDP load balancing) (Apply the configuration)
Enable WSP health checks for group 1.

>> # /cfg/slb/group 1 >> Real server group 1# health wsp (Select the Real Server Group 1 menu) (Set the health check type)

>> Real server group 1# apply
End
Conguring WTP Health Checks

Follow this procedure to congure the health check for connection-oriented, unencrypted WAP trafc. Step 1 Action Select the WAP Health Check Menu.
Enter the WTP port. By default, the health check is sent to the UDP port 9201.
>> WAP Health Check# wtpport 9201
Select the WTP Health Check Menu.

>> WAP Health Check# wtpcnt
Create a WSP session by sending the connect message. Use the connect command to enter the content for the rst switch-generated WSP session packet. This command allows you to customize the headers in the connect message.
.
Health Checking
497
>> WTP+WSP Health Check Content# connect Current Connect content: Enter new Connect content: 01 10 00 00
Use the sndcnt command to enter the content to be sent to the WSP gateway. This send content can be used to get a dummy Web page from the server.
>> WTP+WSP Health Check Content# sndcnt Current Send content: Enter new Send content: 01 42 15 68 74 74 70 3a 2f 77 77 77 2e 6e 6f 6b 61 6d 00 .
Enter the content that the switch expects to receive from the WSP gateway.
>> WTP+WSP Health Check Content# rcvcnt Current Receive content: Enter new Receive content: 01 04 60 0e 03 94
Set the offset value. The offset value is the number of bytes from the beginning of the UDP Data Area, at which the comparison begins to match with the expected receive content. For 9201 service, the UDP data area includes the WTP content as well as the WSP content.
>> WTP+WSP Health Check Content# offset 0
Because WAP gateways are UDP-based and operate on a UDP port, congure UDP service in the virtual server menu.
>> # /cfg/slb/virt 1 >> Virtual Server 1# service Enter virtual port: 9201 (Configure virtual service 1) (On the default WTP port) (Set the real server group number) (Enable UDP load balancing) (Apply the configuration)
>> Virtual Server 1 9200 Service# group 1 >> Virtual Server 1 9200 Service# udp ena >> Virtual Server 1 9200 Service# apply
.
Enable WSP health checks for group 1.

>> # /cfg/slb/group 1 >> Real server group 1# health wtp (Select the Real Server Group 1 menu) (Set the health check type)
10

End
Conguring WTLS Health Checks

Wireless Transport Layer Security (WTLS) is used to health check encrypted WAP trafc. The encrypted WAP trafc can be connectionless (WTLS+WSP) or connection-oriented (WTLS+WTP+WSP). The connectionless encrypted WTLS trafc uses default port 9202 and the connection-oriented encrypted WTLS trafc uses port 9203. The application switch sends a new WTLS Client Hello to the WAP gateway, and checks to see if it receives a valid WTLS Server Hello back from the WAP Gateway. The contents for WTLS health check are not congurable and is generated by the switch automatically. Step 1 Action Select the group with the WAP gateway.
>> Main# /cfg/slb/group 1 (Select the Real Server Group 1 menu)
Use the sndcnt command to enter the content to be sent to the WSP gateway.
>> Real server group 1# health wtls
Select the WAP Health Check Menu.

Select a port number on which your gateway is listening to WTLS trafc.
.
Health Checking
499
By default, the health check is sent to the UDP port 9202 for connectionless trafc (/cfg/slb/adv/waphc/wtlswsp) and to port 9203 for connection-oriented trafc (/cfg/slb/adv/waphc/wtlsprt).
>> WAP Health Check# wtlsprt 9203

>> WAP Health Check# apply
End
LDAP Health Checks

Lightweight Directory Access Protocol (LDAP) health checks enable the switch to determine whether the LDAP server is alive or not. LDAP versions 2 and 3 are described in RFC 1777 and RFC 2251. The LDAP health check process consists of three LDAP messages over one TCP connection: Bind request: The switch rst creates a TCP connection to the LDAP server on port 339, which is the default port. After the connection is established, the switch initiates an LDAP protocol session by sending an anonymous bind request to the server. Bind response: On receiving the bind request, the server sends a bind response to the switch. If the result code indicates that the server is alive, the switch marks the server as up. Otherwise, the switch marks the server as down even if the switch did this because the server did not respond within the timeout window. Unbind request: If the server is alive, the switch sends a request to unbind the server. This request does not require a response. It is necessary to send an unbind request as the LDAP server may crash if too many protocol sessions are active.
If the server is up, the switch closes the TCP connection after sending the unbind request. If the server is down, the connection is torn down after the bind response, if one arrives. The connection will also be torn down if it crosses the timeout limit, irrespective of the servers condition.
Conguring the Switch for LDAP Health Checks

Congure the switch to verify if the LDAP server is alive.
.
Step 1
Action Select the health check menu for the real server group.
Add the desired real servers to the group.

>> Real server group 1# add 2 >> Real server group 1# add 3
Set the backup server.

>> Real server group 1# backup r1 (Set real server 1 as backup)
Set the health check type to LDAP for the real server group.
>> # Real server group 1# health ldap
Congure the LDAP health check to verify the domain name in the content eld. For example, to verify the domain name ldap.example.com , enter the following with the customer name = Admin and password =test :
>> # content "cn=Admin,dc=ldap,dc=example,dc=com:te st"
(Optional) Name the real server group.

>> Real server group 1# name LDAP

End
.
Health Checking
501
Determining the Version of LDAP

Step 1 Action Select the Advanced Menu.
>> # Real server group 1# /cfg/slb/advhc
Set the version of LDAP. The default version is 2.

>> Layer 4 Advanced Health Check# ldapver <2 | 3> (Select the desired LDAP version)

>> Layer 4 Advanced Health Check# apply >> Layer 4 Advanced Health Check# save
End
Windows Terminal Server Health Checks

Application health checking can be performed on Windows Terminal Servers similar to LDAP health checking. The WTS protocol (RDP) is a binary protocol so scripted health checks cannot be used in this instance. Therefore, this health check only entails the checking of server availability on TCP port 3389. To enable WTS health checking on a real server group, use the following command:
>> Main# /cfg/slb/group <Group Number> /health wts
ARP Health Checks

Address Resolution Protocol (ARP) is the TCP/IP protocol that resides within the Internet layer. ARP resolves a physical address from an IP address. ARP queries machines on the local network for their physical addresses. ARP also maintains IP to physical address pairs in its cache memory. In any IP communication, the ARP cache is consulted to see if the IP address of the computer or the router is present in the ARP cache. Then the corresponding physical address is used to send a packet. In the switch, this features allows the user to health check the Intrusion Detection Server (IDS) by sending an ARP query. The health check consists of the following sequence of actions:
.
Step 1 2
Action Accessing the ARP table. Looking for the session entry in the ARP table. If the entry exists in the table, that means the real server is up, otherwise the health check has failed. If the entry is present, then check the timestamp to nd out if the last used time is greater than the ARP health check interval. If it is, then delete the query, as this means that the health check has failed. Send another ARP request and repeat the above process until the timestamp shows the last used time smaller than the ARP health check interval. End
Conguring the Switch for ARP Health Checks

Step 1 Action Select the SLB group from the health check menu.
>> /cfg/slb/group 1
Select the type of health check to use.

>> Real server group 1# health arp
Enable ARP health checks for group 1.

>> Real server group 1# arp

End
.
Health Checking
503
Buddy Server Health Checks

Buddy server health checking gives the administrator the ability to tie the health of a real server to another real server. This real server can be in the same real server group but can be in a separate group as well. In this conguration, a real server will only be considered healthy if the buddy it is associated 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 individual servers and not server groups. To add a real server as a buddy server for another real server, use the following command:
>> Main# /cfg/slb/real <real server number> /adv/buddyhc/add bd <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/del bd <real server number> <real server group> <service>
To view the current buddy server settings for a real server, use the following command:
>> Main# /cfg/slb/real <real server number> /adv/buddyhc/cur
.
Buddy Server Health Check Sample Conguration

The following example outlines the steps necessary for Buddy Server Health Check conguration: Step 1 Action Congure an interface.
>> Main# /cfg/l3/if 1/addr 10.1.11.1/mask 255.255.255.0/ena

Enable ports for SLB.

>> >> >> >> >> Main# Main# Main# Main# Main# /cfg/slb/port /cfg/slb/port /cfg/slb/port /cfg/slb/port /cfg/slb/port 2/server 3/server 4/server 5/server 6/server en en en en en
Congure and enable real servers.

>> >> >> >> >> Main# Main# Main# Main# Main# /cfg/slb/real /cfg/slb/real /cfg/slb/real /cfg/slb/real /cfg/slb/real 1/rip 2/rip 3/rip 4/rip 5/rip 10.1.11.30/ena 10.1.11.31/ena 10.1.11.32/ena 10.1.11.33/ena 10.1.11.34/ena
Congure real server groups and assign real servers to them.

>> Main# /cfg/slb/group 1/add 1 >> Main# /cfg/slb/group 1/health tcp >> >> >> >> >> Main# Main# Main# Main# Main# /cfg/slb/group /cfg/slb/group /cfg/slb/group /cfg/slb/group /cfg/slb/group 2/add 2 2/add 3 2/add 4 2/add 5 2/health tcp
Apply and save the conguration

>> Main# Apply >> Main# Save
.
Health Checking
505
Congure 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
Add real servers 2 to 5, in group 2, to real server 1 as buddy servers.

>> >> >> >> Main# Main# Main# Main# /cfg/slb/real /cfg/slb/real /cfg/slb/real /cfg/slb/real 1/adv/buddyhc/addbd 1/adv/buddyhc/addbd 1/adv/buddyhc/addbd 1/adv/buddyhc/addbd 2 3 4 5 2 2 2 2 80 80 80 80
Apply and save conguration.

>> Main# Apply >> Main# Save
Note: It is not mandatory for a Buddy Server Group to be part of any virtual service. End
DHCP Health Checks

A DHCP health check works by sending a DHCPINFORM packet to the real server. The DHCPINFORM is sent from a random switch port to port 67 on the real server. The group health content can contain one of the following types when using this 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.
.
Conguring the Switch for DHCP Health Checks

The following is the procedure to congure the switch for DHCP health checks: Step 1 Action Select the SLB group from the health check menu.
>> /cfg/slb/group 1
Select the type of health check to use.

>> Real server group 1# health dhcp
(Optional) Set the group health content.

>> Real server group 1# content strict

>> Real server group 1# apply >> Real server group 1# save
End
Failure Types
Service Failure
If a certain number of connection requests for a particular service fail, the Nortel Application Switch places the service into the service failed state. While in this state, no new connection requests are sent to the server for this service; however, if graceful real server failure is enabled (/cfg/slb/adv/grace ena), state information about existing sessions is maintained and trafc associated with existing sessions continues to be sent to the server. Connection requests to, and trafc associated with, other load-balanced services continue to be processed by the server. Example: A real server is congured to support HTTP and FTP within two real server groups. If a session switch detects an HTTP service failure on the real server, it removes that real server group from the load-balancing algorithm for HTTP, but keeps the real server in the mix for FTP. Removing only the failed service from load balancing allows users access to all healthy servers supporting a given service.
.
Health Checking
507
When a service on a server is in the service failed state, the Nortel Application Switch sends Layer 4 connection requests for the failed service to the server. When the session switch has successfully established a connection to the failed service, the service is restored to the load-balancing algorithm.
Server Failure
If all load-balanced services supported on a server fail to respond to switch connection requests within the specied number of attempts, then the server is placed in the server failed state. While in this state, no new connection requests are sent to the server; however, if graceful real server failure is enabled (/cfg/slb/adv/grace ena), state information about existing sessions is maintained and trafc associated with existing sessions continues to be sent to the server. Note: All load-balanced services on a server must fail before the switch places the server in the server failed state. The server is brought back into service as soon as the rst service is proven to be healthy. Additional services are brought online as they are subsequently proven to be healthy.
.
High Availability
Nortel Application Switches support high-availability network topologies through an enhanced implementation of the Virtual Router Redundancy Protocol (VRRP). The following topics are addressed in this chapter: "VRRP Overview" (page 509). This section discusses VRRP operation and Nortel Application Switch Operating System redundancy congurations. "Nortel Application Switch Operating System Extensions to VRRP" (page 512). This section describes VRRP enhancements implemented in Nortel Application Switch Operating System. "IPv6 VRRP Support" (page 521). This section describes VRRP support for IPv6 in the Nortel Application Switch Operating System. "Failover Methods and Congurations" (page 524). This section discusses a few of the more useful and easily deployed redundant congurations. "Active-Standby VSR Conguration in a Non-Shared Environment" (page 526) "Active-Active VIR and VSR Conguration" (page 529) "Active-Active Server Load Balancing Conguration" (page 531) "Hot-Standby Conguration" (page 541) "Service-Based Virtual Router Groups" (page 550) "IPv6 VRRP Conguration Examples" (page 555). This section illustrates examples for IPv6 VRRP conguration. "Hot Standby Conguration Example" (page 555) "Active-Standby Conguration Example" (page 562) "Active-Active Conguration Example" (page 569) "Virtual Router Deployment Considerations" (page 576). This section describes issues to consider when deploying virtual routers. "Stateful Failover of Persistent Sessions" (page 580). This section describes how to enable stateful failover by mirroring Layer 7 and Layer 4 persistent transactional states on the peer switch. "Service-based Session Failover" (page 584). This section describes the Nortel Application Switch Operating System 24.0 support for the failover of a session based on a service.
.
High Availability 509
"Peer Synchronization" (page 586)
VRRP Overview
In a high-availability network topology, no device can create a single point-of-failure for the network or force a single point-of-failure to any other part of the network. This means that your network will remain in service despite the failure of any single device. To achieve this usually requires redundancy for all vital network components. VRRP enables redundant router congurations within a LAN, providing alternate router paths for a host to eliminate single points-of-failure within a network. Each participating VRRP-capable routing device is congured with the same virtual router IP address and ID number. One of the virtual routers is elected as the master, based on a number of priority criteria, and assumes 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 IP address and actively process trafc addressed to it. Because the router associated with a given alternate path supported by VRRP uses the same IP address and MAC address as the routers for other paths, the hosts gateway information does not change, no matter what path is used. A VRRP-based redundancy schema reduces administrative overhead because hosts need not be congured with multiple default gateways. Note: The IP address of a VRRP virtual interface router (VIR) and virtual server router (VSR) must be in the same IP subnet as the interface to which it is assigned.
Standard VRRP Components

Each physical router running VRRP is known as a VRRP router.
Virtual Router
Two or more VRRP routers can be congured to form a virtual router (RFC 2338). Each VRRP router may participate in one or more virtual routers.Each virtual router consists of a user-congured virtual router identier (VRID) and an IP address.
Virtual Router MAC Address

The VRID is used to build the virtual router MAC Address. The ve highest-order octets of the virtual router MAC Address are the standard MAC prex (00-00-5E-00-01) dened in RFC 2338. The VRID is used to form the lowest-order octet.
.
Owners and Renters

Only one of the VRRP routers in a virtual interface router may be congured as the IP address owner. The owner is the virtual router (Nortel Application Switch) whose virtual interface routers IP address is equal to the real interface address. This router responds to packets addressed to the virtual interface routers IP address for ICMP pings, TCP connections, and so on. If the owner is not available, the backup becomes the master and takes over responsibility for packet forwarding and responding to ARP requests. However, because this switch is not the owner, it does not have a real interface congured with the virtual interface routers 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. For the purposes of this chapter, VRRP routers that are not the IP address owner are called renters.
Virtual Router States

Within each virtual router, one VRRP router is selected to be the virtual router master. See "How VRRP Priority Decides Which Switch is the Master" (page 511) for an explanation of the selection process. Note: If the IP address owner is available, it will always become the virtual router master. Master The virtual router master forwards packets sent to the virtual interface router. It also responds to Address Resolution Protocol (ARP) requests sent to the virtual interface routers IP address. Finally, the virtual router master sends out periodic advertisements to let other VRRP routers know it is alive and its priority. Backup Within a virtual router, the VRRP routers not selected to be the master are known as virtual router backups. Should the virtual router master fail, one of the virtual router backups becomes the master and assumes its responsibilities. Init If there is no port in the virtual routers VLAN with an active link, the interface for the VLAN fails, thus placing the virtual router into the INIT state. The INIT state identies that the virtual router is waiting for a startup event. If it receives a startup event, it will either transition to master if its priority is 255, (the IP address owner) or transition to the backup state if it is not the IP address owner.
.
How VRRP Priority Decides Which Switch is the Master

Each VRRP router that is not an owner is congured with a priority between 1254. According to the VRRP standard, an owner has a priority of 255. A bidding process determines which VRRP router is or becomes the masterthe VRRP router with the highest priority. Owners have a higher priority than the range permitted for non-owners. If there is an IP address owner, it is always the master for the virtual interface router, as long as it is available. The master periodically sends advertisements to an IP multicast address. As long as the backups receive these advertisements, they remain in the backup state. If a backup does not receive an advertisement for three advertisement intervals, it initiates a bidding process to determine which VRRP router has the highest priority and takes over as master. If, at any time, a backup determines that it has higher priority than the current master does, it can preempt the master and become the master itself, unless congured not to do so. In preemption, the backup assumes the role of master and begins to send its own advertisements. The current master sees that the backup has higher priority and will stop functioning as the master. A backup router can stop receiving advertisements for one of two reasonsthe master can be down, or all communications links between the master and the backup can be down. If the master has failed, it is clearly desirable for the backup (or one of the backups, if there is more than one) to become the master. Note: If the master is healthy but communication between the master and the backup has failed, there will then be two masters within the virtual router. To prevent this from happening, congure redundant links to be used between the switches that form a virtual router.
Determining How to Congure Priority

Think of a virtual routers priority as a starting value that increases or decreases depending on the parameters that are tracked. For example, if you congure the virtual router to track link state of the physical ports, one port losing link would cause the virtual routers priority to decrease by 2 priority points. In order to ensure that this decrease in priority causes failover from the current master to the backup virtual router, you should make sure to set the "base" priority of the Master switch to be only 1 point higher than the backup; for example priority 101 for master, 100 for backup. If the master and backup switches were set to priorities 110 and 100 respectively, a single port failure would only decrease the master switchs priority to 108. As 108 is still higher than backups priority 100, the master switch would not fail over due to the loss of one ports link.
.
Nortel Application Switch Operating System Extensions to VRRP

This section describes the following VRRP enhancements that are implemented 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 Routers

At Layer 3, a Virtual Interface Router (VIR) allows two VRRP routers to share an IP interface across the routers.VIRs provide a single Destination IP (DIP) for upstream routers to reach various destination networks, and provide a virtual default Gateway. A VIR must be assigned an IP interface, and every IP interface must be assigned to a VLAN. If the IP interface of a VIR is down, then the VIR will be in the INIT state.
Virtual Server Routers

Support for 1024 VSRs Nortel Application Switch Operating System supports up to 1024 virtual server routers, which extend the benets of VRRP to virtual server IP addresses that are used to perform server load balancing. In Nortel Application Switch Operating System 24.0, all VSRs with a Virtual Router ID (VRID) greater than 255 use a new packet format, which differs in size and location of the VRID eld. When sending advertisements using a VSR with a VRID greater than 255, the Type should be set to 15. Switches that do not support the new packet format will automatically discard these packets because VRRP currently only supports one dened 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 operate for IP interfaces. A master is negotiated via a bidding process, during which information about each VRRP routers priority is exchanged. Only the master can process packets that are destined for the virtual server IP address and respond to ARP requests.
.
One difference between virtual server routers and virtual interface routers is that a virtual server router cannot be an IP address owner. All virtual server 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, when you congure a VRRP routers priority in a virtual server router, you are not affecting that VRRP routers priority in any virtual interface router or any other virtual server router of which it is a part. However, because of the requirement that MAC addresses be unique on a LAN, VRIDs must be unique among all virtual routers, whether virtual interface routers or virtual server routers. The Nortel Application Switches in "Virtual Interface Router" (page 513) have been congured as VRRP routers. Together, they form a virtual interface router (VIR).
Virtual Interface Router
Application Switch 1 in "Virtual Interface Router" (page 513) has its real interface congured with the IP address of the virtual interface router, making it the IP address owner. As IP address owner, it receives a priority of 255, and is the virtual router master. Application Switch 2 is a virtual router backup. Its real interface is congured with 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 the VRRP routers have a virtual router MAC address = 00-00-5E-00-01-01.
.
Sharing Interfaces for Active-Active Failover

Nortel Application Switch Operating System supports sharing of interfaces at both Layer 3 and Layer 4, as shown in "Active-Active Failover with Shared Interfaces" (page 514).
Active-Active Failover with Shared Interfaces
With sharing enabled, an IP interface or a VIP address can be active simultaneously on multiple switches, enabling active-active operation as shown 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 Applicatio Master-Active n Switch 1 VRID 2 VIP: 205.178.13.226 Virtual Rtr. MAC address: 00-00-5E-00-01-02 Applicatio Backup-Active VR 1 n Switch 2 VRID 2 VIP: 205.178.13.226 Virtual Rtr. MAC address: 00-00-5E-00-01-02 Virtual Router 2 Backup-Active VRID 4 VIP: 205.178.13.240 Virtual Rtr. MAC address: 00-00-5E-00-01-04 Master-Active VR 2 VRID 4 VIP: 205.178.13.240 Virtual Rtr. MAC address: 00-00-5E-00-01-04 Virtual Router 3 Master-Active VRID 6 VIP: 205.178.13.110 Virtual Rtr. MAC address: 00-00-5E-00-01-06 Backup-Active VR 3 VRID 6 VIP: 205.178.13.110 Virtual Rtr. MAC address: 00-00-5E-00-01-06
.
When sharing is used, incoming packets are processed by the switch on which they enter the virtual router. The ingress switch is determined by external factors, such as routing and Spanning Tree conguration. Sharing cannot be used in congurations where incoming packets have more than one entry point into the virtual routerfor example, where a hub is used to connect the switches. When sharing is enabled, the master election process still occurs. Although the process does not affect which switch processes packets that must be routed or that are destined for the virtual server IP address, it does determine which switch sends advertisements and responds to ARP requests sent to the virtual routers IP address. Nortel strongly recommends that sharing, rather than active-standby congurations, be used whenever possible. Sharing offers both better performance and fewer service interruptions in the face of fault conditions than active-standby congurations. See "Active-Active Redundancy" (page 529) for a conguration example.
Service-Based Virtual Router Groups

A service-based virtual router group (vrgroup) consists of one or more virtual routers on a switch. Virtual routers can be grouped together and behave as a single VRRP entity. Service based virtual router groups allow for efcient tracking and failover based on each groups tracking parameters while leaving other groups unaffected. For example, an administrator wishes to provide high availability for Customer A and Customer Bs servers and services across the same two switches, without one affecting the other: Customer As trafc load-balances across real servers in real server group 1. Customer Bs trafc load balances across real servers in real server group 2.
Each switch is congured with vrgroup 1 for customer A, and vrgroup 2 for Customer B. Because each vrgroup is tracked independently of the other, vrgroup 1 can failover to its equivalent vrgroup 1 on the other switch while not affecting the VRRP state of vrgroup 2.
.
516 Part 3: Application Switching Fundamentals 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/group dis) Up to 16 vrgroups can be congured on a single application switch. Each vrgroup can contain up to 64 virtual routers assigned with a virtual router number from 1-1024. Each virtual router can be congured as a virtual interface router or a virtual service router. Virtual routers that become members of a vrgroup, assume the priority tracking parameters congured for that vrgroup. When one member of a Master vrgroup fails, the priority of the vrgroup decreases, and all the members of that vrgroup change from Master to Backup. This is accomplished by conguring tracking on the service-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 the scenario as an example:
>> Main# /cfg/l3/vrrp/vrgroup 1 >> VRRP Virtual Router Vrgroup 1# add 1 >> VRRP Virtual Router Vrgroup 1# add 2 (Select vrgroup 1) (Add virtual router 1 to vrgroup 1) (Add virtual router 2 to vrgroup 1)
.
>> Main# /cfg/l3/vrrp/vrgroup 2 >> VRRP Virtual Router Vrgroup 2# add 3 >> VRRP Virtual Router Vrgroup 2# add 4
(Select vrgroup 2) (Add virtual router 3 to vrgroup 2) (Add virtual router 4 to vrgroup 2)
See "Tracking Service-Based Virtual Router Groups" (page 520) for a conguration example.
Switch-Based VRRP Groups

A switch-based virtual router group aggregates all virtual routers on the switch as a single entity for non-shared environments. All virtual routers will failover as a group, and cannot failover individually. As members of a group, all virtual routers on the switch (and therefore the switch itself), will be in either a master or backup state. Characteristics of a Switch-Based VRRP Group characteristics of a switch-based VRRP group: The following are
When enabled, all virtual routers behave as one entity, and all group settings override any individual virtual router settings or service-based vrgroup settings. All individual virtual routers, once the switch-based VRRP group is enabled, assume the groups tracking and priority. When one member of a switch-based VRRP group fails, the priority of the group decreases, and the state of the entire switch changes from Master 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 still process trafc addressed to that virtual server IP address. Filtering is also still functional. Only trafc addressed to virtual server routers is not processed. Each VRRP advertisement can include up to 1024 addresses. All virtual routers are advertised within the same packet, conserving processing and buffering resources. Note: The switch-based virtual router group cannot be used for active-active congurations or any other conguration that requires shared interfaces.
Command The switch-based VRRP group is congured by using the following command:
>> Main# /cfg/l3/vrrp/group ena
.
Note: For more information on using switch-based VRRP groups with hot-standby, see "Hot-Standby Conguration" (page 541).
Tracking VRRP Router Parameters

Nortel Application Switch Operating System supports a tracking function that dynamically modies the priority of a VRRP router based on its current state. The objective of tracking is to have, whenever possible, the master bidding processes for various virtual routers in a LAN converge on the same switch. Tracking ensures that the selected switch is the one that offers optimal network performance. For tracking to have any effect on virtual router operation, preemption must be enabled. Note: Tracking only affects hot standby and active-standby congurations. It does not have any effect on active-active sharing congurations. Nortel Application Switch Operating System can track the parameters outlined in "VRRP Tracking Parameters" (page 518).
VRRP Tracking Parameters Parameters and Commands Number of virtual routers in master mode on the switch. Description Useful for ensuring that traffic for any particular client/server pair is handled by the same switch, increasing routing and load-balancing efficiency. This parameter influences the VRRP routers priority in both virtual interface routers and virtual server routers.
To enable tracking on vrs: /cfg/l3/vrrp/vr <#> /track/vrs/ena
To change the virtual router increm ent: /cfg/l3/vrrp/track/vrs Note: The vrs parameter is not available <[0-254]> for tracking for a service based virtual router group (vrgroup). Helps elect the virtual routers with the most available routes as the master. (An IP interface is considered active when there is at least one active port on the same VLAN.) This parameter influences the VRRP routers priority in both virtual interface routers and virtual server routers.
Number of IP interfaces active on the switch.
To enable tracking on IP interfaces: /cfg/l3/vrrp/vr /track/ifs <#> /ena To change the interfaces tracking increment: /cfg/l3/vrrp/trac k/ifs <[0-254]>
.
Parameters and Commands Number of active ports on the same VLAN.
Description Helps elect the virtual routers with the most available ports as the master. This parameter influences the VRRP routers priority in both virtual interface routers and virtual server routers.
To enable tracking on ports on the same VLAN: /cfg/l3/vrrp/vr /track/port <#> /ena To change the ports tracking increment: /cfg/l3/vrrp/trac k/ports <[0-254]>
Number of physical switch ports that Helps elect the main Layer 4 switch as have active Layer 4 processing on the master. This parameter influences the switch. the VRRP routers priority in both virtual interface routers and virtual server routers. To enable tracking on Layer 4 ports: /cfg/l3/vrrp/vr/track /l4pts/ena To change the Layer 4 ports tracking increment: /cfg/l3/vrrp/track/l4pts <[0-254]> Helps elect the switch with the largest server pool as the master, increasing Layer 4 efficiency. This parameter influences the VRRP routers priority in virtual server routers only.
Number of healthy real servers behind the virtual server IP address that is the same as the IP address of the virtual server router on the switch. /cfg/l3/vrrp/track/reals In networks where the Hot Standby Router Protocol (HSRP) is used for establishing router failover, the number of Layer 4 client-only ports that receive HSRP advertisements. /cfg/l3/vrrp/track/hsrp Tracking HSRP on VLAN. /cfg/l3/vrrp/track/hsrv
Helps elect the switch closest to the master HSRP router as the master, optimizing routing efficiency. This parameter influences the VRRP routers priority in both virtual interface routers and virtual server routers.
Hot Standby Router on VLAN (HSRV) is used in VLAN-tagged environments. Enable this option to increment only that VRRP instance that is on the same VLAN as the tagged HSRP master flagged packet. This command is disabled by default.
.
Each tracked parameter is associated with a user-congurable weight. As the count associated with each tracked item increases (or decreases), so does the VRRP routers priority, subject to the weighting associated with each tracked item. If the priority level of a backup is greater than that of the current master, then the backup can assume the role of the master. See "Tracking Virtual Routers" (page 548) for an example on how to congure the switch for tracking VRRP priority.
Tracking Service-Based Virtual Router Groups

Nortel Application Switch Operating System also supports a tracking function that dynamically modies the priority of a service-based virtual router group (vrgroup), which contains one or more virtual routers. Once a VRRP router is added to a vrgroup, the groups tracking conguration overrides an individual VRRP routers tracking. Nortel Application Switch Operating System allows the independent failover of individual virtual router groups on the same switch. When Web hosting is shared between two or more customers on a single VRRP switch, several virtual routers can be grouped to serve the high availability needs of a specic customer. Each vrgroup is treated as a single entity regardless of how many virtual routers belong to the vrgroup. When switch tracks a vrgroup, it measures the resources contained in this group, and updates all members of the vrgroup with the same priority. When any of the tracked parameters changes the priority for one of the virtual routers belonging to the vrgroup, then the entire vrgroup will failover. Tracking can be congured for each vrgroup, with the same resources tracked on individual virtual routers ("VRRP Tracking Parameters" (page 518)). The only resource that cannot be tracked on a vrgroup basis is the number of virtual routers (vrs). If failover occurs on a customer link, only the group of virtual routers associated with that customers vrgroup will failover to the backup switch. Other vrgroups congured for other customers do not failover. For example, if a vrgroup is congured to track on ports, a port failure will decrease the priority of the vrgroup. The lowered priority will cause this vrgroup to failover to its equivalent vrgroup on the other switch. See "Service-Based Virtual Router Groups" (page 550) for an example on how to congure the switch for tracking VRRP priority.
.
VRRP Holdoff Timer

When an application switch becomes the VRRP master at power up or after a failover operation, it may begin to forward data trafc before the connected gateways or real servers are operational. The application switch may create empty session entries for the coming data packets and the trafc cannot be forwarded 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 state during the initialization.The VRRP holdoff timer can be set from 0 to 255 seconds. The VRRP master will wait the specied number of seconds before forwarding trafc to the default gateway and real servers. The VRRP holdoff timer is set with the following command:
>> Main# /cfg/l3/vrrp/holdoff <0-255 seconds>
IPv6 VRRP Support

Nortel Application Switch Operating System 24.0 supports the usage of IPv6 with VRRP. This section describes this support. For conceptual information about IPv6, refer to "IPv6" (page 123). IPv6 hosts on a VLAN usually learn about other routers by receiving IPv6 Routing Advertisements. The Routing Advertisements are multicast periodically at a rate such that the hosts usually learn about the other routers within a few minutes. They are not sent frequently enough for the hosts to rely on to detect router failures. IPv6 hosts can also use the Neighbor Discovery mechanism to detect router failure by sending unicast Neighbor Solicitation messages to the other routers. By using the default setting, it will take a host about 38 seconds to learn that a router is unreachable before it switches to another router. IPv6 VRRP support provides a much faster mechanism for the switch over to a backup router than can be obtained using standard Neighbor Discovery procedures. Using IPv6 VRRP support, a backup router can take over the responsibility of virtual router master within seconds. This is done without any interaction with the hosts and a minimum amount of trafc in the subnet. To accomplish this, two types of addresses are used in IPv6 that faciliate VRRP support: Step 1 Action Unicast address The Global Unicast address is an address that is accessible and identiable globally.
.
The Link-local Unicast address is an address used to communicate with neighbors on the same link. The source address of an IPv6 VRRP packet is set to the IPv6 Link-local address of the transmission interface.
Multicast address The IPv6 Multicast address is an identier for a group interface. IPv6 VRRP support has an IPv6 link-local scope multicast address assigned by IANA. This multicast address follows the format FF02:0:0:0:0:0:XXXX:XXXX. The destination address of the IPv6 packet is set to this link-local scope multicast address. Routers must not forward a datagram with this destination address regardless of its Hop Limit setting. End
IPv6 VRRP packets

IPv6 VRRP packets differ in some aspects to VRRP implemented in an IPv4 network. The key differences are as follows: The Version eld species the VRRP protocol version. In IPv4 packets this value is 2 and in IPv6 packets this value is 3. The Authentication Type eld is not present in IPv6 packets. This eld is used in IPv4 to identify the authentication method in use. The Advertisement Interval eld is a 12-bit eld that indicates the advertisement interval in centiseconds (1/100 second). This is an 8-bit eld in IPv4 that species this interval in seconds. Note: It is recommended that the default of 100 (1 second) or above is used to avoid a high load on the switch management CPU. The Hop Limit eld is used to track how many nodes have forwarded the packet. The eld value is decremented by one for each that forwards the packet. VRRP routers are instructed to discard IPv6 VRRP packets that do not have a Hop Limit value of 255. The Next Header eld is used to identify the type of protocol immediately following the IPv6 header. The IPv6 Next Header assigned by IANA for VRRP is 112. The Neighbor Discovery protocol replaces IPv4 ARP, ICMP Router Discovery, and ICMP Redirection. Neighbor Discovery enables nodes (hosts and routers) to determine the link-layer address of a neighbor on the same network and to detect any changes in these addresses. It also
.
enables a router to advertise its presence and address prex to inform hosts of a better next hop address to forward packets.
IPv6 VRRP conguration

To enable IPv6 VRRP support perform the following two tasks: Note: The VRRP3 VRID for IPv6 VRRP conguration has a range of 1 to 255. Step 1 Action Enable IPv6 support on the virtual router. Before VRRP will support IPv6, it must be enabled on the virtual router. This is accomplished by doing the following: Change the IP version supported by the virtual router. Use the command /cfg/l3/vrrp/vr <virtual router number> /ipver v6 to congure the virtual router for IPv6 support. Assign an IPv6 address to the vitural router. Use the command address <IPv6_address> to assign an IPv6 address to the virtual router. 2 Enable IPv6 support on the virtual router group. After IPv6 support has been enabled on the virtual router, enable it on the virtual router group. This is accomplished by using the /cfg/l3/vrrp/group/ipver v6 command. End
IPv6 VRRP information

Conguration and statistical information can be obtained from the switch about IPv6 VRRP support. The command /info/l3/vrrp displays information about both IPv4 and IPv6 VRRP conguration. The output for this command is illustrated below.
.
>> Main# /info/l3/vrrp VRRP information: 9: vrid 9, 2005:0:0:0:0:0:10:9 if 9, renter, prio 101, master 10: vrid 10, 10.10.10.50, if 1, renter, prio 101, master 20: 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 the current IPv6 VRRP conguration. The output for this command is illustrated below.
>> Main# /stat/l3/vrrp6 -----------------------------------------------------------VRRP6 statistics: vrrp6InAdvers: 7 vrrp6BadAdvers: 0 vrrp6OutAdvers: 86801 vrrp6BadVersion: 0 vrrp6BadVrid: 0 vrrp6BadAddress: 0 vrrp6BadData: 0 vrrp6BadInterval: 0
Failover Methods and Congurations

Nortel Application Switches offer exibility in implementing redundant congurations. This section discusses a few of the more useful and easily deployed congurations: "Active-Standby Redundancy" (page 525) "Active-Standby VSR Conguration in a Non-Shared Environment" (page 526) "Active-Active Redundancy" (page 529) "Active-Active VIR and VSR Conguration" (page 529) "Active-Active Server Load Balancing Conguration" (page 531) "Hot-Standby Redundancy" (page 539) "Hot-Standby Conguration" (page 541) "Tracking Virtual Routers" (page 548) "Service-Based Virtual Router Groups" (page 550)
.
Nortel Application Switch Operating System high availability congurations are based on VRRP. TheNortel Application Switch Operating System implementation of VRRP includes proprietary extensions to accommodate Layer 4 though Layer 7 application switching features. The Nortel Application Switch Operating System implementation of VRRP supports three modes of high availability: Active-Standby Active-Active Hot-Standby
The rst mode, active-standby, is based on standard VRRP, as dened in RFC 2338. The second and third modes, active-active and hot-standby, are based on proprietary Nortel Application Switch Operating System extensions to VRRP. Each mode is described in detail in the following sections.
Active-Standby Redundancy
In an active-standby conguration, shown in "Active-Standby VRRP Routers" (page 525), two application switches are used. Both switches support active trafc but are congured so that they do not simultaneously support 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 switch fails, the remaining switch takes over processing for all services. The backup switch may forward Layer 2 and Layer 3 trafc, as appropriate. Note: In an active-standby conguration, the same service cannot be active 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. Application Switch 2 is master for the virtual interface router with VRID = 2 and backup for the virtual interface router with VRID = 1. In this manner, both routers can actively forward trafc at the same time but not for the same interface.
Active-Standby Conguration VRID = 1 Application Switch 1 Router #1 = Master Active VR IP address = 205.178.13.226 MAC address = 00.00.5E.00.01.01 Priority = 255 IP interface = 205.178.13.226 Router #2 = Backup Standby VR IP address = 205.178.13.226 MAC address = 00.00.5E.00.01.01 Priority = 100 IP interface = 205.178.13.225 VRID = 2 Router #1 = Backup Standby VR IP address = 205.178.13.240 MAC address = 00.00.5E.00.01.02 Priority = 100 IP interface = 205.178.13.239 Router #1 = Master Active VR IP address = 205.178.13.240 MAC address = 00.00.5E.00.01.02 Priority = 255 IP interface = 205.178.13.240
Application Switch 2
Active-Standby VSR Conguration in a Non-Shared Environment

"Non-Shared Active-Standby High Availability Conguration" (page 527) shows an example conguration where two Nortel Application Switches are used as VRRP routers in an active-standby conguration, implementing a virtual server router. In this conguration, 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 congurations that cannot support sharing of interfaces at Layer 3 and Layer 4. This includes congurations where incoming packets will be seen by more than one switch, such as instances where a hub is used to connect the switches.
.
High Availability 527 Non-Shared Active-Standby High Availability Conguration
Although this example shows only two switches, there is no limit on the number of switches that can be used in a redundant conguration. It is possible to implement an active-standby conguration across all the VRRP-capable switches in a LAN. Each VRRP-capable switch in an active-standby conguration is autonomous. Switches in a virtual router need not be identically congured. To implement the active-standby example, perform the following switch conguration: Step 1 Action Congure the appropriate Layer 2 and Layer 3 parameters on both switches. This includes any required VLANs, IP interfaces, default gateways, and so on. If IP interfaces are congured, none of them should use the virtual server IP address described in Step 3. 2 Dene all lters required for your network conguration. Filters may be congured on one switch and synchronized with settings on the other switch (see Step 5 below). 3 Congure all required SLB parameters on application switch 1. For the purposes of this example, assume that application switch 1 in "Non-Shared Active-Standby High Availability Conguration" (page 527) is congured in this step. Required Layer 4 parameters include a VIP = 205.178.13.226 and one real server group with four real servers, RIP = 10.10.10.101, RIP = 10.10.10.102, RIP = 10.10.10.103, and RIP = 10.10.10.104. 4 Congure the VRRP parameters on application switch 1.
.
This conguration includes VRID = 2, VIP = 205.178.13.226 and the priority. Enable tracking on the virtual router, and set the parameters appropriately (refer to "Tracking Virtual Routers" (page 548)). Make sure to disable sharing. 5 Synchronize the SLB and VRRP congurations by synchronizing the conguration from application switch 1 to application switch 2. Use the /oper/slb/sync command (see "Conguring VRRP Peers for Synchronization" (page 578)). 6 Change the real servers in the application switch 2 conguration to RIP = 10.10.11.101, RIP = 10.10.11.102, RIP =10.10.11.103, and RIP = 10.10.11.104. Adjust application switch 2s priority (see "Tracking Virtual Routers" (page 548)). In this example, with application switch 1 as the master, if a link between application switch 1 and a server fails, the server will fail health checks and be taken out of the load-balancing algorithm. If tracking is enabled and is congured to take into account the number of healthy real servers for the Virtual Routers VIP address, application switch 1s priority will be reduced. If it is reduced to a value lower than application switch 2s priority, then application switch 2 will assume the role of master. In this case, all active connections serviced by application switch 1s virtual server IP address are severed. If the link between application switch 1 and its Internet router fails, the protocol used to distribute trafc between the routers, for example, Open Shortest Path First (OSPF), will reroute trafc to the other router. application switch 2 (backup) will act as a Layer 2/3 switch and forward all trafc destined to the virtual server IP address to application switch 1. If the entire application switch 1 (master) fails, the protocol used to distribute trafc between the routers, such as OSPF, will reroute trafc to application switch 2. Application switch 2 (backup) detects that the master has failed because it will stop receiving advertisements. The backup then assumes the masters responsibility of responding to ARP requests and issuing advertisements. End
.
Active-Active Redundancy
Nortel Application Switch Operating System has extended VRRP to include virtual servers, allowing full active/active redundancy between its Layer 4 switches. In an active-active conguration, shown in "Active-Active High Availability Conguration" (page 529), both switches can process trafc for the same service at the same time. Both switches share interfaces at Layer 3 and Layer 4, meaning that both switches can be active simultaneously for a given IP routing interface or load-balancing virtual server (VIP).
Active-Active VIR and VSR Conguration

In "Active-Active High Availability Conguration" (page 529), two Nortel Application Switches are used as VRRP routers in an active-active conguration implementing a virtual server router. As noted earlier, this is the preferred redundant conguration.
Active-Active High Availability Conguration
Although this example shows only two switches, there is no limit on the number of switches used in a high availability conguration. It is possible to implement an active-active conguration and perform load sharing between all of the VRRP-capable switches in a LAN. In this conguration, when both switches are healthy, the load balanced packets are sent to the virtual server IP address, resulting in higher capacity and performance than when the switches are used in an active-standby conguration. The switch on which a frame enters the virtual server router is the one that processes 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 no requirement that the switches in a virtual router be identically congured. Different switch models with different numbers of ports and different enabled services may be used in a virtual router.
.
To implement this example, congure the switches as follows: Step 1 Action Congure the appropriate Layer 2 and Layer 3 parameters on both switches. This conguration includes any required VLANs, IP interfaces, default gateways, and so on. If IP interfaces are congured, none of them should use the VIP address described in Step 3. 2 Dene all lters required for your network conguration. Filters may be congured on one switch and synchronized with the settings on the other switch (see Step 6, below). 3 Congure 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 Conguration" (page 529)) is congured in this step. Congure a VIP = 205.178.13.226 and one real server group with two real servers: RIP = 10.10.10.103 should be congured as a backup server to RIP = 10.10.10.101. RIP = 10.10.10.104 should be congured as a backup server to RIP = 10.10.10.102. Note: In this conguration, each servers backup is attached to the other switch. This ensures that operation will continue if all of the servers attached to a switch fail. 4 Congure the VRRP parameters on the switch. Congure 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 leave switch 2 with its default priority of 100. 6 Synchronize the SLB and VRRP congurations by pushing the conguration 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 in application switch 2s conguration. RIP = 10.10.10.101 should be congured as a backup server to RIP = 10.10.10.103.
.
RIP = 10.10.10.102 should be congured as a backup server to RIP = 10.10.10.104. In this conguration, if a link between a switch and a server fails, the server will fail health checks and its backup (attached to the other switch) will be brought online. If a link between a switch and its Internet router fails, the protocol used to distribute trafc between the routers (for example, OSPF) will reroute trafc to the other router. Since all trafc 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 failure because it will stop receiving advertisements. The backup will assume the masters responsibility of responding to ARP requests and issuing advertisements. Be cautious before setting the maximum connections (maxconn) metric in this conguration. The maxcon number is not shared between switches. Therefore, if a server is used for normal operation by one switch and is activated simultaneously as a backup by the other switch, the total number of possible connections to that server will be the sum of the maximum connection limits dened for it on both switches. End
Active-Active Server Load Balancing Conguration

In this example, you set up four virtual servers each load balancing two servers providing one service (for example, HTTP) per virtual server. You are load balancing HTTP, HTTPS, POP3, SMTP, and FTP. Each protocol is load balanced via a different virtual server. You could load balance all of these services on one VIP, but in this example, four distinct virtual servers are used to illustrate the benets of active/active failover. Set up one switch, dump out the conguration script (also called a text dump), edit it, and dump the edited conguration into the peer switch. Note: Conguring the switch for active-active failover should take no longer than 15 minutes to complete. You can use either theNortel Application Switch Operating System Browser-Based Interface (BBI) or the Command Line Interface (CLI) for conguration. Task 1: Background Conguration Step 1 Action Dene the IP interfaces.
.
The switch will need an IP interface for each subnet to which it will be connected so it can communicate with devices attached to it. Each interface will need to be placed in the appropriate VLAN. In our example, Interfaces 1, 2, 3, and 4 will be in VLAN 2 and Interface 5 will be in VLAN 3. Note: On Nortel Application Switches, you may congure more than one subnet per VLAN. To congure the IP interfaces for this example, enter the following commands from the CLI:
>> Main# /cfg/l3/if 1 >> IP Interface 1 # addr 10.10.10.10 >> IP Interface 1 # vlan 2 >> IP Interface 1 # ena (Select IP interface 1) (Assign IP address for the interface) (Assign VLAN for the interface) (Enable IP interface 1)
Repeat the commands for each interface listed below: 2 IF 220.10.10.10 IF 330.10.10.10 IF 440.10.10.10 IF 5200.1.1.10
Dene the VLANs. In this conguration, 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 downstream switches, toward the servers).
>> Main# /cfg/l2/vlan <VLAN number> >> vlan 3 # add <port number> >> vlan 3 # ena (Select VLAN 3) (Add a port to the VLAN membership) (Enable VLAN 3)
Repeat this command for the second VLAN. VLAN 3 - IF 5physical ports connected to upstream switches. VLAN 2 - IFs 1,2,3,4physical ports connected to downstream switches.
.
Disable Spanning Tree.

>> Main# /cfg/l2/stg 1 >> Main# /cfg/l2/stg 1/off >> Main# /cfg/l2/stg 1/apply (Select the STP Group number) (Disable STP) (Make your changes active)
Enable IP forwarding. IP forwarding is enabled by default. Make sure IP forwarding is enabled if the virtual server IP addresses and real server IP addresses are on different subnets, or if the switch is connected to different subnets and those subnets need to communicate through the switch. If you are in doubt as to whether or not to enable IP forwarding, enable it. In this example, the virtual server IP addresses and real server IP addresses are on different subnets, so enable this feature using the following command:
>> Main# /cfg/l3/frwd/on (Enable IP forwarding)
End
Task 2: SLB Conguration Step 1 Action Dene the Real Servers. The real server IP addresses are dened and put into four groups, depending on the service they are running. Notice that RIPs 7 and 8 are on routable subnets in order to support passive FTP. For each real server, you must assign a real server number, specify its actual IP address, and enable the real server. For example:
>> Main# /cfg/slb/real 1 >> Real server 1 # rip 10.10.10.5 >> Real server 1 # ena (Server A is real server 1) (Assign Server A IP address) (Enable real server 1)
Repeat this sequence of commands for the following real servers: RIP 210.10.10.6/24
.
RIP 320.10.10.5/24 RIP 420.10.10.6/24 RIP 530.10.10.5/24 RIP 630.10.10.6/24 RIP 7200.1.1.5/24 RIP 8200.1.1.6/24
Dene the real server groups, adding the appropriate real servers. This combines the three real servers into one service group:
>> Real server 8 # /cfg/slb/gr oup 1 >> Real server group 1# add 1 >> Real server group 1# add 2 (Select real server group 1) (Add real server 1 to group 1) (Add real server 2 to group 1)
Repeat this sequence of commands for the following real server groups: 3 Group 2Add RIP 3 and 4 Group 3Add RIP 5 and 6 Group 4Add RIP 7 and 8
Dene the virtual servers. After dening the virtual server IP addresses and associating them with a real server group number, you must tell the switch which IP ports/services/sockets you want to load balance on each VIP. You can specify the service by either the port number, service name, or socket number.
>> Real server group 4 # /cfg/slb/virt 1 >> Virtual server 1 # vip 200.200.200.100 >> Virtual Server 1 # service 80 >> Virtual server 1 http Service # group 1 >> Virtual server 1 # ena (Select virtual server 1) (Assign a virtual server IP address) (Assign HTTP service port 80) (Associate virtual port to real group) (Enable the virtual server)
.
Repeat this sequence of commands for the following virtual servers: VIP 2200.200.200.101 will load balance HTTPS (Port 443) to Group 2 VIP 3200.200.200.102 will load balance POP/SMTP (Ports 110/25) to Group 3 VIP 4200.200.200.104 will load balance FTP (Ports 20/21) to Group 4
Dene the client and server port states. Dening a client port state tells that port to watch for any frames destined for the VIP and to load balance them if they are destined for a load-balanced service. Dening a server port state tells the port to the do the remapping (NAT) of the real server IP address back to the virtual server IP address. Note the following: The ports connected to the upstream switches (the ones connected to the routers) will need to be in the client port state. The ports connected to the downstream switches (the ones providing fan out for the servers) will need to be in the server port state.
Congure the ports, using the following sequence of commands:

>> Virtual server 4# /cfg/slb/p ort 1 >> SLB port A1 # client ena >> SLB port A1 # /cfg/slb/port 2 >> SLB port A2 # server ena (Select physical switch port 1) (Enable client processing on port 1) (Select physical switch port 2) (Enable server processing on port 2)
End
Task 3: Virtual Router Redundancy Conguration Step 1 Action Congure virtual routers 2, 4, 6, and 8.
.
These virtual routers will have the same IP addresses as the virtual server IP address. This is what tells the switch that these are virtual service routers (VSRs). In this example, Layer 3 bindings are left in their default conguration, which is disabled. Congure a virtual router using the following sequence of commands:
>> Virtual server 4 # /cfg/l3/vrrp/vr 2 >> Virtual router 2 # vrid 2 >> Virtual router 2 # addr 200.200.200.100 >> Virtual router 2 # if 5 >> Virtual router 2 # ena (Select virtual router 2) (Set virtual router ID) (Assign virtual router IP address) (Assign virtual router interface) (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)Address 200.200.200.101 VR 6 - VRID 6 - IF 5 (associate with IP interface #5)Address 200.200.200.103 VR 8 - VRID 8 - IF 5 (associate with IP interface #5)Address 200.200.200.104
Congure virtual routers 1, 3, 5, and 7. These virtual routers will act as the default gateways for the servers on each respective subnet. Because these virtual routers are survivable next hop/default gateways, they are called virtual interface routers (VIRs). Congure each virtual router listed below, using the sequence of commands in Step 1. VR 1 - VRID 1 - IF 1 (associate with IP interface 1)Address 10.10.10.1 VR 3 - VRID 3 - IF 2 (associate with IP interface 2)Address 20.10.10.1 VR 5 - VRID 5 - IF 3 (associate with IP interface 3)Address 30.10.10.1 VR 7 - VRID 7 - IF 4 (associate with IP interface 4)Address 40.10.10.1
Set the renter priority for each virtual router.
.
Since you want Switch 1 to be the master router, you need to bump the default virtual router priorities (which are 100 to 101 on virtual routers 1-4) to force switch 1 to be the master for these virtual routers. Use the following sequence of commands:
>> Virtual server 4 # /cfg/l3/vrrp/vr 1 >> Virtual router 1 # prio 101 (Select virtual router 1) (Set virtual router priority)
Apply this sequence of commands to the following virtual routers, assigning each a priority of 101: 4 VR 2Priority 101 VR 3Priority 101 VR 4Priority 101
Congure 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 router 1, electing the virtual router with the most available ports as the master router. Repeat this command for the following virtual routers: n VR 2 - Track l4ptsVR 6 - Track l4pts n VR 3 - Track l4ptsVR 7 - Track l4pts n VR 4 - Track l4ptsVR 8 - Track l4pts
Switch 1 conguration is complete. End
Task 4: Conguring Switch 2 Use the following procedure to congure Switch 2: Step 1 Action Dump the conguration script (text dump) of Switch 1 using either 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 to the 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, Flow Control: None.
HyperTerminal Only the Baud Rate and Flow Control options need to be changed from the default settings. Once you connect to the switch, start logging your session in HyperTerminal (transfer/capture text). Save the le as "Customer Name" Switch 1, then type the following 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 le that was created and change the following: Delete anything above Script Start. Delete the two lines directly below Script Start. These two lines identify the switch from which the dump was taken and the date and time. If these two lines are left in, it will confuse Application Switch 2 when you dump in the le. Change the last octet in all the IP interfaces from .10 to .11. Find this line in the le:
/cfg/l3/if 1/addr 10.10.10.10
Simply delete the 0 and put in a 1. Be sure to do this for all the IP interfaces or duplicate IP addresses will be present in the network. Change the virtual router priorities. Virtual routers 14 need to have their priority set to 100 from 101, and virtual routers 5-7 need to have their priorities set to 101 from 100. You can nd this in the line /cfg/l3/vrrp/vr 1/vrid 1/if 1/prio 101.
.
Scroll to the bottom of the text le and delete anything past Script End. Save the changes to the text le as <Customer Name> Switch 2. 3 Move your serial cable to the console port on the second switch. Any conguration on it needs to be deleted by resetting it 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 because the switch will prompt you if you want to use the step-by-step conguration process. When it does, respond: No. Note: After completing the setup you cannot proceed further without conguring the ports. To congure ports enter y or enter n to ignore. 4 In HyperTerminal, go to transfer/send text le and send the Switch 2 text le created in Step 2. The conguration will dump into the switch. Simply type apply , then save. When you can type characters in the terminal session again, reboot the switch ( /boot/reset ). End
Hot-Standby Redundancy
In a hot-standby conguration, Spanning Tree Protocol (STP) is not needed to eliminate bridge loops. This speeds up failover when a switch fails. The standby switch blocks all ports congured as standby ports, whereas the master switch enables these same ports. Consequently, on a given switch, all virtual routers are either master or backup; they cannot change state individually. In a hot-standby conguration, two or more switches provide redundancy for each other. One switch is elected master and actively processes Layer 4 trafc. The other switches (the backups) assume the master role should the master fail. The backups may forward Layer 2 and Layer 3 trafc as appropriate.
Switch-Centric Virtual Router Group

Hot-standby requires that all virtual routers on a switch failover together as a group. 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 virtual routers will failover as a group, and cannot failover individually. As members of 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 States

When a switch changes from master to backup, it does not process any trafc destined to the virtual server routers congured on that switch. However, Layer 4 processing is still enabled. A switch that has become the backup can still process trafc addressed to its virtual server IP address. Filtering is also still functional. Each VRRP advertisement can include up to 1024 addresses, and is therefore is not limited to a single virtual router IP address. A VRRP advertisement packet contains all virtual routers are advertised in the same packet, thus conserving processing and buffering resources.
Hot-Standby and Inter-Switch Port States

The second part of the solution involves introducing two additional Layer 4 port states, hot-standby and inter-switch: Links that attach to the standby switch must be congured as hot standby using:
>> Main# /cfg/slb/port x/hotstan
Note: All ports with hot standby enabled must be connected to another device. Links that are used by VRRP to deliver updates are congured as intersw, or Inter-switch links (not to be confused with Ciscos ISL). The command to congure one or more ports as interswitch links is:
>> Main# /cfg/slb/port <port number> /intersw
Note: A port cannot be congured to support both hot-standby and interswitch link. The hot-standby switch listens to the masters VRRP updates. After an interval period has expired without receiving a update, the backup switch will take over. The forwarding states of hot-standby ports are controlled
.
much like the forwarding states of the old hot-standby approach. Enabling hot-standby on a switch port allows the hot-standby algorithm to control the forwarding state of the port. If a switch is master, the forwarding states of the hot-standby ports are enabled. If a switch is backup, the hot-standby ports are blocked from forwarding or receiving trafc. When the hotstan option (/cfg/slb/port x/hotstan) is enabled and all hot-standby ports have link, the virtual router groups priority is automatically incremented by the track other virtual routers value. This action allows the switches to failover when a hot-standby port loses link. Other enabled tracking features only have effect when all hot-standby ports on a switch have link. The default virtual routers tracking value is two seconds. Keep in mind that this is an automatic process that cannot be turned off. Note: The VRRP hot-standby approach does not support single-link failover. If one hot-standby port loses link, the entire switch must become master to eliminate loss of connectivity. The forwarding states of non-hot-standby ports are not controlled via the hot-standby algorithm, allowing the additional ports on the switches to provide added port density. The client ports on both switches should be able to process or forward trafc to the master switch. The inter-switch port state is only a place holder. Its presence forces the user to congure an inter-switch link when hot-standby is globally enabled and prohibits the inter-switch link from also being a hot-standby link for VRRP advertisements. These advertisements must be able to reach the backup switch.
Hot-Standby Conguration
A hot-standby conguration allows all processes to failover to a backup switch if any type of failure should occur. The primary application for hot-standby redundancy is to avoid bridging loops when using the Spanning Tree Protocol (STP), IEEE 802.1d. VRRP-based hot-standby supports the default Spanning Tree only. It does not support multiple Spanning Trees. "Hot-Standby Conguration" (page 542) shows a classic network topology, designed with redundancy in mind. This topology contains bridging loops that would require the use of STP. In the typical network, STP failover time is 45-50 seconds, much longer than the typical failover rate using VRRP only. Note: To use hot-standby redundancy, peer switches must have an equal number of ports.
.
542 Part 3: Application Switching Fundamentals Hot-Standby Conguration
The key to hot-standby is that the interswitch link (the link between switches), does not participate in STP, so there are no loops in the topology (see"Hot-Standby Conguration" (page 542)). User has to disable STP globally to use VRRR Hot-Standby Scenario. The switch will have failover times similar to what would be the case with VRRP. Note: While the port usage in this example assumes use of a Nortel Application Switch 2424, you may adapt this example according the ports available on your particular Nortel Application Switch model. Task 1: Congure Layer 2 and Layer 3 Parameters on Switch 1 example assumes you have already congured SLB parameters. This
Perform the following procedure to congure Layer 2 and 3 parameters on Switch 1: Step 1 Action On Switch 1, congure the external ports into their respective VLANs as shown in "Hot-Standby Conguration" (page 542) .
>> Main# /cfg/l2/vlan 1 >> VLAN 1# ena >> VLAN 1# name servers >> VLAN 1# /cfg/l2/vlan 192 >> VLAN 192# ena >> VLAN 192# name clients >> VLAN 192# def 25 26 (Name VLAN 1 for server traffic) (VLAN 192 is for client traffic) (Enable the VLAN) (Name VLAN 192 for client traffic) (Add the ports 25, 26 to client VLAN)
.
>> VLAN 192# /cfg/l2/vlan 172 >> VLAN 172# ena >> VLAN 172# name ISL >> VLAN 172# def 3
(VLAN 172 is for the Interswitch Link) (Enable the VLAN) (Name VLAN 172 for ISL) (Add port 3 to ISL VLAN)
Trunk the ports you congured for the client VLAN.

>> Main # /cfg/l2/trunk 1 >> Trunk group 1# ena >> Trunk group 1# add 25 26 (Select Trunk Group 1) (Enable the Trunk Group) (Add the external ports to the trunk)
Turn off Spanning Tree.

>> Main # /cfg/l2/stg 1/off >> Spanning Tree Group 1# apply >> Spanning Tree Group 1# save (Disable STG group) (Make your changes active) (Save for restore after reboot)
Congure the IP addresses for each VLAN.

>> Main # /cfg/l3/if 1 >> IP Interface 1# ena (IP Interface 1: Servers) (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: Interswitch Link)
>> IP Interface 3# ena >> IP Interface 3# addr 172.16.2.251 >> IP Interface 3# vlan 172
End
.
Task 2:Congure Virtual Router Redundancy Perform the following tasks to congure Virtual Router redundancy: Step 1 Action Congure virtual routers for the server, client, and Interswitch Link trafc.
>> Main# /cfg/l3/vrrp/vr 1 >> >> >> >> VRRP VRRP VRRP VRRP Virtual Virtual Virtual Virtual Router Router Router Router 1# 1# 1# 1# (Virtual router for server) ena vrid 1 if 1 addr 10.0.1.250 (Virtual router for client) ena vrid 2 if 2 addr 192.168.1.250 (Virtual router for Interswitch Link)
>> Main #/cfg/l3/vrrp/vr 2 >> >> >> >> VRRP VRRP VRRP VRRP Virtual Virtual Virtual Virtual Router Router Router Router 2# 2# 2# 2#
>> Main # /cfg/l3/vrrp/vr 3 >> >> >> >> VRRP VRRP VRRP VRRP Virtual Virtual Virtual Virtual Router Router Router Router 3# 3# 3# 3#
ena vrid 3 if 3 addr 172.16.2.250
From the VRRP menu, enable VRRP group mode and hot-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 >> VRRP Virtual Router Group# save (Make your changes active) (Save for restore after reboot)
Set VRRP tracking for the ports. If a link on any of the connected ports goes down, the switch will decrease in VRRP priority and the backup switch will take over as the master.
.
>> Main # /cfg/l3/vrrp >> VRRP Virtual Router Group# vrid 254 >> VRRP Virtual Router Group# prio 101 (Set priority at 101 for Master switch)
>> VRRP Virtual Router Group# track/ports ena
Setup the peer switch to receive synchronization. Make sure to disable synchronization of VRRP priorities; the peer switch will assume its own priority based on the VRRP election process and should not acquire the VRRP priority from the Master switchs conguration. If you will be conguring real servers for VRRP hotstandby, make sure to enable synchronization of real server conguration as well.
>> Main # /cfg/slb/sync/prios d >> Config Synchronization# peer 1/ena >> Peer Switch 1# addr 172.16.2.252 (Do not synchronize VRRP priorities to the peer switch) (Enable the synch. peer switch) (Set IP address of switch 1)
From the SLB menu, enable a hot-standby link on the Layer 4 ports; 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
Apply and save changes to the conguration.

End
Task 3: Prepare a Conguration Script for Switch 2 Use the following procedure to dump the conguration script (text dump) from Switch 1. This conguration will be modied and loaded onto Switch 2.
.
Step 1
Action Dump the switch conguration 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 le. The rst and last lines of the le should show the following:
script start "Nortel Application Switch 2424" 4 /**** DO NOT EDIT THIS LINE! (File must begin with this line)
/* 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#
Edit the text le that you just created as follows: Change all the IP interface addresses for switch 2; otherwise, you will 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 1 addr 10.0.1.252
Change the synchronization peer switch to use the IP address of 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 1 ena addr 172.16.2.251
Change the virtual router priority from 100 to 101this will indicate that switch 2 is the backup for now.
.
/c/l3/vrrp/group : prio 101
4 5
Save the changes to the text le as <CustomerName>_backup_cong and load it onto a TFTP server. Begin a Telnet session for the second switch. Delete any existing conguration on it by resetting it to factory settings, using the following command:
>> Main # /boot/conf factory/reset
Conrmation message appears. Enter y to save changes and restart enter n to ignore changes and cancel restart. You can tell if the switch is at factory default when you log on, because the switch will prompt you if you want to use the step-by-step conguration process. When it does, respond: No. 6 From the CLI, download the conguration script into the switch from 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 Switch 2 Synchronize Layer 4 parameters from Switch 1 to 2 using the following procedure: Step 1 Action On Switch 1, synchronize the VRRP, SLB, real server, and lter settings to the other switch (same ports). Switches peering with each other should have an equal number of ports.
.
>> Main# /oper/slb/sync NOTE: Use the "/c/slb/sync" menu to configure omitting sections of the configuration. Synchronizing VRRP, FILT, PORT, REAL and SLB configuration to 172.16.2.252 Confirm synchronizing the configuration to 172.16.2.252 [y/n]:y
On switch 2, apply and save the conguration changes. End
Tracking Virtual Routers

Tracking conguration largely depends on user preferences and network environment. Consider the conguration shown in "Non-Shared Active-Standby High Availability Conguration" (page 527). Assume the following 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 servers than application switch 2, then application switch 1 remains the master. This behavior is preferred because running one server down is less disruptive than bringing a new master online and severing all active connections in the process. If application switch 1 is the master and it has two or more active servers fewer than application switch 2, then application switch 2 becomes the master. If application switch 2 is the master, it remains the master even if servers are restored on application switch 1 such that it has one fewer or an equal number of servers. If application switch 2 is the master and it has one active server fewer than application switch 1, then application switch 1 becomes the master.
The user can implement this behavior by conguring the switch for tracking as follows: Step 1 2 Action Set the priority for application switch 1 to the default value of 100. Set the priority for application switch 2 to 96.
.
On both switches, enable tracking based on the number of virtual routers in master mode on the switch and set the value = 5. On both switches, enable tracking based on the number of healthy real servers behind the VIP address. The VIP address is the same as the IP address of the virtual server router on the switch. Set the value = 6. Initially, application switch 1 ("Non-Shared Active-Standby High Availability Conguration" (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 (4 active real servers * 6 per real server) = 120. If a server attached to application switch 1 fails, then application switch 1s priority will be reduced by 6 to 123. Since 123 is greater than 120 (application switch 2s priority), application switch 1 will remain the master. If a second server attached to application switch 1 fails, then application switch 1s priority will be reduced by 6 more to 117. Since 117 is less than 120 (application switch 2s priority), then application switch 2 will become the Master. At this point, application switch 1s priority will fall by 5 more and application switch 2s will rise by 5 because the switches are tracking how many masters they are running. So, application switch 1s priority will settle out at 112 and application switch 2s priority at 125. When both servers are restored to application switch 1, that switchs priority will rise by 12 (2 healthy real servers * 6 per healthy server) to 124. Since 124 is less than 125, application switch 2 will remain the master. If, at this point, a server fails on application switch 2, its priority will fall by 6 to 119. Since 119 is less than 124, application switch 1 will become the Master. Its priority will settle out at 129 (since its now the master) while application switch 2s priority will drop by 5 more to 114. You can see from this example that the users goals were met by the congured tracking parameters. Note: There is no shortcut to setting tracking parameters. The goals must rst be set and the outcomes of various congurations and scenarios analyzed to nd settings that meet the goals. End
.
Service-Based Virtual Router Groups

Service-based virtual router groups can be used for failover in either an active-active or active-standby conguration. In "Service-based Virtual Router Groups - Active-Standby Conguration" (page 550), two customers are sharing the same VRRP switches congured in Active-Standby conguration for VIP 1 and 2. Virtual routers 1, 2, 3, and 4 are dened on both switches as follows: Virtual routers 1 and 3 are virtual interface routersthey use the IP interface addresses. Virtual routers 2 and 4 are virtual service routersthey use the virtual server IP addresses.
Virtual router 1 on the master forwards the packets sent to the IP addresses associated with the virtual router and answers ARP requests for these IP addresses. The virtual router backup assumes forwarding responsibility for a virtual router should the current master fail. Virtual routers 1 and 2 are members of vrgroup 1 and virtual routers 3 and 4 are members of vrgroup 2.
Service-based Virtual Router Groups - Active-Standby Conguration
.
Conguration Example
In this example, if the interface or link to the real server fails for the vrgroup 1 on Application Switch 1, then all the VRs in vrgroup 1 change to the backup state. At the same time, all VRs in vrgroup 1 on Application Switch 2 change to the master state. Meanwhile, the VRs in vrgroup 2 continue to operate via Application switch 1. The separate real server groups provide segregation of services for each customer., so neither customers trafc interferes with the others. To implement the active-standby example with tracking of service-based virtual router groups, perform the following switch conguration. Step 1 Action Dene the IP interfaces. The switch will need an IP interface for each subnet to which it will be connected so it can communicate with devices attached to it. To congure the IP interfaces for this example, enter the following commands from the CLI:
>> Main# /cfg/l3/if 1 >> IP Interface 1 # addr 200.200.200.1 >> IP Interface 1 # ena (Select IP interface 1) (Assign IP address for the interface) (Enable IP interface 1)
Repeat the commands for the following interfaces: 2 IF 2: 205.178.13.2 IF 3: 200.200.200.3 IF 4: 205.178.13.4
Dene all lters required for your network conguration. Filters may be congured on one switch and synchronized with settings on the other switch.
Congure 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/ >> >> >> >> Real Real Real Real server server server server 1# 1# 2# 3# (Configure real servers)
rip 10.10.10.101 /cfg/slb/real 2/rip 10.10.10.102 /cfg/slb/real 3/rip 10.10.10.103 /cfg/slb/real 4/rip 10.10.10.104
.
>> Real server 3# /cfg/slb/grou p 1 >> Real server group 1# add 1 >> Real server group 1# add 2
(Select real server group 1) (Add real server 1 to group 1) (Add real server 2 to group 1)
>> Main # /cfg/slb/virt 1/vip 205.178.13.226 (Configure virtual server IP 1) >> Virtual server 1# ena >> Virtual server 1# service http >> Virtual server 1 http Service# group 1 >> Main # /cfg/slb/group 2 >> Real server group 1# add 3 >> Real server group 1# add 4 (Add real server 1 to group 1) (Add real server 2 to group 1) (Enable the virtual server) (Select the HTTP service menu) (Associate virtual port to real group) (Enable the virtual server) (Select the HTTP service port menu) (Associate virtual port to real group)
>> Main # /cfg/slb/virt 1/vip 205.178.13.300 >> Virtual server 1# ena >> Virtual server 1# service http >> Virtual server 1 http Service# group 2
Congure virtual interface routers 1 and 3, make sure to disable sharing. These virtual routers are assigned the same IP address as the IP interfaces congured in Step 1, thus telling the switch that these are virtual interface routers (VIRs). In this example, Layer 3 bindings are left in their default conguration, which is disabled. For an active-standby conguration, sharing is disabled.
>> Main # /cfg/l3/vrrp/vr 1 >> VRRP Virtual Router 1# vrid 1 (Select virtual router 1) (Set virtual router ID)
>> VRRP Virtual Router 1# addr 200.200.200.100 (Assign VR IP address) >> VRRP Virtual Router 1# if 1 (Assign virtual router interface)
.
>> VRRP Virtual Router 1# share dis >> VRRP Virtual Router 1# ena >> Main # /cfg/l3/vrrp/vr 3 >> VRRP Virtual Router 3# vrid 3
(Disable sharing of interfaces) (Enable virtual router 1) (Select virtual router 3) (Set virtual router ID)
>> VRRP Virtual Router 3# addr 200.200.200.103 (Assign VR IP address) >> VRRP Virtual Router 3# if 3 >> VRRP Virtual Router 3# share dis >> VRRP Virtual Router 3# ena (Assign virtual router interface) (Disable sharing of interfaces) (Enable virtual router 3)
Congure virtual server routers 2 and 4. These virtual routers will have the same IP addresses as the virtual server IP address. This is what tells the switch that these are virtual service routers (VSRs). For an active-standby conguration, sharing is disabled.
>> Main # /cfg/l3/vrrp/vr 2 >> VRRP Virtual Router 2# vrid 2 (Select virtual router 2) (Set virtual router ID)
>> VRRP Virtual Router 2# addr 205.178.13.226 (Assign VR IP address) >> VRRP Virtual Router 2# if 2 >> VRRP Virtual Router 2# share dis >> VRRP Virtual Router 2# ena >> Main # /cfg/l3/vrrp/vr 4 >> VRRP Virtual Router 4# vrid 4 (Assign virtual router interface) (Disable sharing of interfaces) (Enable virtual router 2) (Select virtual router 4) (Set virtual router ID)
>> VRRP Virtual Router 4# addr 205.178.13.300 (Assign VR IP address) >> VRRP Virtual Router 4# if 4 >> VRRP Virtual Router 4# share dis >> VRRP Virtual Router 4# ena (Assign virtual router interface) (Disable sharing of interfaces) (Enable virtual router 4)
.
Add virtual routers 1 and 2 to the vrgroup 1.

>> Main# /cfg/l3/vrrp/vrgroup 1 >> VRRP Virtual Router Vrgroup 1# add 1 >> VRRP Virtual Router Vrgroup 1# add 2 (Add virtual router 1: the VIR) (Add virtual router 2: the VSR) (Select the Priority Tracking Menu)
>> VRRP Virtual Router Vrgroup 1# ena >> VRRP Virtual Router Vrgroup 1# track
>> VRRP Vrgroup 1 Priority Tracking# ports ena (Track on physical ports)
Add virtual routers 3 and 4 to switch-based vrgroup 2.

>> Main# /cfg/l3/vrrp/vrgroup 2 >> VRRP Virtual Router Vrgroup 2# add 3 >> VRRP Virtual Router Vrgroup 2# add 4 (Add virtual router 1) (Add virtual router 2)
>> VRRP Virtual Router Vrgroup 2# ena >> VRRP Virtual Router Vrgroup 2# track (Select the Priority Tracking Menu)
>> VRRP Vrgroup 2 Priority Tracking# l4ports ena (Track on layer 4 ports)
Disable synchronizing of priority on Application Switch 1. The priorities should not be synchronized between the two switches. Priority for each vrgroup will change based on the tracking parameters congured in Step 6 and Step 7.
>> Main # /cfg/slb/synch prios disable
Synchronize the SLB and VRRP congurations from application switch 1 to application switch 2. Use the /oper/slb/sync command (see "Conguring VRRP Peers for Synchronization" (page 578)). End
.
IPv6 VRRP Conguration Examples

The following section contains three IPv6 VRRP conguration examples covering Hot Standby, Active Standby, and Active Active congurations. For conceptual information on these VRRP conguration types, refer to "Failover Methods and Congurations" (page 524).
Hot Standby Conguration Example

This conguration example demonstrates a Hot Standby conguration between two Nortel Application Switch 2424 units. The following concepts should be taken into account in IPv6 Hot Standby congurations: Step 1 Action Layer 2 (Port and VLAN) conguration Each VLAN must be congured per interface. Client-side and server-side VLANs must also be a member in an inter-switch-link (ISL) port.
Spanning Tree Group conguration The Spanning Tree Protocol must be turned off.
Layer 3 interface and VRRP conguration In this example, tracking is performed by Layer 2 ports so that any failures on the Master switch results in a successful switch to the Backup switch.
Server Load Balancing Ports connected to the peer switch directly, or via a Layer 2 switch, 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 conguration presented in this example
.
556 Part 3: Application Switching Fundamentals IPv6 Hot Standby conguration example
Take the following steps to replicate the conguration demonstrated above: Step 1 Action 2424-A Switch Conguration Layer 2 (Port and VLAN) and Layer 3 (Interface) conguration
/cfg/port 1 pvid 3 /cfg/port 2 pvid 2 /cfg/port 3 tagged ena pvid 911 /cfg/port 4 tagged ena pvid 911 /cfg/l2/vlan 2 ena name "server" learn ena def 2,3,4 /cfg/l2/vlan 3 ena name "client" learn ena
.
def 1,3,4 /cfg/l2/vlan 911 ena name "intersw" learn ena def 3,4 cfg/l2/trunk 1 ena add 3 add 4
Spanning Tree Group conguration

/cfg/l2/stg 1/off /cfg/l2/stg 1/add 1 2 3 911
Interface conguration
/cfg/l3/if 2 ena ipver v6 addr 2000:2:2:0:0:0:0:a mask 96 vlan 2 /cfg/l3/if 3 ena ipver v6 addr 3000:3:3:0:0:0:0:a mask 96 vlan 3 /cfg/l3/if 254 ena ipver v4 addr 192.168.0.1 mask 255.255.255.0 broad 192.168.0.255 vlan 911
Default Gateway conguration

/cfg/l3/gw 1 ena ipver v6 addr 3000:3:3:0:0:0:0:c
VRRP conguration
.
/cfg/l3/vrrp/on /cfg/l3/vrrp/vr 2 ena ipver v6 vrid 2 if 2 addr 2000:2:2:0:0:0:0:fff0 share dis /cfg/l3/vrrp/vr 3 ena ipver v6 vrid 3 if 3 addr 3000:3:3:0:0:0:0:ffff share dis /cfg/l3/vrrp/group ena ipver v6 vrid 254 if 2 share dis track ports
General SLB conguration

/cfg/slb on /cfg/slb/adv direct ena
IPv6 Real Server conguration

/cfg/slb/real 1 ena ipver v6 rip 2000:2:2:0:0:0:0:1001 /cfg/slb/real 2 ena ipver v6 rip 2000:2:2:0:0:0:0:1002
IPv6 Real Server Group 1 conguration

/cfg/slb/group 1 ipver v6 add 1 add 2
.
IPv6 VIP 1 HTTP Service conguration

/cfg/slb/virt 1 ena ipver v6 vip 3000:3:3:0:0:0:0:ffff vname "v6http" /cfg/slb/virt 1/service http group 1
Layer 4 port conguration

/cfg/slb/port 1 client ena hotstan en /cfg/slb/port 2 server ena hotstan en /cfg/slb/port 3 intersw ena /cfg/slb/port 4 intersw ena
Synchronization conguration
/cfg/slb/sync prios d /cfg/slb/sync/peer 1 ena addr 192.168.0.2
2424-B Switch Conguration Layer 2 (Port and VLAN) and Layer 3 (Interface) conguration
/cfg/port 1 pvid 3 /cfg/port 2 pvid 2 /cfg/port 3 tagged ena pvid 911 /cfg/port 4 tagged ena pvid 911 /cfg/l2/vlan 2 ena name "server" learn ena

.
def 2,3,4 /cfg/l2/vlan 3 ena name "client" learn ena def 1,3,4 /cfg/l2/vlan 911 ena name "intersw" learn ena def 3,4 /cfg/l2/trunk 1 ena add 3 add 4
Spanning Tree Group conguration

/cfg/l2/stg 1/off /cfg/l2/stg 1/add 1 2 3 911
/cfg/l3/if 2 ena ipver v6 addr 2000:2:2:0:0:0:0:b mask 96 vlan 2 /cfg/l3/if 3 ena ipver v6 addr 3000:3:3:0:0:0:0:b mask 96 vlan 3 /cfg/l3/if 255 ena ipver v4 addr 192.168.0.2 mask 255.255.255.0 broad 192.168.0.255 vlan 911
.
VRRP conguration
/cfg/l3/vrrp/on /cfg/l3/vrrp/vr 2 ena ipver v6 vrid 2 if 2 addr 2000:2:2:0:0:0:0:fff0 share dis /cfg/l3/vrrp/vr 3 ena ipver v6 vrid 3 if 3 addr 3000:3:3:0:0:0:0:ffff share dis /cfg/l3/vrrp/group ena ipver v6 vrid 254 if 2 share dis track ports


.


Layer 4 Ports conguration

End
Active-Standby Conguration Example

This conguration example demonstrates an Active-Standby conguration between two Nortel Application Switch 2424 units. The following concepts should be taken into account in IPv6 Active-Standby congurations:
.
Step 1
Action Layer 2 (Port and VLAN) conguration Each VLAN must be congured per interface.
Layer 3 interface and VRRP conguration In this example, tracking is performed by Layer 4 ports so that the two virtual routers will switch over when one of the Master virtual routers declare as Backup.
The following illustration demonstrates the Active-Standby conguration presented in this example
IPv6 Active-Standby conguration example
Take the following steps to replicate the conguration demonstrated above: End
.
Step 1
Action 2424-A Switch Conguration Layer 2 (Port and VLAN) and Layer 3 (Interface) conguration
/cfg/port 1 pvid 3 /cfg/port 2 pvid 2 /cfg/port 3 pvid 911 /cfg/l2/vlan 2 ena name "server" learn ena def 2 /cfg/l2/vlan 3 ena name "client" learn ena def 1 /cfg/l2/vlan 911 ena name "intersw" learn ena def 3

.

VRRP conguration
/cfg/l3/vrrp/on /cfg/l3/vrrp/vr 2 ena ipver v6 vrid 2 if 2 addr 2000:2:2:0:0:0:0:fff0 share dis track l4pts ena /cfg/l3/vrrp/vr 3 ena ipver v6 vrid 3 if 3 addr 3000:3:3:0:0:0:0:ffff share dis track l4pts ena




.


/cfg/slb/port 1 client ena /cfg/slb/port 2 server ena
/cfg/port 1 pvid 3 /cfg/port 2 pvid 2 /cfg/port 3 pvid 911 /cfg/l2/vlan 2 ena name "server" learn ena def 2 /cfg/l2/vlan 3 ena name "client"

.
learn ena def 1 /cfg/l2/vlan 911 ena name "intersw" learn ena def 3

VRRP conguration
.
/cfg/l3/vrrp/on /cfg/l3/vrrp/vr 2 ena ipver v6 vrid 2 if 2 addr 2000:2:2:0:0:0:0:fff0 share dis track l4pts ena /cfg/l3/vrrp/vr 3 ena ipver v6 vrid 3 if 3 addr 3000:3:3:0:0:0:0:ffff share dis track l4pts ena



.

/cfg/slb/port 1 client ena /cfg/slb/port 2 server ena
End
Active-Active Conguration Example

This conguration example demonstrates an Active-Active conguration between two Nortel Application Switch 2424 units. The following concepts should be taken into account in IPv6 Active-Active congurations: Step 1 Action Layer 2 (Port and VLAN) conguration 2 Each VLAN must be congured per interface.
Layer 3 interface and VRRP conguration In this example, tracking is performed by Layer 4 ports so that the two virtual routers will switch over when one of the Master virtual routers declare as Backup. End
.
The following illustration demonstrates the Active-Active conguration presented in this example
IPv6 Active-Active conguration example
Take the following steps to replicate the conguration demonstrated above: Step 1 Action 2424-A Switch Conguration Layer 2 (Port and VLAN) and Layer 3 (Interface) conguration
/cfg/port 1 pvid 3 /cfg/port 2 pvid 2 /cfg/port 3 pvid 911 /cfg/l2/vlan 2 ena name "server" learn ena def 2 /cfg/l2/vlan 3
.
ena name "client" learn ena def 1 /cfg/l2/vlan 911 ena name "intersw" learn ena def 3
VRRP conguration
.
/cfg/l3/vrrp/on /cfg/l3/vrrp/vr 2 ena ipver v6 vrid 2 if 2 addr 2000:2:2:0:0:0:0:fff0 share en track l4pts ena /cfg/l3/vrrp/vr 3 ena ipver v6 vrid 3 if 3 addr 3000:3:3:0:0:0:0:ffff share en track l4pts ena

/cfg/slb on
.
/cfg/port 1 pvid 3 /cfg/port 2 pvid 2 /cfg/port 3 pvid 911 /cfg/l2/vlan 2 ena name "server" learn ena def 2 /cfg/l2/vlan 3
.
ena name "client" learn ena def 1 /cfg/l2/vlan 911 ena name "intersw" learn ena def 3
VRRP conguration
.
/cfg/l3/vrrp/on /cfg/l3/vrrp/vr 2 ena ipver v6 vrid 2 if 2 addr 2000:2:2:0:0:0:0:fff0 share en track l4pts en /cfg/l3/vrrp/vr 3 ena ipver v6 vrid 3 if 3 addr 3000:3:3:0:0:0:0:ffff share en track l4pts en
/cfg/slb on


.
End
Virtual Router Deployment Considerations

Review the following issues described in this section to prevent network problems 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) "Conguring VRRP Peers for Synchronization" (page 578) "Synchronizing Active/Active Failover" (page 580)
.
Mixing Active-Standby and Active-Active Virtual Routers

If the network environment can support sharing, enable it for all virtual routers in the LAN. If not, use active-standby for all virtual routers. Do not mix active-active and active-standby virtual routers in a LAN. Mixed congurations may result in unexpected operational characteristics, and are not recommended.
Eliminating Loops with STP and VLANs

VRRP active/active failover is signicantly different from the hot-standby failover method supported in previous releases. As shown in "Loops in Active-Active Conguration" (page 577), active-active congurations can introduce loops into complex LAN topologies.
Loops in Active-Active Conguration
Using Spanning Tree Protocol to Eliminate Loops

VRRP generally requires Spanning Tree Protocol (STP) to be enabled in order to resolve bridge loops that usually occur in cross-redundant topologies, as shown in "Cross-Redundancy Creates Loops but STP Resolves Them." (page 577). In this example, a number of loops are wired into the topology. STP resolves loops by blocking ports where looping is detected.
Cross-Redundancy Creates Loops but STP Resolves Them
.
One drawback to using STP with VRRP is the failover response time. STP could take as long as 45 seconds to re-establish alternate routes after a switch or link failure.
Using VLANs to Eliminate Loops

When using VRRP, you can decrease failover response time by using VLANs instead of STP to separate trafc into non-looping broadcast domains. An example is shown in "Using VLANs to Create Non-Looping Topologies" (page 578):
Using VLANs to Create Non-Looping Topologies
This topology allows STP to be disabled. On the Nortel Application Switches, IP routing allows trafc to cross VLAN boundaries. The servers use the Nortel Application Switches as default gateways. For port failure, trafc is rerouted to the alternate path within one health check interval (congurable between 1 and 60 seconds, with a default of 2 seconds).
Assigning VRRP Virtual Router ID

During the software upgrade process, VRRP virtual router IDs will be automatically assigned if failover is enabled on the switch. When conguring virtual routers at any point after upgrade, virtual router ID numbers (/cfg/l3/vrrp/vr #/vrid) must be assigned. The virtual router ID may be congured as any number between 1 and 255.
Conguring VRRP Peers for Synchronization

The nal piece in conguring a high-availability solution includes the addition of synchronization options to simplify the manual conguration. Conguration options have been added to rene what is synchronized, to whom, and to disable synchronizing certain congurations. These options include proxy IP addresses, Layer 4 port conguration, lter conguration, and virtual router priorities. Also, a peer menu (cfg/slb/sync/peer) has been added to allow the user to congure the IP addresses of the switches that should be synchronized. This provides added synchronization validation but does not require the users to enter the IP address of the redundant switch for each synchronization.
.
Each VRRP-capable switch is autonomous. Switches in a virtual router need not be identically congured. As a result, congurations cannot be synchronized automatically. For user convenience, it is possible to synchronize a conguration from one VRRP-capable switch to another using the /oper/slb/sync command. However, care must be taken when using this command to avoid unexpected results. All server load balancing, port congurations, lter congurations, and VRRP parameters can be synchronized using the /oper/slb/synch command. Note: Before you synchronize the conguration between two switches, a peer must be congured on each switch. Switches being synchronized must use the same administrator password. Sessions created in 33-64 auxiliary table are not synced to backup. Congure the two switches as peers to each other. From Switch 1, congure Switch 2 as a peer and specify its IP address as follows:
>> Main # /cfg/slb/sync >> Config Synchronization # peer 1 >> Peer Switch 1 # addr <IP address> >> Peer Switch 1 # enable (Select the synchronization menu) (Select a peer) (Assign switch 2 IP address) (Enable peer switch)
Similarly, from Switch 2, congure Switch 1 as a peer and specify its IP address as follows:
>> Main # /cfg/slb/sync >> Config Synchronization # peer 2 >> Peer Switch 2 # addr <IP address> >> Peer Switch 2 # enable (Select the synchronization menu) (Select a peer) (Assign switch 1 IP address) (Enable peer switch)
Port specic parameters, such as what lters are applied and enabled on what ports, are part of what is pushed by the /oper/slb/synch command. Thus, if the /oper/slb/synch command is used, it is highly recommended that the hardware congurations and network connections of all switches in the virtual router be identical; that is, each switch should 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 congure a non-existent port or applies an inappropriate conguration to a port.
Synchronizing Active/Active Failover

With VRRP and active/active failover, the primary and secondary switches do not require identical congurations and port topology. Each switch can be congured individually with different port topology, SLB, and lters. If you would rather force two active/active switches to use identical settings, you can synchronize their conguration using the following command:
>> Main # /oper/slb/sync
The sync command copies the following settings to the switch at the specied IP interface address: VRRP settings (including priority) SLB settings (including port settings) Filter settings (including lter port settings) Proxy IP settings
If you perform the sync command, you should check the conguration on the 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 the target switch (the switch that is being synchronized to) to a port other than port 80 before VRRP synchronization begins.
Stateful Failover of Persistent Sessions

Nortel Application Switch Operating System provides stateful failover of persistent session state. See Chapter 19, "Persistence" for more information about 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 and Layer 4 persistent transactional state on the peer switch.
.
Note: Stateful failover is only supported in active-standby mode with VMA enabled. Also, Stateful failover does not synchronize all sessions, except persistent sessions (SSL session ID persistence and cookie-based persistence). If a service fails in the middle of a connection, the current session is discarded, but the new connection binds the session request correctly to the same real server. To provide stateful failover, the state of the connection and session table must be shared between the switches in high-availability congurations. If Virtual Matrix Architecture (VMA) is enabled, all URL and cookie-parsing information is stored in the session table on the last port number on the switch. Sharing this information between switches is necessary to ensure the persistent session goes back to the same server. Stateful failover only ensures that the clients request returns to the same server based on the persistent session entries being shared by the master and the slave switch. The TCP session information, however, is not shared.
What Happens When a Switch Fails

Assume that the user performing an e-commerce transaction has selected a number of items and placed them in the shopping cart. The user has already established a persistent session on the top server in "Stateful Failover Example when the Master Switch Fails" (page 582). The user then clicks the Submit button to purchase the items. At this time, the active switch fails. With stateful failover, the following sequence of events occurs: Step 1 2 3 Action The backup switch becomes active. The incoming request is redirected to the backup switch. When the user clicks Submit again, the request is forwarded to the correct server. Even though the master switch has failed, the stateful failover feature prevents the client from having to re-establish a secure session. The server that stores the secure session now returns a response to the client via the backup switch.
.
582 Part 3: Application Switching Fundamentals Stateful Failover Example when the Master Switch Fails
End
Stateful Failover Conguration Example

After the VRRP setup, perform the following additional steps to enable stateful failover on the switches. On the Master Switch Step 1 Action Enable stateful failover.
>> Main # /cfg/slb/sync/state ena
Set the update interval.

>> Main # /cfg/slb/sync/update 10 (The default is 30)
Congure the backup switch as a peer and specify its IP address.

>> Main # /cfg/slb/sync >> Config Synchronization # peer 1 >> Peer Switch 1 # addr 10.1.1.2 >> Peer Switch 1 # enable (Select a peer) (Assign backup switch IP address) (Enable peer switch)
.
End
On the Backup Switch Step 1 Action Enable stateful failover.

>> Main # /cfg/slb/sync/state ena
Set the update interval.

>> Main # /cfg/slb/sync/update 10 (The default is 30)
Note: The update does not have to be the same for both switches. Stateful failover supports up to two peer switches. Repeat the steps mentioned above to enable stateful failover on all the peer switches. 3 Congure the master switch as a peer and specify its IP address.
>> Main # /cfg/slb/sync >> Config Synchronization # peer 2 >> Peer Switch 2 # addr 10.1.1.1 >> Peer Switch 2 # enable (Select a peer) (Assign master switch IP address) (Enable peer switch)
End
Viewing Statistics on Persistent Port Sessions

You can view statistics on persistent port sessions using the /stats/slb/ssl command. To determine which switch is the master and which is the backup, use the /info/l3/vrrp command. The column on the far right displays the switch status. If the switch is a master:
.
>> Main # /info/l3/vrrp VRRP information: 1: vrid 1, 172.21.16.187,if 109, master, server 3: vrid 3, 192.168.1.30, if prio 109, master 5: vrid 5, 172.21.16.10, if prio 109, master
(View VRRP Information) 4, renter, prio 2, renter, 4, renter,
If the switch is a backup:

>> Main # /info/l3/vrrp VRRP information: 1: vrid 1, 172.21.16.187,if 104, backup, server 3: vrid 3, 192.168.1.30, if prio 104, backup 5: vrid 5, 172.21.16.10, if prio 104, backup (View VRRP Information) 1, renter, prio 3, renter, 1, renter,
Service-based Session Failover

Nortel Application Switch Operating System 24.0 supports the failover of a session based on a service. The NAAP protocol is used as the communication mechanism between the master and backup switches. Since NAAP is a Layer 2 protocol, the switches need to be connected directly over the interswitch link. "Service-based Session Failover Network Topology" (page 585) illustrates a Service-based Session Failover network topology.
.
High Availability 585 Service-based Session Failover Network Topology
When a new session is created on the master, the session entry will be sent to the backup switch using NAAP. The backup switch will create the session and set the age to a maximum age. This prevents the session from aging out on the backup switch and prevents frequent updates between the master 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 active standby congurations. To support this feature, the following new commands have been added: Step 1 Action Enable and disable mirroring for a service.
>> Main # /cfg/slb/virt <Virtual Server> /service <Service Number> / mirror {enable|disable}
Enable and disable mirroring for a lter.

>> Main # /cfg/slb/filt <Filter Number> /adv/mirror {enable|disable}
.
Mirroring statistics.
>> Main # /stats/slb/mirror
End
Peer Synchronization
In situations where a peer device has been created for a switch, the software will prompt for conguration synchronization with that peer before any reboot.
.
587

Nortel Application Switch Operating System can parse requests and classify ows using URLs, host tags, and cookies so that each request can be isolated and treated intelligently. This section describes the following advanced 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 Conguration API" (page 814)
.
588 Part 4: Advanced Switching
Persistence
The Nortel Application Switch Operating Systempersistence feature ensures that all connections from a specic client session reach the same real server, even when Server Load Balancing (SLB) is used. The following topics are addressed in this chapter: "Overview of Persistence" (page 588). This section gives an overview of persistence and the different types of persistence methods implemented in Nortel Application Switch Operating System. "Cookie-BasedPersistence" (page 591). The use of cookie persistence provides a mechanism for inserting a unique key for each client of a virtual server. This feature is only used in non-Secure Sockets Layer (SSL) connections. This section discusses in detail how persistence is maintained between a client and a real server using different types of cookies. "HTTP and HTTPS Persistence Based on Client IP" (page 590). This section explains how both HTTP and HTTPS trafc map to the same server based on client IP. "Server-Side Multi-Response Cookie Search" (page 604). This section explains how to congure the switch to look through multiple HTTP responses from the server to achieve cookie-based persistence. "SSL Session ID-Based Persistence" (page 605). This section explains how an application server and client communicate over an encrypted HTTP session. "Windows Terminal Server Load Balancing and Persistence" (page 607). This section explains how to congure load balancing and persistence for Windows Terminal Services.
Overview of Persistence
In a typical SLB environment, trafc comes from various client networks across the Internet to the virtual server IP address on the Nortel Application Switch. The switch then load balances this trafc among the available real servers. In any authenticated Web-based application, it is necessary to provide a persistent connection between a client and the content server to which it is connected. Because HTTP does not carry any state information for these applications, it is important for the browser to be mapped to the same real server for each HTTP request until the transaction is complete. This ensures that the client trafc is not load balanced mid-session to a different real server, forcing the user to restart the entire transaction.
.
Persistence
589
Persistence-based SLB enables the network administrator to congure the network to redirect requests from a client to the same real server that initially handled the request. Persistenceis an important consideration for administrators of e-commerce Web sites, wherea server may have data associated with a specic user that is not dynamically shared with other servers at the site. In Nortel Application Switch Operating System, persistence can be based on the following characteristics: source IP address, cookies, and Secure Sockets Layer (SSL) session ID.
Using Source IP Address

Until recently, the only way to achieve TCP/IP session persistence was to use the source IP address as the key identier. There are two major conditions which cause problems when session persistence is based on a packets 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 and do not take advantage of SLB on the switch. When many individual clients behind a rewall use the same proxied source IP address, requests are directed to the same server, without the benet of load balancing the trafc across multiple servers. Persistence is supported without the capability of effectively distributing trafc load. Also, persistence is broken if you have multiple proxy servers behind the application switch performing SLB. The application switch changes the clients address to different proxy addresses as attempts are made to load balance client requests. Single client sharing a pool of source IP addresses: When individual clients share a pool of source IP addresses, persistence for any given request cannot be assured. Although each source IP address is directed to a specic server, the source IP address itself is randomly selected, thereby making it impossible to predict which server will receive the request. SLB is supported, but without persistence for any given client.
Using Cookies
Cookies are strings passed via HTTP from servers to browsers. Based on the mode of operation, cookies are inserted by either the application switch or the server. After a client receives a cookie, a server can poll that cookie with a GET command, which allows the querying server to positively identify the client as the one that received the cookie earlier. The cookie-based persistence feature solves the proxy server problem and gives better load distribution at the server site. In the application switch, cookies are used to route client trafc back to the same physical server to maintain session persistence.
.
Using SSL Session ID

The SSL session ID is effective only when the server is running SSL transactions. Because of the heavy processing load required to maintain SSL connections most network congurations use SSL only when it is necessary. Persistence based on SSL Session ID ensures completion of complex transactions in proxy server environments. However, this type of persistence does not scale on servers because of their computational requirements.
HTTP and HTTPS Persistence Based on Client IP

Nortel Application Switch Operating System allows you to use the client IP address to maintain persistence for both HTTP and HTTPS sessions only. The pbind clientip command maintains persistence for the same service across multiple sessions from the same client, or maintains persistence between different services (for HTTP and HTTPS trafc only) from the same client to map to the same server, as long as the same group is congured for both services. In the Nortel Application Switch Operating System, when the metric congured is hash, phash, or minmisses, persistence may also be maintained to the real server port (rport), in addition to the real server.
When to disable persistence to the RPORT

In cases where two different services, such as TCP and UDP must both maintain persistence to the same real server. Client IP-based persistence is not dependent on the load balancing metric.
Conguring Client IP Address-Based Persistence

To congure client IP Address-based persistence for a real server, perform the following steps: Step 1 Action Congure real servers and services for basic SLB, as indicated below: Dene each real server and assign an IP address to each real server in the server pool. Dene a real server group and set up health checks for the group. Dene a virtual server on the virtual port for HTTP (port 80) and HTTPS (port 443) and assign both services to the same real server group. HTTP and HTTPS are supported only on their default service port numbers. Enable SLB on the switch. Enable client processing on the port connected to the client.
.
Persistence
591
For information on how to congure your network for SLB, see "Server Load Balancing" (page 188) 2 If a proxy IP address is not congured on the client port, enable DAM for real servers.
Select Client IP-based persistence as the persistent binding option for the virtual port. If multiple real server ports are congured for this service, you may choose whether to maintain persistence to the rport on the real server.
>> # /cfg/slb/virt 1/service <virtual port> pbind clientIP Current persistent binding mode: disabled Enter clientip|cookie|sslid|disable persistence mode: clientIP Use Rport? (y/n) [y]y
Enable client processing on the client port.

>> # /cfg/slb/port <port number> /client ena
End
Cookie-Based Persistence
Cookies are a mechanism for maintaining state between clients and servers. When the server receives a client request, the server issues a cookie, or token, to the client, which the client then sends to the server on all subsequent requests. Using cookies, the server does not require authentication, the client IP address, or any other time-consuming mechanism to determine that the user is the same user that sent the original request. In the simplest case, the cookie may be just a "customer ID" assigned to the user. It may be a token of trust, allowing the user to skip authentication while his or her cookie is valid. It may also be a key that associates the user with additional state data that is kept on the server, such as a shopping cart and its contents. In a more complex application, the cookie may be encoded so that it actually contains more data than just a single key or an identication number. The cookie may contain the users preferences for a site that allows their pages to be customized.
.
592 Part 4: Advanced Switching Cookie-Based Persistence: How It Works
The following topics discussing cookie-based persistence are detailed in this 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) "Conguring Cookie-Based Persistence" (page 598)
Permanent and Temporary Cookies

Cookies can either be permanent or temporary. A permanent cookie is stored on the clients browser, as part of the response from a Web sites server. It will be sent by the browser when the client makes subsequent requests to the same site, even after the browser has been shut down. A temporary cookie is only valid for the current browser session. Similar to a SSL Session-based ID, the temporary cookie expires when you shut down the browser. Based on RFC 2109, any cookie without an expiration date is a temporary cookie.
.
Persistence
593
Cookie Formats
A cookie can be dened in the HTTP header (the recommended method) or placed in the URL for hashing. The cookie is dened 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 following ways: In the HTTP Header
Cookie: Cookie: Cookie: SesssionID=1234 ASP_SESSIONID=POIUHKJHLKHD name=john_smith
The second cookie represents an Active Server Page (ASP) session ID. The third cookie represents an application-specic cookie that records the name of the client. Within the URL
http://www.mysite.com/reservations/SessionID=1234
Cookie Properties
Cookies are congured on the application switch by dening the following properties: 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 within a longer string. The offset directs the application switch to the starting point of the real cookie value within the longer cookie string. Length of the cookie value This denes the number of bytes to extract for the cookie value within a longer cookie string. Whether to nd the cookie value in the HTTP header (the default) or the 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 hash algorithm 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 Cookies

Under normal conditions, most browsers are congured to accept cookies. However, if a client browser is not congured to accept cookies, you must use hash or pbind clientip (for client IP persistence) as the load-balancing metric to maintain session persistence. With cookie-based persistence enabled, session persistence for browsers that do not accept cookies will be based on the source IP address. However, individual client requests coming from a proxy rewall will appear to be coming from the same source IP address. Therefore, the requests will be directed to a single server, resulting in trafc being concentrated on a single real server instead of load balanced across the available real servers.
Cookie Modes of Operation

Nortel Application Switch Operating System supports the following modes of operation for cookie-based session persistence: insert, passive, and rewrite mode. The following table shows the differences among the modes:
Comparison Among the Three Cookie Modes Cookie Mode Insert Cookie Passive Cookie Rewrite Cookie Configuration Required Switch only Server and Switch Server and Switch Cookie Location HTTP Header HTTP Header or URL HTTP Header Uses Switch Session Entry No Yes No
Insert Cookie Mode

In the insert cookie mode, the application switch generates the cookie value on behalf of the server. Because no cookies are congured 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 application switch performs load balancing and selects a real server. The real server responds without a cookie. The application switch inserts a cookie and forwards the new request with the cookie to the client.
.
Persistence Insert Cookie Mode
595
Cookie Insert Mode Enhancement

This mode allows to congure new cookie values, path and secure ag. Cookie Insert option Currently the conguration options provided are:
Cookie name - This defaults to "AlteonP". Expiry date and time - If congured, client sends cookie only till the expiration time. Otherwise cookie expires after the current session. Domain name - If congured, cookies are sent only to the domain.
Currently domain can be congured under commands the following commands:

>> #/cfg/slb/virt x/dname >> #/cfg/slb/virt x/service y/hname
Note: Domain name is taken as "<hname>.<dname>". It defaults to NULL string. CLI Capture When this command is executed: /cfg/slb/virt <virtual#>/service <service#>/pbind , additional inputs taken from the user are listed in the table below.
.
>> Virtual Server 10 http Service# /c/sl/vi 10/ser http/pbind Current persistent binding mode: disabled New persistent binding mode: cookie
Enter clientip|cookie|sslid|disable persistence mode: 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 (y/n) [n]yes
Insert cookie domain name? Enter path:
"/test/test.html" --------------- NEW
Is cookie secure[y/n] [n]yes --------------- NEW
Passive Cookie Mode

In Passive Cookie mode, when the client rst makes a request, the switch selects the server based on the congured load-balancing metric. The real server embeds a cookie in its response to the client. The switch records the cookie value and matches it in subsequent requests from the same client. Note: The passive cookie mode is recommended for temporary cookies. However, you can use this mode for permanent cookies if the server is embedding an IP address. In this case, a cookie has to be 8 characters long and every 2 characters represent 1 byte of IP address encoded in hexadecimal. The following gure shows passive cookie mode operation:
.
Persistence Passive Cookie Mode
597
Subsequent requests from Client 1 with the same cookie value will be sent to the same real server (RIP 1 in this example). Proxy support for Passive Cookie When passive cookie persistence mode is enabled, switch creates persistent entries for server returned responses with new cookie values, within the same TCP connection.
Rewrite Cookie Mode

In rewrite cookie mode, the application switch generates the cookie value on behalf of the server, eliminating the need for the server to generate cookies for each client. Instead, the server is congured to return a special persistence cookie which the switch is congured to recognize. The switch then intercepts this persistence cookie and rewrites the value to include server-specic information before sending it on to the client. Subsequent requests from the same 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-based persistence with Global Server Load Balancing (GSLB). Note: Rewrite cookie mode only works for cookies dened in the HTTP header, not cookies dened in the URL. Example: The following gure shows rewrite cookie mode operation:
.
598 Part 4: Advanced Switching Rewrite Cookie Mode
Note: When the application switch rewrites the value of the cookie, the rewritten value represents the responding server; that is, the value can be used for hashing into a real server ID or it can be the real server IP address. The rewritten cookie value is encoded.
Conguring Cookie-Based Persistence

Step 1 Action Before you can congure cookie-based persistence, you need to congure the switch for basic SLB. This includes the following tasks: Assign an IP address to each of the real servers in the server pool. Dene an IP interface on the switch. Congure each real server with its IP address, name, weight, and so forth. Assign servers to real server groups. Dene virtual servers and services.
For information see "Server Load Balancing" (page 188). 2 Either enable Direct Access Mode (DAM), or disable DAM and specify proxy IP address(es) on the client port(s). Enable DAM for the switch.
>> # /cfg/slb/adv/direct ena (Enable Direct Access Mode on switch)
.
Persistence
599
Disable DAM and specify proxy IP address(es) on the client port(s).

>> # /cfg/slb/adv/direct disable >> # /cfg/slb/port 1 >> # pip 200.200.200.68 (Disable DAM on the switch) (Select network port 1) (Set proxy IP address for port 1)
Note: If Virtual Matrix Architecture (VMA) is enabled on the switch, you must congure a unique proxy IP address for every port (except port 9). 3 If proxy IP addresses are used, make sure server processing is disabled on the server port.
>> # /cfg/slb/port 1 >> # server dis (Select switch port 1) (Disable server processing on port 1)
Select the appropriate load-balancing metric for the real server group.
>> # /cfg/slb/group 2/metric hash (Select hash as server group metric)
If embedding an IP address in the cookie, select roundrobin or leastconns as the metric. If you are not embedding the IP address in the cookie, select hash as the metric in conjunction with a cookie assignment server. While you may experience trafc concentration using the hash metric with a cookie assignment server, using a hash metric without a cookie assignment server will cause trafc concentration on your real servers.
Enable cookie-based persistence on the virtual server service. In this example, cookie-based persistence is enabled for service 80 (HTTP).
>> # /cfg/slb/virt 1/service 80/pbind Current persistent binding mode: disabled Enter clientip|cookie|sslid|disable persistence mode: cookie
.
Once you specify cookie as the mode of persistence, you will be prompted for the following parameters:
Enter insert|passive|rewrite cookie persistence mode [i/p/r]: p Enter cookie name: CookieSession1 Enter starting point of cookie value [1-64]: 1 Enter number of bytes to extract [0-64]: 8 Look for cookie in URI [e|d]: d
Cookie-based persistence mode: insert, passive or rewrite 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 e to enable this option. To look for the cookie in the HTTP header, enter d to disable this option. End
Setting Expiration Timer for Insert Cookie

If you congure for insert cookie persistence mode, then you will be prompted for cookie expiration timer. The expiration timer species a date string that denes the valid life time of that cookie. The expiration timer for insert cookie can be of the following types: Absolute timer The syntax for the absolute timer is MM/dd/yy[@hh:mm]. The date and time is based on RFC 822, RFC 850, RFC 1036, and RFC 1123, with the variations that the only legal time zone is GMT. Once the expiration date is met, the cookie is not stored or given out. For example,
Enter cookie expiration: 12/31/04@11:59 Current persistent binding for http: disabled New persistent binding for http: cookie New cookie persistence mode: insert Inserted cookie expires on Mon 12/31/04 at 11:59
Relative timer
.
Persistence
601
This timer denes 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:61 Current persistent binding for http: disabled New persistent binding for http: cookie New cookie persistence mode: insert Inserted cookie expires after 33 days 2 hours 1 minutes
The switch adds or subtracts hours according to the time zone settings in /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 cookie mode. Note: If the cookie expiration timer is not specied, the cookie will expire when the users session ends. New Conguration options The new conguration options provided are: Cookie path - If congured, cookie is sent only for URL requests which are subset of the path, path defaults to "/". Secure ag - If secure ag is set, client is required to use secure connection to obtain content associated with the cookie.
Example 1: Setting the Cookie Location

In 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 UID 1 8 dis
The last parameter in this command answers the "Look for cookie in URI?" prompt. If you set this parameter to disable, the application switch will use UID=87654321 as the cookie. Look for the cookie in the URI
>> # /cfg/slb/virt 1/service 80/pbind cookie passive UID 1 8 ena
.
The last "Look for cookie in URI?" parameter is set to enable. Therefore the application switch will use UID=12345678 as the cookie.
Example 2: Parsing the Cookie

This example shows three congurations where the switch uses the hashing key or wild cards to determine which part of the cookie value should be used for determining the real server. For example, the value of the cookie is dened as follows:
Cookie: sid=0123456789abcdef; name1=value1;...
Select the entire value of the sid cookie as a hashing key for selecting the real server:
>> # /cfg/slb/virt 1/service 80/pbind cookie passive sid 1 16 dis
This command directs the switch to use the sid cookie, starting with the rst byte in the value and using the full 16 bytes. Select a specic portion of the sid cookie as a hashing key for selecting the real server:
This command directs the switch to use the sid cookie, starting with the eight byte in the value and using only four bytes. This uses 789a as a hashing key. Using wildcards for selecting cookie names:
>> #/cfg/slb/virt 1/service 80/pbind cookie passive ASPSESSIONID* 1 16 dis
With this conguration, the switch will look for a cookie name that starts with ASPSESSIONID. ASPSESSIONID123, ASPSESSIONID456, and ASPSESSIONID789 will all be seen by the switch as the same cookie name. If more than one cookie matches, only the rst one will be used.
Example 3: Using Passive Cookie Mode

If you are using passive cookie mode, the application switch examines the servers Set-Cookie: value and directs all subsequent connections to the server that assigned the cookie. For example, if Server 1 sets the cookie as "Set-Cookie: sid=12345678," then all trafc from a particular client with cookie sid=12345678 will be directed 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 congured to be eight bytes, the switch will rewrite the placeholder cookie value with the encrypted real server IP address.
>> # /cfg/slb/virt 1/service 80/pbind cookie rewrite sid 1 8 dis
If the server is congured to include a placeholder cookie, such as follows:

Set-Cookie: sid=alteonpersistence;
then the application switch will rewrite the rst eight bytes of the cookie to include the servers encrypted IP address:
Set-Cookie: sid=alteonpersistence;
All subsequent trafc from a specic client with this cookie will be directed to the same real server. Rewrite server cookie with the encrypted real server IP address and virtual server IP address: If the cookie length is congured to be 16 bytes, the switch will rewrite the cookie value with the encrypted real server IP address and virtual server IP address.
>> # /cfg/slb/virt 1/service 80/pbind cookie rewrite sid 1 16 dis
If the server is congured to include a placeholder cookie, as follows:

Set-Cookie: sid=alteonwebcookies;
then the application switch will rewrite the rst 16 bytes of the cookie to include the encrypted real server IP address and virtual server IP address:
.
Set-Cookie:
sid=cdb20f04cdb20f0a;
All subsequent trafc from a specic client to the particular virtual server IP address with this cookie will be directed to the same real server.
Server-Side Multi-Response Cookie Search

Cookie-based persistence requires the switch to search the HTTP response packet from the server and, if a persistence cookie is found, sets up a persistence connection between the server and the client. The Nortel Application Switch looks through the rst HTTP response from the server. While this approach works for most servers, some customers with complex server congurations might send the persistence cookie a few responses later. In order to achieve cookie-based persistence in such cases, Nortel Application Switch Operating System allows the network administrator to congure the switch to search through multiple HTTP responses from the server. In Nortel Application Switch Operating System, the network administrator can modify a response counter to a value from 1-16. The switch will look for the persistence cookie in this number of responses (each of them can be multi-frame) from the server.
Conguring Server-Side Multi-Response Cookie Search

Congure the server-side multi-response cookie search by using the following command:
>> # /cfg/slb/virt <virtual server> /service <virtual port number> /rcount Current Cookie search response count: Enter new Cookie search response count [1-16]:
Proxy Support for Insert Cookie

When the insert cookie persistence mode is enabled, the switch will parse through every HTTP requests within the same TCP connection to look for the congured cookie name to use for persistency. If the client request arrives without a cookie, then the request will be forwarded to the existing binded server. When cookie insert persistence mode is enabled, the switch needs to insert a cookie in the server returned response for those client requests without a cookie. If the client request arrives with a cookie, then the cookie is used to check against the persistence binding table.
.
Persistence
605
SSL Session ID-Based Persistence

SSL is a set of protocols built on top of TCP/IP that allows an application server and client to communicate over an encrypted HTTP session, providing authentication, non-repudiation, and security. The SSL protocol handshake is performed using clear (unencrypted) text. The content data is 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 the same real server to which it was bound during the last session. Because SSL protocol allows many TCP connections to use the same session ID from the same client to a server, key exchange needs to be done only when the session ID expires. This reduces server overhead and provides a mechanism, even when the client IP address changes, to send all sessions to the same real server. Note: The SSL session ID can only be read by the switch after the TCP three-way handshake. In order to make a forwarding decision, the switch must terminate the TCP connection to examine the request. Some versions of Web browsers allow the session ID to expire every 2 minutes, 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 trafc is user-congurable.
How SSL Session ID-Based Persistence Works

All SSL sessions that present the same session ID (32 random bytes chosen 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 server based on the metric for the real server group and waits until a connection is established with the real server and a session ID is received. The session ID is stored in a session hash table. Subsequent connections with the same session ID are sent to the same real server. This binding is preserved even if the server changes the session ID mid-stream. A change of session ID in the SSL protocol will cause a full three-way handshake to occur. Session IDs are kept on the switch until an idle time equal to the congured server time-out (a default of 10 minutes) for the selected real server has expired.
.
"SSL Session ID-Based Persistence" (page 606) illustrates persistence based on SSL session ID as follows: Step 1 2 3 4 Action An SSL Hello handshake occurs between Client 1 and Server 1 via the application switch. An SSL session ID is assigned to Client 1 by Server 1. The application switch records the SSL session ID. The application switch selects a real server based on the existing SLB settings. As a result, subsequent connections from Client 1 with the same SSL session ID are directed to Server 1.
SSL Session ID-Based Persistence
Client 2 appears to the switch to have the same source IP address as Client 1 because they share the same proxy rewall. However, the application switch does not automatically direct Client 2 trafc to Server 1 based on the source IP address. Instead an SSL session ID for the new trafc 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 same SSL session ID are directed to Server 3. End
.
Persistence
607
Conguring SSL Session ID-Based Persistence

To congure session ID-based persistence for a real server, perform the following steps: Step 1 Action Congure real servers and services for basic SLB, as indicated below: Dene each real server and assign an IP address to each real server in the server pool. Dene a real server group and set up health checks for the group. Dene a virtual server on the virtual port for HTTPS (for example, port 443) and assign a real server group to service it. Enable SLB on the switch. Enable client processing on the port connected to the client.
For information on how to congure your network for SLB, see "Server Load Balancing" (page 188). 2 If a proxy IP address is not congured on the client port, enable DAM for real servers.
Select session ID-based persistence as the persistent binding option for the virtual port.
>> # /cfg/slb/virt <virtual server number> /service <virtual port> pbind sslid
Enable client processing on the client port.

>> # /cfg/slb/port <port number> /client ena
End
Windows Terminal Server Load Balancing and Persistence

Windows Terminal Services refer to a set of technologies that allow Windows users to run Windows-based applications remotely on a computer running as the Windows Terminal Server. The Nortel Application Switch Operating System includes load balancing and persistence options aimed specically at Windows Terminal Services.
.
In a load-balanced environment, a group of terminal servers have incoming session connections distributed in a balanced manner across the servers in the group. The Windows session director is used to keeping a list of sessions indexed by user name. This allows a user to reconnect to a disconnected user session. The session director provides functionality that allows a group of terminal servers to coordinate the reconnection of disconnected sessions. The session director is updated and queried by the terminal servers whenever users log on, log off, or disconnect their sessions while leaving their applications active. Client can be reconnected to the terminal server where the users disconnected session resides using the routing token information. The session director passes the routing token information to the client with the correct server IP address embedded. The client presents this routing token 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 correct terminal server. In some instances a dedicated session director may not exist. If this is the case, enable the userhash functionality to perform the terminal server binding operation based on user name hashing. By default, Windows Terminal Server trafc uses TCP port 3389 but it can congured to work on any non-standard port. For further information regarding Windows Terminal Services, refer to the Microsoft website. The following illustration demonstrates a sample Windows Terminal Server Load Balancing network topology.
.
Persistence Windows Terminal Server Load Balancing Network Topology
609
Conguring Windows Terminal Server Load Balancing and Persistence

Note: When using Windows Terminal Server Load Balancing and Persistence, ensure that either DMA is enabled or a proxy IP address has been congured. To congure this feature, follow this procedure:
.
Step 1
Action Access the Windows Terminal Server menu.

>> Main# /cfg/slb/virt <virtual server number> /service 3389/wts
Enable the Windows Terminal Server feature.

>> WTS Load Balancing# ena
(Optional) Enable the WTS userhash. If the dedicated session director does not exist to relate users to disconnected sessions, it is advised that the userhash functionality be enabled to perform this task.
>> WTS Load Balancing# userhash enable
End
.
Advanced Denial of Service Protection
611

This chapter describes the Advanced Denial of Service protection features in Nortel Application Switch Operating System that can be used to prevent a wide range of network attacks. The features described in this chapter are located within the new security menu commands, and are enabled via a separately purchased license key. Note: If you purchased the advanced Denial of Service protection option, make sure you enable it by typing /oper/swkey and entering its software key. "Background" (page 611) describes the rationale for providing Advanced Denial of Service protection and how the features can assist traditional rewalls in preventing malicious network attacks. "IP Address Access Control Lists" (page 612). Describes how to setup blocking of large ranges of IP addresses. "Protection Against Common Denial of Service Attacks" (page 615): This section explains how to prevent common denial of service (DOS) attacks from entering switch ports that are connected to unsafe networks. "Protocol-BasedRate Limiting" (page 628): This section explains how to monitor and limit incoming UDP, ICMP or TCP trafc within a congurable time window. "Protection Against UDP Blast Attacks" (page 635). This section describes how to monitor and limit trafc on UDP ports to a maximum number of connections per second. "TCP or UDP Pattern Matching" (page 636). This section describes how to match on binary or ascii patterns embedded in IP packets, and combine them into pattern groups which can be applied to a lter to deny trafc containing those patterns.
Background
The Advanced Denial of Service Protection feature set extends the functionality of the Nortel Application Switch to act as an application-intelligent rewall. An administrator can use the features described in this chapter to congure the Nortel Application Switch to perform deep inspection and blocking of malicious content. For example, many newer viruses, worms, malicious code, buggy applications, and cyber-attacks have targeted application and protocol weaknesses by tunneling through the rewall over HTTP port 80, or by encapsulating attacks into SSL tunnels. Such packets can pass undetected through standard network rewalls, which are congured 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 include illegal elds in the IP headers.
Security Inspection Workow

A typical workow of the application switch to handle security inspection is described below. 1. The Nortel Application Switch is congured with a predened set of rules. To increase the performance of the inspection, complex pattern inspection rules can be dened with an offset value so that the inspection engine can go directly to the location to be inspected. A virus pattern often is a combination of multiple patterns within the IP payload. The application switch can be congured to inspect multiple patterns and 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 the rules to the content of the packet. 4. When an attack pattern is matched, the application switch drops this packet, and creates a session in the switch so that subsequent packets of the same session (if it is TCP) will be also dropped without going through additional rule inspection.
Other Types of Security Inspection

The Nortel Application Switch can use its inspection engine to provide rate limiting capability to complex protocols such as those used in the Peer to Peer programs that use dynamic ports to establish communication between clients. Standard rewalls are unable to detect these programs, because the protocol signatures do not appear at the Layer 4 port level. Many of these protocols have signatures that are embedded in the HTTP header or in 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 total trafc generated by these programs. This is especially useful in Cable ISP and universities where Peer to Peer programs can reach as much as 70% of the total trafc. For more information, see "Protocol-BasedRate Limiting" (page 628).
IP Address Access Control Lists

Nortel Application Switch Operating System can be congured with IP access control lists (ACLs) composed of ranges of client IP addresses that are to be denied access to the switch. When trafc ingresses the switch, the client source or destination IP address is checked against this pool of addresses. If a match is found, then the client trafc is blocked.
.
613
ACLs vs. Filters

Access control lists (ACLs) are used to control which IP addresses are allowed access to a network. Unlike a lter, the ACL feature in Nortel Application Switch Operating System can only perform a deny action. The decision about whether to deny trafc is based solely on whether or not a match is found between the client IP and the ACL. The IP access control list (ipacl) commands can be used to congure a pool of up to 8192 blockable IP addresses (5120 congured source IP addresses, 1024 congured destination IP addresses, 1024 operationally added source IP addresses, and 1024 operationally added destination IP addresses). While lters can perform the same function by blocking IP addresses ranges, they contain more information besides source IP address which also must be matched on ingress trafc before determining whether to allow, deny, or redirect trafc.
How it works
The IP ACL feature uses a hash table to effectively block a congured range of IP addresses. The access control list is a global list which is by default disabled on the switch; and then enabled on a per-port basis. When a packet ingresses a port that has been enabled with IP access control list processing, the switch compares the client source or destination IP address with internal hash tables containing the IP addresses. If a match is found, the packet is dropped. If no match on the address is found in any of the hash tables, the packet is allowed to pass.
Conguring Blocking with IP Access Control Lists

Step 1 Action Add IP addresses that you wish to block. The following example will block source addresses 192.168.40.0-255.
>> Main # /cfg/security/ipacl >> IP ACL# add 192.168.40.0 (Select the IP ACL menu) (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 addresses 192.180.11.0-255:
.
>> Main# /cfg/security/ipacl >> IP ACL# dadd 192.180.11.0
(Select the IP ACL menu) (Enter a network address)
Enter IP subnet mask [default is 255.255.255.255]: 255.255.255.0 (Enter the appropriate mask)
2 3
Repeat step 1 to congure any other IP addresses that should be dropped. Enable IP ACL processing on the ingress port.
>> Main# /cfg/security/port <x> /ipacl ena (Enable IP ACL) Current IP ACL processing: disabled New IP ACL processing: enabled
Viewing IP ACL statistics

You can view the accumulated blocked packets for each IP address /mask pair by entering the following command:
>> /stats/security/ipacl/dump Address --------------192.168.40.1 192.168.40.12 192.168.40.65 Blocked Packets --------------3049 9702 563 (Dump IP ACL statistics)
Bogon List
The Nortel Application Switch Operating System supports the importation and use of a Bogon list. A bogon list species a listing of source IP addresses that are not currently in use or valid and therefore should be blocked. This is a useful tool in ltering out packets that would otherwise not be caught by other means. Bogon lists will be imported through the Nortel Application Switch Element Manager 4.0 although usage statistics can be viewed through either the Nortel ASEM application or the CLI. To view the number of bogon lists through the CLI, use the following command:
>> Main# /cfg/security/ipacl/bogon
To enable Bogon processing on an ingress port, use the following command:

.
615
>> Main# /cfg/security/port <port number> /bogon ena
Protection Against Common Denial of Service Attacks

Nortel Application Switch Operating System can protect switch ports against a variety ofDenial of Service (DOS) attacks including Port Smurf, LandAttack, Fraggle, Blat, Nullscan, Xmascan, PortZero, andScan SynFin among many others. Enable DOS protection on any ports connected to unsafe networks.
Conguring Ports with DoS Protection

Enable DoS protection on any switch port that is connected to an unsafe network. Once enabled, this feature will automatically detect and drop packets containing any of the supported types of DoS attack. Step 1 Action Enable DoS protection on the ports.
>> Main# /cfg/security/port 1/dos enable (Enable DOS protection on this port)
Current Protocol anomaly and DoS attack prevention: disabled New Protocol anomaly and DoS attack prevention: enabled
Add a DoS attack type to guard against.

>> Main# /cfg/security/port 1/dos/add <DoS attack type>
Note: To determine which DoS attack types a port is guarding against, 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 the following command.
>> Main# /cfg/security/port 1/dos/rem <DoS attack type>
4 5
Repeat steps 1 and 2 to apply DoS protection to any other ports. Apply and save the conguration. End

.
Viewing DOS statistics

You can view the number of times packets were dropped when a DOS attack was detected on the switch or on a specic port. When an attack is detected, the switch will generate a message such as:
Jun 18 22:33:32 ALERT security: DoS Attack:Fraggle sip:192.115.106.200 dip:192.115.106.255 ingress port:1
The following command shows DOS statistics on all ports where DOS protection is enabled:
>> /stats/security/dos/dump -----------------------------------------------------------Protocol anomaly and DoS attack prevention statistics for port 1: -----------------------------------------------------------Protocol anomaly and DoS attack prevention statistics for port 8: broadcast : 1 loopback : 8 land : 1 ipttl : 1 ipprot : 1 fragmoredont: 1 fragdata : 2 fragboundary: 2 fraglast : 1 fragdontoff : 1 fragoff : 1 fragoversize: 1 tcplen : 4 tcpportzero : 2 blat : 1 nullscan : 1 fullxmasscan: 1 finscan : 1 vecnascan : 5 xmasscan : 1 synfinscan : 1 synfrag : 1 ftpport : 1 dnsport : 1 seqzero : 1 ackzero : 1 udplen : 2 udpportzero : 2
.
617
fraggle snmpnull icmplen smurf icmpdata igmplen igmpfrag arpnbcast -----Totals
: : : : : : : : :
1 1 2 1 1 2 1 21 77
Specic subtotals are given for only those ports that are seeing attack trafc.
Viewing DOS statistics per port

The following command displays DOS protection statistics only on the specied port:
>> /stats/security/dos/port 8 >> Main# /st/sec/dos/port 8 -----------------------------------------------------------Protocol anomaly and DoS attack prevention statistics for port 8: broadcast : 1 loopback : 8 land : 1 ipttl : 1 ipprot : 1 fragmoredont: 1 fragdata : 2 fragboundary: 2 fraglast : 1 fragdontoff : 1 fragoff : 1 fragoversize: 1 tcplen : 4 tcpportzero : 2 blat : 1 nullscan : 1 fullxmasscan: 1 finscan : 1 vecnascan : 5 xmasscan : 1 synfinscan : 1 synfrag : 1 ftpport : 1 dnsport : 1 seqzero : 1 ackzero : 1 udplen : 2
.
udpportzero fraggle snmpnull icmplen smurf icmpdata igmplen igmpfrag arpnbcast -----Totals
: : : : : : : : : :
2 1 1 2 1 1 2 1 21 77
Understanding the types of DOS attacks

You can use the help command to obtain a brief explanation of each type of DOS attack detected by the switch.
>> /stats/security/dos/help
Once DOS protection is enabled on the appropriate ports on the Nortel Application Switch, the switch performs the following checks on incoming packets.
IPLen:
Description: An IPv4 packet is sent with an invalid payload or IP header length. Switch action: The switch checks for malformed packets that have either an IP header length less than 20 bytes, an IP total packet length less than the IP header length, or an actual packet length less than the IP total 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 version other than 4 and drops any matching packets.
Broadcast:
Description: An IPv4 packet with a broadcast source or destination IP address. Switch action: The switch checks for IPv4 packets with a broadcast source or destination IP address (0.0.0.0,255.255.255.255) and drops any matching packets.
.
619
LoopBack:
Description: An IPv4 packet with a loopback source or destination IP address. Switch action: The switch checks for IPv4 packets with a loopback source or destination IP address (127.0.0.0/8) and drops any matching packets.
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 drop any matching packets.
IPReserved:
Description: An IPv4 packet with the reserved IP bit set. Switch action: The switch checks for IPv4 packets with the reserved IP bit 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 TTL and 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 unassigned or 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 IP options length set and drops any matching packets.
FragMoreDont:
Description: An IPv4 packet with the more fragments and dont fragment bits set. Switch action: The switch checks for IPv4 packets with both the more fragments and dont fragments bits set and drops any matching packets.
.
FragData:
Description: An IPv4 packet with the more fragments bit set but a small payload. Switch action: The switch checks for IPv4 packets with the more fragments bit set but exhibiting a small payload and drops any matching packets.
FragBoundary:
Description: An IPv4 packet with the more fragments bit set but a payload not at an 8-byte boundary. Switch action: The switch checks for IPv4 packets with the more fragments bit set but whose payload is not at an 8-byte boundary and drops 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 fragment bit set but no payload and drops any matching packets.
FragDontOff:
Description: An IPv4 packet with a non-zero fragment offset and the dont fragment bits set. Switch action: The switch checks for IPv4 packets with a non-zero fragment offset and the dont fragment bits set and drops any matching packets.
FragOpt:
Description: An IPv4 packet with a non-zero fragment offset and IP options bits set. Switch action: The switch checks for IPv4 packets with a non-zero fragment offset and the IP options bits set and drops any matching packets.
FragOff:
Description: An IPv4 packet with a small non-zero fragment offset. Switch action: The switch checks for IPv4 packets with a small non-zero fragment offset and drops any matching packets.
.
621
FragOverSize:
Description: An IPv4 packet with a non-zero fragment offset and an oversized payload. Switch action: The switch checks for IPv4 packets with a non-zero fragment offset and an oversized payload and drops any matching packets.
TCPLen:
Description: A TCP packet with a TCP header length less than 20 bytes and an IP data length less than the TCP header length. Switch action: The switch checks for TCP packets with a TCP header length less than 20 bytes and an IP data length less than the TCP header 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 or destination 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 TCP reserved bit set and drops any matching packets.
NULLscan:
Description: A TCP packet with a sequence number of zero or all of the control bits are set to zero. Switch action: The switch checks for TCP packets with a sequence number or zero or with all control bits set to zero and drops any matching packets.
FullXmasScan:
Description: A TCP packet with all control bits set. Switch action: The switch checks for TCP packets with all of the control bits 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 bit set 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 any matching packets.
Xmascan:
Description: Sequence number is zero and the FIN, URG, and PSH bits are set. Switch action: The switch checks for any TCP packets where the sequence number is zero and the FIN, URG, and PSH bits are set and drops 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 FIN bits 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 combination and drops any matching packets.
SynData:
Description: A TCP packet with the SYN bit set and that also has a payload. Switch action: The switch checks for TCP packets with the SYN bit set and 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 and more fragments bits set and drops any matching packets.
FTPPort:
Description: A TCP packet with a source port of 20, a destination port of less than 1024 and the SYN bit set.
.
623
Switch action: The switch checks for TCP packets with a source port of 20, a destination port of less than 1024 and the SYN bit set and drops any matching packets.
DNSPort:
Description: A TCP packet with a source port of 53, a destination port of less than 1024 and the SYN bit set. Switch action: The switch checks for TCP packets with a source port of 53, a destination port of less than 1024 and the SYN bit set and drops any matching packets.
SeqZero:
Description: A TCP packet with a sequence number of zero. Switch action: The switch checks for TCP packets with a sequence number of zero and drops any matching packets.
AckZero:
Description: A TCP packet with an acknowledgement number of zero and the ACK bit set. Switch action: The switch checks for TCP packets with an acknowledgement number of zero and the ACK bit set and drops any matching packets.
TCPOptLen:
Description: A TCP packet with a TCP options length of less than two or where the TCP options length is greater than the TCP header length. Switch action: The switch checks for TCP packets with a TCP options length of less than two or where the TCP options length is greater than the TCP header length and drops any matching packets.
UDPLen:
Description: An UDP packet with a UDP header length of less than 8 bytes or where the IP data length is less than the UDP header length. Switch action: The switch checks for UDP packets with a UDP header length of less than 8 bytes or where the IP data length is less than the UDP 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 or destination port of zero and drops any matching packets.
.
Fraggle:
Description: Similar to a smurf attack, attacks are directed to a broadcast address, except that the packets sent are UDP, not ICMP. Switch action: Deny all the UDP packets with destination address set to a broadcast address. User action: Congure "UDP and ICMP Rate Limiting" (page 629).
Pepsi:
Description: An UDP packet with a source port of 19 and destination port of 7 or vice versa. Switch action: The switch checks for UDP packets with a source port of 19 and destination port of 7 or vice versa and drops any matching packets.
RC8:
Description: An UDP packet with a source and destination port of 7. Switch action: The switch checks for UDP packets with a source and destination port of 7 and drops any matching packets.
SNMPNull:
Description: An UDP packet with a destination port of 161 and no payload. Switch action: The switch checks for UDP packets with a destination port 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 improper ICMP header length and drops any matching packets.
Smurf:
Description: The attacker sends ICMP ping requests to multiple broadcast destination IP (x.x.x.255). The packet contains spoofed source IP of the victim. Switch action: Check every packet for destination IP set to a broadcast address in a lter, and drop any matching packet.
ICMPData:
Description: An ICMP packet with a zero fragment offset and a large payload.
.
625
Switch action: The switch checks for ICMP packets with a zero fragment offset 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 fragment offset 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 is unassigned 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 improper IGMP header length and drops any matching packets.
IGMPFrag:
Description: An IGMP packet with the more fragments bit set and a non-zero fragment offset. Switch action: The switch checks for IGMP packets with the more fragments bit set and a non-zero fragment offset and drops any matching packets.
IGMPType:
Description: An IGMP packet with the type of unassigned or reserved. Switch action: The switch checks for IGMP packets with the type of unassigned 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 with an improper length and drops any matching packets.
ARPNBCast:
Description: An ARP request packet with a non-broadcast destination MAC address.
.
Switch action: The switch checks for ARP request packets with a non-broadcast destination MAC address and drops any matching packets.
ARPNUCast:
Description: An ARP reply packet with a non-unicast destination MAC address. Switch action: The switch checks for ARP reply packets with a non-unicast destination MAC address and drops any matching packets.
ARPSpoof:
Description: An ARP request or reply packet with a mismatched source with sender MAC addresses or destination with target MAC addresses. Switch action: The switch checks for ARP request or reply packets with a mismatched source with sender MAC addresses or destination with target MAC addresses and drops any matching packets. It should be noted that VRRP enabled gateways can produce a false positive for arpspoof.
GARP:
Description: An ARP request or reply packet with the same source and destination IP. Switch action: The switch checks for ARP request or reply packets with the 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 improper header length and drops any matching packets.
IP6Version:
Description: An IPv6 packet with the IP version set to a value other than 6. Switch action: The switch checks for IPv6 packets with the IP version set to a value other than 6 and drops any matching packets.
Blat
Description: TCP packets with a source IP (sip) not equal to a destination IP (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.
.
627
DoS Attack Prevention Conguration

Many of the DoS attacks guarded against by the switch have congurable values associated with them. These values allow the switch to make a judgement about packets under inspection based on additional administrator input. "DoS Attack Prevention Commands" (page 627) outlines these DoS attacks and their associated commands.
DoS Attack Prevention Commands DoS Attack IPTTL IPProt FragData FragOff SynData ICMPData ICMPOff Command /cfg/security/dos/ipttl <smallest allowable IP TTL> /cfg/security/dos/ipprot <highest allowable protocol> /cfg/security/dos/fragdata <smallest allowable IP fragment payload> /cfg/security/dos/fragoff <smallest allowable IP fragment offset> /cfg/security/dos/syndata <largest allowable TCP SYN payload> /cfg/security/dos/icmpdata <largest allowable ICMP payload> /cfg/security/dos/icmpoff <largest allowable ICMP offset>
To view the current values associated with these DoS attacks, use either of 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 switch can be acquired by using the following command:
>> Main# /cfg/security/dos/help
Preventing other types of DOS attack Ping Flood:

Description: Flood of ICMP packets intentionally sent to overwhelm servers. The server is removed from service while it attempts to reply to every ping.
.
User action: Congure "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 echo request packets. When these packets are reassembled, they are larger than the 65536 byte packets allowed by the IP protocol. Oversized packets cause overows in the servers input buffer, and can cause a system to crash, hang, or reboot. User action: Congure FragOversize or "Matching and Denying Large Packets - ICMP Ping of Death Example" (page 643).
Protocol-BasedRate Limiting
Nortel Application Switch Operating System allows you to detect and block certain kinds of protocol-based attacks. These attacks can ood servers with enough trafc to severely affect their performance or bring them down altogether. Protocol-based rate limiting is implemented via lters. Nortel Application Switch Operating System currently supports rate limiting on TCP, UDP and ICMP protocols. Each lter is congured with one of the above protocols, and then rate limiting is enabled or disabled in the Filtering Advanced menu. TCP Rate Limiting: limits new TCP connection requests, or SYN packets. The switch monitors the rate of incoming TCP connection requests to a virtual IP address and limits the client requests with a known set of IP addresses. See "TCP Rate Limiting" (page 629) for more information. UDP and ICMP Rate limiting: counts all received packets from a client and compares against the congured maximum threshold. When the maximum congured threshold has been reached before the time window expires, the switch will drop until the congured hold-down period expires. See "UDP and ICMP Rate Limiting" (page 629) for more information.
Time Windows and Rate Limits

A time window is a congured period of time (in seconds) during which packets are allowed to be received. A rate limit is dened as the maximum number of TCP connection requests (for TCP rate limiting), or the maximum number of UDP or ICMP packets that have been received from a particular client within a congured time window.
.
629
When the fastage value is congured, the time window used by the switch is a multiple of the congured switch fastage and timewin values. Refer to Chapter 6 of the Command Reference for information on these value. The total time window then is the outcome of the timewin value multiplied by the fastage value.
Hold Down Periods

The switch monitors the number of new TCP connections (for TCP rate limiting) or UDP/ICMP packets received (for UDP/ICMP rate limiting). When the number of new connections or packets exceeds the congured limit, any new TCP connection requests or UDP/ICMP packets from the client are blocked. When blocking occurs, the client is said to be held down. The client is held down for a specied number of minutes, after which new TCP connection requests or packets from the client are allowed once again to pass through. Note: The time window and hold duration can be congured individually on a per-lter basis. The switch hold down period is a multiple of the slowage and holddur values. Refer to Chapter 6 of the Command Reference for information on these values. The total hold down period is an outcome of the holddur value multipled by the slowage value.
UDP and ICMP Rate Limiting

Nortel Application Switch Operating System lters can be congured to perform rate limiting on UDP and ICMP trafc. Because UDP and ICMP are stateless protocols, the maximum threshold (the maxcon command) should be interpreted as the maximum number of packets received from a particular client IP address. When the maximum threshold has been reached before the time window has expired, all packets of the congured protocol will be dropped until the congured hold down (holddur) period has expired.
TCP Rate Limiting

The switch monitors new TCP connections by looking for incoming SYN packets that match a specied TCP rate lter. The rst SYN packet to match the lter creates a TCP Rate session in the session table. Subsequent SYN packets from the same client that match the same lter increment the TCP Rate session counter. If the counter reaches the threshold value before the TCP Rate session ages out, then a hold down period is reached. During the hold down period no new TCP sessions from this client that match this lter are allowed. Once the hold down period ends, the next SYN packet is allowed, and a new TCP Rate session is created.
.
"Conguring Clients with Different Rates" (page 630) shows four clients congured for TCP rate limits based on source IP address. Clients 1 and 4 have the same TCP rate limit of 10 connections per second. Client 2 has a TCP rate limit of 20 connections per second. Client 3 has a TCP rate limit of 30 connections per second. When the rate of new TCP connections from clients 1, 2, 3, and 4 reach the congured threshold, any new connection request from the client is blocked for a pre-determined amount of time. If the clients IP address and the congured lter do not match, then the default lter is applied. In "Conguring Clients with Different Rates" (page 630), the default lter 2048 congured for Any is applied for all other connection requests.
Conguring Clients with Different Rates
Conguring Protocol-Based Rate Limiting Filters

Rate limiting lters are supported on TCP, UDP or ICMP protocols only. Protocol-based rate limiting can be congured for all lter types (allow, deny, redir, SIP, and DIP) and parameters. Specify the source IP address and mask options in the lter conguration menu to monitor a client or a group of clients. The destination IP address and mask options are used to monitor connections to a virtual IP address or a group of virtual IP addresses. The following examples work for any supported protocol-based rate limiting conguration. To specify a rate limiting lter for TCP, UDP, or ICMP, simply set the protocol on the lter itself, then go into the Filtering Advanced menu to set the rate limiting parameters.
.
631
A Basic Rate Limiting Filter

The following example shows how to congure rate limiting for Filter 10 in "Conguring Clients with Different Rates" (page 630). Step 1 Action Set the protocol used for the rate limiting lter. Only UDP, ICMP, and TCP protocols are supported for rate limiting.
>> Main# /cfg/slb/filt 10 >> Filter 10 # proto <any|<numb er>|<name>> (Select the filter 10 menu) (Specify TCP, UDP or ICMP protocol)
Enable rate limiting for the lter.

>> # /cfg/slb/filt 10/adv/security/ratelim/ena (Enable rate limiting)
Congure 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 time window)
Note: From step 3 and step 4 the rate limit dened as the maximum number of connections over a specied time window is 30 TCP connections for every 3 seconds (or 10 TCP connections per 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 allowed to make any new TCP connections or UDP/ICMP packets for 4 minutes. The following two conguration examples illustrate how to use protocol-based rate limiting to limit user access based on source IP address and virtual IP address.
.
6 7
Repeat steps 1-5 to congure the other lters shown in "Conguring Clients with Different Rates" (page 630). Apply and save the conguration. End
A Rate Limiting Filter Based on Source IP Address

This example shows how to dene a lter that limits clients with IP address 30.30.30.x to a maximum of 150 TCP connections or 150 UDP or ICMP packets per second. Step 1 Action Congure the lter as follows.
>> # /cfg/slb/filt 100/ena >> Filter 100 # sip 30.30.30.0 >> Filter 100 # smask 255.255.255.0 >> Filter 100 # proto <any|<number>|<name>> >> Filter 100 # adv/security/ra telim >> Rate Limiting # ena >> Rate Limiting # maxconn 15 (Enable the filter) (Specify the source IP address) (Specify the source IP address mask) (Specify TCP, UDP or ICMP protocol) (Select the Rate Limiting Adv. menu) (Enable rate limiting on TCP) (Specify the maximum connections in multiples of 10) (Set the time window in seconds) (Set the hold duration in minutes)
>> Rate Limiting # timewin 1 >> Rate Limiting # holddur 10
Time window = 1 second Hold duration = 10 minutes Max rate = maxconn/timewin = 150 connections/1 second = 150 connections/second
.
633
Any client with source IP address equal to 30.30.30.x is allowed to make 150 new TCP connections (or UDP/ICMP packets) per second to any single destination. When the rate limit of 150 is met, the hold duration takes effect. The client is not allowed to transmit sessions or connections to the same destination for 10 minutes. End
A Rate Limiting Filter Based on Virtual Server IP Address

This example denes a lter that limits clients to 100 TCP connections per second or 100 UDP or ICMP sessions per second to a specic destination (VIP 10.10.10.100). Once a client exceeds that limit, the client is not allowed to initiate new TCP connection requests or send UDP or ICMP trafc 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 specic destination.
Limiting User Access to Server
Step 1
Action Congure the following on the switch:

>> # /cfg/slb/filt 100/ena >> Filter 100 # dip 10.10.10.100 >> Filter 100 # dmask 255.255.255.255 >> Filter 100 # proto <any|<number>|<name>> >> Filter 100 # adv/security >> Security# ratelim ena (Specify TCP, UDP or ICMP protocol) (Select the Security menu) (Enable rate limiting) (Enable the filter)
.
>> Security# maxconn 20
(Specify the maximum connections in multiples of 10) (Set the time window for the session) (Set the hold duration for the session)
>> Security# timewin 2 >> Security# holddur 40
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 conguration limits all clients to 100 new TCP (or UDP/ICMP packets) per second to the server. If a client exceeds this rate, then the client is not allowed transmit sessions or connections to the virtual server for 40 minutes. 2 Add the lter to the ingress port on the switch.
>> Rate Limiting # /cfg/slb/port 2/filt ena/add 100
A Rate Limiting Filter to Thwart Ping Flooding

This example shows how to dene a lter that limits the amount of ICMP pings to any destination behind the application switch. A ping ood attempts to overwhelm servers with ping packets, thus removing it from service while it attempts to reply to every ping. Step 1 Action Congure the following lter on the switch.
>> # /cfg/slb/filt 30/ena >> Filter 30 # proto icmp >> Filter 30 # action allow >> Filter 30 # adv/security (Specify ICMP protocol) (Allow ICMP traffic) (Select the Security menu)
.
635
>> Security# ratelim ena >> Security# maxcon 10
(Enable rate limiting) (Specify the maximum connections in multiples of 10)
Add the lter to the ingress port on the switch.

>> Rate Limiting # /cfg/slb/por t 2 >> SLB port 2# filt ena Current port 2 filtering: New port 2 filtering: >> SLB port 2# add 30 Filter 30 added to port 2. (Select the appropriate ingress port) (Enable filtering on the port) disabled
enabled (Add the rate limit filter to the port)
Protection Against UDP Blast Attacks

Malicious attacks over UDP protocol ports are becoming a common way to bring down real servers. Nortel Application Switch Operating System can be congured to restrict the amount of trafc allowed on any UDP port, thus ensuring that backend servers are not ooded with data. In the CLI, specify a series of UDP port ranges and the allowed packet limit for that range. When the maximum number of packets/second is reached, UDP trafc is shut down on those ports.
Conguring UDP Blast Protection

Step 1 Action Congure the UDP port numbers or ranges of UDP ports that you want to protect against UDP attacks. For example, congure UDP ports 1001-2000 @ 1000pps, UDP ports 2001-4000 @2000pps, and UDP ports 4001-6000 @5000pps.
.
>> /cfg/security/udpblast
(Access the UDP Blast Protection Menu)
>> UDP Blast Protection# add Enter UDP port number (1 to 65535) or range (first-last): 1001-2000 Enter max packet rate per second (1 to 20000000): 1000 >> UDP Blast Protection# add Enter UDP port number (1 to 65535) or range (first-last): 2001-4000 Enter max packet rate per second (1 to 20000000): 2000 >> UDP Blast Protection# add Enter UDP port number (1 to 65535) or range (first-last): 4001-6000 Enter max packet rate per second (1 to 20000000): 5000
Nortel Application Switch Operating System supports up to 5000 UDP port numbers, using any integer from 1 to 65535. For the entire port range, the difference between the highest port number and the lowest port number must be less than or equal to 5000. 2 Enable UDP blast protection on the ports on the switch that are connected to unsafe networks
/cfg/security/port 1/udpblast ena
TCP or UDP Pattern Matching

This feature provides the capability to scan ingressing packets for patterns contained in some well-known TCP or UDP attacks on backend servers. The switch can be congured with one or more lters that scan the rst IP packet, and drop if it nds one or all of the congured patterns. If no match is found, the packets will be allowed through. Pattern matching is constructed much in the same way as any other lter congured to examine Layer 7 content, such as "Deny Filter Based on Layer 7 Content Lookup" (page 400).
.
637
Note: The ability to match and perform lter action on a pattern or group of patterns is available only when the Security Pack software is enabled on your switch.
Pattern Criteria
Many TCP or UDP attacks contain common signatures or patterns in the IP packet data. The switch can be congured to examine an IP packet from either the beginning, from a specic offset value (starting point) within the IP packet, and/or from a specied depth (number of characters) into the IP packet. It then performs a matching operation. "IP Packet Format" (page 638) shows an IP packet format. The switch is able to track from the beginning of the IP packet (at IP version number), through IP packet payload of 1500 bytes. Each row in an IP packet is four bytes.
Pattern
A pattern can be a regular expression string pattern in ASCII characters, or a binary pattern in Hexadecimal notation. For more information on using regular expressions to match pattern data, see "Regular Expression Matching" (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, enter FC2D.
Offset
An offset value is the byte count from the start of the IP header, from which a search or compare operation is performed. An offset value is always required when the creating pattern strings, even if the desired value is zero (0). For example, if an offset of 12 is specied, the switch will start examining the hexadecimal representation of a binary string, from the 13th byte. In the IP packet, the 13th byte starts at the Source IP Address portion of the IP payload.
.
638 Part 4: Advanced Switching IP Packet Format
Depth
Depth is the number of bytes in the IP packet that should be examined from either the beginning of the packet or from the offset value. For example, if an offset of 12 and a depth of 8 is specied, the search begin at the 13th byte in the IP packet, and will match 8 bytes. As we can see from "IP Packet Format" (page 638), an offset of 12 and depth of 8 encompasses the Source IP Address and Destination IP Address elds in the IP payload. If no depth is specied in ASCII matches, the exact pattern will be matched from the offset value to the end of the pattern. A depth must be specied for Binary matches that is larger than the pattern length in bytes.
Operation
An operation tells the switch how to interpret the pattern, offset and depth criteria. For a string pattern, use the operation eq (equals) in order to match the content of the string. Use the operations to nd values lt (less than), gt (greater than) or eq (equals) to the specied binary value. If no operation is specied, the pattern is invalid. The lt and gt operations can be used for certain attack signatures, in which one or more bytes are less than or greater than a certain value.
Syntax:
>> /cfg/slb/layer7/slb/addstr
.
639
Matching Groups of Patterns

When a virus or other attack contains multiple patterns or strings, it is useful to combine them into one group and give the group a name that is easy to remember. When a pattern group is applied to a deny lter, the switch will match any of the strings or patterns within that group before denying and dropping the packet. Up to ve patterns can be combined into a single pattern group. Congure the binary or ascii pattern strings, group them into a pattern group, name the pattern group, and then apply the group to a lter. The ltering commands allow the administrator to dene groups of patterns and place them into groups. By applying the patterns and groups to a deny lter, the packet content can be detected and thus denied access to the network. The Nortel Application Switch Operating System supports up to 1024 pattern groups. Note: The pattern group matching feature is available only if you have purchased and enabled the Advanced Denial of Service Protection software key. The Nortel Application Switch Operating System supports multi-packet inspection. This allows for the inspection of multiple patterns across multiple packets in a session. Filtering actions will be taken only after matching all the patterns in the same given sequence. For example, assume a chain consisting of multiple patterns numbered 1 through 4. The incoming packets of the session will be rst searched for pattern 1. Once pattern 1 of the chain is matched, subsequent packets of the session will be searched for pattern 2 and if matched, pattern 3 will be searched for and so on, until all the patterns in the chain are matched. The lter action will be taken after patterns 1 through 4 are matched. Note: A reset frame is sent to the destination device when a Layer 7 deny lter is matched instead of waiting for a server side timeout. This will release the TCP connection in the destination device. Similarly, any time a TCP packet is denied by the switch a reset frame is sent.
Matching and Denying a UDP Pattern Group

Step 1 Action Congure a list of SLB strings containing binary patterns and offset pairs.
.
The following example illustrates adding one binary pattern and one ASCII string pattern. The binary pattern is written in hexadecimal notation.
>> /cfg/slb/layer7/slb/addstr Enter type of string [l7lkup|pattern]: pattern (Add the first pattern) Enter match pattern type [ascii|binary]: binary (Select binary 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 this Binary pattern)
>> Server Loadbalance Resource# add (Add the second pattern) Enter type of string [l7lkup|pattern]: pattern
Enter match pattern type [ascii|binary]: ascii (Select ascii 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)


ID 1 2 3 4 6 7 SLB String ida %c1%9c %c0%af playdog.com HTTPHDR:Host:www.playdog.com HTTPHDR:SoapAction=*
.
641
ID 8 9
SLB String BINMATCH=014F, offset=2, depth=0, op=eq, cont 256 STRMATCH=/default.htm offset=44, depth=30, op=eq, cont 256
In the security menu, congure a pattern group and name it something relevant and easy to remember.
>> /cfg/security/pgroup 1/name Current pattern group name: Enter new pattern group name: virus_x (Name the group) (Name pattern group 1)
Add the new pattern/offset pairs to the pattern group using their ID numbers. Refer back to step 2, where you typed the cur command, if you need to recall the ID number associated with the SLB string.
>> Pattern Match Group 1# add 8 >> Pattern Match Group 1# add 9 (Add the first binary pattern) (Add the ascii string pattern)
Congure a lter and its appropriate protocol in which the patterns are found.
>> /cfg/slb/filt 90 >> Filter 90 # proto tcp (Go to the Filter 90 menu)
Congure the lter source and destination ports.

>> Filter 90 >> Filter 90 # sport any # dport http (From any TCP source port) (To HTTP destination port)
Congure the lter to deny.

>> Filter 90 # action deny Current action: none Pending new action: deny (Set the filter action to deny)
Apply the pattern group you congured in step 3 and step 4 to the lter.
.
>> Main# /cfg/slb/filt 90/adv/security/addgrp 1 Group ID 1 added.
(Add pattern group 1 to the filter)
Enable pattern matching on the lter. This command will automatically enable Layer 7 lookup on the lter.
>> /cfg/slb/filt 90/adv/security/pmatch enable Current Pattern Match: disabled New Pattern Match: enabled
10
Apply the lter to the client port. If the incoming client requests enter the switch on port 3, then add this lter to port 3.
>> # /cfg/slb/port 3 >> SLB Port 3# filt ena >> SLB Port 3# add 90 (Select the client port) (Enable filtering on the client port) (Add Filter #90 to the client port)
11
Matching All Patterns in a Group

The switch is capable of matching on all patterns in a pattern group before the lter denies a packet. Use the matchall command to instruct the lter to match all patterns in the group before performing the deny action. Note: The matchall command is congurable only for binary or ascii patterns added to pattern groups (pgroup). It does not apply to l7lkup lter strings congured with the /cfg/slb/layer7/slb/addstr command. Step 1 2 Action Use the base conguration in "Matching and Denying a UDP Pattern Group" (page 639). In the Filter menu, enable the matching of all criteria.
.
643
>> /cfg/slb/filt 90/adv/secu rity/matchall ena
(Enable matching all criteria)
Current Match-all Criteria: disabled New Match-all Criteria: enabled
Now, both patterns congured in the above example must be matched before a packet is denied and dropped:
8 9 BINMATCH=014F, offset=2, depth=0, op=eq, cont 256 STRMATCH=/default.htm offset=44, depth=30, op=eq, cont 256
Matching and Denying Large Packets - ICMP Ping of Death Example

A ping of death attack sends fragmented ICMP echo request packets. When these packets are reassembled, they are larger than the 65536 byte packets allowed by the IP protocol. Oversized packets cause overows in the servers 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 be blocked using a deny lter combined with binary patterns used to lter non-zero IP offsets or More-Fragment bits sent in the IP ags. An IP packet is determined to be an IP fragment if: (a) the 13-bit fragment offset eld in the IP header is non-zero, or (b) the More Fragments bit in the 3-bit ags eld in the IP header is set. The ags eld begins at the 7th byte of the IP packet, and the fragment offset is right after this eld. The two elds taken together occupy a total of 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 conguration is similar to the examples in "Matching and Denying a UDP Pattern Group" (page 639) and "Matching All Patterns in a Group" (page 642). Step 1 Action Create an SLB string pattern that lters non-zero IP offsets. Enter the value in Hexadecimal notation.
.
>> /cfg/slb/layer7/slb/addstr Enter type of string [l7lkup|pattern]: pattern (Add the pattern) Enter match pattern type [ascii|binary]: binary (Select binary 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 than 0000)
Create another SLB string pattern that lters More Fragments.

>> Server Loadbalance Resource# add Enter type of string [l7lkup|pattern]: pattern (Add the pattern) Enter match pattern type [ascii|binary]: binary (Select binary 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)
Apply the new conguration.

>> Server Loadbalance Resource# apply
Identify the IDs of the dened patterns.


ID 1 2 3 4 SLB String ida %c1%9c %c0%af playdog.com
.
645
ID 6 7 8 9 10 11
SLB String HTTPHDR:Host:www.playdog.com HTTPHDR:SoapAction=* BINMATCH=014F, offset=2, depth=0, op=eq, cont 256 STRMATCH=/default.htm offset=44, depth=30, op=eq, cont 256 BINMATCH=0000, offset=6, depth=0, op=gt, cont 256 BINMATCH=4000, offset=6, depth=0, op=lt, cont 256
In the security menu, congure a pattern group and name it something relevant and easy to remember.
>> /cfg/security/pgroup 2/name Current pattern group name: Enter new pattern group name: pingofdeath (Enter name for pattern group 2)
Add the dened patterns to the pattern group.

>> Pattern Match Group 2# add 10 >> Pattern Match Group 2# add 11
Congure a lter and its appropriate protocol in which the patterns are found; in this case, icmp protocol should be specied.
>> /cfg/slb/filt 190 >> Filter 190 # proto icmp (Go to the Filter 90 menu)
Set the lter action to deny.

>> Filter 190 # action deny Current action: none Pending new action: deny (Set the filter action to deny)
Set the ICMP message type. Ping of Death uses the ICMP message type echoreq.
.
>> Filter 190 # adv/icmp >> Filter 190 Advanced# icmp Current ICMP message type: Enter ICMP message type or any: echoreq
any (Set ICMP message type)
10
Apply the pattern group you congured in step 5 and step 6 to the lter.
>> Filter 190 # security/addgrp 2 Group ID 2 added. (Add pattern group 2 to the filter)
11
Enable pattern matching on the lter.

>> /cfg/slb/filt 190/adv/security/pmatch enable Current Pattern Match: disabled New Pattern Match: enabled
12
Enable matchall criteria so that the lter matches on all patterns in the pattern group.
>> Security# matchall ena Current Match-all Criteria: disabled New Match-all Criteria: enabled
13
Apply the lter to the client port. This example assumes a client connection on port 22.
>> # /cfg/slb/port 22 >> SLB Port 22# filt ena >> SLB Port 22# add 190 (Select the client port) (Enable filtering on the client port) (Add Filter #190 to the client port)
14
.
647
Nortel Threat Protection System 4.1 Enforcement Point

The Nortel Application Switch Operating System gives the Nortel Application Switch the ability to be an enforcement point for the Nortel Threat Protection System version 4.0. In this capacity, the switch can enforce policies that have been generated by the Threat Protection System.
Remediation Subsystem
The Remediation Subsystem is a component of the Nortel Threat Protection System that issues remediations directly to the Nortel Application Switch in response to detected threats on the network. These remediations, with the exception of session deletion, take the form of Operations IP Access Control Lists. Refer to "Operations IP Access Control List" (page 648) for more information on this topic. The following remediations are issued directly to the Nortel Application Switch from the Remediation Subsystem of the Nortel TPS: Step 1 Action Block Source IP Blocks any trafc sent from the source IP in the event that triggered the remediation. 2 Block Destination IP Blocks any trafc sent to the destination IP in the event that triggered the remediation. 3 Block Source Network Block any trafc sent from source network in the event that triggered the remediation. 4 Block Destination Network Block any trafc sent to destination network in the event that triggered the remediation. 5 Delete Session Deletes existing session based on ve parameters of the event that triggered the remediation. Refer to "Session Deletion" (page 649) for further information on this topic. When an operations IP ACL is added remotely by the remediation subsystem a syslog entry is generated. End
.
Operations IP Access Control List

The Operations IP Access Control List (ACL) feature allows up to 1024 source IP ACLs and 1024 destination IP ACLs to be set for a user-specied time duration in minutes without making conguration changes or manually removing the IP ACL. As well, when the maximum number of source or destination IP ACLs is reached, any new source or destination IP ACL set will automatically remove the next source or destination IP ACL that will expire. Any new source IP ACL will remove the next source IP ACL only and any new destination ACL will only replace the next destination IP ACL. This will allow the new IP ACL to be set even though the maximum is reached.
Conguring Operations IP Access Control Lists

The following sections outline the commands necessary to congure and maintain Operations IP ACLs. Conguring Source IP Access Control Lists A switch administrator has the option of performing the following three actions with source IP access control lists: Step 1 Action Add a new source IP access control list. To add a new source IP access control list, use the following command:
>> Main# /oper/sec/ipacl/add <IP Address> <Subnet Mask> <Duration in Minutes (110080)>
Remove a source IP access control list. A source IP access control list can be removed from the switch before its timeout threshold is reached. To remove a source IP access control list, use the following command:
>> Main# /oper/sec/ipacl/rem <IP Address> <Subnet Mask>
Remove all source IP access control lists. To remove all source IP access control lists from the switch, use the following command:
>> Main# /oper/sec/ipacl/arem
End
.
649
Conguring Destination IP Access Control Lists A switch administrator has the option of performing the following three actions with destination IP access control lists: Step 1 Action Add a new destination IP access control list. To add a new destination IP access control list, use the following command:
>> Main# /oper/sec/ipacl/dadd <IP Address> <Subnet Mask> <Duration in Minutes (110080)>
Remove a destination IP access control list. A destination IP access control list can be removed from the switch before the timeout threshold is reached. To remove a destination IP access control list, use the following command:
>> Main# /oper/sec/ipacl/drem <IP Address> <Subnet Mask>
Remove all destination IP access control lists. To remove all destination IP access control lists from the switch, use the following command:
>> Main# /oper/sec/ipacl/darem
When an operations IP ACL is removed automatically, a syslog entry is generated. End
Session Deletion
Sessions can be deleted from the switch through the Remediation Subsystem when the switch is acting as a Nortel TPS enforcement point or manually through the command line interface. Manual session deletion is based on the ve parameters entered by the user when the command is executed. Based on these parameters the operating system will nd the corresponding single session entry and delete it. The ve 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 will loop and send session deletion requests to all SPs but it will stop once the session 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

This chapter describes the Symantec Intelligent Network Protection features in the Nortel Application Switch Operating System. These new features are used in conjunction with the Intelligent Trafc Management functionality to create a more robust and well-rounded security solution. It should be noted that although this chapter provides an explanation of the Symantec Intelligent Network Protection feature and general conguration information, it does not provide specic and detailed information on the conguration, usage, and management of this feature. For detailed information on these topics, refer to the following documents in the Nortel Application Switch documentation suite: Nortel Intelligent Trafc Management 5.0 Users Guide (NN47220-102) Nortel Application Switch Element Manager 5.0 Users Guide (NN47220-101) Nortel Application Switch Element Manager 5.0 Help (NN47220-100)
Symantec Intelligent Network Protection is only available to switches that have a valid Intelligent Trafc Management and Symantec license that are running the Nortel Application Switch Operating System 24.0 and higher. Symantec Intelligent Network Protection is not meant to supplant the existing security functionality of the Nortel Application Switch Operating System but to enhance it. For the most secure solution possible, use this functionality in conjunction with the existing security functionality. Information on this security functionality can be found in "Advanced Denial of Service Protection" (page 611) This chapter contains the following topics: "Overview" (page 652) "Installing Software Keys" (page 653) "Intelligent Network Protection Components" (page 653) "Conguration Tasks" (page 654) "Tunable Resources" (page 656) "Monitoring Symantec Functionality" (page 657) "General Symantec Information" (page 657) "Signature Names" (page 658) "Conguration Example" (page 659) "Troubleshooting" (page 665)
.
Overview
Intelligent Network Protection provides enhanced security functionality to the switch by providing a continually updated line of defense against moderate and severe network threats. Intelligent Network Protection is provided as a subscription based service that is purchased on a yearly basis for each switch it protects. This allows a user to provide up to date protection to the switch. Intelligent Network Protection is available to a Nortel Application Switch with a valid Intelligent Trafc Management license. Once this functionality is enabled on the switch, Symantec security signatures are downloaded to it through the Symantec LiveUpdate technology. Security signatures are continuously updated by Symantec and posted for immediate download by subscribers. Updated signatures can be downloaded through Nortel ASEM automatically and applied either automatically or manually. Trafc ows are then steered through the Symantec security engine for inspection and the results are communicated to the Application Switch to enable the pre-determined course of action. Trafc that cleanly passes security interrogation is then processed for application classication and policy assignment. "Security Layers in Nortel Application Switch Operating System" (page 652) illustrates the multiple layers of security enabled by a Nortel Application Switch running Intelligent Trafc Management and Intelligent Network Protection.
Security Layers in Nortel Application Switch Operating System
.
653
Intelligent Network Protection Components

The Intelligent Network Protection functionality is composed of several components that work together to provide the overall security solution. This overall security solution is composed of the following items: Switch Software The main component of the Intelligent Network Protection functionality is the software included in the Nortel Application Switch Operating System. The switch software contains the logic for ltering and denying trafc based on the Symantec signatures downloaded to the switch. Intelligent Trafc Management The Intelligent Trafc Management component works in conjunction with the Intelligent Network Protection functionality to lter and monitor trafc. Intelligent Network Protection does not replace Intelligent Trafc Management and Intelligent Trafc Management does not provide a substitute to Intelligent Network Protection. Both provide complimentary services that aid in the overall security of the switch. Application Switch Element Manager Conguration and management tasks are performed through the Application Switch Element Manager (ASEM). The Application Switch Element Manager provides screens for the conguration, monitoring, and scheduling of Intelligent Network Protection functionality.
Installing Software Keys

Symantec Intelligent Network Protection requires the installation of one or more software keys to enable the feature on the switch. To install these software keys and enable the feature, perform the following procedure: Step 1 2 Action Log into the switch CLI. Install software keys. Symantec Intelligent Network Protection requires the previous installation of the Intelligent Trafc Management and Security Pack features before this feature can be installed. If these features have not been previously installed they must be purchased and installed. Once all software keys have been acquired, they must be installed in the following order: Intelligent Trafc Management Security Pack Symantec Intelligent Network Protection
.
Use the following command to install all software keys:

>> Main# /oper/swkey <software key>
Globally enable Intelligent Network Protection functionality. Globally enable the Intelligent Network Protection functionality using the following command:
>> Main# /boot/symantec ena
The switch will prompt for conrmation of the request. Answer y at the prompt. The switch will then reset and load the Intelligent Network Protection memory management scheme. Note: To disable the Intelligent Network Protection functionality globally, use the command /boot/symantec dis. The switch will prompt for conrmation of the request and reset after answering y at the prompt. End
Conguration Tasks
The tasks listed in this section must be completed to successfully enable Intelligent Network Protection on a switch. Before enabling Intelligent Network Protection, both an Intelligent Trafc Management and Symantec license must be purchased for each switch on which this feature will run. For information on purchasing these licenses, refer to http://www.nortel.com/contactus. The tasks outlined in this section refer to, and make use of, the Application Switch Element Manager. Use of the ASEM is the preferred mode of conguration for Intelligent Network Protection functionality. To enable Intelligent Network Protection, perform the following tasks: Note: Although many of these tasks are represented individually, most can be performed together when running the Trafc Management Wizard in the Application Switch Element Manager. Step 1 Action Log into the switch using SNMPv3.
.
655
Symantec Intelligent Network Protection requires the use of SNMPv3 for switch authentication. Using any other form of SNMP authentication to log into the switch will cause the Intelligent Network Protection options to be unavailable. 2 Open the Trafc Management Wizard. Open the Trafc Management Wizard by selecting Wizards > Trafc Management 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 the Threats - Criticial and Threats-Severe tabs of the Application Selection screen of the Trafc Management Wizard. 5 Schedule signature updates. Symantec signatures can be congured to update automatically using Symantec LiveUpdate functionality. Use the Symantec Schedule button found at the bottom of the Application Selection screen of the Trafc Management Wizard to schedule updates. This screen is also used to determine if signatures will be automatically or manually applied to the switch. 6 Congure application actions. Once threats have been identied and congured for monitoring, the action to take on these threats are congured in the Application Actions screen of the Trafc Management Wizard. End
CLI Command Analogs

Although the primary conguration mechanism for Intelligent Network Protection is the Application Switch Element Manager, many of the procedures performed in the ASEM can also be performed in the CLI. Extension of ASEM functionality into the CLI is primarily provided as a troubleshooting mechanism. "Intelligent Network Protection CLI Commands" (page 656)outlines the Intelligent Network Protection CLI commands.
.
656 Part 4: Advanced Switching Intelligent Network Protection CLI Commands Command /cfg/bwm/cont <contract number> /maxsess <0 - 65534> Description This command limits the number of open sessions per user or application. If Intelligent Traffic Management is in use, this command should not be used. Configuration should take place in the Traffic Management Wizard. This command enables or disables Intelligent Network Protection on a port. Since Intelligent Traffic Management will automatically enable or disable Symantec processing, this command is provided for troubleshooting purposes only. This command manually adds a Symantec signature to bandwidth contract mappings. This command is provided for troubleshooting purposes only. Where possible, this procedure should be performed in the third screen of the Traffic Management Wizard. This command manually removes a Symantec signature to bandwidth contract mappings. This command is provided for troubleshooting purposes only. Where possible, this procedure should be performed in the third screen of the Traffic Management Wizard.
/cfg/slb/port <port number> /symantec {enable | disable}
/cfg/security/symsig <signa ture_id> <inbound_contract> <outbound_contract>
/cfg/security/symdel <signature_id>
Tunable Resources
As features are added to the Nortel Application Switch Operating System, more and more memory is necessary to sufciently support these new features. Since the Nortel Application Switch hardware has not been upgraded to provide this additional capacity, the Tunable Resource feature has been created to provide variable memory proles. The Tunable Resources feature allows switch memory to be allocated based on two types of conguration: Intelligent Trafc Management / Symantec Default
Switches running the Nortel Application Switch Operating System automatically have their memory allocations tuned to the Default conguration. This memory allocation conguration maximizes switch resources to handle day to day operations.
.
657
The Intelligent Trafc Management / Symantec memory allocation conguration maximizes switch performance for the use of the Intelligent Network Protection feature. This memory allocation prole is automatically selected when the user enables the Symantec Intelligent Network Protection feature. Memory allocation proles are not congurable and are selected automatically by the switch. The switch will indicate the current memory allocation conguration when logging into the CLI or by using the /info/sys/general command.
Monitoring Symantec Functionality

Once Intelligent Network Protection is congured, it can be monitored using the ASEM or CLI. Monitoring Intelligent Network Protection functionality will provide information about threat applications that have been ltered and monitored and what applications that are not currently congured but should be. "Intelligent Network Protection Monitoring Tasks" (page 657) outlines the monitoring tasks available in the ASEM and CLI.
Intelligent Network Protection Monitoring Tasks Monitoring Task Symantec Match Statistics ASEM Location Monitor > Security (Several tabs) CLI Command /stat/security/symh its /stat/security/symc lear /info/security/syma ntec /stat/slb/sp <sp_number> /maint /stat/slb/maint
Symantec SP Match Statistics Symantec Maintenanc e Statistics Symantec Engine Statistics
Monitor > Security (Several tabs) Monitor > Layer 4 > SLB > SP Maintenance Monitor > Layer 4 > SLB > SP Maintenance
General Symantec Information

The ASEM application also provides general information about the Symantec conguration on the administered switch. "General Symantec Information" (page 658) outlines the information provided by the application.
.
658 Part 4: Advanced Switching General Symantec Information Symantec Information License Expiration ASEM Location Configure > Security > General Description The number of days left on the current Symantec license. Licenses expire within 365 days after the first signature download. The default action the switch applies to newly downloaded signatures. The Traffic Management Wizard is used to set the long term signature policy. The version of the Symantec security engine currently running on the switch. Indicates whether a license renewal is pending.
LiveUpdate Default Action
Configure > Security > General
Scan Engine Version
Symantec Pending License Renewal
Signature Names
All Symantec signatures used in Intelligent Network Protection functionality follow a specic naming scheme where le names are as follows: YYYYMMDDNN where: Step 1 2 3 4 Action YYYY = The year the signature was issued. MM = The month the signature was issued. DD = The day the signature was issued. NN = The iteration number of the signature issued on the date specied by the previous three name components. End
.
659
Conguration Example
This section contains a Nortel Symantec Intelligent Network Protection example conguration. This conguration example assumes that client port 5 and server port 6 are Symantec enabled. Trafc in this example is being sent at 10 Mbps but rate limited to 5 Mbps as dened in the policy in the example. Take the following steps to create the sample conguration: Step 1 Action Congure the switch management port options.
/cfg/sys/mmgmt addr 47.80.20.103 mask 255.255.255.0 broad 47.80.20.255 gw 47.80.20.1 tftp mgmt report mgmt ena
Congure the physical switch management port options.

/cfg/sys/mmgmt/port speed any mode any auto on
Associate action and bandwidth contracts with Symantec signatures.

/cfg/sec/ symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig
20595 20596 20267 20268 20269 20270 20271 20272 20273 20274 20294 20295 20296 20275 20293 20297
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
.
symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig
20276 20148 20277 20298 20278 20299 20300 20301 20302 20575 20597 20303 20304 20305 20279 20179 20306 20307 20598 20309 20310 20311 20313 20314 20315 20316 20317 20280 20281 20282 20283 20284 20285 20319 20286 20318 20287 20320 20599 20288 20289 20321 20600 20290 20322 20601 20291 20292 20715 20021
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
.
661
symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig symsig
20076 1 2 20958 1 2 20359 1 2 21298 1 2 20716 1 2 21744 1 2 21732 1 2 21320 1 2 21750 1 2 20704 1 2 20726 1 2 21265 1 2 21297 1 2 21319 1 2 21256 1 2 20727 1 2 20094 1 2 21391 1 2 20706 1 2 20633 1 2 20634 1 2 20097 7 8 20098 7 8 20088 7 8 20077 7 8 20767 7 8 20086 7 8 20087 7 8 20074 7 8 20326 7 8 20765 7 8 21701 7 8 21702 7 8 20022 7 8 20023 7 8 20024 7 8 20637 7 8 20763 7 8 21266 7 8 100101 11 100102 12 100103 13 100104 14 100105 15
11 12 13 14 15
Congure switch access.
.
/cfg/sys/access snmp w http ena tnet ena
Congure port options.

/cfg/port 5 cont 3 nonip 5 /cfg/port 6 cont 4 nonip 6
Congure general bandwidth management options.

/cfg/bwm on report 47.80.20.88 email dis
Congure bandwidth management contracts.

/cfg/bwm/cont 1 ena name "Symantec-Severe_IN" pol 1 prec 255 /cfg/bwm/cont 2 ena name "Symantec-Severe_OUT" pol 2 prec 255 /cfg/bwm/cont 3 ena name "OTHER_IN" mononly ena /cfg/bwm/cont 4 ena name "OTHER_OUT" mononly ena /cfg/bwm/cont 5 ena name "NONIP_IN" mononly ena /cfg/bwm/cont 6 ena name "NONIP_OUT"
.
663
mononly ena /cfg/bwm/cont 7 ena name "Symantec-Critical_IN" pol 1 prec 255 /cfg/bwm/cont 8 ena name "Symantec-Critical_OUT" pol 2 prec 255 /cfg/bwm/cont 11 ena pol 11 /cfg/bwm/cont 12 ena pol 12 /cfg/bwm/cont 13 ena pol 13 /cfg/bwm/cont 14 ena pol 14 /cfg/bwm/cont 15 ena pol 15
Congure bandwidth management policies.

/cfg/bwm/pol 1 hard 5M soft 0K resv 0K userlim 5M /cfg/bwm/pol 2 hard 6M soft 0K resv 0K userlim 6M /cfg/bwm/pol 11 hard 10M soft 9M /cfg/bwm/pol 12 hard 10M soft 9M /cfg/bwm/pol 13 hard 10M soft 9M /cfg/bwm/pol 14 hard 10M

.
soft 9M /cfg/bwm/pol 15 hard 10M soft 9M

/cfg/slb on
10
Enable Nortel Symantec functionality.

/cfg/slb/port 5 symantec ena /cfg/slb/port 6 symantec ena
11
Congure SLB lters.

/cfg/slb/filt 2043 name "L7_INSPECT_IN" ena action allow ipver v4 sip any smask 0.0.0.0 dip any dmask 0.0.0.0 vlan any /cfg/slb/filt 2043/adv cont 3 /cfg/slb/filt 2044 name "L7_INSPECT_OUT" ena action allow ipver v4 sip any smask 0.0.0.0 dip any dmask 0.0.0.0 vlan any /cfg/slb/filt 2044/adv cont 4
12
Enable SLB lters.
.
665
/cfg/slb/port 5 filt ena add 2043 /cfg/slb/port 6 filt ena add 2044
End
Troubleshooting
This section details known situations that may arise out of the operation of the Symantec Intelligent Network Protection functionality. Where possible, workarounds for these situations are provided.
Conguration Synchronization - Different Memory Proles

The situation may arise in a networked environment where two switches synchronize their congurations but do not share the same memory proles (see "Tunable Resources" (page 656)). In this instance, not all conguration changes may be transferred successfully from one switch to another. Consider the following example. Switch B synchronizes its conguration with Switch A. Switch A is currently running the Symantec memory prole and Switch B is running the default memory prole. Additionally, Symantec processing is enabled on port 1 of Switch A and disabled on port 1 of Switch B. Although the system messages from the switch will indicate success during the conguration synchronization, Symantec processing will never be enabled on port 1 of Switch B until Symantec processing is enabled on the switch and Switch B is placed into the Symantec memory prole. This is due in part to the fact that the Symantec Intelligent Network Protection functionality is licensed per switch and this license cannot be shared between switches. In the above example, Switch B would have fully accepted Switch As conguration if a Symantec license had been purchased for it and the switch placed into the Symantec memory prole.
Conguration Synchronization - Similar Memory Proles

The situation may arise in a networked environment where two switches that synchronize their congurations deviate from one another because of administrator intervention. Consider the following example.
.
Switch A synchronizes its conguration with Switch B. Both Switch A and Switch B are currently running the Symantec memory prole (see "Tunable Resources" (page 656)). Additionally, Symantec processing is enabled on port 1 of Switch A and Switch B. If an administrator disables Symantec processing on Switch A it will revert to the default memory prole, disable Symantec processing previously congured on port 1 and reboot. The congurations of Switch A and B will remain inconsistent until such time as the congurations are synchronized.
.
Firewall Load Balancing
667

Firewall Load Balancing (FWLB) with Nortel Application Switches allows multiple active rewalls to operate in parallel. Parallel operation allows users to maximize rewall productivity, scale rewall performance without forklift upgrades, and eliminate the rewall as a single point-of-failure. This chapter presents the following topics: "Firewall Overview" (page 667) An overview of rewalls and the various FWLB solutions supported by Nortel Application Switches. "Basic FWLB" (page 669) Explanation and example conguration for FWLB in simple networks, using two parallel rewalls and two application switches. The basic FWLB method combines redirection lters and static routing for FWLB. "Four-Subnet FWLB" (page 682) Explanation and example conguration for FWLB in a large-scale, high-availability network with redundant rewalls and application switches. This method combines redirection lters, static routing, and Virtual 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 for servers that attach to the Nortel Application Switch between the Internet and the rewalls. "Firewall Health Checks" (page 706). Methods for ne-tuning the health checks performed for FWLB.
Firewall Overview
Firewall devices have become indispensable for protecting network resources from unauthorized access. Prior to FWLB, however, rewalls could become critical bottlenecks or single points-of-failure for your network. As an example, consider the following network:
.
668 Part 4: Advanced Switching Typical Firewall Conguration Before FWLB
One network interface card on the rewall is connected to the public side of the network, often to an Internet router. This is known as the dirty or untrusted side of the rewall. Another network interface card on the rewall is connected to the side of the network with the resources that must be protected. This is known as the clean or trusted side of the rewall. In this simple example, all trafc passing between the dirty, clean, and DMZ networks must traverse the rewall, which examines each individual packet. The rewall is congured with a detailed set of rules that determine which types of trafc are allowed and which types are denied. Heavy trafc can turn the rewall into a serious bottleneck. The rewall is also a single point-of-failure device. If it goes out of service, external clients can no longer reach your services and internal clients can no longer reach the Internet. Sometimes, a Demilitarized Zone (DMZ) is attached to the rewall or between the Internet and the rewall. Typically, a DMZ contains its own servers that provide dirty-side clients with access to services, making it unnecessary for dirty-side trafc to use clean-side resources. FWLB with Nortel Application Switches provides a variety of options that enhance rewall performance and resolve typical rewall 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 lters and is usually employed in smaller networks. A Nortel Application Switch lter on the dirty-side splits incoming trafc into streams headed for different rewalls. To ensure persistence of session trafc through the same rewall, distribution is based on a mathematical 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
.
669
Although similar to basic FWLB, the four-subnet method is more often deployed in larger networks that require high-availability solutions. This method adds Virtual Router Redundancy Protocol (VRRP) to the conguration. Just as with the basic method, four-subnet FWLB uses the hash metric to distribute rewall trafc and maintain persistence. For more information, see "Four-Subnet FWLB" (page 682). Each method is described in more detail in the following sections.
Basic FWLB
The basic FWLB method uses a combination of static routes and redirection lters to allow multiple active rewalls to operate in parallel. "Basic FWLB Topology" (page 669) shows a basic FWLB topology:
Basic FWLB Topology
The rewalls being load balanced are in the middle of the network, separating the dirty side from the clean side. This conguration requires a minimum of two application switches: one on the dirty side of the rewalls and one on the clean side. A redirection lter on the dirty-side application switch splits incoming client trafc into multiple streams. Each stream is routed through a different rewall. The same process is used for outbound server responses; a redirection lter on the clean-side application switch splits the trafc, and static routes forward each stream through a different rewall and then back to the client. Although other metrics can be used in some congurations (see "Free-Metric FWLB" (page 701)), the distribution of trafc within each stream is normally based on a mathematical hash of the source IP address and destination IP addresses. This ensures that each client request and its related responses
.
will use the same rewall (a feature known as persistence) and that the trafc will be equally distributed. The persistence is required for the rewall as it maintains state and processes trafc in both directions for a connection. Although basic rewall load-balancing techniques can support more rewalls as well as multiple switches on the clean and dirty sides for redundancy, the conguration complexity increases dramatically. The four-subnet FWLB solution is usually preferred in larger scale, high-availability topologies (see "Four-Subnet FWLB" (page 682)).
Basic FWLB Implementation

In this example, trafc is load balanced among the available rewalls.
Basic FWLB Process
Step 1
Action The client requests data. The external clients intend to connect to services at the publicly advertised IP address assigned to a virtual server on the clean-side application switch.
A redirection lter balances incoming requests among different IP addresses. When the client request arrives at the dirty-side application switch, a lter redirects it to a real server group that consists of a number of different IP addresses. This redirection lter splits the trafc into balanced streams: one for each IP address in the real server group. For FWLB, each IP address in the real server group represents an IP Interface (IF) on a different subnet on the clean-side application switch.
Requests are routed to the rewalls.
.
671
On the dirty-side switch, one static route is needed for each trafc stream. For instance, the rst static route will lead to an IP interface on the clean-side application switch using the rst rewall as the next hop. A second static route will lead to a second clean-side IP interface using the second rewall as the next hop, and so on. By combining the redirection lter and static routes, trafc is load balanced among all active rewalls. All trafc between specic IP source/destination address pairs ows through the same rewall, ensuring that sessions established by the rewalls persist for their duration. Note: More than one stream can be routed though a particular rewall. You can weight the load to favor one rewall by increasing the number of static routes that traverse it. 4 The rewalls decide if they should allow the packets and, if so, forwards them to a virtual server on the clean-side application switch. Client requests are forwarded or discarded according to rules congured for each rewall. Note: Rule sets must be consistent across all rewalls. 5 The clean-side application switch performs normal SLB functions. Packets forwarded from the rewalls are sent to the original destination address, that is, the virtual server on the clean-side application switch. There, they are load balanced to the real servers using standard SLB conguration. 6 7 The real server responds to the client request. Redirection lters on the clean-side application switch balance responses among different IP addresses. Redirection lters are needed on all ports on the clean-side application switch that attach to real servers or internal clients on the clean-side of the network. Filters on these ports redirect the Internet-bound trafc to a real server group that consists of a number of different IP addresses. Each IP address represents an IP interface on a different subnet on the dirty-side application switch. 8 Outbound trafc is routed to the rewalls. Static routes are congured on the clean-side switch. One static route is needed for each stream that was congured on the dirty-side application switch. For instance, the rst static route would be congured to lead to the rst dirty-side IP interface using the rst
.
rewall as the next hop. The second static route would lead to the second dirty-side IP interface using the second rewall as the next hop, and so on. Since application switches intelligently maintain state information, all trafc between specic IP source/destination addresses ows through the same rewall, maintaining session persistence. Note: If Network Address Translation (NAT) software is used on the rewalls, FWLB session persistence requires the RTS option to be enabled on the application switch (see "Free-Metric FWLB" (page 701)). 9 The rewall decides if it should allow the packet and, if so, forwards it to the dirty-side application switch. Each rewall forwards or discards the server responses according to the rules that are congured for it. Forwarded packets are sent to the dirty-side application switch and out to the Internet. 10 The client receives the server response. End
Conguring Basic FWLB

The steps for conguring basic FWLB are provided below. While two or four switches can be used, the following procedure assumes a simple network topology with only two application switches (one on each side of the rewalls) as shown in "Basic FWLB Example Network" (page 672).
Basic FWLB Example Network
.
673
Congure the Dirty-Side Nortel Application Switch

Step 1 Action Congure VLANs. Note: Alternately, if using hubs between the switches and rewalls and you do not wish to congure VLANs, you must enable Spanning Tree Protocol to prevent broadcast loops. 2 Dene the dirty-side IP interface. In addition to one IP interface for general switch management, there must be one dirty-side IP interface for each rewall path being load balanced. Each must be on a different subnet.
>> # /cfg/l3/if 1 >> IP Interface 1# addr 192.16.12.1 >> IP Interface 1# mask 255.255.255.0 >> IP Interface 1# ena >> IP Interface 1# /cfg/l3/if 2 >> IP Interface 2# addr 10.1.1.1 >> IP Interface 2# mask 255.255.255.0 >> IP Interface 2# ena >> IP Interface 2# /cfg/l3/if 3 >> IP Interface 3# addr 10.1.2.1 >> IP Interface 3# mask 255.255.255.0 >> IP Interface 3# ena (Select IP interface 1) (Set address for switch management) (Set subnet mask for interface 1) (Enable IP interface 1) (Select IP interface 2) (Set the IP address for interface 2) (Set subnet mask for interface 2) (Enable IP interface 2) (Select IP interface 3) (Set the IP address for interface 3) (Set subnet mask for interface 3) (Enable IP interface 3)
Congure the clean-side IP interface as if they were real servers on the dirty side. Later in this procedure, youll congure one clean-side IP interface on a different subnet for each rewall path being load balanced. On the dirty-side application switch, create two real servers using the IP address of each clean-side IP interface used for FWLB. Note: The real server index number must be the same on both sides of the rewall. For example, if real server 1 is the dirty-side
.
IP interface for Firewall 1, then congure real server 1 on the clean side with the dirty-side IP interface. Conguring the same real server number on both sides of the rewall ensures that the trafc travels through the same rewall.
>> IP Interface 3# /cfg/slb/rea l 1 >> Real server 1# rip 10.1.3.1 >> Real server 1# ena >> Real server 1# /cfg/slb/real 2 >> Real server 2# rip 10.1.4.1 >> Real server 2# ena (Select real server 1) (Assign clean-side IF 2 address) (Enable real server 1) (Select real server 2) (Assign clean-side IF 3 address) (Enable real server 1)
Real servers in the server groups must be ordered the same on both clean side and dirty side switch. For example, if real server 1 IP interface connects to Firewall 1 for clean side server group, then real server 1 IP interface on the dirty side should be connected to Firewall 1. Selecting the same real server ensures that the trafc travels through the same rewall. Note: Each of the four interfaces used for FWLB (two on each application switch) in this example must be congured for a different IP subnet. 4 Place the IP interface real servers into a real server group.
>> Real server 2# /cfg/slb/group 1 >> Real server group 1# add 1 >> Real server group 1# add 2 (Select real server group 1) (Add real server 1 to group 1) (Add real server 2 to group 1)
Set the health check type for the real server group to ICMP.
>> Real server group 1# health icmp (Select ICMP as health check type)
Set the load-balancing metric for the real server group to hash.
.
675
>> Real server group 1# metric hash
(Select SLB hash metric for group 1)
Using the hash metric, all trafc between specic IP source/destination address pairs ows through the same rewall. This ensures that sessions established by the rewalls are maintained for their duration. Note: Other load balancing metrics such as leastconns, roundrobin, minmiss, response, and bandwidth can be used when enabling the Return to Sender (RTS) option. For more information, see "Free-Metric FWLB" (page 701). 7 Enable SLB on the switch.
>> Real server group 1# /cfg/slb/on
Create a lter to allow local subnet trafc on the dirty side of the rewalls to reach the rewall interfaces.
>> Layer 4# /cfg/slb/filt 10 >> Filter 10# sip any >> Filter 10# dip 192.16.12.0 >> Filter 10# dmask 255.255.25 5.0 >> Filter 10# action allow >> Filter 10# ena (Select filter 10) (From any source IP address) (Specify destination IP address) (Specify destination mask) (Allow frames with this DIP address) (Enable filter)
Create the FWLB redirection lter. This lter will redirect inbound trafc, load balancing it among the dened real servers in the group. In this network, the real servers represent IP interfaces on the clean-side application switch.
>> Filter 10# /cfg/slb/filt 15 >> Filter 15# sip any >> Filter 15# dip any >> Filter 15# proto any >> Filter 15# action redir (Select filter 15) (From any source IP address) (To any destination IP address) (For any protocol) (Perform redirection)
.
>> Filter 15# group 1 >> Filter 15# ena
(To real server group 1) (Enable the filter)
10
Enable rewall load balancing

>> Filter 15# adv/redir/fwlb ena
11
Add lters to the ingress port.

>> Filter 15# /cfg/slb/port 1 >> SLB Port 1# add 10 >> SLB Port 1# add 15 >> SLB Port 1# filt ena (Select the ingress port) (Add the filter to the ingress port) (Add the filter to the ingress port) (Enable filtering on the port)
12
Dene static routes to the clean-side IP interfaces, using the rewalls as gateways. One static route is required for each rewall path being load balanced. In this case, two paths are required: one that leads to clean-side IF 2 (10.1.3.1) through the rst rewall (10.1.1.10) as its gateway, and one that leads to clean-side IF 3 (10.1.4.1) through the second rewall (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.255 10.1.1.10 >> IP Static Route# add 10.1.4.1 255.255.255.255 10.1.2.10
13
Apply and save the conguration changes

End
.
677
Congure the Clean-Side Nortel Application Switch

Step 1 Action Dene the clean-side IP interfaces. Create one clean-side IP interface on a different subnet for each rewall being load balanced. Note: An extra IP interface (IF 1) prevents server-to-server trafc from being redirected.
>> # /cfg/l3/if 1 >> IP Interface 1# addr 20.1.1.1 >> IP Interface 1# mask 255.255.255.0 >> IP Interface 1# ena >> IP Interface 1# /cfg/l3/if 2 >> IP Interface 2# addr 10.1.3.1 >> IP Interface 2# mask 255.255.255.0 >> IP Interface 2# ena >> IP Interface 2# /cfg/l3/if 3 >> IP Interface 3# addr 10.1.4.1 >> IP Interface 3# mask 255.255.255.0 >> IP Interface 3# ena (Select IP interface 1) (Set the IP address for interface 1) (Set subnet mask for interface 1) (Enable IP interface 1) (Select IP interface 2) (Set the IP address for interface 2) (Set subnet mask for interface 2) (Enable IP interface 2) (Select IP interface 3) (Set the IP address for interface 3) (Set subnet mask for interface 3) (Enable IP interface 3)
Congure the dirty-side IP interfaces as if they were real servers on the clean side. You should already have congured a dirty-side IP interface on a different subnet for each rewall path being load balanced. Create two real servers on the clean-side switch, using the IP address of each dirty-side IP interface. Note: The real server index number must be the same on both sides of the rewall. For example, if real server 1 is the dirty-side IP interface for Firewall 1, then congure real server 1 on the clean side with the dirty-side IP interface. Conguring the same real server number on both sides of the rewall ensures that the trafc travels through the same rewall.

.
>> IP Interface 5# /cfg/slb/rea l 1 >> Real server 1# rip 10.1.1.1 >> Real server 1# ena >> Real server 1# /cfg/slb/real 2 >> Real server 2# rip 10.1.2.1 >> Real server 2# ena
(Select real server 1) (Assign dirty-side IF 1 address) (Enable real server 1) (Select real server 2) (Assign dirty-side IF 2 address) (Enable real server 2)
Note: Each of the four IP interfaces (two on each application switch) in this example must be congured for a different IP subnet. 3 Place the real servers into a real server group.
>> Real server 2# /cfg/slb/grou p 1 >> Real server group 1# add 1 >> Real server group 1# add 2 (Select real server group 1) (Select real server 1 to group 1) (Select real server 2 to group 1)
Set the health check type for the real server group to ICMP.
>> Real server group 1# health icmp (Select ICMP as health check type)
Set the load-balancing metric for the real server group to hash.
>> Real server group 1# metric hash (Select SLB hash metric for group 1)
Note: The clean-side application switch must use the same metric as dened on the dirty side. 6 Enable server load balancing on the switch.
Congure ports 2 and 3, which are connected to the clean-side of the rewalls, for client processing.
.
679
>> Real server group 1# /cfg/slb/port 2/client ena (Enable client processing on port 2) >> SLB port 2# /cfg/slb/port 3/client ena >> SLB port 3# apply >> SLB port 3# save (Enable client processing on port 3) (Apply the configuration) (Save the configuration)
Congure the virtual server that will load balance the real servers.
>> SLB port 3# /cfg/slb/virt 100 >> Virtual Server 100# vip 20.1.1.10 >> Virtual Server 100# ena (Configure virtual server 100) (Assign virtual server 100 IP address) (Enable the virtual server)
Congure the real servers to which trafc 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 >> Real server 2 # ena >> Real server 2 # /cfg/slb/rea l 4 >> Real server 3# ena 20.1.1.3 (Select real server 3) (Assign real server 2 IP address) (Enable real server 2) (Select real server 4) (Assign real server 3 IP address)
10
Place the real servers into a real server group.

>> Real server 3# /cfg/slb/grou p 200 >> Real server group 200# add 3 >> Real server group 200# add 4 (Select real server group 1) (Select real server 2 to group 200) (Select real server 3 to group 200)
11
Congure ports 4 and 5, which are connected to the real servers, 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 lter to prevent server-to-server trafc from being redirected.

>> Layer 4# /cfg/slb/filt 10 >> Filter 10# sip any >> Filter 10# dip 20.1.1.0 >> Filter 10# dmask 255.255.255.0 >> Filter 10# proto any >> Filter 10# action allow >> Filter 10# ena (Select filter 10) (From any source IP address) (To base IP address for IF 5) (For the range of addresses) (For any protocol) (Allow traffic) (Enable the filter)
14
Create the redirection lter. This lter will redirect outbound trafc, load balancing it among the dened real servers in the group. In this case, the real servers represent IP interfaces on the dirty-side switch.
>> Filter 10# /cfg/slb/filt 15 >> Filter 15# sip any >> Filter 15# dip any >> Filter 15# proto any >> Filter 15# action redir >> Filter 15# group 1 >> Filter 15# ena (Select filter 15) (From any source IP address) (To any destination IP address) (For any protocol) (Perform redirection) (To real server group 1) (Enable the filter)
15
Add the lters to the ingress ports for the outbound packets. Redirection lters are needed on all the ingress ports on the clean-side application switch. Ingress ports are any that attach to real servers or internal clients on the clean-side of the network. In this case, two real servers are attached to the clean-side application switch on port 4 and port 5.
.
681
>> Filter 15# /cfg/slb/port 4 >> SLB Port 4# add 10 >> SLB Port 4# add 15 >> SLB Port 4# filt ena >> SLB Port 4# /cfg/slb/port 5 >> SLB Port 5# add 10 >> SLB Port 5# add 15 >> SLB Port 5# filt ena
(Select ingress port 4) (Add the filter to the ingress port) (Add the filter to the ingress port) (Enable filtering on the port) (Select ingress port 5) (Add the filter to the ingress port) (Add the filter to the ingress port) (Enable filtering on the port)
16
Dene static routes to the dirty-side IP interfaces, using the rewalls as gateways. One static route is required for each rewall path being load balanced. In this case, two paths are required: one that leads to dirty-side IF 2 (10.1.1.1) through the rst rewall (10.1.3.10) as its gateway, and one that leads to dirty-side IF 3 (10.1.2.1) through the second rewall (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.255 10.1.3.10 >> IP Static Route# add 10.1.2.1 255.255.255.255 10.1.4.10
Note: Conguring static routes for FWLB does not require IP forwarding to be turned on. 17 Apply and save the conguration changes
End
.
Four-Subnet FWLB
The four-subnet FWLB method is often deployed in large networks that require high-availability solutions. This method uses ltering, static routing, and Virtual Router Redundancy Protocol (VRRP) to provide parallel rewall operation between redundant application switches. "Four-Subnet FWLB Topology" (page 682) shows one possible network topology using the four-subnet method:
Four-Subnet FWLB Topology
This network is classied as a high-availability network because no single component or link failure could cause network resources to become unavailable. Simple switches and vertical block interswitch connections are used to provide multiple paths for network failover. However, the interswitch links may trunked together with multiple ports for additional protection from failure. Note: Other topologies that use internal hubs, or diagonal cross-connections between the Nortel Application Switches and simple switches are also possible. While such topologies may resolve networking issues in special circumstances, they can make conguration more complex and can cause restrictions on the use of advanced features such as Active-Active VRRP, free-metric FWLB, or Content Intelligent Switching. Alternate topologies are explored in more detail in Nortel Application Switch Operating System FWLB white papers, but are not within the scope of this manual. As shown in "Four-Subnet FWLB Topology" (page 682), the network is divided into four sections: Subnet 1 includes all equipment between the exterior routers and dirty-side application switches. Subnet 2 includes the dirty-side application switches with their interswitch link, and dirty-side rewall interfaces.
.
683
Subnet 3 includes the clean-side rewall interfaces, and clean-side application switches with their interswitch link. Subnet 4 includes all equipment between the clean-side application switches and their servers.
In this network, external trafc arrives through both routers. Since VRRP is enabled, one of the dirty-side application switches acts as primary and receives all trafc. The dirty-side primary application switch performs FWLB in a fashion similar to basic FWLB: a redirection lter splits trafc into multiple streams which are routed through the available rewalls to the primary clean-side application switch. Just as with the basic method, four-subnet FWLB uses the hash metric to distribute rewall trafc and maintain persistence, though other load-balancing metrics can be used by conguring an additional Return to Sender (RTS) option (see "Free-Metric FWLB" (page 701)).
Four-Subnet FWLB Implementation

In this example, trafc between the redundant Nortel Application Switches is load balanced among the available rewalls.
Four-Subnet FWLB Process
Step 1
Action Incoming trafc converges on the primary dirty-side application switch. External trafc arrives through redundant routers. A set of interconnected switches ensures that both routers have a path to each dirty-side application switch.
.
VRRP is congured on each dirty-side application switch so that one acts as the primary routing switch. If the primary fails, the secondary takes over. 2 FWLB is performed between primary application switches. Just as with basic FWLB, lters on the ingress ports of the dirty-side application switch redirect trafc to a real server group composed of multiple IP addresses. This conguration splits incoming trafc into multiple streams. Each stream is then routed toward the primary clean-side application switch through a different rewall. Although other load balancing metrics can be used in some congurations (see "Free-Metric FWLB" (page 701)), the distribution of trafc within each stream is normally based on a mathematical hash of the IP source and destination addresses. Hashing ensures that each request and its related responses will use the same rewall (a feature known as persistence), and that the streams will be statistically equal in trafc load. 3 The primary clean-side application switch forwards the trafc to its destination. Once trafc arrives at the primary clean-side application switch, it is forwarded to its destination. In this example, the application switch uses regular server load balancing settings to select a real server on the internal network for each incoming request. The same process is used for outbound server responses; a lter on the clean-side application switch splits the trafc, and static routes forward each response stream back through the same rewall that forwarded the original request. End
Conguring Four-Subnet FWLB

An example network for four-subnet FWLB is illustrated in "Four-Subnet FWLB Example Network" (page 685). While other complex topologies are possible, this example assumes a high-availability network using block (rather than diagonal) interconnections between switches.
.
Firewall Load Balancing Four-Subnet FWLB Example Network
685
Note: The port designations of both dirty-side application switches are identical, as are the port designations of both clean-side application switches. This simplies conguration by allowing you to synchronize each primary application switchs conguration with the secondary. Four-subnet FWLB conguration is summarized as follows: Congure routers and rewalls and test them for proper operation. Congure VLANs, IP interfaces, and static routes on all application switches and test them. Congure secondary application switches with VRRP support settings. Congure FWLB groups and redirection lters on the primary dirty-side application switch. Congure and synchronize VRRP on the primary dirty-side application switch. Congure FWLB and SLB groups, and add FWLB redirection lters on the primary clean-side application switch. Congure VRRP on the primary clean-side application switch and synchronize the secondary.
These steps are explained in detail in the following sections.
Congure the Routers

The routers must be congured with a static route to the destination services being accessed by the external clients.
.
In this example, the external clients intend to connect to services at a publicly advertised IP address on this network. Since the real servers are load balanced behind a virtual server on the clean-side application switch using normal SLB settings, the routers require a static route to the virtual server IP address. The next hop for this static route is the application switch Virtual Interface Router (VIR), which is in the same subnet as the routers:
Route Added: 10.10.4.100 (to clean-side virtual server) via 195.1.1.9 (Subnet 1 VIR)
Congure the Firewalls

Before you congure theNortel Application Switches, the rewalls must be properly congured. For incoming trafc, each rewall must be congured with a static route to the clean-side virtual server, using the VIR in its clean-side subnet as the next hop. For outbound trafc, each rewall must use the VIR in its dirty-side subnet as the default gateway. In this example, the rewalls are congured with the following IP addresses:
Four-Subnet Firewall IP Address Conguration Item Firewall 1 Dirty-side IP interface Clean-side IP interface Default Gateway Route Added 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 (Subnet 3 VIR) 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 (Subnet 3 VIR) Address
The rewalls must also be congured with rules that determine which types of trafc will be forwarded through the rewall and which will be dropped. All rewalls participating in FWLB must be congured with the same set of rules.
.
687
Note: It is important to test the behavior of the rewalls prior to adding FWLB.
Congure the Primary Dirty-Side Switch

Step 1 Action Congure VLANs on the primary dirty-side application switch. Two VLANs are required. VLAN 1 includes port 25, for the Internet connection. VLAN 2 includes port 26, for the rewall connection, and port 28, for the interswitch connection.
>> # /cfg/l2/vlan 2 >> # add 26 >> # add 28 >> # ena (Port 26 connects to the firewall) (Port 28 is the inter-switch connection)
Note: Port 25 is part of VLAN 1 by default and does not require manual conguration. 2 Congure IP interfaces on the primary dirty-side application switch. Three IP interfaces (IFs) are used. IF 1 is on placed on Subnet 1. IF 2 will be used for routing trafc through the top rewall. IF 3 will be used for routing trafc through the lower rewall. 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 conguring the IP interface mask prior to the IP address, the broadcast address is automatically calculated. Also,
.
only the rst IP interface in a given subnet is given the full subnet range mask. Subsequent IP interfaces (such as IF 3) are given individual masks. 3 Turn Spanning Tree Protocol (STP) off for the primary dirty-side application switch.
>> # /cfg/l2/stg #/off
Congure static routes on the primary dirty-side application switch. 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 switches whenever routing through the top rewall, and IF 3 is being used on all application switches whenever routing through the lower rewall. The static route add command uses the following format: add <destination address> <dest. address> <source interface> mask> <gateway
This example requires the following static route conguration:

>> >> >> >> >> # # # # # /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 dening static routes for FWLB, it is important to specify the source IP interface numbers. 5 When dynamic routing protocols are not used, congure a gateway to the external routers.
>> # /cfg/l3/gw 1/addr 195.1.1.1 >> # /cfg/l3/gw 2/addr 195.1.1.2
Make your changes take effect.


.
689
>> # apply >> # save >> # /boot/reset
End
Congure the Secondary Dirty-Side Switch

Except for the IP interfaces, this conguration is identical to the primary dirty-side application switch. Step 1 Action Congure VLANs on the secondary dirty-side application switch.
>> >> >> >> # # # # /cfg/l2/vlan 2 add 26 add 28 ena
Congure IP interfaces on the secondary dirty-side application switch.

>> >> >> >> >> >> >> >> >> >> >> >> >> >> # # # # # # # # # # # # # # /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
Turn STP off for the secondary dirty-side application switch.

Congure static routes on the secondary dirty-side application switch.
.
>> >> >> >> >>
# # # # #
/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
When dynamic routing protocols are not used, congure a gateway to the external routers on the secondary dirty-side switch.
>> # /cfg/l3/gw 1/addr 195.1.1.1 >> # /cfg/l3/gw 2/addr 195.1.1.2

End
Congure the Primary Clean-Side Switch

Step 1 Action Congure VLANs on the primary clean-side application switch. Two VLANs are required. VLAN 3 includes the rewall port and interswitch connection port. VLAN 4 includes the port that attaches to the real servers.
>> >> >> >> >> >> >> # # # # # # # /cfg/l2/vlan 3 add 25 add 28 ena /cfg/l2/vlan 4 add 26 ena
Congure IP interfaces on the primary clean-side application switch.
.
691
>> >> >> >> >> >> >> >> >> >> >> >> >> >> >>
# # # # # # # # # # # # # # #
/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
Turn STP off for the primary clean-side application switch.

>> # /cfg/l2/stg/off
Spanning Tree Protocol is disabled because VLANs prevent broadcast loops. 4 Congure static routes on the primary clean-side application switch. 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. address> <source interface> mask> <gateway
This example requires the following static route conguration:



.
End
Congure the Secondary Clean-Side Switch

Step 1 Action Congure VLANs on the secondary clean-side application switch.
>> >> >> >> >> >> >> # # # # # # # /cfg/l2/vlan 3 add 25 add 28 ena /cfg/l2/vlan 4 add 26 ena
Congure IP interfaces on the secondary clean-side application switch.

>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> # # # # # # # # # # # # # # # /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
Turn STP off for the secondary clean-side application switch.

.
693
Spanning Tree Protocol is disabled because VLANs prevent broadcast loops. 4 Congure static routes on the secondary clean-side application switch.

End
Verify Proper Connectivity

To verify proper conguration up to this point, use the ping option to test network connectivity. At each Nortel Application Switch, you should receive a valid response when pinging the destination addresses established in the static routes. For example, on the secondary clean-side application switch, the following commands should receive a valid response:
>> # ping Response; >> # ping Response; >> # ping Response; >> # ping Response; 10.10.2.1 10.10.2.1: #1 OK, RTT 1 msec. 10.10.2.2 10.10.2.2: #1 OK, RTT 1 msec. 10.10.2.11 10.10.2.11: #1 OK, RTT 1 msec. 10.10.2.12 10.10.2.12: #1 OK, RTT 1 msec.
Congure VRRP on the Secondary Dirty-Side Switch

The secondary dirty-side application switch must be congured with the primary as its peer. Once this is done, the secondary application switch will get the remainder of its conguration from the primary when synchronized in a later step.
.
In this example, the secondary application switch is congured to use primary 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
Congure VRRP on the Secondary Clean-Side Switch

In this example, the secondary application switch uses primary clean-side interface 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 Conguration

Step 1 Action Create an FWLB real server group on the primary dirty-side application switch. A real server group is used as the target for the FWLB redirection lter. Each IP address that is assigned to the group represents a path through a different rewall. In this case, since two rewalls are used, two addresses are added to the group. Earlier, it was stated that this example uses IF 2 on all application switches whenever routing through the top rewall, and IF 3 on all application switches whenever routing through the lower rewall. Therefore, the rst address will represent the primary clean-side IF 2, and the second represents the primary clean-side IF 3.
.
695
>> >> >> >> >> >> >> >> >> >> >> >>
# # # # # # # # # # # #
/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 trafc between specic IP source/destination address pairs ows through the same rewall, ensuring that sessions established by the rewalls are maintained for their duration (persistence). Note: Other load balancing metrics, such as leastconns, roundrobin, minmiss, response, and bandwidth, can be used when enabling the Return to Sender (RTS) option. For more information, see "Free-Metric FWLB" (page 701). 2 Create the FWLB lters. Three lters are required on the port attaching to the routers:
>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>
Filter 10 prevents local trafc from being redirected. Filter 20 prevents VRRP trafc (and other multicast trafc on the reserved 224.0.0.0/24 network) from being redirected. Filter 2048 redirects the remaining trafc to the rewall 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
.
Congure VRRP on the primary dirty-side application switch. VRRP in this example requires two virtual routersone for the subnet attached to the routers, and one for the subnet attached to the rewalls.
>> # /cfg/l3/vrrp >> # on >> # vr 1 >> # vrid 1 >> # addr 195.1.1.9 >> >> >> >> >> >> >> >> # # # # # # # # if 1 prio 101 share dis ena track ifs ena ports ena /cfg/l3/vrrp/vr 2 (Configure virtual router 2) (For the subnet attached to the firewall) (Configure virtual router 1) (For the subnet attached to the routers)
>> # vrid 2 >> # addr 10.10.2.9 >> >> >> >> >> >> >> # # # # # # # if 2 prio 101 share dis ena track ifs ena ports ena
Congure the VRRP peer on the primary dirty-side application switch.

>> >> >> >> >> # # # # # /cfg/slb/sync prios d peer 1 ena addr 195.1.1.11
Apply and save your conguration changes.

.
697
Synchronize primary and secondary dirty-side application switches for the VRRP conguration.
>> # /oper/slb/sync
End
Complete Primary Clean-Side Switch Conguration

Step 1 Action Create an FWLB real server group on the primary clean-side application switch. A real server group is used as the target for the FWLB redirection lter. Each IP address assigned to the group represents a return path through a different rewall. In this case, since two rewalls are used, two addresses are added to the group. The two addresses are the interfaces of the dirty-side application switch, and are congured as if they are real servers. Note: IF 2 is used on all application switches whenever routing through the top rewall, and IF 3 is used on all application switches whenever routing through the lower rewall.
>> # /cfg/slb >> # on >> # real 1 >> # rip 10.10.2.1 >> # ena >> # /cfg/slb/real 2 >> # rip 10.10.2.2 >> >> >> >> >> # # # # # ena /cfg/slb/group 1 add 1 add 2 metric hash (IF2 of the primary dirty-side application switch) (IF2 of the primary dirty-side application switch)
Note: The clean-side application switch must use the same metric as dened on the dirty side. For information on using metrics other than hash, see "Free-Metric FWLB" (page 701).
.
Create an SLB real server group on the primary clean-side application switch, to which trafc will be load-balanced. The external clients intend to connect to HTTP services at a publicly advertised IP address. The servers on this network are load balanced by a virtual server on the clean-side application switch. SLB options are congured as follows:
>> # /cfg/slb >> # real 20 >> # rip 10.10.4.20 >> # ena >> # /cfg/slb/real 21 >> # rip 10.10.4.21 >> # ena >> # /cfg/slb/real 22 >> # rip 10.10.4.22 >> # ena >> # /cfg/slb/group 2 >> # add 20 >> # add 21 >> # add 22 >> # metric leastconns >> # /cfg/slb/virt 1 >> # vip 10.10.4.100 >> # service http >> # group 2 >> # ena >> # /cfg/slb/port 26/server ena >> # /cfg/slb/port 25/client ena >> # /cfg/slb/port 28/client ena (Select least connections as the load balancing metric) (Select the virtual server 1 menu) (Set the virtual server IP address) (Select HTTP for load balancing) (Add real server group 2) (Enable the virtual server) (Enable server processing on the port connected to the real servers) (Enable client processing on the port connected to the firewall) (Enable client processing on the interswitch connection) (Select the SLB menu) (Select real server 20) (Set IP address of real server 20) (Enable) (Select real server 21) (Set IP address of real server 21) (Enable) (Select real server 22) (Set IP address of real server 22) (Enable) (Select real server group 2) (Add the real servers to the group)
Note: The virtual server IP address congured in this step will also be congured as a Virtual Server Router (VSR) when VRRP is congured in a later step.
.
699
Create the FWLB lters on the primary clean-side application switch. Three lters are required on the port attaching to the real servers:
>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>
Filter 10 prevents local trafc from being redirected. Filter 20 prevents VRRP trafc from being redirected. Filter 2048 redirects the remaining trafc to the rewall 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
Congure VRRP on the primary clean-side application switch. VRRP in this example requires two virtual routers to be conguredone for the subnet attached to the real servers, and one for the subnet attached to the rewalls.
>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> # # # # # # # # # # # # # # # # # /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 optional SLB.
>> >> >> >> >> >> >> >> >> # # # # # # # # # /cfg/l3/vrrp/vr 3 vrid 5 addr 10.10.4.100 prio 102 share dis ena track ifs ena ports ena
Congure the peer on the primary clean-side application switch.

>> >> >> >> >> # # # # # /cfg/slb/sync prios d peer 1 ena addr 10.10.4.11
Apply and save your conguration changes.

Synchronize primary and secondary dirty-side application switches for the VRRP conguration.
>> # /oper/slb/sync
End
.
701
Advanced FWLB Concepts

Free-Metric FWLB
Free-metric FWLB allows to you use load-balancing metrics other than hash, such as leastconns, roundrobin, minmiss, response, and bandwidth for more 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 FWLB

For this example, review the basic FWLB example network.
Basic FWLB Example Network
To use free-metric FWLB in this network, the following conguration changes are necessary. Step 1 Action On the clean-side application switch, enable RTS on the ports attached to the rewalls (ports 2 and 3). Enable lter and server processing on ports 2 and 3, so that the responses from the real server are looked up in the session table.
>> # /cfg/slb/port 2/rts enable >> # /cfg/slb/port 3/rts enable
On the clean-side application switch, remove the redirection lter from the ports attached to the real servers (ports 4 and 5), but make sure lter processing is enabled. The redirection lter is removed so that the return packet traverses through the same rewall. If the rewalls synchronize their states, then it is not required to remove the redirection lter. Filter processing 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 or RTSP 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 using each metric. Note: Some metrics allow other options (such as weights) to be congured. End
Free-Metric with Four-Subnet FWLB

For this example, review the four-subnet example network.
Four-Subnet FWLB Example Network
.
703
To use free-metric FWLB in this network, the following conguration changes are necessary. Step 1 Action On the clean-side application switches, enable RTS on the ports attached to the rewalls (port 3) and on the interswitch port (port 9). Enable lter and server processing on ports 3 and 9, so that the responses 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
On the clean-side application switches, remove the redirection lter from the ports attached to the real servers (ports 4), but make sure lter processing is enabled. To view the original redirection lters that were congured for the four-subnet example, see Step step 3. On both clean-side switches:
>> # /cfg/slb/port 4/rem 2048 >> # filt ena
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 using each metric. Note: Some metrics allow other options (such as weights) to be congured. End
.
Adding a Demilitarized Zone (DMZ)

Implementing a DMZ in conjunction with rewall load balancing enables the Nortel Application Switch to do the trafc ltering, off-loading this task from the rewall. A DMZ is created by conguring FWLB with another real server group and a redirection lter towards the DMZ subnets. The DMZ servers can be connected to the application switch on the dirty side of the rewall. A typical rewall load balancing conguration with a DMZ 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 or through an intermediate hub or switch. The application switch is then congured with lters to permit or deny access to the DMZ servers. In this manner, two levels of security are implemented: one that restricts access to the DMZ through the use of application switch lters, and another that restricts access to the clean network through the use of stateful inspection performed by the rewalls. You could add the lters required for the DMZ (to each application switch) as follows: Step 1 Action On the dirty-side application switch, create the lter to allow HTTP trafc to reach the DMZ Web servers. In this example, the DMZ Web servers use IP addresses 205.178.29.0/24.
>> # /cfg/slb/filt 80 >> Filter 80# sip any (Select filter 80) (From any source IP address)
.
705
>> Filter 80# dip 205.178.29.0 >> Filter 80# dmask 255.255.255.0 >> Filter 80# proto tcp >> Filter 80# sport any >> Filter 80# dport http >> Filter 80# action allow >> Filter 80# ena
(To the DMZ base destination) (For the range of DMZ addresses) (For TCP protocol traffic) (From any source port) (To an HTTP destination port) (Allow the traffic) (Enable the filter)
Create another lter to deny all other trafc to the DMZ Web servers.
>> Filter 80# /cfg/slb/filt 89 >> Filter 89# sip any >> Filter 89# dip 205.178.29.0 >> Filter 89# dmask 255.255.25 5.0 >> Filter 89# proto any >> Filter 89# action deny >> Filter 89# ena (Select filter 89) (From any source IP address) (To the DMZ base destination) (For the range of DMZ addresses) (For TCP protocol traffic) (Allow the traffic) (Enable the filter)
Note: The deny lter has a higher lter number than the allow lter. This is necessary so that the allow lter has the higher order of precedence. 3 Add the lters to the trafc ingress ports.
>> Filter 89# /cfg/slb/port 1 >> SLB Port 1# add 80 >> SLB Port 1# add 89 (Select the ingress port) (Add the allow filter) (Add the deny filter)

End
.
Firewall Health Checks

Basic FWLB health checking is automatic. No special conguration is necessary unless you wish to tune the health checking parameters. See "Health Checking" (page 463) " for details.
Firewall Service Monitoring

To maintain high availability, application switches monitor rewall health status and send packets only to healthy rewalls. There are two methods of rewall service monitoring: ICMP and HTTP. Each application switch monitors the health of the rewalls on a regular basis by pinging the IP interfaces congured on its partner application switch on the other side of the rewall. If an application switch IP interface fails to respond to a user-specied number of pings, it (and, by implication, the associated rewall), is placed in a Server Failed state. At this time, the partner application switch stops routing trafc to that IP interface and, instead, distributes it across the remaining healthy application switch IP interfaces and rewalls. When an application switch IP interface is in the Server Failed state, its partner application switch continues to send pings to it at user-congurable intervals. After a specied number of successful pings, the IP interface (and its associated rewall) is brought back into service. For example, to congure the switch to allow one-second intervals between health checks or pings, two failed health checks to remove the rewall, and four successful health checks to restore the rewall to the real server group, use the following command:
>> /cfg/slb/real <real server number> /inter 1/retry 2/restr 4
Physical Link Monitoring

Nortel Application Switches also monitor physical link status of switch ports connected to rewalls. If the physical link to a rewall goes down, that rewall is placed immediately in the Server Failed state. When a Nortel Application Switch detects that a failed physical link to a rewall has been restored, it brings the rewall back into service.
Using HTTP Health Checks

For those rewalls that do not permit ICMP pings to pass through, application switches can be congured to perform HTTP health checks, as described below.
.
707
Step 1
Action Set the health check type to HTTP instead of ICMP.

>> # /cfg/slb/group 1/health http (Select HTTP health checks)
Enable HTTP access to the switch.

>> # /cfg/sys/access/http ena (Enable HTTP)
Congure a "dummy" redirect lter as the last lter (after the redirect all lter) to force the HTTP health checks to activate, as shown below:
>> # /cfg/slb/filt 2048 >> Filter 2048# proto tcp >> Filter 2048# action redir >> Filter 2048# group 1 >> Filter 2048# rport http >> Filter 2048# ena (Select filter 2048) (For TCP protocol traffic) (Redirect the traffic) (Set real server group for redirection) (Set real server port for redirection) (Enable the filter)
Note: Make sure that the number of each real lter is lower than the number of the "dummy" redirect lter. 4 Apply lter to the port directed to the rewall.
>> # /cfg/slb/port #/add 2048 (Add the dummy filter)
In addition to HTTP, Nortel Application Switch Operating System allows you to congure up to 5 different TCP services to listen for health checks. For example, you can congure FTP and SMTP ports to 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 Nortel Application Switch Operating System allows the switch to load balance simultaneously up to 255 VPN devices. The switch records from which VPN server a session was initiated and ensures that the trafc returns back to the same VPN server from which the session started. The following topics are addressed in this chapter: "Overview" (page 708) This section describes a VPN network and how VPN load balancing works on an Nortel Application Switch. "VPN Load-Balancing Conguration" (page 711) This section provides step-by-step instructions to congure VPN load balancing on a four- subnet network with four application switches and two VPN devices.
Overview
A VPN is a connection that has the appearance and advantages of a dedicated link, but it occurs over a shared network. Using a technique called tunneling, data packets are transmitted across a routed network, such as the Internet, in a private tunnel that simulates a point-to-point connection. This approach enables network trafc from many sources to travel via separate tunnels across the infrastructure. It also enables trafc from many sources to be differentiated, so that it can be directed to specic destinations and receive specic levels of service. VPNs provide security features of a rewall, network address translation, data encryption, and authentication and authorization. Since most of the data sent between VPN initiators and terminators is encrypted, network devices cannot use information inside the packet to make intelligent routing decisions.
How VPN Load Balancing Works

VPN load balancing requires that all ingress trafc passing through a particular VPN must traverse the same VPN as it egresses back to the client. Trafc ingressing from the Internet is usually addressed to the VPNs, with the real destination encrypted inside the datagram. Trafc egressing the VPNs into the intranet contains the real destination in the clear.
.
709
In many VPN/rewall congurations it may not be possible to use the hash algorithm on the source and destination address, because the address may be encrypted inside the datagram. Also, the source/destination IP address of the packet may change as the packet traverses from the dirty-side switches to clean-side switches and back. To support VPN load balancing, the Nortel Application Switch records state on frames entering the switch to and from the VPNs. This session table ensures that the same VPN server handles all the trafc between an inside host and an outside client for a particular session. Note: VPN load balancing is supported for connecting from remote sites to the network behind the VPN cluster IP address. Connection initiated from clients internal to the VPN gateways is not supported. Basic frame ow, from the dirty side of the network to the clean side, is shown in "Basic Network Frame Flow and Operation" (page 709). An external client is accessing an internal server. The VPN devices do not perform Network Address Translation (NAT).
Basic Network Frame Flow and Operation
The basic steps that occur at the switches when a request arrives from the Internet are described below:
.
Step 1 2 3
Action The client prepares to send trafc to the destination real server (with IP address E10). The VPN client software encrypts the packet and sends it to the cluster IP address (D3) of the VPN devices. Nortel Application Switch 1 makes an entry in the session table and forwards the packet to VPN device 1. It is recommended to use the hash load-balancing metric to select the VPN device.
4 5
The VPN device 1 strips the IP header and decrypts the encrypted IP header. Nortel Application Switch 2 forwards the packet to the real server. 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 performing a lookup with the source MAC address of the frame. If the MAC address matches a MAC address of a VPN device, the switch adds an entry to the session table so that reverse trafc is redirected to the same VPN device.
VPN Load Balancing Persistence

VPN load balancing persistence ensures that VPN sessions that exist in a load balanced environment retain their persistence with the load balanced server. Since both the ISAKMP and IPSec protocols are used in a VPN environment, load balancing such an environment involves maintaining persistence for two protocols. For each user VPN login, the security associations must be established and key exchanges performed using the ISAKMP protocol before the IPSec protocols can be sent securely. The switch will redirect the ISAKMP request to a load balanced VPN server and create a session. Subsequent ISAKMP requests will be sent to this session. When the associated IPSec session arrives, the switch will look for the associated ISAKMP session using session lookup so that it can be load balanced to the same server. If the ISAKMP session is not found, the IPSec session will be bound to a VPN server according to previously congured load balancing metrics.
.
711
VPN Load-Balancing Conguration

Before you start conguring the switch for VPN load balancing, do the following: Congure the switch with rewall load balancing. For more information, see "Firewall Load Balancing" (page 667). Enable the Return to Sender (RTS) feature on the ports attached to the VPN devices, using the following command:
>> # /cfg/slb/port <port number> /rts ena
The following example illustrates VPN load balancing with two VPN devices and four Nortel Application Switches in a four subnet scenario.
VPN Load-Balancing Conguration Example
Build the topology illustrated in "VPN Load-Balancing Conguration Example" (page 711), and congure the switches as shown in the following sections.
.
Congure the First Clean-Side Application Switch-CA

Step 1 Action Turn off BOOTP.
>> # /cfg/sys/bootp dis
Dene and enable VLAN 2 for ports 25, and 26.

>> # /cfg/l2/vlan 2/ena/def 25 26
Turn off Spanning Tree Protocol (STP).

Dene the clean-side IP interfaces. Create one clean-side IP interface on a different subnet for each VPN device being load balanced.
>> # /cfg/l3/if 1/ena >> IP Interface 1# mask 255.255.255.0 >> IP Interface 1# addr 30.0.0.10 >> IP Interface 1# vlan 1 >> IP Interface 1# /cfg/l3/if 2/ena >> IP Interface 2# mask 255.255.255.0 >> IP Interface 2# addr 20.0.0.10 >> IP Interface 2# vlan 2 >> IP Interface 2# /cfg/l3/if 3/ena >> IP Interface 3# mask 255.255.255.255 >> IP Interface 3# addr 20.0.0.11 >> IP Interface 3# vlan 2 (Select IP interface 1 and enable) (Set subnet mask for interface 1) (Set IP address for interface 1) (For VLAN 1) (Select IP interface 2 and enable) (Set subnet mask for interface 2) (Set IP address for interface 2) (For VLAN 2) (Select IP interface 3 and enable) (Set subnet mask for interface 3) (Set IP address for interface 3) (For VLAN 2)
.
713
Congure routes for each of the IP interfaces you congured in Step 4 using the VPN devices as gateways. One static route for redirection is required for each VPN device being load balanced.
>> # /cfg/l3/route >> IP Static Route# add 10.0.0.10 >> IP Static Route# 255.255.25 5.255 >> IP Static Route# 20.0.0.101 >> IP Static Route# 2 >> IP Static Route# add 10.0.0.11 >> IP Static Route# 255.255.25 5.255 >> IP Static Route# 20.0.0.102 >> IP Static Route# 3 >> IP Static Route# add 10.0.0.20 >> IP Static Route# 255.255.25 5.255 >> IP Static Route# 20.0.0.101 >> IP Static Route# 2 >> IP Static Route# add 10.0.0.21 >> IP Static Route# 255.255.25 5.255 >> IP Static Route# 20.0.0.102 >> IP Static Route# 3 (Static route destination IP address) (Destination subnet mask) (Enter gateway IP address) (For interface 2) (Enter destination IP address) (Destination subnet mask) (Enter gateway IP address) (For interface 3) (Enter destination IP address) (Destination subnet mask) (Enter gateway IP address) (For interface 2) (Static route destination IP address) (Destination subnet mask) (Enter gateway IP address) (For interface 3)
Congure VRRP for virtual 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 (Enable VRRP) (Select virtual router 1 menu) (Enable the virtual router) (Assign virtual router ID 1) (To interface number 1)
.
>> VRRP Virtual Router 1# prio 101 >> VRRP Virtual Router 1# addr 30.0.0.50 >> VRRP Virtual Router 1# share dis >> VRRP Virtual Router 1# track >> VRRP VR 1 Priority Tracking# vrs ena >> VRRP VR 1 Priority Tracking# apply >> VRRP VR 1 Priority Tracking# save
(Set the renter priority) (Set IP address of virtual router) (Disable sharing) (Select virtual router tracking menu) (Enable tracking of virtual routers) (Apply the configuration) (Save the configuration)
>> VRRP VR 1 Priority Tracking# /cfg/l3/vrrp/vr 2 (Select virtual router 2 menu) >> 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 20.0.0.1 >> VRRP Virtual Router 2# share dis >> VRRP Virtual Router 2# track >> VRRP VR 2 Priority Tracking# ports ena >> VRRP VR 2 Priority Tracking# apply >> VRRP VR 2 Priority Tracking# save (Enable the virtual router) (Assign virtual router ID 2) (To interface number 2) (Set the renter priority) (Set IP address of virtual router) (Disable sharing) (Select Virtual Router Tracking Menu) (Track VLAN switch ports) (Apply the configuration) (Save the configuration)
Enable Server Load Balancing (SLB) on the rst clean switch.

>> # /cfg/slb/on
Congure real servers for health checking VPN devices.
.
715
>> # /cfg/slb/real 1/ena >> Real server 1 # rip 10.0.0.10 >> Real server 1 # /cfg/slb/rea l 2/ena >> Real server 2 # rip 10.0.0.11 >> Real server 2 # /cfg/slb/rea l 3/ena >> Real server 3 # rip 10.0.0.20 >> Real server 3 # /cfg/slb/rea l 4/ena >> Real server 4 # rip 10.0.0.21
(Enable slb for real server 1) (Assign IP address for real server 1) (Enable SLB for real server 2) (Assign IP address for real server 2) (Enable SLB for real server 3) (Assign IP address for real server 3) (Enable SLB for real server 4) (Assign IP address for real server 4)
Congure real server group 1, and add real servers 1, 2, 3, and 4 to the group.
>> # /cfg/slb/group 1 >> Real server group 1# metric hash >> Real server group 1# add 1 (Configure real server group 1) (Select SLB hash metric for group 1) (Add real servers 1-4 to group 1)
>> Real server group 1# add 2/add 3/add 4
10
Enable RTS on the necessary ports.

>> # /cfg/slb/port 26/rts ena >> # /cfg/slb/port 25/rts ena (Enable Return to Sender on port 26) (Enable Return to Sender on port 25)
11
Enable lter processing on the server ports so that the responses from the real server is looked up in the VPN session table.
>> # /cfg/slb/port 1/filt ena
.
12
When dynamic routing protocols are not used, congure a gateway to the external router.
>> # /cfg/l3/gw 1/addr 192.168.10.50
13
Apply and save the conguration, and reboot the switch.

End
Congure the Second Clean-Side Application Switch-CB

Step 1 Action Turn off bootp.
Dene and enable VLAN 2 for ports 25 and 26.

Turn off Spanning Tree Protocol.

Dene the clean-side IP interfaces. Create one clean-side IP interface on a different subnet for each VPN device being load balanced.
>> # /cfg/l3/if 1/ena/mask 255.255.255.0/addr 30.0.0.11 >> # /cfg/l3/if 2/ena/mask 255.255.255.0/addr 20.0.0.20/vl 2 >> # /cfg/l3/if 3/ena/mask 255.255.255.255/addr 20.0.0.21/vl 2
Congure routes for each of the IP interfaces you congured in Step 4, using the VPN devices as gateways.
.
717
One static route is required for each VPN device being load balanced.
>> >> >> >> >> # # # # # /cfg/l3/route add 10.0.0.10 add 10.0.0.11 add 10.0.0.20 add 10.0.0.21
255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255
20.0.0.101 20.0.0.102 20.0.0.101 20.0.0.102
2 3 2 3
Congure Virtual Router Redundancy Protocol (VRRP) for virtual 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
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
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 lter processing on the server ports so that the response from the real server will be looked up in VPN session table.
>> SLB port 25# /cfg/slb/port 1/filt ena
12

>> SLB port 25# apply >> SLB port 25# save >> SLB port 25# /boot/reset
End
Congure the First Dirty-Side Application Switch-DA


Turn off STP.

Congure IP interfaces 1, 2, and 3.

.
719
Dene static routes for each of the IP interfaces you congured in Step 4, using the VPN devices as gateways. One static route is required for each VPN device being load balanced.
>> >> >> >> >> # # # # # /cfg/l3/route add 20.0.0.10 add 20.0.0.11 add 20.0.0.20 add 20.0.0.21
255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255
10.0.0.101 10.0.0.102 10.0.0.101 10.0.0.102
2 3 2 3

>> # /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
Enable SLB.
>> VRRP Virtual Router 1 Priority Tracking# /cfg/slb/on
Congure 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
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
Congure the lters to allow local subnet trafc on the dirty side 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 lter and enable rewall load balancing. This lter will redirect inbound trafc, redirecting it among the dened real 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 lter to allow the management rewall (Policy Server) to reach the VPN rewall.
>> >> >> >> >> # # # # # /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
.
721
13

>> # /cfg/slb/port 1 >> # filt ena >> # add 100/add 110/add 2048
14

End
Congure the Second Dirty-Side Application Switch-DB


Turn off STP.

Congure IP interfaces 1, 2, and 3.

Congure routes for each of the IP interfaces you congured in Step 4.
.
>> >> >> >> >>
# # # # #
/cfg/l3/route add 20.0.0.10 add 20.0.0.11 add 20.0.0.20 add 20.0.0.21
255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255
10.0.0.101 10.0.0.102 10.0.0.101 10.0.0.102
2 3 2 3

>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> # # # # # # # # # # # # # # # # # # # /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
Enable SLB.
>> # /cfg/slb/on

>> >> >> >> # # # # /cfg/slb/real /cfg/slb/real /cfg/slb/real /cfg/slb/real 1/ena/rip 2/ena/rip 3/ena/rip 4/ena/rip 20.0.0.10 20.0.0.11 20.0.0.20 20.0.0.21
Enable the real server group, and place real servers 1-4 into the real server group.
>> # /cfg/slb/group 1 >> # metric hash >> # add 1/add 2/add 3/add 4
.
723
10
Congure the lters to allow local subnet trafc on the dirty side 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 lter and enable rewall load balancing. This lter will redirect inbound trafc, among the dened real servers in the group.
>> >> >> >> >> >> >> >> # # # # # # # # /cfg/slb/filt 2048 ena sip any dip any proto any action redir /cfg/slb/filt 2048/adv fwlb ena
12

>> # /cfg/slb/port 1 >> # filt ena >> # add 100/add 110/add 2048
13
Apply and save the conguration and reboot the switch.

End
Test Congurations and General Topology

The application switches should be able to perform health checks to each other and all switches should see four real servers (see "Checkpoint Rules for Both VPN Devices as Seen in the Policy Editor" (page 724)).
.
724 Part 4: Advanced Switching Checkpoint Rules for Both VPN Devices as Seen in the Policy Editor
Step 1
Action Disconnect the cables (cause failures) to change the available servers that are up
>> # /info/slb/dump (Verify which servers are up)
This should change the VRRP preferences. You can view VRRP preferences using the CLI command /info/l3/vrrp. 2 Watch for accepted and dropped trafc. 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 1 2 Action Launch the SecuRemote client on the dirty side of the network. Add a new site.
.
725
3 4 5
Enter the policy server IP address: 192.168.10.120. You have the option of adding a nickname. Launch a browser (such as Netscape or Internet Explorer) and go to http://30.0.0.100 You will be prompted for authentication. Enter vpnuser for user name and alteon for the password.
A message is displayed verifying that you were authenticated.
Browse to the Web site.
.
If there are other services running on other servers in the internal network, you should be able to reach those services. All trafc traveling over the VPN is decrypted at the VPN device. You can verify which VPN device is being used by looking at the Log Viewer. You should also be able to see the client authentication as well as the decrypted trafc. To verify that the FWLB and hash metric is working correctly on the dirty-side switches (that is, hashed on client IP address/destination IP address), congure your current client with an IP address one higher (or lower) in the last octet, and try to reestablish the VPN connection. Or, add another PC on the dirty side and connect to it. Note: When many clients are coming from behind a VPN gateway (for example, not using the SecuRemote clients but using a VPN 1 Gateway or other compatible VPN Gateway), you will not see load balancing across those clients. Each SecuRemote client will be treated differently, but each VPN 1 Gateway will be treated as one client each (that is, one Client IP address). VPN Device 1 and VPN Device 2 belong to one cluster IP. End
.
Global Server Load Balancing
727

This chapter provides information for conguring Global Server Load Balancing (GSLB) across multiple geographic sites. The following topics are covered: "Enabling GSLB on the Switch" (page 727) "GSLB Overview" (page 728) "Conguring Basic GSLB" (page 735) "Conguring a Standalone GSLB Domain" (page 752) "Conguring GSLB with Rules" (page 759) "Conguring GSLB Network Preference" (page 762) "Conguring 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 Switch

To use GSLB on your application switch, you must purchase an additional software license and password key. Instructions for obtaining a password key are provided with your software license certicate. Once you have obtained the proper password key to enable GSLB, follow these instructions: Step 1 Action Connect to the switch command line interface via Telnet or the console port, and login as the administrator, following the directions in the Nortel Application Switch Operating System Command Reference. From the command line prompt, type the /oper/swkey command. You will be prompted to enter the password key. If the key is correct for this MAC address, the switch will accept the password, permanently record it in the switchs non-volatile RAM (NVRAM), and will then enable the feature. End
.
DSSP version 1 vs. version 2

Distributed Site Selection Protocol (DSSP) is a proprietary protocol that resides above TCP. It enables the sending and receiving of remote site updates. By default, DSSP version 1 is enabled on the Nortel Application Switch and supports server response time and sessions available in the remote site updates. DSSP version 2 supports server response time, CPU utilization, session availability, and session utilization in the remote site updates. For more information on the site selection metrics, see "GSLB Metrics" (page 731). Although both versions of DSSP are supported, it is recommended that DSSP version 2 is utilized in most instances. DSSP version 1 remains to provide backward compatiability to switches in a network running older versions of the Nortel Application Switch Operating System. If interconnection to switches running older software versions is not required, use DSSP version 2. The command to change to DSSP version 2 is /cfg/slb/gslb/version 2.
Migrating Previous GSLB Congurations

GSLB congurations running in earlier versions of the Nortel Application Switch Operating System are maintained after upgrading to version 24.0. Simply upgrade the software image to the new version and the conguration will be migrated.
GSLB License Key

If GSLB is not already enabled on the application switch, obtain a GSLB key specically for this new version to use it. GSLB licenses from earlier versions of the Nortel Application Switch Operating System are still valid after an upgrade.
GSLB Overview
GSLB allows balancing server trafc load across multiple physical sites. The Nortel Application Switch Operating System GSLB implementation takes into account an individual sites health, response time, and geographic location to smoothly integrate the resources of the dispersed server sites for complete global performance.
Benets
GSLB meets the following demands for distributed network services: High content availability is achieved through distributed content and distributed decision making. If one site becomes disabled, the others become aware of it and take up the load. There is no latency during client connection set up. Instant site hand-off decisions can be made by any distributed switch.
.
729
The best performing sites receive a majority of trafc over a given period of time but are not overwhelmed. Switches at different sites regularly exchange information through the Distributed Site State Protocol ( DSSP), and can trigger exchanges when any sites health status changes. This ensures that each active site has valid state knowledge and statistics. DSSP v1.0 and DSSP v2.0 are supported. GSLB implementation takes geography as well as network topology into account. Creative control is given to the network administrator or Webmaster to build and control content by user, location, target application, and more. GSLB is easy to deploy, manage, and scale. Switch conguration is straightforward. There are no complex system topologies involving routers, protocols, and so forth. Flexible design options are provided. All IP protocols are supported.
How GSLB Works

A GSLB device performs or initiates a global server selection to direct client trafc to the best server for a given domain during the initial client connection. GSLB is based on the Domain Name System (DNS) and proximity by source IP address. In the example in "DNS Resolution with Global Server Load Balancing" (page 730), a client is using a Web browser to view the Web site for the Example Corporation at "www.example.com." The Example Corporation has two Web sites: one in San Jose, and one in Denver, each with identical content and available services. Both Web sites have an Nortel Application Switch congured for GSLB, with domain name set to "www.gslb.example.com." These switches are also congured as the Authoritative Name Servers for "www.example.com."On the company master DNS server, the conguration is to delegate "www.example.com" to "www.gslb.example.com."
.
730 Part 4: Advanced Switching DNS Resolution with Global Server Load Balancing
The DNS resolution for GSLB is described in detail in the following procedure: Step 1 2 Action The client Web browser requests the "www.example.com" IP address from the local DNS. The clients DNS asks its upstream DNS, which in turn asks the next, and so on, until the address is resolved. Eventually, the request reaches an upstream DNS server that has the IP address information available or the request reaches one of the Example, Inc. DNS servers. 3 The Example Inc.s San Jose DNS tells the local DNS to query the Nortel Application Switch with GSLB software as the authoritative name server for "www.example.com." The San Jose switch responds to the DNS request, listing the IP address with the current best service. Each switch with GSLB software is capable of responding to the clients name resolution request. Since each switch regularly checks and communicates health and performance information with its peers, either switch can determine which site(s) are best able to serve the clients Web access needs. It can respond with a list of IP addresses for the Example Inc.s distributed sites, which are prioritized by performance, geography, and other criteria.
.
731
In this case, the San Jose switch knows that Example Inc. Denver currently provides better service, and lists Example Inc. Denvers virtual server IP address rst when responding to the DNS request. 5 The client connects to Example Inc. Denver for the best service. The clients Web browser will use the IP address information obtained from the DNS request to open a connection to the best available site. The IP addresses represent virtual servers at any site, which are locally load balanced according to regular SLB conguration. If the site serving the client HTTP content suddenly experiences a failure (no healthy real servers) or becomes overloaded with trafc (all real servers reach their maximum connection limit), the switch issues an HTTP Redirect and transparently causes the client to connect to another peer site. The end result is that the client gets quick, reliable service with no latency and no special client-side conguration. End
GSLB Metrics
This section describes all GSLB metrics. All metrics can be prioritized for selection order, and can be weighted on a per site basis. For details on the conguration parameters of GSLB metrics, see the /cfg/slb/gslb/rule menu and the command descriptions in the Nortel Application Switch Operating System 24.0 Command Reference. The following is a list of all GSLB metrics: Session utilization capacity threshold This metric causes the GSLB-enabled application switch to not select the server when the session utilization of the server goes above the threshold. The session utilization is the percentage of sessions used over total sessions that results in normalized sessions between servers. When the server is not available, the session utilization is 100%. This is a threshold metric and it overwrites all other metrics. This metric requires remote site updates. CPU utilization capacity threshold This metric causes the GSLB-enabled application switch to not select the server when the CPU utilization of the site with the server goes above the threshold. CPU utilization is the highest CPU utilization for periods of up to 64 seconds among SPs. This is a threshold metric and overwrites all other metrics.This metric requires remote site updates. Session available capacity threshold This metric does not select the server when the number of available sessions on the server falls below
.
the threshold. When the server is not available, the session available is 0. This is a threshold metric and it overwrites all other metrics. This metric requires remote site updates. Geographical preference This metric causes the GSLB-enabled application switch to select the server based on the same IANA region of the source IP address and the server IP address. This metric does not require remote site updates. The command, /info/slb/gslb/geo can be used to obtain a list of the IP address ranges that are mapped to each region. The regions are as follows: North America South America Europe Caribbean Pacic Rim Sub-Sahara Japan Network preferenceThis metric selects the server based on the preferred network of the source IP address. This metric does not require remote site updates. Weighted least connections This metric selects the server based on which server has the lowest session utilization. Session utilization is the percentage of sessions used over total sessions, which results in normalized sessions between servers. A server whose session utilization is 100% is considered unavailable. This metric requires remote site updates. Weighted response time This metric selects the server based on the lowest response time in milliseconds from an SLB health check of the servers. This metric requires SLB health checks and remote site updates. Weighted round robin This metric selects the server based on round robin of the servers. Weighted random This metric selects the server based on uniform random distribution of the servers. Availability This metric selects the same server while the server is still available. If the same server is not available, this metric selects the next server based on a ranking of the local virtual server and remote real server in a list from the highest (48) to the lowest (1) ranking. Multiple servers can have the same priority. This metric allows servers to be grouped based on priorities, or into primary and secondary groups. This metric requires SLB health checks and remote site updates.
.
733
Quality of service This metric selects the server based on combination of the lowest session utilization and the lowest response time of the SLB health check of the servers. This metric requires SLB health checks and remote site updates. Minmisses This metric selects the same server based on the hash of source IP address and domain name. The hash calculation uses all the servers that are congured for the domain irrespective of the state of the server. When the server selected is not available, minmisses selects the next available server. Hashing This metric selects the same server based on the hash of source IP address and domain name. The hash calculation uses only the servers that are available for the domain. The server selected may be affected when a server become available or not available since the hash calculation uses only the servers that are available. DNS local This metric selects the local virtual server only when the local virtual server is available. This metric applies to DNS-based GSLB only. DNS always This metric selects the local virtual server even though the local virtual server is not available. This metric applies to DNS-based GSLB only. Remote This metric selects the remote real servers only.
Metric preferences
This metric allows the GSLB selection to use multiple metrics from a metric preference list. The GSLB selection starts with the rst metric in the list. The GSLB selection goes to the next metric when no server is selected, or more than the required servers is selected. The GSLB selection stops when the metric results at least one and no more than the required servers, or after the last metric in the list is reached. For DNS direct-based GSLB, the DNS response can be congured to return up to 10 required servers. For HTTP 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
Rules
A rule allows the GSLB selection to use a different GSLB site selection metric preference list, and rules can be set based on the time of day. Each domain has one or more rules. Each rule has a metric preference list. The GSLB selection selects the rst rule that matches for the domain and starts with the rst metric in the metric preference list of the rule. For more information, see "Conguring GSLB with Rules" (page 759).
GSLB Availability Persistence

The Global Server Load Balancing (GSLB) Availability metric is used in GSLB rules to select a server exclusively when that server is available. Should that server become unavailable, the next available server in a list is selected to service requests. Availability is determined by a rank assigned to 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 selecting the server with the next highest score compared to that of the server that failed and begins forwarding requests to that server. Should the server that failed become operational again, that server regains precedence and requests are routed to it once more. GSLB Availability Persistence allows the switch administrator to change the behavior of the Availability metric to reassign requests to a server that had previously failed because of its higher initial score. With Availability Persistence enabled, a server that takes over after a failure situation is automatically assigned the highest possible Availablity value (48). This ensures that after the server that failed becomes operational again, it cannot regain precedence from the recovery server. Should this new primary server fail, its original Availability value will be restored and the next server in the list will gain the high precedence. To enable GSLB Availability Persistence, the following tasks must be performed: Step 1 Action DSSP version 3 must be enabled. DSSP version 3 must be enabled on all switches with GSLB congured. Use the following command to do so:
.
735
/cfg/slb/gslb/version 3
Availability must be the primary rule metric. The Availability metric must be the rst metric congured in the rst GSLB rule. For information on rule creation, refer to "Rules" (page 734).
Enable Availability Persistence. Enable Availability Persistence on the backup switch (the switch that will 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 a switch reboot. After the primary server recovers, reversion to the congured availabilities can be accomplished at a convenient time. To do so, use the following command on the switch whose virtual server currently has precedence. This would be the switch with the virtual server that is advertising an availability of 48. /oper/slb/gslb/avpersis <virtual server number> disable. After both sites are reporting their congured availability, turn the feature back on. This is accomplished by enabling Availability Persistence on the switch with the backup server using the following command: /oper/slb/gslb/avpersis <virtual server number> enable. Nortel Application Switch Operating System 24.0 supports the following command to enable or disable Availability Persistence on the backup switch: /cfg/slb/virt <virtual server number>/avpersis enable/disable. End
Conguring Basic GSLB

Conguring GSLB is simply an extension of the conguration procedure for SLB. The process is summarized as follows: Use the administrator login to connect to the switch you want to congure.
.
Activate the GSLB software key. See the Nortel Application Switch Operating System Command Reference for details. Congure the switch at each site with basic attributes. Congure the switch IP interface. Congure the default gateways.
Congure the switch at each site to act as the DNS server for each service that is hosted on its virtual servers. Also, congure the master DNS server to recognize the switch as the authoritative DNS server for the hosted services. Congure the switch at each site for local SLB. Dene each local real server. Group local real servers into real server groups. Dene the local virtual server with its IP address, services, and real server groups. Dene the switch port states. Enable SLB.
Finally, congure each switch so that it recognizes its remote peers. Congure a remote real server entry on each switch for each remote service. This is the virtual server IP address that is congured on the remote peer. Add the remote real server entry to an appropriate real server group. Enable GSLB.
Basic GSLB Requirements

The following is required prior to conguration: 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 Topology

Consider the following example network:
.
Global Server Load Balancing GSLB Topology Example 1
737
In the following examples, many of the options are left to their default values. See "Additional Server Load Balancing Options" (page 199) for more options. Note: For details about any of the processes or menu commands described in this example, see the Nortel Application Switch Operating System Command Reference.
Task 1: Congure the Basics at the San Jose Site

Step 1 Action (Optional) On the San Jose switch, congure management access, and management gateway address on the application switch, then enable the management port.
>> # /cfg/sys/mmgmt/addr 50.133.88.31 >> Management Port# mask 255.255.255.0 >> Management Port# gw 50.133.88.1 >> Management Port# ena (Mgmt. port IP address) (Mgmt. port mask) (Mgmt. port gateway addr.) (Enable the Mgmt port)
If using the Browser-Based Interface (BBI) for managing the San Jose switch, change its service port. By default, GSLB listens on service port 80 for HTTP redirection. By default, the Nortel Application Switch Operating System Browser-Based Interface (BBI) also uses port 80. Both services cannot use the same port. If the BBI is enabled (see the
.
/cfg/sys/access/http command in the Nortel Application Switch Operating System Command Reference), congure it to use a different port. For example, enter the following command to change the BBI port to 8080:
>> # /cfg/sys/wport 8080 (Set service port 8080 for BBI)
Congure a VLAN for the Internet trafc.

>> # /cfg/l2/vlan 101/name internet >> VLAN 101# add 2/ena (VLAN 101 for Internet) (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]: y Current ports for VLAN 101: empty Pending new ports for VLAN 101: 2 Current status: disabled New status: enabled
Congure another VLAN for local server trafc, and add server ports to this VLAN.
>> # /cfg/l2/vlan 201/name servers >> VLAN 201# add 4/ena (VLAN 201 for local servers) (Add port 4 to VLAN 201)
Port 4 is an UNTAGGED port and its current PVID is 1. Confirm changing PVID from 1 to 201 [y/n]: y Current ports for VLAN 201: empty Pending new ports for VLAN 201: 10 Current status: disabled New status: enabled >> VLAN 201# add 3/ena (Add port 3 to VLAN 201)
Port 3 is an UNTAGGED port and its current PVID is 1. Confirm changing PVID from 1 to 201 [y/n]: y Current ports for VLAN 201: empty Pending new ports for VLAN 201: 3 4
Dene an IP interface to the local real servers.

>> # /cfg/l3/if 201 >> IP Interface 201# addr 200.2.2.201 (Select IP interface 201) (Assign IP address for the interface)
.
739
>> IP Interface 201# mask 255.255.255.0 >> IP Interface 201# vlan 201 >> IP Interface 201# ena
(Assign network mask) (Assign interface to VLAN 201) (Enable IP interface 201)
Dene an IP interface to the Internet. The switch IP interface responds when asked to resolve client DNS requests.
>> # /cfg/l3/if 101 >> IP Interface 101# addr 200.200.200.1 >> IP Interface 101# mask 255.255.255.0 >> IP Interface 101# vlan 101 >> IP Interface 101# ena (Select IP interface 101) (Assign IP address for the interface) (Assign network mask) (Assign interface to VLAN 101) (Enable IP interface 101)
Dene the default ga teway. The router at the edge of the site acts as the default gateway to the Internet. The default gateway address should be on the same subnet as the IP interface 101, which points to the Internet. To congure the default gateway for this example, enter these commands from the CLI:
>> IP Interface 101# /cfg/l3/gw 1 >> Default gateway 1# addr 200.200.200.101 >> Default gateway 1# ena (Select default gateway 1) (Assign IP address for the gateway) (Enable default gateway 1)

Congure the master DNS server to recognize the local GSLB switch as the authoritative name server for the hosted services.
.
Determine the domain name that will be distributed to both sites and the host name for each distributed service. In this example, the San Jose DNS server is congured to recognize 200.200.200.1 (the IP interface of the San Jose GSLB switch) as the authoritative name server for "www.gslb.example.com." End
Task 2: Congure the San Jose Switch for Standard SLB

Step 1 Action Assign an IP address to each of the real servers in the local San Jose server pool. The real servers in any real server group must have an IP route to the switch that will perform the SLB functions. This is most easily accomplished by placing the switches and servers on the same IP subnet, although advanced routing techniques can be used as long as they do not violate the topology rules outlined in "Network Topology Requirements" (page 192). For this example, the host real servers have IP addresses on the same IP subnet:
GSLB Example: San Jose Real Server IP Addresses Real Server Server 10 Server 20 IP address 200.2.2.10 200.2.2.20
Dene 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. For example:
>> Default gateway 1# /cfg/slb/real 10 >> Real server 10# rip 200.2.2.10 >> Real server 10# ena >> Real server 10# /cfg/slb/real 20 (Configure Real Server 10) (Assign IP address to server 10) (Enable real server 10) (Configure Real Server 20)
.
741
>> Real server 20# rip 200.2.2.20 >> Real server 20# ena
(Assign IP address to server 20) (Enable real server 20)
On the San Jose switch, dene a real server group. Combine the real servers into one service group and set the necessary health checking parameters. In this example, HTTP health checking is used to ensure that Web content is being served. If the index.html le is not accessible on a real server during health checks, the real server will be marked as down.
>> Real server 2# /cfg/slb/group 1 >> Real server group 1# add 10 >> Real server group 1# add 20 >> Real server group 1# health http >> Real server group 1# content index.html (Select real server group 1) (Add real server 10 to group 1) (Add real server 20 to group 1) (Use HTTP for health checks) (Set URL content for health checks)
On the San Jose switch, dene a virtual server. All client requests will be addressed to a virtual server IP address dened on the switch. Clients acquire the virtual server IP address through normal DNS resolution. HTTP uses well-known TCP port 80. In this example, HTTP is congured as the only service running on this virtual server IP address and, is associated with the real server group. For example:
>> Real server group 1# /cfg/slb/virt 1 >> Virtual server 1# vip 200.200.200.100 >> Virtual Server 1# service 80 >> Virtual server 1 http Service# group 1 (Associate virtual port to real group) (Select virtual server 1) (Assign a virtual server IP address)
>> Virtual server 1 http Service# /cfg/slb/virt 1 ena (Enable virtual server)
.
Note: This conguration is not limited to HTTP services. For a list of other well-known TCP/IP services and ports, see "Well-Known Application Ports" (page 199). 5 On the San Jose switch, dene the type of Layer 4 trafc processing each port must support. In this example, the following ports are being used on the Nortel Application Switch:
GSLB Example: San Jose Nortel Application Switch Port Usage Port 4 3 2 Host Server 10 Server 20 Layer 4 Processing Server Server
Default Gateway Router. This connects Client the switch to the Internet where all client requests originate.

>> Virtual server 1# /cfg/slb/port 4 >> SLB port 4# server ena >> SLB port 4# /cfg/slb/port 3 >> SLB port 3# server ena >> SLB port 3# /cfg/slb/port 2 >> SLB port 2# client ena (Select physical switch port 4) (Enable server processing on port 4) (Select physical switch port 3) (Enable server processing on port 3) (Select physical switch port 2) (Enable client processing on port 2)
On the San Jose switch, enable SLB.

>> SLB port 6# /cfg/slb/on
End
.
743
Task 3: Congure the San Jose Site for GSLB

Step 1 Action On the San Jose switch, turn on GSLB.
>> Virtual server 1# /cfg/slb/gslb/on
Enable DSSP version 2 to send out remote site updates. Unless you are in the middle of network migration from an Nortel Application Switch Operating System version prior to 22.0 you should always enable DSSP version 2.
>> # /cfg/slb/gslb/version 2 (Enable DSSP version 2 updates)
On the San Jose switch, dene each remote site. When you start conguring at the San Jose site, San Jose is local and Denver is remote. Add and enable the remote switchs Internet-facing IP interface address. In this example, there is only one remote site: Denver, with an IP interface address of 74.14.70.2. The following commands are used:
>> # /cfg/slb/gslb/site 2 >> Remote site 2# name site_2 >> Remote site 2# prima 174.14.70.2 >> Remote site 2# ena (Select remote site 2) (Name remote site 2) (Define remote interface) (Enable remote site 1)
Each additional remote site would be congured in the same manner. You can enable up to 64 remote sites. 4 On the San Jose switch, assign each remote distributed service to a local virtual server. Congure the local San Jose site to recognize the services offered at the remote Denver site. To do this, congure one real server entry on the San Jose switch for each virtual server located at each remote site. Since there is only one remote site (Denver) with only one virtual server, only one more local real server entry is needed at the San Jose site.
.
The new real server entry is congured with the remote virtual server IP address, i.e. Switch 2s VIP address, rather than the usual IP address of a local physical server. Do not confuse this value with the IP interface address on the remote switch. Also, the remote parameter is enabled, and the real server entry is added to the real server group under the local virtual server for the intended service. Finally, since the real server health checks are performed across the Internet, the health-checking interval should be increased to 30 or 60 seconds to avoid generating excess trafc. The health check interval should also depend on the number of remote sites. The more remote sites you have, the larger the time interval should be. For example:
>> # /cfg/slb/real 2 >> Real server 2# rip 174.14.70.200 >> Real server 3# remote enable >> Real server 3# inter 30 >> Real server 3# ena >> Real server 3# /cfg/slb/group 1 >> Real server group 1# add 2 (Create an entry for real server 2) (Set remote virtual server IP address) (Define the real server as remote) (Set a higher health check interval) (Enable the real server entry) (Select appropriate real server group) (Add real server 2 to the group 1)
Note: Take care to note where each congured value originates, or this step can result in improper conguration. 5 On the San Jose switch, dene the domain name and host name 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 congured as follows:
>> Real server group 1# /cfg/slb/virt 1 (Select virtual server 1)
>> Virtual server 1# dname gslb.example.com (Define domain name) >> Virtual server 1# service 80/hname www (Define HTTP host name)
.
745
To dene other services (such as FTP), make additional hostname entries. 6 Apply and verify the conguration.
>> Global SLB# apply >> Global SLB# cur >> Global SLB# /cfg/slb/cur (Make your changes active) (View current GSLB settings) (View current SLB settings)
Examine the resulting information. If any settings are incorrect, make and apply any appropriate changes, and then check again. 7 Save your new conguration changes.
End
Task 4: Congure the Basics at the Denver Site

Following the same procedure described for San Jose (see "Example GSLB Topology" (page 736)), congure the Denver site as follows: Step 1 Action (Optional) On the Denver switch, congure management access, and management gateway address on the application switch.
>> # /cfg/sys/mmgmt/addr 49.133.88.31 >> Management Port# mask 255.255.255.0 >> Management Port# gw 49.133.88.1 >> Management Port# ena (Mgmt. port IP address) (Mgmt. port mask) (Mgmt. port gateway addr.) (Enable the Mgmt. port)
If using the Browser-Based Interface (BBI) for managing the San Jose switch, change its service port. By default, GSLB listens on service port 80 for HTTP redirection. By default, the Nortel Application Switch Operating System Browser-Based Interface (BBI) also uses port 80. Both services cannot use the same port. If the BBI is enabled (see the
.
/cfg/sys/access/http command in the Nortel Application Switch Operating System Command Reference), congure it to use a different port. For example, enter the following command to change the BBI port to 8080:
>> # /cfg/sys/wport 8080 (Set service port 8080 for BBI)

>> # /cfg/l2/vlan 102/name internet >> VLAN 102# add 2/ena (VLAN 102 for Internet) (Add port 2 to VLAN 102 and enable)
Congure a VLAN for local server trafc, and add server ports to this VLAN.
>> # /cfg/l2/vlan 202/name servers >> VLAN 202# add 11/ena (VLAN 202 for local servers) (Add port 11 to vlan 202)
Port 10 is an UNTAGGED port and its current PVID is 1. Confirm changing PVID from 1 to 202 [y/n]: y Current ports for VLAN 202: empty Pending new ports for VLAN 202: 11 Current status: disabled New status: enabled >> VLAN 202# add 12/ena Port 11 current Confirm Current Pending (Add port 12 to VLAN 201)
is an UNTAGGED port and its PVID is 1. changing PVID from 1 to 202 [y/n]: y ports for VLAN 202: empty new ports for VLAN 202: 11 12
Dene an IP interface to the local real servers.
.
747
>> # /cfg/l3/if 202 >> IP Interface 202# addr 174.40.7.202 >> IP Interface 202# mask 255.255.255.0 >> IP Interface 202# vlan 202 >> IP Interface 202# ena
(Select IP interface 202) (Assign IP address for the interface) (Assign network mask) (Assign interface to VLAN 202) (Enable IP interface 202)
Dene an IP interface to the Internet.

>> # /cfg/l3/if 102 >> IP Interface 102# addr 174.14.70.2 >> IP Interface 102# mask 255.255.255.0 >> IP Interface 102# vlan 102 >> IP Interface 102# ena (Select IP interface 102) (Assign IP address for the interface) (Assign network mask) (Assign interface to VLAN 102) (Enable IP interface 102)
Dene the default ga teway.


Congure the local DNS server to recognize the local GSLB switch as the authoritative name server for the hosted services. Determine the domain name that will be distributed to both sites and the host name for each distributed service. In this example, the Denver DNS server is congured to recognize 174.14.70.2 (the IP interface of the Denver GSLB switch, congured with the domain name "www.gslb.example.com") as the authoritative name server for "www.example.com."
.
End
Task 5: Congure the Denver Switch for Standard SLB

Step 1 Action Assign an IP address to each of the real servers in the local Denver server pool.
Denver Real Server IP Addresses Real Server Server 11 Server 21 IP address 174.14.7.11 174.14.7.21
On the Denver switch, dene each local real server.

>> Default gateway 1# /cfg/slb/real 11 >> Real server 11# rip 174.14.7.11 >> Real server 11# ena >> Real server 11# /cfg/slb/real 21 >> Real server 21# rip 174.14.7.21 >> Real server 21# ena (Server C is real server 1) (Assign IP address for Server 11) (Enable real server 11) (Server D is real server 21) (Assign IP address for Server 21) (Enable real server 21)
On the Denver switch, dene a real server group.

>> Real server 2# /cfg/slb/group 1 >> Real server group 1# add 11 >> Real server group 1# add 21 >> Real server group 1# health http >> Real server group 1# content index.html (Select real server group 1) (Add real server 11 to group 1) (Add real server 21 to group 1) (Use HTTP for health checks) (Set URL content for health checks)
.
749
On the Denver switch, dene a virtual server.

>> Real server group 1# /cfg/slb/virt 1 >> Virtual server 1# vip 174.14.70.200 >> Virtual server 1# service http >> Virtual server 1 http service# group 1 (Select virtual server 1) (Assign IP address) (Select the HTTP service menu) (Associate virtual port to real group)
>> Virtual server 1 http service# /cfg/slb/virt 1/ena (Enable the virtual server)
On the Denver switch, dene the type of Layer 4 processing each port must support. In this example, the following ports are being used on the Nortel Application Switch:
Web Host Example: Port Usage Port 11 12 2 Host Server 11 Server 12 Layer 4 Processing Server Server

>> # /cfg/slb/port 11 >> SLB port 11# server ena >> SLB port 11# /cfg/slb/port 12 >> SLB port 12# server ena >> SLB port 12# /cfg/slb/port 2 >> SLB port 2# client ena (Select physical switch port 11) (Enable server processing on port 11) (Select physical switch port 12) (Enable server processing on port 12) (Select physical switch port 2) (Enable client processing on port 2)
On the Denver switch, enable SLB.


.
>> # /cfg/slb/on
End
Task 6: Congure the Denver Site for GSLB

Following the same procedure described for San Jose (see "Task 3: Congure the San Jose Site for GSLB" (page 743)), congure the Denver site as follows: Step 1 Action On the Denver switch, turn on GSLB.
>> Virtual server 1# /cfg/slb/gslb/on
Enable DSSP version 2 to send out remote site updates. Unless you are in the middle of network migration to 22.0, you should always enable DSSP version 2.
>> # /cfg/slb/gslb/version 2 (Enable DSSP version 2 updates)
On the Denver switch, dene each remote site. When you start conguring at the Denver site, Denver is local and San Jose is remote. Add and enable the remote switchs IP address interface. In this example, there is only one remote site: San Jose, with an IP interface address of 200.200.200.1. The following commands are used:
>> # /cfg/slb/gslb/site 1 >> Remote site 1# prima 200.200.200.1 >> Remote site 1# ena (Select remote site 1) (Define remote IP interface address) (Enable remote site 1)
Each additional remote site would be congured in the same manner. You can enable up to 64 remote sites. 4 On the Denver switch, assign each remote distributed service to a local virtual server. In this step, the local Denver site is congured to recognize the services offered at the remote San Jose site. As before, congure one real server entry on the Denver switch for each virtual server
.
751
located at each remote site. Since there is only one remote site (San Jose) with only one virtual server, only one more local real server entry is needed at the Denver site. The new real server entry is congured with the IP address of the remote virtual server, rather than the usual IP address of a local physical server. Do not confuse this value with the IP interface address on the remote switch. Also, the remote parameter is enabled, and the real server entry is added to the real server group under the local virtual server for the intended service. Finally, since the real server health checks are headed across the Internet, the health-checking interval should be increased to 30 or 60 seconds to avoid generating excess trafc. The more remote sites you have, the larger the time interval should be. For example:
>> Remote site 1# /cfg/slb/real 1 >> Real server 1# rip 200.200.200.100 >> Real server 1# remote enable >> Real server 1# inter 30 >> Real server 1# ena >> Real server 1# /cfg/slb/grou p 1 >> Real server group 1# add 1 (Create an entry for real server 1) (Set remote virtual server IP address) (Define the real server as remote) (Set a high health check interval) (Enable the real server entry) (Select appropriate. real server group) (Add real server 1 to group 1)
Note: Take care to note where each congured value originates or this step can result in improper conguration. 5 On the Denver switch, dene the domain name and host name for each service hosted on each virtual server. These will be the same as for the San Jose switch: the domain name is "gslb.example.com," and the host name for the HTTP service is "www." These values are congured as follows:
>> Real server group 1# /cfg/slb/virt 1 >> Virtual server 1# dname gslb.example.com
.
(Select virtual server 1) (Define domain name)
>> Virtual server 1# service 80 >> Virtual server 1 http# hname www
(Select HTTP for virtual server) (Define HTTP hostname)

>> Global SLB# apply >> Global SLB# cur >> Global SLB# /cfg/slb/cur (Make your changes active) (View current GSLB settings) (View current SLB settings)
Examine the resulting information. If any settings are incorrect, make and apply any appropriate changes, and then check again. 7 Save your new conguration changes.
Web Host Example: Port Usage Port 11 12 2 Host Server 11 Server 12 Layer 4 Processing Server Server
End
Conguring a Standalone GSLB Domain

An Nortel Application Switch can serve as a standalone GSLB device, which means that it can perform GSLB health checking and site selection to other sites, without supporting SLB to local real servers. The remote sites can be other sites congured with an Nortel Application Switch running GSLB, an Nortel Application Switch running only SLB, or even a site that uses another vendors load balancers. An Nortel Application Switch running GSLB can operate in standalone mode as long as it uses site selection metrics that do not require remote site updates.
.
753
GSLB Topology with a Standalone GSLB Site

GSLB Topology Example 2 - with Standalone GSLB
Task 1: Congure the Basics at the Tokyo Site

Following a similar procedure as described in "Conguring Basic GSLB" (page 735), congure a third siteTokyoin Standalone mode. Remember that in Standalone mode, the Nortel Application Switch does not require SLB conguration of local real servers. Step 1 Action (Optional) On the Tokyo switch, congure management access and management gateway address.
>> # /cfg/sys/mmgmt/addr 43.100.80.20 >> Management Port# mask 255.255.255.0 >> Management Port# gw 43.100.80.1 >> Management Port# ena (Mgmt. port IP address) (Mgmt. port mask) (Mgmt. port gateway addr.) (Enable the Mgmt Port)
.
>> # /cfg/l2/vlan 103/name internet >> VLAN 103# add 3
(VLAN 102 for Internet) (Add port 3 to VLAN 103)
Dene anIP interface to the Internet.

>> # /cfg/l3/if 103 >> IP Interface 103# addr 43.10.10.3 >> IP Interface 103# mask 255.255.255.0 >> IP Interface 103# ena >> IP Interface 103# vlan 103 (Select IP interface 103) (Assign IP address for the interface) (Assign network mask) (Enable IP interface 103) (Assign interface to VLAN 103)
Dene the default gateway.


Congure the local DNS server to recognize the local GSLB switch as the authoritative name server for the hosted services. Determine the domain name that will be distributed to both sites and the host name for each distributed service. In this example, the Tokyo DNS server is congured to recognize 43.10.10.3 (the IP interface of the Tokyo GSLB switch) as the authoritative name server for "www.gslb.example.com." End

.
755
Task 2: Congure the Tokyo Site for GSLB

Following the similar procedure described for San Jose (see "Task 3: Congure the San Jose Site for GSLB" (page 743)), congure the Tokyo site as follows: Step 1 Action On the Tokyo switch, turn on SLB and GSLB.
>> # /cfg/slb >> SLB# on >> # /cfg/slb/gslb >> Global SLB# on (Select the SLB Menu) (Activate SLB for the switch) (Select the GSLB Menu) (Activate GSLB for the switch)
On the Tokyo switch, assign each remote distributed service to a local virtual server. In this step, the local site, Tokyo, is congured to recognize the services offered at the remote San Jose and Denver sites. As before, congure one real server entry on the Tokyo switch for each virtual server located at each remote site. The new real server entry is congured with the IP address of the remote virtual server, rather than the usual IP address of a local physical server. Do not confuse this value with the IP interface address on the remote switch.
>> # /cfg/slb/real 1 >> Real server 1# ena >> Real server 1# name San_Jose >> Real server 1# rip 200.200.200.100 >> Real server 1# remote enable >> # /cfg/slb/real 2 >> Real server 2# ena >> Real server 2# name Denver (Create an entry for San Jose) (Enable the real server entry) (Set a name for the real server entry) (Set remote vip address of San Jose) (Define the real server as remote) (Create an entry for Denver) (Enable the real server entry) (Set a name for the real server entry)
.
>> Real server 2# rip 74.14.70.200 >> Real server 2# remote enable
(Set remote vip address for Denver) (Define the real server as remote)
Note: Take care to note where each congured value originates, or this step can result in improper conguration. 3 Dene a network that will match and accept all incoming trafc for the other sites.
>> # /cfg/gslb/net 1 >> Network 1# ena >> Network 1# sip 0.0.0.0 >> Network 1# mask 0.0.0.0 >> Network 1# addreal 1 >> Network 1# addreal 2 (Create an entry for the new network) (Enable the new network) (Define a source IP address match) (Define a network mask match) (Add the San Jose site to the network) (Add the Denver site to the network)
Dene a new rule that will make the new network active.
>> # /cfg/slb/gslb/rule 1/ena >> Rule 1# dname gslb.example.c om >> Rule 1# metric 1/gmetric network >> Rule 1# metric 1/addnet 1 (Enable the new rule) (Define a domain name) (Define the metric this rule will use) (Add network to the rule metric)

>> Virtual Server 2 http Service# apply >> Global SLB# cur >> Global SLB# /cfg/slb/cur (Make your changes active) (View current GSLB settings) (View current SLB settings)
Examine the resulting information. If any settings are incorrect, make and apply any appropriate changes, and then check again.
.
757
Save your new conguration changes.

Note: Conguration for the Tokyo site is now complete. End
A Standalone DNS Server Conguration

A customer can use any DNS server that can provide the following specic functionality: It is possible to congure 2 NS records: NS1 with Alteon1 interface IP address and NS2 with Alteon2 interface IP address. If Alteon2 is alive, Alteon1 is down (domain name can not be resolved by using NS1) DNS server switches to NS2. If Alteon1 is alive, Alteon2 is down (domain name can not be resolved by using NS2) DNS server switches to NS1. If Alteon1 is alive (NS1 is used), Alteon2 was down; after that Alteon2 is alive, DNS server continues to use NS1. If Alteon2 is alive (NS2 is used), Alteon1 was down; after that Alteon1 is alive, DNS server continues to use NS2 Round Robin algorithm for DNS server can be disabled.
The conguration example for Microsoft Windows 2003 DNS Server is explained below. The DNS server is congured 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 conguration steps on the DNS server machine: Step 1 2 3 4 Action Run the DNS console. Create a primary forward lookup zone com. Create a delegation in zone com: Delegated domain geored; FQDN - geored.com. Add rst resource record: FQDN Alteon1 interface IP address (which is set up by /c/l3/if 1); IP address Alteon1 interface IP address.
.
Add second resource record: FQDN Alteon2 interface IP address; IP address Alteon2 interface IP address. The example of the conguration is as shown in "DNS Console" (page 758).
DNS Console
6 7
Set TTL = 10 seconds for records of zone com. 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 phone that supports DNS and AudioCodes GW) do not work. End
.
759
Conguring GSLB with Rules

GSLB rules can be congured on a per-domain basis to allow dynamic site selection based on time of day for a given domain. The criteria for domain rules are as follows: Each domain has one or more rules. Each rule has a metric preference list. The site selection selects the rst rule that matches for the domain and starts with the rst metric in the metric preference list of the rule.
Up to 128 rules can be congured, with up to eight metrics per rule. The site selection metric sequence in the default Rule 1 is as follows: Step 1 Action Network Preference The rst metric in rule 1 is set to "Network Preference," which selects the server based on the preferred network of the source IP address for a given domain. If preferred networks are not congured, this metric is not used in the default rule. For more information on conguring preferred networks, see "Conguring GSLB Network Preference" (page 762). 2 None The second metric in rule 1 is set to "None" in order to allow you to congure the local or availability metric here. The local server or the server with the highest availability is selected before any subsequent metric is used to select other servers. 3 Geographical preference The third metric in rule 1 is set to "Geographical Preference" so that the IANA-dened geographical region based on the client source IP is used to redirect the request to the clients region. 4 5 Least connections Round robin "Round robin" or random should be the last metric dened in a rule, because they always return a value if there is at least one functional site. 6 7 None None
.
None The last metric in rule 1 should be congured as dnsalways so that the GSLB selection selects at least the local virtual server when all servers are not available. In this case, metric 6 can be congured with DNS always. End
Conguring Time-Based Rules Task 1: Congure the rst time-based rule

Using the base conguration "Conguring Basic GSLB" (page 735), you can dene a new time-based rule for certain networks, as follows: Step 1 Action Disable the default rule 1, in order to ensure that the time based rule is processed rst.
>> # /cfg/slb/gslb/rule 1/dis (Disable rule 1)
Congure the networks to be added to the GSLB rule.

>> # /cfg/slb/gslb/net 43/sip 43.0.0.0/mask 255.0.0.0/addvirt 1/ena >> # /cfg/slb/gslb/net 55/sip 55.0.0.0/mask 255.0.0.0/addreal 10/ena >> # /cfg/slb/gslb/net 56/sip 56.0.0.0/mask 255.0.0.0/addreal 10/ena
Congure a new rule.

>> # /cfg/slb/gslb/rule 2 (Select rule 2)
Specify a start and end time for this rule to be applied.

>> Rule 2# start 7 00/end 18 00/ena >> Rule 2# ena (From 7am until 6PM) (Enable the rule)
Specify the GSLB metrics to be used to select a site if a server is not selected at rst. Since network metric is the rst metric, make sure to add the congured networks to metric 1.

.
761
>> # /cfg/slb/gslb/rule 2/metric 1/gmetric network >> # /cfg/slb/gslb/rule 2/metric 1/addnet 43/addnet 55/addnet 56
Specify the other preferred GSLB metrics.

>> # /cfg/slb/gslb/rule 2/metric 2/gmetric geographical >> # /cfg/slb/gslb/rule 2/metric 3/gmetric roundrobin
Task 2: Congure the second time-based rule Using the steps in "Conguring Time-Based Rules" (page 760), congure another rule with the following parameters.
>> # /cfg/slb/gslb/net 48/sip 48.0.0.0/mask 240.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/gmetric network/addnet 48 >> # /cfg/slb/gslb/rule 4/metric 2/gmetric geographical >> # /cfg/slb/gslb/rule 4/metric 3/gmetric random
Add the rule to the congured virtual server. Using the basic GSLB example, add the following command to the virtual server conguration steps on step 5 on step 5.
>> # /cfg/slb/virt 1/addrule 2/addrule 4 (Add rules 2 and 4 to the virtual server/domain)

>> Rule 2 Metric 4# apply >> Rule 2 Metric 4# save
End
Using the Availability Metric in a Rule

The availability metric selects the next server in a priority list when any capacity thresholds of the previous servers has been reached. Step 1 Action Set the availability metric for metric 2 in rule 1.
.
>> # /cfg/slb/gslb/rule 1/metric 2/gmetric availability
Set the Availability values for the real/virt servers. For example:
>> Rule 1# /cfg/slb/virt 1/avail 11 >> Rule 1# /cfg/slb/real 10/avail 22 >> Rule 1# /cfg/slb/real 11/avail 33 (Set avail. weight for virt. server) (Set avail. weight for real server) (Set avail. weight for real server)

>> Rule 1 Metric 4# apply >> Rule 1 Metric 4# save
End
Conguring GSLB Network Preference

Nortel Application Switch Operating System software allows clients to select GSLB sites based on where the client is located. This is implemented by conguring network preference. Network preference selects the server based 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 "Conguring Client Proximity Table" (page 763), shows how to create rules based on client network preference. Two client networks, A and B, are congured in the network preference rule on the master switch at Site 4. Client A with a subnet address of 205.178.13.0 is congured with a network preference rule for preferred Sites 1 and 3. Client B, with a subnet address of 204.165.0.0, is congured a network preference rule for preferred Sites 2 and 4. Client A, with a source IP address of 205.178.13.10, initiates a request that is sent to the local DNS server. The local DNS server is congured to forward requests to the DNS server at Site 4. The Nortel Application Switch at Site 4 looks up its network preference and nds Client A prefers to connect to Sites 1 or 3. Similarly, Client Bs requests are always forwarded to Sites 2 or 4.
.
Global Server Load Balancing Conguring Client Proximity Table
763
Note: Nortel Application Switch Operating System allows you to congure up to 128 preferred client networks. Each network can contain up to 1023 real servers. Use the following commands to congure network preferences on the application switch at Site 4:
>> # /cfg/slb/gslb/net 1/ >> Network 1# sip 205.178.13.0 >> Network 1# mask 255.255.255.0 >> Network 1# addreal 1/addreal 3 >> # /cfg/slb/gslb/net 2/ >> Network 2# sip 204.165.0.0 >> Network 2# mask 255.255.0.0 >> Network 2# addreal 2 >> Network 2# addvir 4 (Select Network 1) (Assign source address for Client A) (Assign the mask for Client A) (Add real servers 1 and 3) (Select Network 2) (Assign source address for Client B) (Assign the mask for Client B) (Add real server 2) (Select preferred Site 4)
.
>> # /cfg/slb/gslb/rule 1/metric 1 >> Rule 1 Metric 2# addnet 1/addnet 2
(Select metric 1-network preference) (Add Network 1 and Network 2)
Using this conguration, the DNS request for "nortelnetworks.com" from client IP 205.178.13.0 will receive a DNS response with only the virtual server IP address of Site 1, if Site 1 has less load than Site 3.
Conguring GSLB with Proxy IP for Non-HTTP Redirects

Typically, client requests for HTTP applications are automatically redirected to the location with the best response and least load for the requested content. The HTTP protocol has a built-in redirection function that allows requests to be redirected to an alternate site. However, if a client requests a non-HTTP application such as FTP, POP3, or SMTP, then the lack of a redirection function in these applications requires that a proxy IP address be congured on the client port. The client port will initiate a redirect only if resources are unavailable at the rst site. Note: This feature should be used as a method of last resort for GSLB implementations in topologies where the remote servers are usually virtual server IP addresses in other Nortel Application Switches. "HTTP and Non-HTTP Redirects" (page 765) illustrates the packet-ow of HTTP and non-HTTP redirects in a GSLB environment. "HTTP Versus Non-HTTP Redirects" (page 764) explains the packet -ow process in detail. In this example, the HTTP or non-HTTP request from the client reaches Site 2, but Site 2 has no available services.
HTTP Versus Non-HTTP Redirects Site 2 Nortel Application Switch Switch HTTP application (built-in redirectio n) Non-HTTP application (no redirection Site 1 Nortel Application Switch Switch
2a. Client resends request to Site 1. 1a Client HTTP request reaches Site 2. Resources are unavailable at Site 2. Resources are available at Site 1. Site 2 sends an HTTP redirect to Client with Site 1s virtual server IP address. 1b. Client non-HTTP request reaches Site 2. Resources are unavailable at Site 2. Site 2 sends a request to Site 1 with Site 2s proxy IP address as the source IP address and the virtual server IP address of Site 1 as the destination IP address. 2b. Site 1 processes the client proxy IP request. Resources are available at Site 1. Site 1 returns request to proxy IP port on Site 2.
.
Global Server Load Balancing HTTP and Non-HTTP Redirects
765
How Proxy IP Works

"POP3 Request Fullled via IP Proxy" (page 765) shows examples of two GSLB sites deployed in San Jose and Denver. The applications being load balanced are HTTP and POP3. Any request that cannot be serviced locally is sent to the peer site. HTTP requests are sent to the peer site using HTTP Redirect. Any other application request will be sent to the peer site using the proxy IP feature.
POP3 Request Fullled via IP Proxy
The following procedure explains the three-way handshake between the two sites and the client for a non-HTTP application (POP3).
.
Step 1
Action A user POP3 TCP SYN request is received by the virtual server at Site 2. The switch at that site determines that there are no local resources to handle the request. The Site 2 switch rewrites the request such that it now contains a client proxy IP address as the source IP address, and the virtual server IP address at Site 1 as the destination IP address. The switch at Site 1 receives the POP3 TCP SYN request to its virtual server. The request looks like a normal SYN frame, so it performs normal local load-balancing. Internally at Site 1, the switch and the real servers exchange information. The TCP SYN ACK from Site 1s local real server is sent back to the IP address specied by the proxy IP address. The Site 1 switch sends the TCP SYN ACK frame to Site 2, with Site 1s virtual server IP address as the source IP address, and Site 2s proxy IP address as the destination IP address. The switch at Site 1 receives the frame and translates it, using Site 1s virtual server IP address as the source IP address and the clients IP address as the destination IP address. This cycle continues for the remaining frames to transmit all the clients mail, until a FIN frame is received. End
Conguring Proxy IP Addresses

The switch at Site 1 in San Jose is congured with switch port 6 connecting to the default gateway and real server 3 represents the remote server in Denver. The following commands are used at Site 1 in San Jose to congure the proxy IP address for the remote server in Denver:
>> # /cfg/slb/pip >> Proxy IP address# type port >> Proxy IP address# add 200.200.2 00.4 >> # /cfg/slb/port 6/proxy enable (Select proxy IP address menu) (Use port-based proxy IP) (Set unique proxy IP address) (Enable proxy on the port)
.
767
>> Proxy IP address /cfg/slb/real 1/proxy dis (Disable local real server proxy) >> Real server 1# /cfg/slb/real 2/proxy dis (Disable proxy for local server) >> Real server 2# /cfg/slb/real 3/proxy ena (Enable proxy for remote server) >> Real server 3# apply >> Real server 3# save (Apply configuration changes) (Save configuration changes)
For more information on proxy IP address, see "Proxy IP Addresses" (page 228). If you want to congure proxy IP addresses on Site 2, the following commands are issued on the Denver switch:
>> # /cfg/slb/pip >> Proxy IP address# type port >> Proxy IP address# add 174.14.70 .4 >> # /cfg/slb/port 4/proxy enable (Select proxy IP address menu) (Use port-based proxy IP) (Set unique proxy IP address) (Enable proxy on the port)
>> Proxy IP address# /cfg/slb/real 1/proxy dis (Disable local real server proxy) >> Real server 1# /cfg/slb/real 2/proxy dis (Disable local real server proxy) >> Real server 2# /cfg/slb/real 3/proxy ena (Enable proxy for remote server) >> Real server 3# apply >> Real server 3# save (Apply configuration changes) (Save configuration changes)
Using Border Gateway Protocol for GSLB

Border Gateway Protocol (BGP)-based GSLB utilizes the Internets routing protocols to localize content delivery to the most efcient and consistent site. This is done by using a shared IP block that co-exists in each Internet Service Providers (ISPs) network and is then advertised, using BGP, throughout the Internet. Because of the way IP routing works, BGP-based GSLB allows for the routing protocols to route DNS requests to the closest location, which then returns IP addresses of that particular site, locking in the requests to that site. 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 the reliability and bandwidth of their Internet connection. Enterprises with more than one ISP are referred to as being multi-homed. Instead of multi-homing a network to several other networks, BGP-based GSLB enables you to multi-home a particular piece of content (DNS information) to the Internet by distributing the IP blocks that contain that content to several sites. When using DNS to select the site, a single packet is used to make the decision so that the request will not be split to different locations. Through the response to the DNS packet, a client is locked in to a particular site, resulting in efcient, consistent service that cannot be achieved when the content itself is shared. For example, in multi-homing, you can connect a data center to three different Internet providers and have one DNS server that has the IP address 1.1.1.1. In this case, all requests can be received via any given feed but are funneled to the same server on the local network. In BGP-based GSLB, the DNS server (with the IP address 1.1.1.1) is duplicated and placed local to the peering point instead of having a local network direct trafc to one server. When a particular DNS server receives a request for a record (in this case, the application switch), it returns with the IP address of a virtual server at the same site. This can be achieved using the local option (/cfg/slb/gslb/rule 1/metric 2/gmetric local) in the GSLB conguration. If one site is saturated, then the switch will failover and deliver the IP address of a more available site. For more information on conguring your switch to support BGP routing, see "Border Gateway Protocol" (page 131).
Verifying GSLB Operation

Use your browser to request the congured service (www.gslb.example.com in the previous example). Examine the /info/slb and /info/slb/gslb information on each switch. Check to see that all SLB and GSLB parameters are working according to expectation. If necessary, make any appropriate conguration changes and then check the information again. Examine the /stats/slb and /stats/slb/gslb statistics on each switch.
.
Bandwidth Management
769
Bandwidth Management (BWM) enables Web site managers to allocate a portion of the available bandwidth for specic users or applications. It allows companies to guarantee that critical business trafc, such as e-commerce transactions, receive higher priority versus non-critical trafc. Trafc classication can be based on user or application information. BWM policies can be congured to set lower and upper bounds on the bandwidth allocation. The following topics are addressed in this chapter: "Enabling Bandwidth Management" (page 769) "Contracts" (page 770) "Policies" (page 776) "Rate Limiting" (page 777) "Trafc Shaping" (page 780) "Bandwidth Management Information" (page 781) "Packet Coloring (TOS bits) for Burst Limit" (page 783) "Conguring Bandwidth Management" (page 784) "Additional BWM Conguration Examples" (page 788)
Enabling Bandwidth Management

To use the bandwidth management features, you must purchase an additional software license and password key. Instructions for obtaining a password key are provided with your software license certicate. 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 keys may only be enabled if Layer 4 services have been enabled. Once you have obtained the proper password key to enable BWM, follow these instructions: Step 1 Action Connect to the switch command line interface via Telnet or the console port, and login as the administrator, following the directions in the Nortel Application Switch Operating System Command Reference. From the command line prompt, type the /oper/swkey command.
.
You will be prompted to enter the password key. If the key is correct for this switchs MAC address, the switch will accept the password, permanently record it in the switchs non-volatile RAM (NVRAM), and will then enable the feature. End
Contracts
A contract is created to assign a certain amount of bandwidth. Up to 1024 contracts can be congured on a single Nortel Application Switch. The switch uses these contracts to limit individual trafc ows. Contracts can be assigned to different types of trafc. Trafc can be classied based on layer 2, layer 4, or layer 7 trafc. Trafc classication can be based on the following: port, VLAN, trunk, lters, virtual IP address, service on the virtual server, URL, and so on. Any item that is congured with a lter can be used for BWM. Bandwidth classication is performed using the following menus: /cfg/slb/filt is used to congure classications based on the IP destination address, IP source address, TCP port number, UDP, UDP port number, 802.1p priority value, or any lter rule. /cfg/slb/virt is used to congure classications based on virtual servers. /cfg/port is used to congure classications based on physical ports (in case of trunking, use /cfg/l2/trunk). /cfg/l2/vlan is used to congure classications based on VLANs. /cfg/slb/layer7/lb is used to congure classication based on URL paths.
To associate a particular classication with a contract, enter the contract index into the cont menu option under the applicable conguration menus. When Virtual Matrix Architecture (VMA) is enabled, trafc classication is done on the ingress portthat is, the port on which the frame is received (not the client port or the server port). If the trafc classication is done on layer 4 through layer 7 trafc (lter-based or SLB trafc), then the classication occurs on the designated port.
.
Bandwidth Management Bandwidth Management: How It Works
771
Classication Rules
In a classication rule certain frames are grouped together. For frames qualifying for multiple classications, precedence of contracts is also specied per contract. If no precedence is specied, the default order is used (see "Classication Precedence" (page 772)). The following classications are aimed at limiting the trafc outbound from the server farm for bandwidth measurement and control. Physical Port - All frames are from a specied physical port. VLAN - All frames are from a specied VLAN. If a VLAN translation occurs, the bandwidth policy is based on the ingress VLAN. IP Source Address - All frames have a specied IP source address or range of addresses dened with a subnet mask. IP Destination Address - All frames have a specied IP destination address or range of addresses dened 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 a particular virtual server IP address.
.
The following are various Layer 7 groupings: A single URL path A group of URL paths A single cookie
Classication Precedence
If a frame qualies for different classications, it is important to be able to specify the classication with which it should be associated. There are two mechanisms to address classicationa per-contract precedence value and a default precedence ordering from 1-255. The higher numbers having the higher precedence. If a contract does not have an assigned precedence value, then the default ordering is applied as follows: Step 1 2 3 4 5 Action Incoming source port/default assignment VLAN Filter Layer 4 services on the virtual server Layer 7 applications (for example, URL, HTTP, headers, cookies, and so forth End
If a frame falls into all of classications #15, and if the precedence is same for all the applicable contracts, then the Layer 7 applications contract classication (#5) will be assigned since it comes last and has the highest presentness.
Application Bandwidth Control

Classication policies allow bandwidth limitations to be applied to particular applications; that is, they allow applications to be identied and grouped. Classication can be based on any ltering rule, including those listed below: Layer 7 strings that identify which application the trafc belongs to TCP Port Number - All frames with a specic TCP source or destination port number UDP - All UDP frames UDP Port Number - All frames with a specic UDP source or destination port number
.
773
Combinations
Combinations of classications are limited to grouping items together into a contract. For example, if you wanted to have three different virtual servers associated with a contract, you would specify the same contract index on each of the three virtual server IP addresses. You can also combine lters in this manner. "Grouped Bandwidth Contracts" (page 773) describes how the contracts can be grouped together to aggregate BWM resources. "IP User Level Contracts for Individual Sessions" (page 774) describes a user level contract.
Grouped Bandwidth Contracts

The Nortel Application Switch Operating System uses the concept of multi-tiered, or grouped bandwidth management contracts. In earlier Nortel Application Switch Operating System releases, a single level bandwidth management contract was used to manage bandwidth on an Nortel Application Switch. BWM contract groups can now be congured to aggregate contract resources and share unused bandwidth within the contract group. A group level contract should contain two or more individual contracts as dened in "Contracts" (page 770). Based on how much trafc is sent in each contract in the group, the hard limits of the contracts will be adjusted proportionately to their share in the group. For example, a group level contract is congured with four individual contracts with rate limits of 10, 20, 30 and 40 Mbps each. Together, the total rate limit of the member contracts is 100 Mbps. If a particular contract is not using its full bandwidth allocation, the switch will re-allocate the bandwidth to the other members of the contract group by polling bandwidth statistics every second, and re-calculating the bandwidth allocation. "Bandwidth Reallocation in Grouped Contracts" (page 774) shows how individual contracts hard limits self-adjust when placed into a contract group. The hard limit indicates the actual hard limits set for each individual contract. Since Contracts 14 are part of a contract group, the Total hard limit allowed for the group in this example is 100 Mbps. The actual trafc indicates that Contracts 1 and 4 have exceeded their hard limits by a total of 25 Mbps. Contract 3 is underutilizing its hard limit by 10 Mbps. Because all contracts are members of the group, the unused bandwidth is divided proportionately between the two contracts that exceeded their hard limitsContracts 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 BW Hard Limit for the contract group, it will thus receive one-fth of the
.
available Extra Share, or 2 Mbps. The remaining 3 Mbps that Contract 1 requested 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 Hard Limit for the contract group, it will thus receive four-fths of the Extra Share, or 12 Mbps. The remaining 12 Mbps requested by Contract 4 is dropped.
Bandwidth Reallocation in Grouped Contracts Contract 1 Hard Limit (Mbps) Actual traffic Unused BW BW over Hard Extra Share Adjusted Hard Limit (All units in Mbps) a. Denotes the BW over hard limit in Contract 1, divided by the Total BW over hard 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 over hard limit for the contract group, multiple by the total Extra Share bandwidth. 12 10 15 NA 5 Contract 2 20 20 NA 0 0 20 Contract 3 30 20 10 NA NA 20 48 Contract 4 40 60 NA 20 Total 100 115 10 25 10 100
The soft and reserved (CIR) limits of each contract are not part of the grouped contracts calculation, and remain set at their individual contracts levels. For a group contract conguration example, see "ConguringGrouped Contracts for Bandwidth Sharing" (page 791).
IP User Level Contracts for Individual Sessions

The Nortel Application Switch Operating System contains user limits for bandwidth management. User limits are policies that can be applied to a contract that specify a rate limit for each user who is sending or receiving trafc in that contract. Each user is identied by his/her IP address. The contract can be congured to identify a user by either the source or the destination IP address in the packets. An individual users bandwidth can be restricted by setting a limit based on the users IP address, monitoring the amount of bandwidth used per second, and dropping any trafc that exceeds the congured limit. In order
.
775
to monitor a users bandwidth, the switch creates a user entry that records the source or destination IP address, and the amount of bandwidth used. This user entry is called an IP user entry, because the user is identied by his/her IP address. The user limit feature is extremely useful for limiting bandwidth hogging by a few overactive internet users with unimportant trafc (for example peer-to-peer movie sharing), which may end up denying the other users with legitimate trafc from their fair share. Since the user limiting is done on per-contract basis, different types of trafc can be classied into different contracts and can have different user limits applied according to the class of trafc. Also, since user limiting for a contract is optional, it can be congured for some contracts with class of trafc where fair sharing of bandwidth is important, and not congured for the contracts where fair sharing of bandwidth is not important or undesirable. The following sections describe how user limits work.
User Limits are Overwritten by the Contract Hard Limit

The IP user limit is congured in addition to the contracts hard limit. However, the contracts hard limit overrides the individual user entrys user limit. For example, consider a contract with hard limit 10 Mbps and user limit 1 Mbps. If there are 20 IP users for the contract with offered trafc rate of 1 Mbps each (for total offered trafc rate for the contract 20 Mbps), the total trafc allowed for the contract will not exceed the hard limit (10 Mbps). Therefore, even though the individual IP user limits do not exceed their 1 Mbps hard limit, some or all of the IP users may have some trafc dropped because the contracts hard limit (10 Mbps) is less than the total of the offered trafc rate for all 20 users (20 Mbps).
User Limits are Maintained when a Contract has Available Bandwidth

Consider another example for the same contract (hard limit 10 Mbps, user limit 1 Mbps) where there are two IP users for the contract, with offered trafc rate of 5 Mbps each (total offered trafc rate for the contract 10 Mbps). Even though the offered trafc rate for the whole contract does not exceed the hard limit, Nortel Application Switch Operating System will limit the trafc for both the IP users to their user limits: 1 Mbps each. The user limit congured for a contract will be the limit for one egress SP rather than the entire switch. For example; on an Nortel Application Switch 2424, if a contract is congured for a user limit of 64 kbpsand trafc for a 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 kbps egressing out on port 20.
.
For an example, see "Conguring a IP User-Level Rate Limiting Contract" (page 794).
Policies
Bandwidth policies are bandwidth limitations dened for any set of frames, that specify the maximum, best effort, and minimum guaranteed bandwidth rates. A bandwidth policy is assigned to one or more contracts. A bandwidth policy is often based on a rate structure whereby a Web host or co-location provider could charge a customer for bandwidth utilization. There are three rates that are congured: a Committed Information Rate (CIR)/Reserved Limit, a Soft Limit, and a Hard Limit, as described below.
Bandwidth Policy Index

Each 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 classications associated with each contract can be viewed using the /info/bwm menu. Each bandwidth policy, composed of the reserved, soft, hard and optional user limits, is assigned an index. These policies can be found under the /cfg/bwm menu. Up to 64 bandwidth policies can be dened. Bandwidth limits 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 as either "1" or as "1024k." In addition, a queue size is associated with each policy. The queue size is measured in bytes.
Time Policy
A BWM contract can be congured to apply different time policies dened by ranges of hours or days of the week. The time policy is based on the time set in the switchs system clock (/info/sys/general). "Conguring Time and Day Policies" (page 809) describes how to congure and apply policies to different times and days.
Enforcing Policies
In order for BWM contracts and policies to take effect, the policies must be enforced using the /cfg/bwm/force ena command.
.
777
Even when BWM is not enforced, the Nortel Application Switch can still collect classication information and report it, allowing an administrator to observe a network for a while before deciding how to congure it. This feature can be disabled using /cfg/bwm/force dis. When this command is used, no limits will be applied on any contract.
Rate Limiting
A rate limiting contract is controlled by metering the trafc that egresses from the switch. If the egress rate is below the congured rate limit (hard limit) for the port, the trafc is transmitted immediately without any buffering. If the egress rate is above the congured rate limit the trafc above the rate limit is dropped.
Bandwidth Rate Limits
For rate limiting contracts, the queue depth is ignored because trafc is not buffered. Typically, bandwidth management occurs on the egress port of the switchthat is, the port from which the frame is leaving. However, in the case of multiple routes or trunk groups, the egress port can actually be one of several ports (from the point-of-view of where the queues are located). A bandwidth policy species four limits, listed and described in "Bandwidth Rate Limits" (page 778):
.
778 Part 4: Advanced Switching Bandwidth Rate Limits Rate Limit Committed Information Rate (CIR) or Reserved Limit Description This is a rate that a bandwidth classification is always guaranteed. In configuring BWM contracts, ensure that the sum of all committed information rates never exceeds the link speeds associated with ports on which the traffic is transmitted. In a case where the total CIRs exceed the outbound port bandwidth, the switch will perform a graceful degradation of all traffic on the associated ports. For traffic shaping contracts, this is the desired bandwidth rate, that is, the rate the customer has agreed to pay on a regular basis. When output bandwidth is available, a bandwidth class will be allowed to send data at this rate. No exceptional condition will be reported when the data rate does not exceed this limit. For rate limiting contracts, the soft limit is ignored. This is a "never exceed" rate. A bandwidth class is never allowed to transmit above this rate. Typically, traffic bursts between the soft limit and the hard limit are charged a premium. The maximum hard limit for a bandwidth policy is 1 Gbps, even when multiple Gigabit ports are trunked. To ensure a specific amount of throughput on a port, configure hard and soft limits close together. For example: to ensure 20Mbps of throughput on a 100Mbps port, create a policy on a contract that sets the hard limit to 20M, and the soft limit to 19M. If you apply this contract to a filter on the egress port, 20Mbps of throughput can be ensured. A user limit is a Hard Limit rate for individual users. It is defined as a policy and is applied and enabled for an individual contract. It is based on either a source IP or destination IP address. Setting user limits requires that a contract be configured that enables IP limiting (/cfg/bwm/cont <x> /iplimit ena), and sets the type 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 to traffic between 0kbps and 1000Mbps. A user limit based on source IP address should be set if the goal is to limit the amount of data being transmitted from a source IP address in your network. A user limit based on destination IP address should be set if the goal is to limit the amount of data being downloaded from a destination IP address in your network.
Soft Limit
Hard Limit
User Limit
.
779
Application Session Capping

Application Session Capping is a feature that allows limits to be placed on the number of sessions on a user per contract or per contract basis. Bandwidth contracts will now have an additional maximum sessions parameter that will dene the upper limit at which the application will be capped. 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 in todays world of peer to peer applications that require a large amount of network bandwidth. This feature will allow the switch administrator to cap the 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 or completely eliminated on the network. Note: For the purposes of this feature, a user is dened as a unique source IP address and the application is identied based upon a bandwidth contract This feature functions by creating an entry in the session table that designates the contract/user combination. Whenever a new session is created, this entry is checked against existing sessions in the session table and if a match is made, the maximum sessions value is queried. If the maximum sessions value has been reached, the new session will be dropped. If the value has not been reached, the session count is incremented and the session allowed to continue. Note 1: Application Session Capping is not supported when a contract is assigned to a port, VLAN, trunk, or virtual service. Note 2: Application Session Capping does not support an iplimit contract based on DIP. It will however support on based on SIP.
Rate Limiting Timeslots

For rate limiting contracts, metering of individual trafc ows is accomplished using several timeslots per second. The timeslot trafc limit is the trafc that is sent for a particular contract for every timeslot corresponding to the contracts rate limit or the hard limit is initially calculated.
.
For any contract there is one timeslot trafc limit for each egress port. The timeslot trafc limit is calculated from the hard limit. The timeslot trafc limit is the amount of trafc that corresponds to the hard limit per second divided by the number of timeslots per second. Trafc is transmitted for every timeslot as long as the trafc is below the timeslot trafc limit for the contract. Any trafc that exceeds the timeslot trafc is discarded.
Trafc Shaping
A trafc shaping contract establishes queues and schedules when frames are sent from each queue. Trafc is shaped by pacing the packets according to the hard, soft and reserve limits. Each frame is put into a managed buffer and placed on a contract queue. The time that the next frame is supposed to be transmitted for the contract queue is calculated according to the congured rate of the contract, the current egress rate of the ports, and the buffer size set for the contract queue. The scheduler then organizes all the frames to be sent according to their time-based ordering and meters them out to the port. When packets in a contract queue have not yet been sent and the buffer size set for the queue is full, any new frames attempting to be placed in the queue is discarded. For trafc shaping contracts, a queue depth is also associated with a policy. A queue depth is the size of the queue that holds the data. It can be adjusted to accommodate delay-sensitive trafc (such as audio) versus drop-sensitive trafc (such as FTP).
Data Pacing for trafc shaping Contracts

The mechanism used to keep the individual trafc ows under control in a trafc shaping contract is called data pacing. It is based on the concept of a real-time clock and theoretical departure times (TDT). The actual calculation of the TDT is based initially on the congured soft limit rate. The soft limit can be thought of as a target limit for the ISPs customer. As long as bandwidth is available and the classication queue is not being lled at a rate greater than the soft limit, the TDT will be met for both incoming frames and outgoing frames and no borrowing or bandwidth limitation will be necessary. If the classication queue exceeds the soft limit, a frame is queued for transmittal and the TDT is increased by the size of the frame multiplied by the transmittal rate of the queue. "Real-time Clocks and Theoretical Departure Times" (page 781) shows a simple illustration of how data may be paced in a trafc shaping contract. Six arriving frames are processed differently depending on rate of the queue. Queue 1 processes each packet evenly. Queue 2 processes per
.
781
1500 bytes and inserts some delay as it processes the rst three 500 byte frames and then the next three frames. Queue 3 processes at 3000 bytes per second and has ample capacity to process egress frames at the same rate 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 soft limit and sufcient bandwidth is still available, the rate is adjusted upwards based on the depth of the queue, until the rate is fast enough to reduce the queue depth or the hard limit is reached. If the data cannot be transmitted at the soft limit, then the rate is adjusted downward until the data can be transmitted or the CIR is hit. If the CIR is overcommitted among all the contracts congured for the switch, graceful degradation will reduce each CIR until the total bandwidth allocated ts within the total bandwidth available.
Bandwidth Management Information

Statistics are stored in the individual Switch Processors (SP) and then collected every second by the MP (Management Processor). The MP then combines the statistics, as statistics for some classications may be spread across multiple SPs.
Viewing BWM Statistics

The /stats/bwm/dump command displays the total number of octets sent, octet discards, and times over the soft limit are kept for each contract. The history buffer maintains the average queue size for the time interval and the average rate for the interval. Packet counters also maintain bandwidth management statistics for packets on a per contract basis as well as calculation of the average packet size.
.
Conguring BWM History

History is maintained only for the contracts for which the history option is enabled (/cfg/bwm/cont x/hist).
Sending BWM History

The MP maintains global statistics, such as total octets, and a window of historical statistics. When the history buffer of 128K is ready to overow, it can be sent from the switch using either an e-mail or direct socket transfer mechanism. To congure the sending of bandwidth management statistics, follow this procedure: Step 1 Action Select the statistics delivery method. Bandwidth Management statistics can be sent through e-mail or by 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, issue the following commands:
>> Main# /cfg/bwm/email disable (E-Mail statistics delivery must be disabled)
>> Main# /cfg/bwm/report <Reporting Server IP Address>
BWM statistics will be sent to TCP port 49152 of the specied reporting server. 2 Congure the selected delivery method. To congure e-mail usage, issue these commands:
>> Main# /cfg/bwm/user <SMTP User Name> >> Main# /cfg/sys/smtp <SMTP host name or IP address>
To congure socket delivery usage, issue this commands:
.
783
>> Main# /cfg/sys/mmgmt/repor t {mgmt | data}
(Select to use the management or data port to communicate with the reporting server).
To obtain graphs, the data must be collected and processed by an external entity through SNMP. End
Statistics and Management Information Bases

For existing BWM classes: As mentioned above, the MP maintains per-contract rate usage statistics. These are obtainable via a private MIB. When BWM services are not enabled: Even when BWM is not enforced, the MP can still collect classication information and report it, allowing an administrator to observe a network for a while before deciding how to congure it. This feature can be disabled using /cfg/bwm/force dis. When this command is used, no limits will be applied on any contract.
Synchronizing BWM Congurations in VRRP

BWM congurations will optionally be synchronized to a backup switch during VRRP synchronization. However, port contracts and VLAN contracts will not be synchronized. For more information on VRRP and synchronized congurations, see "Conguring VRRP Peers for Synchronization" (page 578).
Packet Coloring (TOS bits) for Burst Limit

Whenever the soft limit is exceeded, optional packet coloring can be done to allow downstream routers to use diff-serv mechanisms (that is, writing the Type-Of-Service (TOS) byte of the IP header) to delay or discard these out-of-prole frames. Frames that are not out-of -prole are marked with a different, higher priority value. This feature can be enabled or disabled on 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 (depending on whether trafc is over or under the soft TOS limit) are set in the bandwidth policy menu (/cfg/bwm/pol <x>) with the utos and otos options. The
.
values allowed are 0-255. Typically, the values specied should match the appropriate diff-serv specication but could be different, depending on the customer environment.
Contract-Based Packet Mirroring

The Nortel Application Switch Operating System features the availability of contract-based packet mirroring. This feature allows an egress packet that matches a contract to be mirrored to a specied port. This feature can be used for troubleshooting and analysis as well as a tool to identify new signatures for Internet Trafc Management (ITM) functionality. The user enables packet mirroring on a contract by conguring a valid mirroring port. When a packet is classied, if a mirroring port is congured for that contract, a copy of the packet will be mirrored to the congured port. The packet is mirrored at the egress port after all modications are made 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 are also copied to the mirroring port.
Conguring Bandwidth Management

The following procedure provides general instructions for conguring BWM on the switch. Specic conguration examples begin on "Additional BWM Conguration Examples" (page 788). Step 1 Action Congure the switch as you normally would for SLB. Conguration includes the following tasks: Assign an IP address to each of the real servers in the server pool. Dene an IP interface on the switch. Dene each real server.
.
785
Dene a real server group. Dene a virtual server. Dene the port conguration.
For more information about SLB conguration, see "Server Load Balancing" (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 entering its software key. For more information, see "Enabling Bandwidth Management" (page 769).
>> # /cfg/bwm/on (Turn BWM on)
Select a bandwidth policy. Each policy must have a unique number from 1 to 64.
>> Bandwidth Management# pol 1 (Select bandwidth policy 1)
Set the hard, soft, and reserved rate limits for the policy, in Mbps. Typically, charges are applied for burst rates between the soft and hard limit. Each limit must be set between 64K-1000M. Note: For rates less than 1 Mbps, append a "K" sufx to the number.
>> Policy 1# hard 6 >> Policy 1# soft 5 >> Policy 1# resv 4 (Set "never exceed" rate) (Set desired bandwidth rate) (Set committed information rate)
(Optional) Set the Type-Of-Service (TOS) byte value, between 0-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 to overwrite the TOS values of IP packets if the trafc for a contract is under or over the soft limit, respectively. These values only have signicance to a contract if TOS overwrite is enabled in the Bandwidth Management Contract Menu (/cfg/bwm/cont <x> /wtos ena). The administrator has to be very careful in selecting the TOS values because of their greater impact on the downstream routers.

.
>> Policy 1# utos 204 >> Policy 1# otos 192
(Set BWM policy underlimit) (Set BWM policy overlimit)
Set the buffer limit for the policy. Set a value between 8192-128000 bytes. The buffer depth for a BWM contract should be set to a multiple of the packet size. Note: Keep in mind that the total buffer limit for the Bandwidth Management policy is 128K.
>> Policy 1# buffer 16320 (Set BWM policy buffer limit)
On the switch, select a BWM contract and (optional) a name for the contract. Each contract must have a unique number from 1 to 256.
>> Policy 1# /cfg/bwm/cont 1 >> BWM Contract 1# name BigCorp (Select BWM contract 1) (Assign contract name "BigCorp")
(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 is applicable to different classications, then the contract with higher precedence will be assigned to the frame. If the precedence is the same for the applicable contracts, then the following order will be used to assign the contract to the frame: (1) Incoming port, (2) VLAN, (3) Filter, (4) Service on the Virtual server, (5) URL/Cookie
>> BWM Contract 1# prec 1 (Sets contract precedence value to 1)
(Optional) Enable TOS overwriting for the BWM contract.

>> BWM Contract 1# wtos ena (Enables TOS overwriting for contract)
10
Set the bandwidth policy for this contract. Each bandwidth management contract must be assigned a bandwidth policy.
.
787
>> BWM Contract 1# pol 1
(Assign policy 1 to BWM contract 1)
11
(optional) Enable trafc shaping. Rate limiting is enabled by default. Enabling trafc shaping automatically disables rate limiting. See "Trafc Shaping" (page 780) 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 BWM contract to the lter or virtual IP address. Each BWM contract must be assigned a classication rule. The classication can be based on a lter or service(s) on the Virtual server. Filters are used to create classication policies based on the IP source address, IP destination address, TCP port number, UDP, and UDP port number.
>> BWM Contract 1# /cfg/slb/vi rt 1/cont 1 >> Virtual Server 1# /cfg/slb/f ilt 1/adv/cont 1 (Assign contract to virtual server) (Assign contract 1 to filter 1)
In this case, all frames that match lter 1 or virtual server 1 will be assigned contract 1. 14 On the switch, apply and verify the conguration.
>> Filter 1 Advanced# apply >> Filter 1 Advanced# /cfg/bwm/cur (Make your changes active) (View current settings)
Examine the resulting information. If any settings are incorrect, make any appropriate changes. 15 On the switch, save your new conguration 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. If necessary, make any appropriate conguration changes and then check the information again. End
Additional BWM Conguration Examples

Examples are provided for the following Bandwidth Management applications: "Conguring User/Application Fairness" (page 788) "ConguringGrouped Contracts for Bandwidth Sharing" (page 791) "Conguring a IP User-Level Rate Limiting Contract" (page 794) "Conguring BWMPreferential Services" (page 796) "Conguring Content Intelligent Bandwidth Management" (page 799) "Conguring Cookie-Based Bandwidth Management" (page 803) "ConguringSecurity Management" (page 807) "Conguring Time and Day Policies" (page 809) "Egress Bandwidth Tuning for Lower Speed Networks" (page 811) "Conguring Intelligent Trafc Management" (page 812) Note: Ensure BWM is enabled on the switch (/cfg/bwm/on).
Conguring User/Application Fairness

Bandwidth Management can be applied to prevent heavy bandwidth bursters from locking out other users, such as the following: Customers using broadband access (such as DSL) blocking dial-up customers Customers using the same hosting facility locking out each other because of ash crowd FTP locking out Telnet Rate limits of particular applications
.
789
In the following example, BWM is congured to prevent broadband customers from affecting dial-up customer access. This is accomplished by setting higher bandwidth policy rate limits for the port that processes broadband trafc. Policy 1 is for dialup customers with lower bandwidth allocation needs Policy 2 is for broadband customers with higher bandwidth allocation needs. Action Select the rst bandwidth policy for dialup customers. Each policy must have a number from 1 to 512. Note: Ensure BWM is enabled on the switch (/cfg/bwm/on).
>> # /cfg/bwm/pol 1 (Select BWM policy 1)
Step 1
Set the hard, soft, and reserved rate limits for the bandwidth policy, in Mbps.
On the switch, select a BWM contract and name the contract. Each contract must have a unique number from 1 to 1024.
>> Policy 1# /cfg/bwm/cont 1 >> BWM Contract 1# name dial-up (Select BWM contract 1) (Assign contract name "dial-up")
Set the bandwidth policy for this contract. Each BWM contract must be assigned a bandwidth policy.
>> BWM Contract 1# pol 1 (Assign policy 1 to BWM Contract 1)
Enable this BWM contract.

Select the second bandwidth policy for broadband customers.
.
>> BWM Contract 1# /cfg/bwm/po l 2
(Select bandwidth policy 2)
Set the hard, soft, and reserved rate limits for this policy, in Mbps.
On the switch, select the second BWM contract and name the contract.
>> Policy 2# /cfg/bwm/cont 2 >> BWM Contract 2# name broadband (Select BWM contract 2) (Assign contract name "broadband")
Set the bandwidth policy for this contract. Each BWM contract must be assigned a bandwidth policy.
>> BWM Contract 2# pol 2 (Assign policy 2 to BWM contract 2)
10

11
Assign the BWM contracts to different switch ports. Physical switch ports are used to classify which frames are managed by each contractthat is, one BWM contract will be applied to all frames from a specic port. The second contract will be applied to all frames from another specied port.
>> BWM Contract 2# /cfg/port 1/cont 1 >> Port 1# /cfg/slb/port 2/cont 2 (Assign contract 1 to port 1) (Assign contract 2 to port 2)
12
On the switch, apply and verify the conguration.

>> Port 2# apply >> Port 2# /cfg/bwm/cur (Make your changes active) (View current BWM settings)
.
791
Examine the resulting information. If any settings are incorrect, make any appropriate changes. 13 On the switch, save your new conguration changes.
14
On the switch, check the BWM information.

>> Bandwidth Management# /info/bwm <contract number> (View BWM information)
ConguringGrouped Contracts for Bandwidth Sharing

In the following example, BWM is congured to allow sharing of BWM resources by conguring a group contract. While the group hard limit will be essentially the aggregate of the hard limits dened for each contract in the group, any unused bandwidth may be shared amongst all member contracts. For example, a group level contract is dened with four individual contracts that have committed information rates (CIR) of 10, 20, 30, and 40 Mbps each. Together, the total CIR of the member contracts is 100 Mbps. Based on how much trafc is actually being sent by all the contracts in the group, the hard limits of each contract are readjusted every few seconds, in proportion to each contracts share in the group. In effect, the contract with only 10 Mbps may be allowed at times to share any unused resources in the group and burst up to a higher hard limit. If that contract is removed from the group, then the contract will revert to its individual hard limits, and any trafc above its congured hard limit would be dropped as usual. For a more detailed explanation on how hard limits for contracts behave in a contract group, refer back to "Bandwidth Reallocation in Grouped Contracts" (page 774). Note: While trafc shaping contracts may be added to a group level contract, their soft and reserved limits are not readjusted. Step 1 Action Ensure BWM is enabled on the switch.
.
>> /cfg/bwm/on
Congure the switch as you normally would for SLB. Conguration includes the following tasks: Assign an IP address to each of the real servers in the server pool. Dene an IP interface on the switch. Dene each real server. Dene a real server group. Dene a virtual server. Dene the port conguration.
Select the rst bandwidth policy and set the hard, soft, and reserved rate limits for the bandwidth policy, in Mbps.
>> # /cfg/bwm/pol 1 >> Policy 1# hard 10M >> Policy 1# soft 5M >> Policy 1# resv 1M (Select BWM policy 1) (Set "never exceed" rate) (Set desired bandwidth rate) (Set committed information rate)
Congure BWM contract 1. Each contract must have a unique number from 1 to 1024.
>> Policy 1# /cfg/bwm/cont 1 (Select BWM contract 1)
Assign the bandwidth policy 1 to contract 1.

>> BWM Contract 1# pol 1 (Assign policy 1 to BWM Contract 1)
Enable contract 1.
Select bandwidth policy 2.

>> BWM Contract 1# /cfg/bwm/pol 2 (Select bandwidth policy 2)
.
793
On the switch, select BWM contract 2.

>> Policy 2# /cfg/bwm/cont 2 (Select BWM contract 2)
10
Assign bandwidth policy 2 to contract 2. Each BWM contract must be assigned a bandwidth policy.
11
Enable contract 2.
12
Using the same CLI commands as described above, congure policy 3 with hard, soft, and reserved limits of 30, 25, and 20 Mbps respectively. Then create contract 3 and apply policy 3 to this contract. Congure policy 4 with hard, soft, and reserved limits of 40, 35, and 30 Mbps respectively. Then create contract 4 and apply policy 4 to this contract. Assign the BWM contracts to different switch ports. Physical switch ports are used to classify which frames are managed by each contractthat is, one BWM contract will be applied to all frames from a specic port. The second contract will be applied to all frames from another specied port.
>> BWM Contract 4# /cfg/port 1/cont 1 >> Port 1# /cfg/port 2/cont 2 >> Port 2# /cfg/port 3/cont 3 >> Port 3# /cfg/port 4/cont 4 (Assign contract 1 to port 1) (Assign contract 2 to port 2) (Assign contract 3 to port 3) (Assign contract 4 to port 4)
13
14
15
Congure BWM contract group 1 and add all four contracts to this group.

.
>> /cfg/bwm/group 1 >> BW Group 1# add 1 Contract 1 added to group 1. >> BW Group 1# add 2 Contract 2 added to group 1. >> BW Group 1# add 3 Contract 3 added to group 1. >> BW Group 1# add 4 Contract 4 added to group 1.
(Select contract group 1) (Add contract 1 to group 1) (Add contract 2 to group 1) (Add contract 3 to group 1) (Add contract 4 to group 1)
16

>> Port 2# apply >> Port 2# /cfg/bwm/cur (Make your changes active) (View current BWM settings)
Examine the resulting information. If any settings are incorrect, make any appropriate changes. 17 Save your new conguration changes.
18
Check the BWM information.

Conguring a IP User-Level Rate Limiting Contract

The following example is for university that wants to restrict the amount of TCP trafc for individual students and for the student body as a whole. Contract 1 is congured as follows: Each student (IP address) is limited to 64 kbps.
.
795
All members of the student body is limited to maximum (hard limit) of 10 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), a session is created on the switch that records the students IP address, the egress port number, and the contract number, as well as the number of octets transferred for that second. The session updates the number of octets being transferred every second, thus maintaining trafc within the congured user limit of 64 kbps.
The administrator would setup a conguration as follows: Step 1 Action Select the rst bandwidth policy. Each policy must have a number from 1 to 512.
Congure 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 >> BW Contract 1# policy 1 (Select contract 1) (Apply policy 1 to this contract)
Congure a lter to match the source IP address range of the student body, and assign BWM Contract 1 to that lter.
/cfg/slb/filt 20/sip 150.150.0.0/smask 255.255.0.0/ac tion allow (Allow student traffic) >> Filter 20 # adv (Select the filter 20 advanced menu) (Apply BWM contract 1 to this filter)
>> Filter 20 Advanced# cont 1
Add the lter to an ingress port on the Nortel Application Switch.

/cfg/slb/port 1/filt ena/add 20 (Add filter 20 to port 1)
.
In the BWM conguration, enable IP limiting.

/cfg/bwm/cont 1/iplimit e
Determine whether the user should be identied by their source or destination IP address. If the contract is used for trafc going out to the Internet, dene it by the source IP address: iptype sip. If the contract is used to limit the amount of trafc downloaded from the user by a client on the Internet, dene it by the destination IP address: iptype dip.
>> BW Contract 1# iptype sip
Disable trafc shaping on this contract. Trafc shaping cannot be used in user-level rate limiting contracts.
>> /cfg/bwm/cont 1/shaping dis
8 9
Apply and save the conguration. View the current per-user BWM sessions for the active contract.
/stats/bwm/port 1/cont 1
End
Conguring BWMPreferential Services

BWM can be used to provide preferential treatment to certain trafc, based on source IP blocks, applications, URL paths, or cookies. You may nd it useful to congure higher policy rate limits for specic sites, for example, those used for e-commerce. In the following example, there are two Web sites, "A.com" and "B.com." BWM is congured to give preference to trafc sent to Web site "B.com:" Step 1 Action Congure the switch as you normally would for SLB. Conguration includes the following tasks: Assign an IP address to each of the real servers in the server pool. Dene an IP interface on the switch.
.
797
Dene each real server. Dene a real server group. Dene a virtual server. Dene the port conguration.
For more information about SLB conguration, refer to "Server Load Balancing" (page 188)." Note: Ensure BWM is enabled on the switch (/cfg/bwm/on). 2 Select bandwidth policy 1. Each policy must have a number from 1 to 512.
Set the hard, soft, and reserved rate limits for the bandwidth policy in Mbps.
Select a BWM contract and name the contract. Each contract must have a unique number from 1 to 1024.
>> Policy 1# /cfg/bwm/cont 1 >> BWM Contract 1# name a.com (Select BWM Contract 1) (Assign contract name "a.com")
Assign the bandwidth policy to this contract. Each BWM contract must be assigned a bandwidth policy.

Select bandwidth policy 2.

>> BWM Contract 1# /cfg/bwm/pol icy 2
(Select BWM policy 2)

.
Select the second BWM contract and name the contract.

>> Policy 2# /cfg/bwm/cont 2 >> BWM Contract 2# name b.com (Select BWM contract 2) (Assign contract name "b.com")
10
Assign the bandwidth policy to this contract. Each BWM contract must be assigned a bandwidth policy.
11

12
Create a virtual server that will be used to classify the frames for contract 1 and assign the Virtual server IP address for this server. Then, assign the BWM contract to the virtual server. Repeat this procedure for a second virtual server. Note: This classication applies to the services within the virtual server and not to the virtual server itself. The classication rule for these BWM contracts is based on a virtual service. One of the BWM contracts will be applied to any frames that are 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) >> Virtual Server 1# vip 100.2.16.2 >> Virtual Server 1# ena >> Virtual Server 1# /cfg/slb/virt 2/cont 2 (Set virtual server VIP address) (Enable this virtual server) (Assign contract to virtual server)
.
799
>> Virtual Server 2# vip 100.2.16.3 >> Virtual Server 2# ena
(Set virtual server IP address) (Enable this virtual server)
13

>> Virtual Server 2# apply >> Virtual Server 2# /cfg/bwm/ cur (Make your changes active) (View current BWM settings)
15
Check the bandwidth management information.

Conguring Content Intelligent Bandwidth Management

Content intelligent BWM allows the network administrator or Web site manager 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 conguration guidelines on content switching described in "Content Intelligent Server Load Balancing" (page 210) and "Application Redirection" (page 409)." You would also need to assign a contract to each dened string, where the string is contained in a URL, an HTTP header, or a cookie. BWM based on Layer 7 content gives Web site managers the following capabilities: Ability to allocate bandwidth based on the type of request
.
The switch allocates bandwidth based on certain strings in the incoming URL request. For example, as shown in "URL-Based SLB with Bandwidth Management" (page 800), if a Web site has 10Mbps of bandwidth, the site manager can allocate 1 Mbps of bandwidth for static HTML content, 3Mbps of bandwidth for graphic content and 4Mbps of bandwidth for dynamic transactions, such as URLs with cgi-bin requests and .asp requests. Ability to prioritize transactions or applications By allocating bandwidth, the application switch can guarantee that certain applications and transactions get better response time. Ability to allocate a certain amount of bandwidth for requests that can be cached As shown in "URL-Based SLB with Bandwidth Management" (page 800), users will be able to allocate a certain percentage of bandwidth for Web cache requests by using the URL parsing and bandwidth management feature.
URL-Based SLB with Bandwidth Management
The following example assumes you have congured URL-based SLB and the layer 7 strings as described in "Content Intelligent Server Load Balancing" (page 210). For URL-based server load balancing, a user has
.
801
to rst dene strings to monitor. Each of these strings is attached to real servers, and any URL with the string is load balanced across the assigned servers. The best way to achieve URL-based bandwidth management is to assign a contract to each dened string. This allocates a percentage of bandwidth to the string or URL containing the string. Step 1 2 Action Congure "Content Intelligent Server Load Balancing" (page 210). Congure BWM policies with the desired bandwidth limits. In this example, four policies are congured, 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/res 250k >> Policy 3# /cfg/bwm/pol 4/hard 2M/soft 1M/res 500k
Congure BWM contracts and apply the appropriate policies to the contracts. In this example, the policy numbers correspond to the contract numbers.
>> Main# /cfg/bwm/cont 1/policy 1 (Apply policy 1 to contract 1)
>> 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
Identify the dened string IDs that were congured.

For easy conguration and identication, each dened string is assigned an ID number, as shown in the following example. The third column shows the BWM contracts to assign to the strings in this example
ID 1 2 3 4 5 SLB String any .gif .jpg .cgi .bin BWM Contract 4 1 1 2 2
.
ID 6 7
SLB String .exe .html
BWM Contract 2 3
Assign BWM contracts to each string using the syntax shown:

>> Main# /cfg/slb/layer7/slb/cont <String ID> < BWM Contract number>
Verify that the strings and contracts are assigned properly.:

>> Server Load Balance Resource# cur Number of entries: 2 1: any, cont 4 2: .gif, cont 1 3: .jpg, cont 1 4: .cgi, cont 2 5: .bin, cont 2 6: .exe, cont 2 7: .html, cont 3
Congure a real server to handle the URL request. To add a dened string:
>> # /cfg/slb/real 2/layer7/addlb <SLB string ID>
where SLB string ID is the identication number of the dened string as 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 or congure a proxy IP address on the client port. To turn on DAM:
To turn off DAM and congure a proxy IP address on the client port:
>> # /cfg/slb/adv/direct dis >> # /cfg/slb/port 2/proxy ena (Enable use of proxy IP on this port)
.
803
>> # /cfg/slb/pip/type port >> # /cfg/slb/pip/add 12.12.12.12 (Add this proxy IP address to port 2)
For more information on proxy IP addresses, see "Proxy IP Addresses" (page 228). Note: Port mapping for content intelligent server load balancing can be performed by enabling DAM on the switch, or disabling DAM and conguring a proxy IP address on the client port. 9 Turn on HTTP SLB processing on the virtual server. Congure everything under the virtual server as in Conguration Example 1.
>> # /cfg/slb/virt 1/service 80/httpslb urlslb
If the same string is used by more than one service, and you want to allocate a certain percentage of bandwidth to this URL string for this service on the virtual server, then dene a rule using the urlcont command.
>> # /cfg/slb/virt 1/service 80/urlcont <SLB string ID> <BW Contract number>
This contract is tied to service 1. The urlcont command will override the contract assigned to the URL string ID. 10 Enable Server Load Balancing.
>> # /cfg/slb/on
11
Conguring Cookie-Based Bandwidth Management

Cookie-based BWM enables Web site managers to prevent network abuse by bandwidth-hogging users. Using this feature, bandwidth can be allocated by type of user or other user-specic information available in the cookie. Cookie-based bandwidth management empowers service providers to create tiered services. For example, Web site managers can classify users as rst class, business class, and coach and allocate a larger share of the bandwidth for preferred classes.
.
804 Part 4: Advanced Switching Cookie-Based Bandwidth Management
Note: Cookie-based BWM does not apply to cookie-based persistency or cookie passive/active mode applications. In this example, you will assign bandwidth based on cookies. First, congure cookie-based server load balancing, which is very similar to URL-based load balancing. Any cookie containing the specied string is redirected to the assigned server. Scenario 1: In this scenario, the Web site has a single virtual server IP address and supports multiple classes of users. Turn on cookie parsing for the service on the virtual server.
>> # /cfg/slb/virt 1/service 80 >> Virtual Server 1 http Service# httpslb cookie ena Enter the starting point of the cookie value [1-64]: Enter the number of bytes to be extract [1-64]: 8 Look for cookie in URI [e|d]: d
Step 1
Action Dene one or more load-balancing strings.

>> # /cfg/slb/layer7/slb/addstr <l7lkup|pattern> <SLB string>
Example:
>> # /cfg/slb/layer7/slb/addstr l7lkup "Business" >> # add l7lkup "First" >> # add l7lkup "Coach"
.
805
Allocate bandwidth for each string. To do this, assign a BWM contract to each dened string.
>> # /cfg/slb/layer7/slb/cont <SLB string ID> <BWM Contract number>
Congure a real server to handle the cookie. To add a dened string:

>> # /cfg/slb/real 2/layer7/addlb <SLB string ID>
where SLB string ID is the identication number of the dened string. Example:
>> # /cfg/slb/real 2/layer7/addlb 3
Either enable DAM on the switch or congure a proxy IP address on the client port. To turn on DAM:
To turn off DAM and congure a Proxy IP address on the client port:
>> # /cfg/slb/adv/direct dis >> # /cfg/slb/pip >> Proxy IP address# type port >> Proxy IP Address# add 12.12.12.12 >> # /cfg/slb/port 2 >> SLB Port 2# proxy ena (Use port-based proxy IP)
For more information on proxy IP addresses, see "Proxy IP Addresses" (page 228). Note: By enabling DAM on the switch or, alternatively, disabling DAM and conguring a proxy on the client port, port mapping for URL-based load balancing can be performed. 5 Enable SLB.
>> # /cfg/slb/on
.
Scenario 2: In this scenario, the Web site has multiple virtual server IP addresses, and the same user classication or multiple sites use the same string name. In this scenario, there are two Virtual IP (VIP) addresses: 172.17.1.1 and 172.17.1.2. Both the virtual servers and sites have rst class and business class customers, with different bandwidth allocations, as shown in "Cookie-Based Preferential Services" (page 806).
Cookie-Based Preferential Services
The conguration to support this scenario is similar to scenario 1. Note the following: End
Step 1 2
Action Congure the string and assign contracts for the strings and services. If the same string is used by more than one service, and you want to allocate a certain percentage of bandwidth to a user class for this service on the virtual server, then dene a rule using the urlcont command:
>> # /cfg/slb/virt 1/service 80/ urlcont <URL path ID> <BW Contract number>
.
807
Note: When assigning /cfg/slb/virt 1/service 80/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
ConguringSecurity Management
BWM can be used to prevent Denial of Service (DoS) attacks that generate a ooding of "necessary evil" packets. BWM can be used to limit the rate of TCP SYN, ping, and other disruptive packets. BWM can also be used to alert the network manager when soft limits are exceeded. In the following example, a lter is congured to match ping packets, and BWM is congured to prevent DoS attacks by limiting the bandwidth policy rate of those packets: Step 1 Action Congure the switch as usual for SLB (see "Server Load Balancing" (page 188)): Assign an IP address to each of the real servers in the server pool. Dene an IP interface on the switch. Dene each real server. Dene a real server group. Dene a virtual server. Dene the port conguration. Note: Ensure BWM is enabled on the switch (/cfg/bwm/on). 2 Select a bandwidth policy. Each policy must have a number from 1 to 512.
Set the hard, soft, and reserved rate limits for this policy in Kilobytes.
.
>> Policy 1# hard 250k >> Policy 1# soft 250k >> Policy 1# resv 250k
(Set "never exceed" rate) (Set desired bandwidth rate) (Set committed information rate)
Set the buffer limit for the policy. Set a parameter between 8192 and 128000 bytes. The buffer depth for a BWM contract should be set to a multiple of the packet size.
>> Policy 1# buffer 8192 (Set policy buffer limit of 8192 bytes)
On the switch, select a BWM contract and name the contract. Each contract must have a unique number from 1 to 1024.
>> Bandwidth Management# /cfg/bwm/cont 1 >> BWM Contract 1# name icmp (Select BWM contract 1) (Select contract name "icmp")
Set the bandwidth policy for the contract. Each BWM contract must be assigned a bandwidth policy.
Enable the BWM contract.

>> BWM Contract 1# ena (Enable this BWM contract)
Create a lter that will be used to classify the frames for this contract and assign the BWM contract to the lter. The classication rule for this BWM contract is based on a lter congured to match ICMP trafc. The contract will be applied to any frames that match this lter
>> BW Contract 1# /cfg/slb/filt 1/proto icmp >> Filter 1# adv/icmp any >> Filter 1 Advanced# cont 1 (Define protocol affected by filter) (Set the ICMP message type) (Assign BWM contract 1 to this filter)
.
809
>> Filter 1 Advanced# /cfg/slb/filt 1/ena >> Filter 1# apply
(Enable this filter) (Port and enable filtering)
On the switch, apply and verify the conguration.

>> Filter 1 Advanced# apply >> Filter 1 Advanced# /cfg/bwm/cur (Make your changes active) (View current BWM settings)
Examine the resulting information. If any settings are incorrect, make the appropriate changes. 10 On the switch, save your new conguration changes.
11
On the switch, check the BWM information.

Conguring Time and Day Policies

Bandwidth Management contracts can be congured to have different limits depending on the time of day and day of the week. For example, in ofce networks that are typically busy during a workday, higher bandwidth limits can be applied during peak work hours. Lower bandwidth limits can be applied during hours with minimal trafc, such as on evenings or weekends. Up to two time policies can be applied to each contract. The default settings for each time policy is "Day everyday, From Hour 12am, To Hour 12am, Policy 512, time policy disabled" If both time policy 1 and time policy 2 are enabled on a contract, and both policies match the current time set in the switchs system clock, time policy 1 will take effect.
.
CAUTION
When conguring time policies, the "to" hour cannot be earlier than the "from" hour, as in a time policy set from 7pm to 7 am. Nortel Application Switch Operating System does not calculate time policies that cross the 24-hour day boundary.
Step 1
Action Congure three BWM policies for high, low and default bandwidth. These policies will be applied to different time policies later in this procedure.
>> /cfg/bwm/policy 1/hard 10M/soft 5M >> /cfg/bwm/policy 2/hard 5M/soft 1M >> /cfg/bwm/policy 3/hard 4M/soft 2M (For peak working hours) (For weekday evening hours) (For all other times)
Create a BWM contract that will contain the time policies.

>> /cfg/bwm/cont 1
Create the rst time policy under contract 1, for peak working hours.
>> # /cfg/bwm/cont 1/timepol 1 >> BW Contract 1 Time Policy 1# day weekday Current Time Policy Day: everyday Pending new Time Policy Day: weekday >> BW Contract 1 Time Policy 1# from 7am Current Time Policy from hour: 12am Pending new Time Policy from hour: 7am >> BW Contract 1 Time Policy 1# to 7pm Current Time Policy to hour: 12am Pending new Time Policy to hour: 7pm >> BW Contract 1 Time Policy 1# policy 1 (Assign highest BW policy to this time policy)
>> BW Contract 1 Time Policy 1# ena Current status: disabled New status: enabled
.
811
Create the second time policy under contract 1, for weekday evening hours.
>> # /cfg/bwm/cont 1/timepol 2/day weekday/from 7pm/to 11pm/policy 2/ena
Apply the default BWM policy 3 to this contract. This BW policy will be in effect at all other times beyond the specications of the two time policies.
>> # /cfg/bwm/cont 1/policy 3/ena
Assign the contract to an ingress port on the Application Switch.

>> Main# /cfg/port 1 >> Port 1# cont 1 Current BW Contract: 256 New pending BW Contract: 1
Egress Bandwidth Tuning for Lower Speed Networks

In situations where an Nortel Application Switch is connected to a router that feeds into lower speed networks, the egress trafc from the Nortel Application Switch should be throttled down to prevent the packets from being dropped from the router as it forwards trafc into the slower network. For example, an Nortel Application Switch may be connected to a router with high bandwidth of 1Gbps. However that router may be connected into a Wide Area Network (WAN) using a T1 line (1.544 Mbps) or a T3 line (44.736 Mbps). 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 following commands.
>> # /cfg/port 1 >> Port 1# egbw 44M (Select the desired port) (Change egress BW to 44Mbps)
Current port egress bandwidth: 0K New pending port egress bandwidth: 44M
.
Overwriting the TCP Window Size

The TCP window size set in the packet indicates how many bytes of data the receiver of that TCP packet can send without waiting for acknowledgement. In network environments where congestion is a common problem and trafc usually exceeds the congured BWM soft limit in a BWM contract, the TCP window size may be overwritten to better accommodate the prevailing trafc rates. It would be benecial if the TCP trafc was slowed down by modifying the TCP window size rather than by dropping TCP packets, which would cause retransmissions. By default, the TCP window size is overwritten only when trafc exceeds the soft limit of the BWM contract, and when the window size is above 1500 bytes. To overwrite TCP window size on a contract, enter the following command:
>> # /cfg/bwm/cont 1/wtcpwin e (Enable overwriting of TCP window)
Conguring Intelligent Trafc Management

Intelligent Trafc Management (ITM) can be used to congure, monitor and limit IP and non-IP trafc based on well-known application signatures. Content intelligent trafc management includes classifying different types of trafc by denying, rate limiting, or shaping according to your policies. To setup Nortel Intelligent Trafc Management (ITM), it is recommended that you use the Trafc Management Wizard in the Nortel ASEM client software. For more information on Intelligent Trafc management and how to classify trafc see the Nortel Intelligent Trafc Management Users Guide. The ITM wizard enables you to congure complex lters for BWM contracts and policies using a simple click of a mouse. This wizard also includes Nortel signature les to classify different types of trafc, for example, you can allow HTTP trafc, Deny peer-to-peer uploads, Rate limit peer-to-peer downloads, User limit trafc, Allow Instant Messaging chat, Deny Instant Messaging le transfers, Guarantee Voice over Internet Protocol (VoIP) trafc, etc. Nortel ITM has the ability to combat high-prole network worms and viruses without stopping valid application trafc. Shape and prioritize critical business application trafc, so that it is not impacted when a new worm attacks the network. Initially you can setup the Nortel ASEM wizard to monitor all available trafc on a switch for a few days. Monitor the unclassied trafc to identify the popular applications on the network. Use the Nortel Trafc Management Reporting tool to graph application trafc. Analyze the data in your report and determine the trafc you want denied or rate limited on your network. Run the Trafc Management wizard again to classify the trafc.
.
813
Reverse session update avoids the need to inspect trafc in both directions. This feature can also supply a "reverse contract" association so that returning trafc can be classied, through Bandwidth Management, into a different contract than was congured on the ingress lter. For more information on how to run the wizard and classify trafc see Chapter 2, "Getting Started" in the Nortel Intelligent Trafc Management Users Guide. Run the Reporting tool frequently to verify if the policies are being enforced.
.
XML Switch Conguration API

The Nortel Application Switch Operating System supports an Extensible Markup Language (XML) conguration application programming interface (API). This support has been introduced to provide a common interface for applications that wish to interoperate with a Nortel Application Switch. Also, XML was chosen for its wide adoption and usage. XML is also supported by the Nortel Threat Protection System.
Software Components
This feature uses two distinct software components that will work together to interpret XML les sent to the switch. These two software components are: Step 1 Action Schema Document The Schema, document is the roadmap that allows the switch software to interpret the XML documents that are sent to it. This Schema document denes the markup tags that appear in the XML document and what each means. "Schema Document" (page 814) illustrates the Schema document used by the XML Conguration 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 root element</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="Cli" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="Command" type="xs:string" use="required"/> </xs:complexType> </xs:element> </xs:sequence>
.
815
<xs:attribute name="Version" type="xs:int" use="required"/> </xs:complexType> </xs:element> </xs:schema>
XML Parser An XML parser is embedded in the software. This parser is used to interpret an XML le received by the switch into usable CLI commands. End
XML Conguration File

The XML conguration le will conform to the rules laid out by the DTD document. The conguration le can either be produced by an application equipped to do so or manually in a text editor. For information about the form and format of the Extensible Markup Language, refer to the World Wide Web Consortium XML web site at http://www.w3.org/XML/. "XML Conguration File" (page 815) illustrates an example of an XML le that could be used to congure a Nortel Application Switch.
XML Conguration 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 Transmission

SSL is used as the transport medium for sending XML conguration les to the switch. An SSL client will be needed to connect to the switch using certicate authentication. This SSL client could be a standalone application or embedded as part of another application. After authentication takes place, the le can be sent securely. Certicates used for authentication purposes must be in DER format. Self-signed certicates are supported for this purpose.
.
Feature Conguration
To make use of this feature, several steps must be taken: Note: All Command Line Interface commands ending with enable to enable a feature can be used to disable a feature as well. Simply repeat the command and substitute enable with disable. Step 1 Action Globally enable XML conguration. The XML Switch Conguration API is disabled by default. To enable this feature, enter the following command:
>> Main# /cfg/sys/access/xml/xml enable
(Optional) Set the XML transport port number. Since SSL is the transport mechanism for the XML conguration le, the port used by the switch to receive these les is the SSL port by default. 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 must use the same port if both are enabled. 3 Import client certicate. Certicate authentication is required to send an XML conguration le to the switch. To import a client certicate, complete the process outlined below:
>> Main# /cfg/sys/access/xml/gtcert <TFTP/FTP IP Address> <Certificate File Name> <FTP User Name> <FTP Password>
After entering the required information, the client certicate will be downloaded to the switch. End
.
817
Additional Feature Commands

Although not necessary for the conguration of this feature, the following commands are used to maintain and monitor the XML Switch Conguration API: Step 1 Action Delete client certicate. To delete the client certicate, issue this command:
>> Main# /cfg/sys/access/xml/delcert
Display client certicate. To display the current client certicate, issue this command:
>> Main# /cfg/sys/access/xml/dispcert
Debug XML operations. Enabling XML debug operations causes all commands in the XML le to be echoed to the Console and prefaces each one with running XML cmd: or Invalid XML cmd:. All responses to the commands will also be output to the Console. To debug XML switch operations, issue this command:
>> Main# /cfg/sys/access/xml/debug enabled
Display the current XML API conguration. To display the current XML API conguration, issue this command:
>> Main# /cfg/sys/access/xml/cur
End
.
.
819
Appendix Troubleshooting
This section discusses some tools to help you troubleshoot common problems on the Nortel Application Switch: "Port Mirroring" (page 819) "Filtering the Session Dump" (page 822)
Port Mirroring
Mirroring Individual Ports
The port mirroring feature in the Nortel Application Switch Operating System allows you to attach a sniffer to a monitoring port that is congured to receive a copy of all packets that are forwarded from the mirrored port. Nortel Application Switch Operating System enables you to mirror port trafc for all layers (Layer 2 - 7). Port mirroring can be used as a troubleshooting tool or to enhance the security of your network. For example, an IDS server can be connected to the monitor port to detect intruders attacking the network. As shown in "Monitoring Ports" (page 819), port 19 is monitoring ingress trafc (trafc entering the switch) on port 3 and egress trafc (trafc leaving the switch) on port 11. You can attach a device to port 19 to monitor the trafc on ports 3 and 11.
Monitoring Ports
.
820 Appendix Troubleshooting
"Monitoring Ports" (page 819) shows two mirrored ports monitored by a single 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 "Mirroring VLANs 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 port being monitored by multiple ports. Ingress trafc is duplicated and sent to the mirrored ports before processing and egress trafc is duplicated and sent to the mirrored ports after processing. To congure port mirroring for the example shown in "Monitoring Ports" (page 819): Step 1 Action Specify the monitoring port.
>> # /cfg/pmirr/monport 19 (Select port 19 for monitoring)
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)
Enable port mirroring.

>> # /cfg/pmirr/mirr ena (Enable port mirroring)
.
Port Mirroring
821
>> PortMirroring# apply >> PortMirroring# save
(Apply the configuration) (Save the configuration)
View the current conguration.

>> 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 Port

VLAN-ba sed port mirroring allows the user to monitor trafc based on VLANs associated with a port. If a mirrored port is congured as a member of more than one VLAN, you may wish to monitor only trafc entering that port on a specic VLAN. You can add specic VLAN(s) to be mirrored, even if there are multiple VLANs associated with that port. If you do not specify a VLAN, all trafc on the port will be mirrored. Enabling VLAN-based port mirroring feature is simply a matter of selecting a VLAN as one of the command parameters when choosing the mirrored port. You can use the same commands described in "Mirroring Individual Ports" (page 819), and specify which VLANs trafc that you wish to mirror, using the following syntax:
add <mirrored port (port to mirror from)> <direction> <vlan index or Carriage Return for all vlans>
To enable mirroring of ingress trafc for VLAN 3 on port 3, and egress trafc for VLAN 4 on port 11 of step 1 and step 2 step 2, change the commands to the following:.
>> # /cfg/pmirr/monport 19 >> Port 19 # add 3 in 3 >> Port 19 # add 11 out 4 (Select port 19 for monitoring) (Mirror only vlan 3 ingress traffic on port 3) (Mirror only vlan 4 egress traffic on)
To view the current conguration:

>> 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 Dump

Typically, session dumps are long and unwieldy. Nortel Application Switch Operating System however, provides a tool to lter session dumps based on any of the following attributes: Client IP address Source port Destination IP address Destination port Proxy IP address Proxy port Matching lter Matching ag Ingress port Real IP address SP
Only one attribute can be used at a time to lter the session dump. For example, to lter a session dump based on client IP address 10.10.10.1, use the following command:
>> # /info/slb/sess/cip 10.10.10.1 Printing Sessions for SP 1 1,01: 10.10.10.1 137, 205.178.13.100 ALLOW age 2 f:100 E 1,01: 10.10.10.1 2592, 172.21.31.100 10.20.1.2 http age 0 1,01: 10.10.10.1 2593, 172.21.31.100 10.20.1.3 http age 0 1,01: 10.10.10.1 2594, 172.21.31.100 10.20.1.2 http age 0 1,01: 10.10.10.1 2595, 172.21.31.100 10.20.1.3 http age 0 1,01: 10.10.10.1 2596, 172.21.31.100 10.20.1.4 http age 0 1,01: 10.10.10.1 2597, 172.21.31.100 10.20.1.3 http age 0 1,01: 10.10.10.1 2598, 172.21.31.100 10.20.1.4 http age 0 1,01: 10.10.10.1 2599, 172.21.31.100 10.20.1.3 http age 0 1,01: 10.10.10.1 2600, 172.21.31.100 10.20.1.4 http age 0
137 http -> 14291 http -> 14292 http -> 14307 http -> 14308 http -> 14309 http -> 14310 http -> 14311 http -> 14339 http -> 14340
.
Filtering the Session Dump
823
1,01: 10.10.10.1 2601, 10.20.1.3 http age 0 1,01: 10.10.10.1 2602, 10.20.1.2 http age 10 1,01: 10.10.10.1 2603, 10.20.1.3 http age 10 1,01: 10.10.10.1 2604, 10.20.1.2 http age 10
172.21.31.100 http -> 14367 172.21.31.100 http -> 14384 172.21.31.100 http -> 14385 172.21.31.100 http -> 14414
>> Session Table Information#
Because VMA is enabled, the command displayed all sessions for client IP address 10.10.10.1 on SP 1. The sessions hash on source IP address and destination IP address.
.
.
825
Appendix Layer 7 String Handling

This appendix describes how to create and manage the Layer 7 content used for conguring content-intelligent load balancing and redirection features described elsewhere in this manual. The following topics are addressed in this chapter: "Exclusionary String Matching for Real Servers" (page 825) "Regular Expression Matching" (page 827) "Content Precedence Lookup" (page 829) "String Case Insensitivity" (page 832) "Congurable HTTP Methods" (page 833) Note: For all content-intelligent switching features enable Direct Access Mode (DAM) or congure proxy IP addresses. For more information, see "Direct Access Mode" (page 239).
Exclusionary String Matching for Real Servers

URL-based SLB and application redirection can match or exclude up to 128 strings. Examples of strings are as follows: "/product," matches URLs that starts with /product. "product," matches URLs that have the string "product" anywhere in the URL.
You can assign one or more strings to each real server. When more than one URL string is assigned to a real server, requests matching any string are 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 exclusionary string matching. Using this option, you can dene a server to accept any requests regardless of the URL, except requests with a specic string.
.
826 Appendix Layer 7 String Handling
Note: Once exclusionary string matching is enabled, clients cannot access the URL strings that are added to that real server. This means you cannot congure a dedicated server to receive a certain string and, at the same time, have it exclude other URL strings. The exclusionary feature is enabled per server, not per string. For example, the following strings are assigned to a real server: string 1 = cgi string 2 = NOT cgi/form_A string 3 = NOT cgi/form_B As a result, all cgi scripts are matched except form_A and form_B.
Conguring Exclusionary URL String Matching

This conguration example shows you how to congure a server to handle any requests except requests that contain the string "test" or requests that start with "/images" or "/product". To congure exclusionary URL string matching, perform the following procedure: Step 1 Action Before you can congure URL string matching, ensure that the switch has already been congured for basic SLB: Assign an IP address to each of the real servers in the server pool. Dene an IP interface on the switch. Dene each real server. Assign servers to real server groups. Dene virtual servers and services. Enable SLB.
For information on how to congure your network for server load balancing, 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 1 2 3 4 SLB String any test /images /product
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
Enable the exclusionary string matching option.

>> Real Server 1 Layer 7 commands# exclude enable
If you congured a string "any" and enabled the exclusion option, the server will not handle any requests. This has the same effect as disabling the server. End
Regular Expression Matching

Regular expressions are used to describe patterns for string matching. They enable you to match the exact string, such as URLs, host names, or IP addresses. It is a powerful and effective way to express complex rules for Layer 7 string matching. Both Layer 7 HTTP SLB and cache redirection can use regular expressions as a resource. conguring regular expressions can enhance content-based switching in the following areas: HTTP header matching URL matching
Standard Regular Expression Characters

The following is a list of standard regular expression special characters that are supported in Nortel Application Switch Operating System:
.
828 Appendix Layer 7 String Handling Standard Regular Expression Special Characters Construction * . + ? $ \ [abc] [^abc] ^ Description Matches any string of zero or more characters Matches any single character Matches one or more occurrences of the pattern it follows Matches zero or one occurrences of its followed pattern Matches the end of a line Escape the following special character Matches any of the single character inside the bracket Matches any single character except those inside the bracket Matches the pattern exactly only if it appears at the beginning 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 the end 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 exceed 43 bytes for load balancing strings and 23 bytes for cache redirection. The size of regular expression after compilation varies, based on regular expression characters used in the user input string. Use "/" at the beginning of the regular expression. Otherwise a regular expression will have "*" prexed to it automatically. For example, "html/*\.htm" appears as "*html/*\.htm". Incorrectly or ambiguously formatted regular expressions are rejected instantly. For example: where a "+" or "?" follows a special character like the "*" A single "+" or "?" sign Unbalanced brackets and parenthesis
Conguring Regular Expressions

The regular expression feature is applicable to both path strings used for URL-based server load balancing, and expression strings used for URL-based application redirection. Congure regular expressions at the following CLI prompt:
.
Content Precedence Lookup
829
>> # /cfg/slb/layer7/slb/addstr
As a result, both HTTP SLB and application redirection can use regular expression as the resource. Note: The more complex the structure of the string, the longer it will take for the server to load balance the incoming packets.

The Layer 7 Precedence Lookup feature in Nortel Application Switch Operating System allows you to give precedence to one Layer 7 parameter over another and selectively decide which parameter should be analyzed rst. The Content Precedence Lookup feature allows you to combine up to two Layer 7 load balancing mechanisms. You can specify which types of Layer 7 content to examine, the order in which they are examined, and a logical operator (and/or) for their evaluation.The following Layer 7 content types can be specied: URL SLB HTTP Host Cookie Browsers (User agent) URL hash Header hash
Using the above content types with the and and or operators, the application switch is congured to rene HTTP-based server load balancing multiple times on a single client HTTP request in order to bind it to an appropriate server. 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 load balancing can be congured 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 7 content types. For more information on cookie persistence, see "Persistence" (page 588)." For example, the Content Precedence Lookup feature can be used in the following scenarios: If the client request is sent without a cookie and if no HTTP SLB is congured, then the switch binds the request to the real server using normal SLB. If the client request is sent without a cookie, but HTTP SLB is congured on the switch, then the request is bound to real server based on HTTP SLB. If the client request is sent with a cookie, and a real server associated to the cookie is found in the local session table, then the request will stay bound to that real server.
Requirements
Enable Direct Access Mode (DAM), or congure proxy IP address if DAM is disabled. Enable delayed binding.
Using the or / and Operators

"Content Precedence Lookup Protectors Example" (page 830) shows a network with real servers 1 and 3 congured for URL SLB and real servers 2 and 3 congured for HTTP Host SLB.
Content Precedence Lookup Protectors Example
If the Content Precedence Lookup feature is congured with the or and and operators, the request from the client is as follows: HTTP Host or URL SLB
.
831
The HTTP Host header takes precedence because it is specied rst. 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 URL string (such as "/gold"), the request is load balanced among Server 1 or Server 3. If a request from a client contains a Host Header, then the request is load balanced among Server 2 and Server 3. The URL string is ignored because the HTTP Host was specied and matched rst. HTTP Host and URL SLB The HTTP Host header takes precedence because it is specied rst. Because and is the operator, both a Host Header and URL string are required. If either is not available, the request is dropped. If a request from a client contains a URL string (such as "/gold") but not a Host Header, it is not served by any real server. If a request from a client contains a URL string (such as "/gold") and Host Header, it is served only by real server 3.
Assigning Multiple Strings

"Content Precedence Lookup Multiple Strings Example" (page 832) shows an 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 wishes to assign them on a very conservative basis. As a result, the company implements virtual hosting by advertising a single virtual server IP address that includes both customers Web sites. Additionally, the hosting company assigns only one service (HTTP port 80) to support the virtual server. The virtual hosting company wishes to maintain the exibility to allow different types of content to be placed on different servers. To make most efcient use of their server resources, they separate their servers into two groups, using their fastest servers to process dynamic content (such as .cgi les) and their slower servers to process all static content (such as .jpg les).
.
832 Appendix Layer 7 String Handling Content Precedence Lookup Multiple Strings Example
To congure content precedence lookup for the example in "Content Precedence Lookup Multiple Strings Example" (page 832), the hosting company groups all the real servers into one real server group even though different servers provide services for different customers and different types of content. In this case, the servers are set up for the following purpose:
Real Server Content Server Server 1 Server 2 Server 3 Server 4 Server 5 Customer Customer A Customer A Customer A Customer B Customer B Content Static .jpg files Static .jpg files Dynamic .cgi files Static .jpg files 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 and Server 2. To accomplish this conguration, you must assign multiple strings (a Host Header string and a URL string) for each real server.
String Case Insensitivity

By default, Nortel Application Switch Operating System supports case sensitive matching when performing lookup of Layer 7 string content. If the following strings were congured for a real server:
1. 2. default.asp search.asp
.
Congurable HTTP Methods
833
Any incoming request containing "GET /Default.asp" would not bind to string 1 because of the capitalized D in Default.asp. String case sensitivity may be disabled, so that any incoming request containing "GET /Default.asp, GET /DEFAULT.ASP, and other case combinations, all map to string 1.
>> # /cfg/slb/layer7/slb/case disable (Disable case-sensitive matching)
Congurable HTTP Methods

Various types of HTTP methods to be processed by the Nortel Application Switchs Layer 7 engine are now congurable. To view the currently supported HTTP methods, enter the following:
>> # /cfg/slb/layer7/slb/cur HTTP method types: 1 GET 2 POST 5 BMOVE 6 BDELETE 9 CONNECT 10 DELETE 13 MOVE 14 OPTIONS 17 PROPFIND 18 PROPPATCH 21 TRACE 22 UNLINK
3 7 11 15 19
HEAD BPROPPATCH LINK POLL SEARCH
4 8 12 16 20
BCOPY COPY MKCOL PUT SUBSCRIBE
To add an HTTP method type, select the method by its index number from the 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 Nortel Application 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/https443/DNS-53)
NAT (Network Address Translation)

Any time an IP address is changed from one source IP or destination IP address to another address, network address translation can be said to have taken place. In general, half NAT is when the destination IP or source IP address is changed from one address to another. Full NAT is when both addresses are changed from one address to another. No NAT is when neither source nor destination IP addresses are translated. Virtual server-based load balancing uses half NAT by design, because it translates the destination IP address from the Virtual Server IP address, to that of one of the real servers.
Preemption
In VRRP, preemption will cause a Virtual Router that has a lower priority to go into backup should a peer Virtual Router start advertising with a higher priority.
Priority
In VRRP, the value given to a Virtual Router to determine its ranking with its peer(s). Minimum value is 1 and maximum value is 254. Default is 100. A higher number will win out for master designation.
Proto (Protocol)
The protocol of a frame. Can be any value represented by a 8-bit value in the IP header adherent to the IP specication (for example, TCP, UDP, OSPF, ICMP, and so on.)
.
836 Glossary
Real Server Group

A group of real servers that are associated with a Virtual Server IP address, or a lter.
Redirection or Filter-Based Load Balancing

A type of load balancing that operates differently from virtual server-based load balancing. With this type of load balancing, requests are transparently intercepted and "redirected" to a server group. "Transparently" means that requests are not specically destined for a Virtual Server IP address that the switch owns. Instead, a lter is congured in the switch. This lter intercepts trafc based on certain IP header criteria and load balances it. Filters can be congured to lter on the SIP/Range (via netmask), DIP/Range (via netmask), Protocol, SPort/Range or DPort/Range. The action on a lter can be Allow, Deny, Redirect to a Server Group, or NAT (translation of either the source 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 balance devices that normally operate transparently in your networksuch as a rewall, spam lter, or transparent cache.
RIP (Real Server)

Real Server IP Address. An IP addresses that the switch load balances to when 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/HTTPS443/DNS-53).
Tracking
In VRRP, a method to increase the priority of a virtual router and thus master designation (with preemption enabled). Tracking can be very valuable in an active/active conguration. 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 by 2 for each) Ports: Active ports on the same VLAN (increments priority by 2 for each) l4pts: Active Layer 4 Ports, client or server designation (increments priority 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 particular service requests (like HTTP) to other servers.
VIR (Virtual Interface Router)

A VRRP address that is an IP interface address shared between two or more virtual routers.
Virtual Router
A shared address between two devices utilizing VRRP, as dened in RFC 2338. One virtual router is associated with an IP interface. This is one of the IP interfaces that the switch is assigned. All IP interfaces on the Nortel Application Switches must be in a VLAN. If there is more than one VLAN dened on the application switch, then the VRRP broadcasts will only be sent out on the VLAN of which the associated IP interface is a member.
Virtual Server Load Balancing

Classic load balancing. Requests destined for a Virtual Server IP address (VIP), which is owned by the switch, are load balanced to a real server contained in the group associated with the VIP. Network address translation is done back and forth, by the switch, as requests come and go. Frames come to the switch destined for the VIP. The switch then replaces the VIP and with one of the real server IP addresses (RIPs), updates the relevant checksums, and forwards the frame to the server for which it is now destined. This process of replacing the destination IP (VIP) with one of the real server addresses is called half NAT. If the frames were not half NATed to the address of one of the RIPs, a server would receive the frame that was destined for its MAC address, forcing the packet up to Layer 3. The server would then drop the frame, since the packet would contain the destination IP of the VIP and not that of the server (RIP).
VRID (Virtual Router Identier)

In VRRP, a value between 1 and 255 that is used by each virtual router to create its MAC address and identify its peer for which it is sharing this VRRP address. The VRRP MAC address as dened in the RFC is 00-00-5E-00-01-{VRID}. If you have a VRRP address that two switches are sharing, then the VRID number needs to be identical on both switches so each virtual router on each switch knows whom to share with.
.
838 Glossary
VRRP (Virtual Router Redundancy Protocol)

A protocol that acts very similarly to Ciscos proprietary HSRP address sharing protocol. The reason for both of these protocols is so devices have a next hop or default gateway that is always available. Two or more devices sharing an IP interface are either advertising or listening for advertisements. These advertisements are sent via a broadcast message to an address such 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 is always listening for the broadcasts. Should the master stop advertising, the backup will take over ownership of the VRRP IP and MAC addresses as dened by the specication. The switch announces this change in ownership to the devices around it by way of a Gratuitous ARP, and advertisements. If the backup switch didnt do the Gratuitous ARP the Layer 2 devices attached to the switch would not know that the MAC address had moved 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 is Nortel Application Switch Operating System proprietary extension to the VRRP specication. The switches must be able to share Virtual Server IP addresses, as well as IP interfaces. If they didnt, the two switches would ght for ownership of the Virtual Server IP address, and the ARP tables in the devices around them would have two ARP entries with the same IP address but different MAC addresses.
.
839
Index
Symbols/Numerics
80 (port) 737, 745 802.1Q VLAN tagging 72, 72 authoritative name servers 729 autonomous systems (AS) 151
B
backup servers 208, 209, 209 bandwidth management burst limit 783 conguration, general 770, 788 conguration, preferential service 796 conguration, security 807 conguration, user fairness 788 content intelligent 799, 803 contracts 773 cookie-based 803 data pacing 780 egress bandwidth tuning 811 grouped contracts 773, 774, 791 operational keys 769 overwriting TCP window 811 rate limiting 787 statistics and history 781 time policy 776 conguration example 809, 811 trafc shaping 780, 780, 787 user limits 776 conguration example 794, 796 VMA 770 bandwidth managment policies 776 bandwidth metric 206 bandwidth policies rates blat 626 Border Gateway Protocol (BGP) 131
A
accessing the switch dening source IP addresses 48 RADIUS authentication 49 security 46 using ASEM 35 using the Browser-based Interface 36 using the CLI 26 active cookie mode 597 administrator account 53 aggregating routes 137 example 143 allow (ltering) 190, 329, 365 application health checking 479 application ports application redirection 367, 409 client IP address authentication 423 example with NAT 415 games and real-time applications 423 non cacheable sites 423 non-HTTP redirects for GSLB 764 proxies 411, 415, 421 rport 415, 422 See cache redirection 411 topologies 412 Web-cache redirection example 409, 423 Application Switch Element Manager (ASEM) 35 authenticating, in OSPF 158
.
840 Index
attributes 138 failover conguration 139 route aggregation 137 route maps 133 selecting route paths 139 use with GSLB 767 Bridge Protocol Data Unit (BPDU) 94 broadcast domains 71, 72, 74, 115 Browser-Based Interface 471, 737, 745
C
cache redirection browser-based 434 delayed binding 417 example 411 HTTP header-based 433 layer 7 trafc 423 RTSP 417, 417, 439 See application redirection 410 servers 410, 412, 412 URL hashing 436 URL-based 424 CGI-bin scripts 193, 207 Cisco EtherChannel 87 CIST 105 client trafc processing 193, 197 command conventions 19 Command Line Interface 26, 151 conguring BGP failover 139 cache redirection cookie-based persistence 598 default lter 368 delayed binding 245 DNS load balancing 263 dynamic NAT 388 lter-based security 379 FTP Server Load Balancing 256, 257, 261 IDS load balancing 295 IP load balancing 254 IP routing 113 LDAP load balancing 260 multi-response cookie search 604 multiple services 202 OSPF 164
port trunking 86 proxy IP addresses 232 RTSP cache redirection 418 server load balancing 194 static NAT 386 tunable hash for lter redirection 377 VLAN-based lters 373 WAP load balancing 281, 284, 288 conguring WAN links basic example 338 summary 336 with SLB 350 connection time-out 207 console port 26 content intelligent cache redirection 423 server load balancing 210 contracts, bandwidth management 773 cookie active 597 different types 594 expiration timer 600 header 593 names 593 passive mode 596 permanent 592 rewrite 597 temporary 592 values 593 cookie-based persistence 591
D
data pacing 780 datagram 708 default gateway 112, 112 conguration example 78, 79, 114, 739, 747, 754 VLAN-based 75 default password 53 default route OSPF 155 delayed binding 242, 244 cache redirection 417 denial of service protection 646 deny (ltering) 190, 329, 365 detecting SYN attacks 245
.
Index 841
dip (destination IP address for ltering) 369 rate limiting 631 Direct Access Mode (DAM) 345, 355 security example 378 direct real server access 238 session dumps 822 disabling real servers 200 ltering-based VLANs 373 Distributed Site State Protocol (DSSP) 729 rewalls 379 dmask fraggle 624 destination mask for ltering 369 fragmenting jumbo frames 110, 112 DNS load balancing 263 frame processing 80 Domain Name Server 348, 360 frame tagging. See VLANs tagging. 72 Domain Name System (DNS) FTP ltering 379, 383 applications 200 Global SLB (diagram) 730 proxy IP 764 load balancing, layer 7 265 Server Load Balancing 255 round robin 189, 329 conguring 256, 257, 261 dport (ltering option) 380, 415 DSSP. See Distributed Site State Protocol. 729 gateway. See default gateway. 112 duplex mode for jumbo frames 81 Gigabit adapters dynamic NAT 388, 388 jumbo frames 80 Global SLB conguration tutorial 736, 752, 757 egress trafc 708 Distributed Site State Protocol 729 encrypt 708 DNS resolution (diagram) 730 End user access control domain name conguration 744 conguring 64 health check interval 744 EtherChannel 83 hostname conguration 744 as used with port trunking 87 HTTP redirect 731 expiration timer, insert cookie 600 port states 742 external routing 131, 150 real server groups 741 real servers 740 remote site conguration 743 tests 768 failed server protection, SLB 188, 329 using proxy IP 764 fault tolerance group SLB, metrics 202 port trunking 85 grouped contracts, bandwidth 773, 774, Server Load Balancing 192, 329 791 lter redirection example 791, 794 tunable hash 378
ltering conguration example 379 default lter 368, 380 IP address ranges 369 layer 7 deny 401 NAT conguration example 385, 388 numbering 369 order of precedence 367, 367 proto (option) 380, 415
H
half-duplex for jumbo frames 81 hash metric 203 hashing redirection lters 378 hashing on any HTTP header 225 health checks 415, 488 conguration using scripts 474
.
842 Index
format 471 internal routing 131, 150 Global SLB interval 744 Internet Service Provider (ISP), SLB hostname for HTTP content 479, 480 example 191 HTTPS/SSL 492 Intrusion Detection System (IDS) 290 IMAP server 488 IP address RADIUS server 489, 490 conservation 385 real server parameters 479 lter ranges 369 real servers 201 local route cache ranges 117 script-based 470, 478 private 386 SNMP 483 proxies 192, 228, 411, 415, 421 verifying scripts 478 real server groups 196, 430, 741 wireless session protocol 492, 498 real servers 190, 194, 330, 340, 351, 740 WTLS 498 routing example 77, 113 Host routes SLB real servers 195 OSPF 160 virtual servers 190, 192, 196, 196, 330, hostname, for HTTP health checks 479, 744 346, 358, 741 HP-OpenView 27 IP interfaces HTTP conguration example 195, 739, 739, application health checks 479 747, 747, 754, 754 redirects (Global SLB option) 731 example conguration 77, 113, 116 HTTP header VLAN 1 (default) 72 hashing 225 VLANs 72 HTTP redirection IP packet format 638 IP-based 447, 450 IP proxies MIME header-based 452, 454 for application redirection 421 TCP service port-based 450, 452 for Global Server Load Balancing 764 URL-based 454 for Server Load Balancing 228 HTTP URL request 400 See also proxies, proxy IP address HTTPS/SSL health checks 492 (PIP). 228 IP routing 194 cross-subnet example 110 default gateway conguration 78, 79, 114 ICMP 366 IP interface conguration 77, 113, 116 IDS load balancing 295 IP subnets 111 IEEE 802.1Q VLAN tagging 72 network diagram 111 IEEE standards subnet conguration example 112 802.1s 104 switch-based topology 112 IF. See IP interfaces. 72 IP subnets 112 IGMP 366 routing 111, 112 IMAP server health checks 488, 488 VLANs 71, 73 imask 201 ISL Trunking 83 inbound trafc 332 ITM. See Intelligent Trafc Management 812 incoming route maps 134 ingress trafc 708 insert cookie mode expiration timer 600 jumbo frames Intelligent Trafc Management 812 fragmenting to normal size 110, 112
.
Index 843
frame size 80 Gigabit adapter 80 isolating with VLANs 80 routing 110, 112 supported duplex modes 81 VLANs 80
L
landattack 619 Layer 4 administrator account 52, 53 cache redirection 412 server load balancing 194, 336 Layer 7 cache redirection 423 deny lter 401 precedence lookup 829 regular expression matching 827 server load balancing 210 string matching 825 Layer 7 lookup with deny lter 401 LDAP load balancing 260 least connections (SLB Real Server metric) 205 leastconn metric 205 link load balancing basic example 338 benets 328 conguration summary 336 example with SLB 350 inbound trafc 332 outbound trafc 330 using virtual servers 330 WAN links 327 Link load balancing using lters 329 lmask (local route cache parameter) 117 lnet (local route cache parameter) 117 load balancing DNS 261, 265 FTP trafc 255 IDS trafc 290 layer 7 trafc 210 SIP trafc 310 TFTP trafc 256
types of 254, 327 WAN trafc 327, 327 WAP trafc 279 local route cache address range 117 local route cache parameters lmask 117 lnet 117 log ltering option 365 log (ltering option) 379 logical segment. See IP subnets. 71 LSAs 150
M
MAC address 710 Main Menu Command-Line Interface (CLI) 26 management port setting up 38 management port, using 37 Management Processor (MP) use in switch security 48 manual style conventions 19 mapping ports 422 mapping virtual ports to real ports 234 matchall 642 matching TCP ags 394 maxcons limit 207, 208 maximum connections 207, 208 metrics real server groups 202 MIME header, in HTTP redirection 452, 454 minimum misses (SLB real server metric) 203 minmiss metric 203 mirroring ports 819 monitoring ports 819 monitoring real servers 242 MSTPMultiple Spanning Tree Protocol (MSTP) 104 multi-homing 768 WAN links 327 multi-links between switches using port trunking 83 using VLANs 74 multimedia servers 268
.
844 Index
multiple services, conguring 202 multiple spanning tree groups 98 Multiple Spanning Tree Protocol 104
parallel links 74 password administrator account 53 default 53 name servers, Global SLB conguration L4 administrator account 52, 53 example 729 user account 52 Network Address Translation (NAT) 415 pattern group 639 conguration example 385, 388 pattern matching lter action 367 criteria 637 lter example 388 depth 638 proxy 388 groups 639 static example 386 matchall 642 network management 27 offset 637 network performance operation 638 statistics, with use of proxy addresses 228 TCP or UDP 636 NFS server 191 persistence non cacheable sites in application Client IP-based 590, 591 redirection 423 cookie-based 591 non-HTTP redirects for GSLB 764 multi-response cookie search 604 none (port processing mode) example 197 SSL session ID-based 605, 607 Nortel ASEM 27 persistent nullscan 621 bindings 193 ping ood 627, 634 ping of death 628, 643, 646 PIP. See proxies, proxy IP address. 421 offset 637 POP3 764 optional software 409 port 80 737, 745 OSPF port mapping 422 area types 147 port mirroring 819, 821 authentication 158 port processing mode conguration examples 165, 185 client 197 default route 155 none 197 external routes 164 server 193, 197 ltering criteria 366 port states 742 host routes 160 port trunking 84 link state database 150 conguration example 85 neighbors 149 description 87 overview 146 EtherChannel 83 redistributing routes 133, 137 fault tolerance 85 route maps 133, 135 ports route summarization 155 for services router ID 157 monitoring 819 virtual link 156 physical. See switch ports. 71 outbound trafc 330 SLB conguration example 197 outgoing route maps 134 overow servers 208, 209, 209
.
Index 845
precedence, in bandwidth classicamaximum connections 207 tions 772 SLB conguration example 195 private IP address 386 weights 206 private network 386 redirect (HTTP) 731 protocol types redirecting lters proxies 192, 228, 411, 421 tunable hash 378 conguration example 388 redirecting non-HTTP applications 764 NAT 388 redirection. See application redirection 409 proxy IP address (PIP) 192, 228, 240, 421, redistributing routes 133, 137, 143 421 remote (Global SLB real server proxy servers 410 property) 744 PVID (port VLAN ID) 72 response metric 205 Return-to-Sender (RTS) for link load balancing 332, 344, 355, 357 RIP (Routing Information Protocol) QuickTime Streaming Server 269 advertisements 126 distance vector protocol 126 hop count 126 RADIUS metric 126 authentication 49 TCP/IP route information 18, 126 health checks 489 version 1 126 port 1812 and 1645 199, 280, 281, 285 roundrobin port 1813 199, 286, 289 SLB Real Server metric 205 SSH/SCP 63 route aggregation 137, 143 RADIUS snooping 283, 283, 287 route cache, sample 76 RADIUS static session entries 280 route maps 133 RADIUS/WAP persistence 287 conguring 135 Rapid Spanning Tree Protocol 102 incoming and outgoing 134 Rapid Spanning Tree Protocol route paths in BGP 139 (RSTP)RSTP 102 Router ID rate limiting 777, 787 OSPF 157 lter 631 routers 78, 111, 114 hold down periods 629 border 151 protocol-based 628, 635 peer 151 TCP 629 port trunking 83 time window 628 switch-based routing topology 112 timeslots 779 using redirection to reduce Internet UDP and ICMP 629 congestion 409 Rate limiting 778 web-cache redirection example 410 real server groups routes, advertising 151 conguration example 430, 741 routing 131 real servers 192 internal and external 150 backup/overow servers 208 Routing Information Protocol. See RIP 126 conguration example 740 rport (ltering) 415, 422 connection timeouts 207 RSA keys 62 disable/enable 200 RSTP 102 health checks 479 RTSP
Q R
.
846 Index
overview 189 persistent bindings 193 port processing modes 193, 197 proxies 192, 228 proxy IP addresses 240 scalability, service 188, 329 real server group 196, 430 SCP real server IP address (RIP) 190, 330 client commands 60, 61 real servers 192 conguring administrator password 59 remote sites 728 enabling 59 topology considerations 192 services 60, 60 virtual IP address (VIP) 190, 192, 330 script-based health checks 470, 478 virtual servers 190, 196, 330 searching for cookie 604 WAN links 327, 327 SecurID 63 WAP 279 security weights 206 allowable SIP addresses 48 server pool 188 denial of service protection 615, 646 server port processing 193 lter-based 378 service failure 506 ltering 365, 378 service ports rewalls 379 session dumps 822 from viruses 365 Session Initiation Protocol (SIP) 310 IP access control lists 612, 614 shared services 188, 328 layer 7 deny lter 400 SIP (source IP address for ltering) 369 port mirroring 819 smask private networks 385 source mask for ltering 369 RADIUS authentication 49 SMTP 764 switch management 48 smurf 624 VLANs 71 SNMP 27 segmentation. See IP subnets. 71 assign health check 471 segments. See IP subnets. 71 HP-OpenView 27 server (port processing mode) example 197 Nortel ASEM 27 server failure 507 SNMP content health check 483 Server Load Balancing SNMP health check 483 across subnets 110 Spanning-Tree Protocol backup servers 208, 209, 209 multiple instances 98 complex network topologies 227, 228 VLANs 74 conguration example 191, 228 spoong, prevention of 48 distributed sites 728 sport (ltering option) 380, 415 DNS 261, 265 SSH failed server protection 188, 329 client commands 60, 61 fault tolerance 192, 329 RSA host and server keys 62 FTP 255 SSH/SCP health checks 479 client commands 60, 61 IDS 290, 310 conguring 58 maximum connections 207 encryption and authentication metrics 202 methods 61 overow servers 209, 209 with Radius authentication 63
cache redirection 417 server load balancing 268
.
Index 847
with SecurID 63 static NAT 386 static session entries 280 statistical load distribution 84, 84 streaming media 268 summarizing routes 155 switch management security 48 via IP interface 72 switch ports VLANs membership 71 synn scan 622 syslog messages 365
Using proxy IP GSLB 764
V
virtual clocks 780 virtual IP address (VIP) 190, 192, 330 virtual link, OSPF 156 Virtual Local Area Networks. See VLANs. 71 Virtual Matrix Architecture (VMA) 227 virtual port mapping to multiple real ports 234, 237 virtual servers 190, 330 conguration example 196 IP address 196, 346, 358, 741 virus attacks, preventing 400 VLAN-based 821 VLAN-based ltering 373 VLANs broadcast domains 71, 72, 74, 115 default PVID 72 example showing multiple VLANs 73 ltering 373 gateway, default 75 ID numbers 71 IP interface conguration 116 IP interfaces 72 jumbo frames 80 multiple links 74 multiple spanning trees 93 multiple VLANs 72, 73 parallel links example 74 port members 71 port mirroring 821 PVID 72 routing 115 security 71 Spanning-Tree Protocol 74, 93, 93 tagging 71, 74 topologies 72 VLAN 1 (default) 72, 72, 195, 413 VLAN-tagging adapter support for 73 VPN 708 VPN cluster 709 VPN Load Balancing overview 708
T
tagging. See VLANs tagging. 72 TCP 366, 383, 383 health checking using 201 port 80 241 TCP ags 394 TCP window size overwriting 811 TCP/UDP port numbers 234 TDT (Theoretical Departure Times) 780 Telnet 379 text conventions 19 Theoretical Departure Times (TDT) 780 timeouts for real server connections 207 Trafc shaping 778, 780 trafc shaping 787 bandwidth management 780 transparent proxies 228, 411, 415, 421 troubleshooting 822 tunable hashing 378 tunneling 708 typographic conventions 19
U
UDP 366, 383, 383 jumbo frame trafc fragmentation 112 server status using 201 UDP blast protection 635, 636 URL, in HTTP redirection 454 user account 52 user limits, bandwidth 774, 776
.
848 Index
W
WAN links conguration summary 336 conguring basic example 338 conguring with SLB 350 inbound trafc 332 load balancing 329 multi-homing 327 outbound trafc 330 WAP WTLS health check 498 WAP Gateway 279 WAP load balancing RADIUS snooping 283, 283, 287 RADIUS/WAP persistence 287
static session entries 280 Web cache redirection See application redirection 409 Web hosting 191 weights 206 Wide Area Networking (WAN) load balancing 327, 327 Wireless Application Protocol 279 World Wide Web, client security for browsing 379 WSP health checks 492, 498 WTLS health check 498
X
xmascan 622
.
Nortel Application Switch Operating System
Application Guide
Copyright 2008, Nortel Networks All Rights Reserved. Publication: NN47220-104 (320507-D) Document status: Standard Document version: 01.01 Document 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 design or 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 rst appearance in the document. All other trademarks are the property of their respective owners.

24.0.0 Application Guide

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

24.0.0 Application Guide

Uploaded by

Copyright:

Available Formats

Nortel Application Switch Operating System

New in this release

Part 1: Basic Switching

6 Contents MSTP Conguration Guidelines 105 MSTP Conguration Example 105

Part 3: Application Switching Fundamentals

Part 4: Advanced Switching

Who should use this guide

What you will nd in this guide

Part 1: Basic Switching

Part 3: Application Switching Fundamentals

Part 4: Advanced Switching

To establish a Telnet session, enter: host# telnet <IP address>

Read your Users Guide thoroughly. host# ls [-a]

How to get help

How to get help

New in this release

24 New in this release

Part 1: Basic Switching

26 Part 1: Basic Switching

Accessing the Switch

Using the CLI

Accessing the Switch

28 Part 1: Basic Switching

Accessing the Switch

Link the user to a particular access group.

30 Part 1: Basic Switching

View based Congurations

Accessing the Switch

Conguring SNMP Trap Hosts

32 Part 1: Basic Switching

Congure an entry in the notify table.

Accessing the Switch

34 Part 1: Basic Switching

/cfg/sys/ssnmp/snmpv3/comm 10 index v2trap name public uname v2trap

Accessing the Switch

Using Nortel ASEM

36 Part 1: Basic Switching

Using the Browser-Based Interface

Conguring BBI Access via HTTP

Accessing the Switch

Conguring BBI Access via HTTPS

Using the Management Port

38 Part 1: Basic Switching

Setting Up the Management Port

Congure a static IP address.

Enable the management port.

Accessing the Switch

40 Part 1: Basic Switching

Limiting Management Access

Accessing the Switch

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

Time Zone Conguration

42 Part 1: Basic Switching

Select the general geographic zone in which the switch is located.

Accessing the Switch

44 Part 1: Basic Switching

Enter the number of your choice:

Apply and save the conguration change. End

Network Time Protocol

Accessing the Switch

Note: To disable NTP functionality use the off command. End

46 Part 1: Basic Switching

Securing the Switch