alteon os 22.0.2 application guide

8/12/2019 Alteon OS 22.0.2 Application Guide

http://slidepdf.com/reader/full/alteon-os-2202-application-guide 1/743

4655 Great America Parkway

Santa Clara, CA 95054

Phone 1-800-4Nortel

http://www.nortelnetworks.com

Alteon OS 22.0.2

Application Guide

part number: 315394-J, January 2005



Alteon OS 22.0.2 Application Guide

315394-J, January 20052 :

Copyright 2005 Nortel Networks, Inc.,4655 Great America Parkway, Santa Clara, California 95054, USA.

All rights reserved. Part Number: 315394-J.

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 meanswithout 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 fitness for a particular purpose.

U.S. Government End Users: This document is provided with a “commercial item” as defined 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.

Alteon OS, Alteon 2424, Alteon 2424-SSL, Alteon 2224, 2216, 2208, 3408, Alteon 180, Alteon 180e,

Alteon 184, Alteon AD3, Alteon AD4, and ACEswitch are trademarks of Nortel Networks, Inc. in theUnited 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.

Originated in the U.S.A.



315394-J, January 20053

Contents

Preface 25

Who Should Use This Guide 25

What You’ll Find in This Guide 25

Typographic Conventions 28

Related Documentation 28

How to Get Help 29

Part 1: Basic Switching 31

Accessing the Switch 33

Using the CLI 34

Using SNMP 35

SNMP v1.0 35

SNMP v3.0 36

Using Alteon EMS 43Using the Browser-Based Interface 45

Configuring BBI Access via HTTP 45

Configuring BBI Access via HTTPS 45

Using the Management Port 46

Setting Up the Management Port 47

Securing the Switch 49

Protecting Switch-Owned Addresses from Attacks 49

How Different Protocols Attack the Switch 50

Configuring Denial of Service Protection 50

Viewing Dropped Packets 51

Setting Allowable Source IP Address Ranges for Switch Management 52

RADIUS Authentication and Authorization 53RADIUS Authentication Features in Alteon OS 53




315394-J, January 20054 Contents

How Radius Authentication Works 54

Configuring RADIUS Authentication on the Switch 55

Switch User Accounts 56

RADIUS Attributes for Alteon OS User Privileges 57

TACACS+ Authentication 58

How TACACS+ Authentication Works 58

TACACS+ Authentication Features in Alteon OS 59

Authorization 59

Configuring TACACS+ Authentication on the Switch 60

Secure Shell and Secure Copy 61

Configuring SSH/SCP features on the switch 61

Configuring the SCP Administrator Password 62

SCP Services 63

Using SSH and SCP Client Commands 63

SSH and SCP Encryption of Management Messages 65

Generating RSA Host and Server Keys for SSH Access 65

SSH/SCP Integration with Radius Authentication 66SSH/SCP Integration with SecurID 66

End User Access Control 67

Considerations for Configuring End User Accounts 67

User Access Control Menu 68

Setting up User IDs 68

Defining User Names and Passwords 69

Changing Passwords 69Defining a User’s Access Level 69

Assigning One or More Real Servers to the End User 69

Validating a User’s Configuration 70

Listing Current Users 70

Enabling or Disabling a User 71

Logging into an End User Account 71

Performing Operational Commands on Real Servers when Logged Into an EndUser Account 71

Deny Routes 72

Configuring a Deny Route 72

Viewing a Deny Route 73

VLANs 75

VLAN ID Numbers 76




315394-J, January 2005Contents 5

VLAN Tagging 76

VLANs and the IP Interfaces 77

VLAN Topologies and Design Issues 77

Example 1: Multiple VLANS with Tagging Adapters 78

Example 2: Parallel Links with VLANs 80

VLANs and Default Gateways 81

Segregating VLAN Traffic 81

Configuring the Local Network 83

Configuring Gateways per VLAN 83

VLANs and Jumbo Frames 85

Limitations 85

Isolating Jumbo Frame Traffic using VLANs 85

Configuring VLANs for Jumbo and Non-Jumbo Frames 86

Port Trunking 89

Overview 90

Statistical Load Distribution 90The Trunk Hash Algorithm 91

Built-In Fault Tolerance 92

Static Port Trunking Example 92

Link Aggregation Control Protocol Trunking 95

Configuring LACP 97

Spanning Tree Protocol 99Overview 100

Bridge Protocol Data Units (BPDUs) 101

Determining the Path for Forwarding BPDUs 101

Spanning Tree Compatibility between Cisco and Nortel BPDU Formats 102

Spanning Tree Group Configuration Guidelines 103

Adding a VLAN to a Spanning Tree Group 103

Creating a VLAN 103Multiple Spanning Trees 106

Why Do We Need Multiple Spanning Trees? 106

Four-Switch Topology with a Single Spanning Tree 107

Four-Switch Topology with Multiple Spanning Trees 108

Switch-Centric Spanning Tree Protocol 109

VLAN Participation in Spanning Tree Groups 110

Configuring Multiple Spanning Tree Groups 111





Part 2: IP Routing 113

Basic IP Routing 115IP Routing Benefits 116

Routing Between IP Subnets 116

Example of Subnet Routing 119

Defining IP Address Ranges for the Local Route Cache 123

Dynamic Host Configuration Protocol 124

DHCP Relay Agent 125

DHCP Relay Agent Configuration 126

Routing Information Protocol 127

Distance Vector Protocol 127

Stability 127

Routing Updates 128

Border Gateway Protocol 129Internal Routing Versus External Routing 130

Forming BGP Peer Routers 131

What is a Route Map? 131

Incoming and Outgoing Route Maps 132

Precedence 133

Configuration Overview 133

Aggregating Routes 134

Redistributing Routes 135

BGP Attributes 136

Local Preference Attribute 136

Metric (Multi-Exit Discriminator) Attribute 136

Selecting Route Paths in BGP 137

BGP Failover Configuration 138

Default Redistribution and Route Aggregation Example 141

Part 3: Application Switching Fundamentals 143

Open Shortest Path First (OSPF) 145

OSPF Overview 146

Equal Cost Multipath Routing Support 146





Types of OSPF Areas 146

Types of OSPF Routing Devices 148

Neighbors and Adjacencies 149

The Link-State Database 149

The Shortest Path First Tree 150

Internal Versus External Routing 150

OSPF Implementation in Alteon OS 151

Configurable Parameters 151

Defining Areas 152

Interface Cost 154

Electing the Designated Router and Backup 154

Summarizing Routes 154

Default Routes 155

Virtual Links 156

Router ID 157

Authentication 157

Host Routes for Load Balancing 160Redistributing Routes into OSPF 160

OSPF Features Not Supported in This Release 163

OSPF Configuration Examples 164

Example 1: Simple OSPF Domain 165

Example 2: Virtual Links 167

Example 3: Summarizing Routes 171

Example 4: Host Routes 174Verifying OSPF Configuration 180

Server Load Balancing 181

Understanding Server Load Balancing 182

Identifying Your Network Needs 182

How Server Load Balancing Works 183

Implementing Basic Server Load Balancing 185 Network Topology Requirements 186

Configuring Server Load Balancing 188

Additional Server Load Balancing Options 191

Supported Services and Applications 192

Disabling and Enabling Real Servers 193

IP Address Ranges Using imask 194

Health Checks for Real Servers 194





Configuring Multiple Services 194

Metrics for Real Server Groups 195

Weights for Real Servers 199

Connection Time-outs for Real Servers 200

Maximum Connections for Real Servers 200

Unlimited Connections to Real Servers 200

Backup/Overflow Servers 201

Content Intelligent Server Load Balancing 202

URL-Based Server Load Balancing 202

Virtual Hosting 207

Cookie-Based Preferential Load Balancing 210

Browser-Smart Load Balancing 213

URL Hashing for Server Load Balancing 214

Header Hash Load Balancing 216

Inserting the “X-Forwarded-For” Header in HTTP Requests 217

Extending SLB Topologies 218

Virtual Matrix Architecture 218Proxy IP Addresses 219

Proxy IP Address Configuration 219

VLAN-based Proxy IP Addresses 221

Selecting a Proxy IP Based on the Egress Port or VLAN 221

Proxy IP Addresses in Filters 222

Source Grouping: Using a Virtual Server IP Address as the Proxy IP Address 222

Configuring Proxy IP Addresses 223Mapping Ports 225

Mapping a Virtual Server Port to a Real Server Port 225

Mapping a Single Virtual Server Port to Multiple Real Server Ports 225

Direct Server Return 228

How Direct Server Return Works 229

Direct Access Mode 230

Configuring Global Direct Access Mode 230Blocking Direct Access Mode on Selected Services 231

Assigning Multiple IP Addresses 232

Using Proxy IP Addresses 232

Mapping Ports 232

Monitoring Real Servers 233

Delayed Binding 234

Configuring Delayed Binding 236





Detecting SYN Attacks 236

Load Balancing Special Services 239

IP Server Load Balancing 239FTP Server Load Balancing 240

FTP Network Topology Restrictions 240

Configuring FTP Server Load Balancing 240

TFTP Server Load Balancing 241

Requirements 241

Configuring TFTP Server Load Balancing 241

Lightweight Directory Access Server SLB 242

LDAP Operations and Server Types 242

How LDAP SLB Works 242

Selectively Resetting a Real Server 243

Configuring LDAP SLB 243

Domain Name Server (DNS) SLB 245

Preconfiguration Tasks 246Configuring UDP-based DNS Load Balancing 248

Configuring TCP-based DNS Load Balancing 248

Layer 7 DNS Load Balancing 250

Real Time Streaming Protocol SLB 253

How RTSP Server Load Balancing Works 253

Supported RTSP Servers 254

Configuring RTSP Load Balancing 254Content-Intelligent RTSP Load Balancing 258

Wireless Application Protocol SLB 263

WAP SLB with RADIUS Static Session Entries 265

WAP SLB with RADIUS Snooping 267

WAP SLB with Radius/WAP Persistence 270

Intrusion Detection System SLB 274

How Intrusion Detection Server Load Balancing Works 275Setting Up IDS Servers 276

IDS Load Balancing Configurations 276

Session Initiation Protocol Server Load Balancing 293

SIP Processing on the Switch 293

Configuring SIP Server Load Balancing 294





WAN Link Load Balancing 297

Multi-homing 297

Benefits of WAN Link Load Balancing 298

Identifying Your Network Needs 299What is Load Balancing? 300

How WAN Link Load Balancing Works 300

Outbound Traffic 301

Inbound Traffic 302

Configuring WAN Link Load Balancing 306

Before You Begin 306

Configuration Summary 308

Example 1: Simple WAN Link Load Balancing 309

Example 2: WAN Link Load Balancing with Server Load Balancing 320

Filtering 331

Overview 332

Filtering Benefits 332Filtering Criteria 333

Filtering Actions 334

Stacking Filters 334

Overlapping Filters 335

The Default Filter 335

Optimizing Filter Performance 336

IP Address Ranges 337Filter Logs 337

Cached versus Non-cached Filters 338

MAC-Based Filters for Layer 2 Traffic 339

VLAN-based Filtering 340

Configuring VLAN-based Filtering 341

Filtering on 802.1p Priority Bit in a VLAN Header 342

802.1p Priorities 342Classifying and Prioritizing Packets Based on 802.1p

Priority Bits 343

Tunable Hash for Filter Redirection 344

Filter-based Security 345

Network Address Translation 351

Static NAT 351

Dynamic NAT 353





FTP Client NAT 355

Matching TCP Flags 357

Matching ICMP Message Types 361

Deny Filter Based on Layer 7 Content Lookup 363Denying HTTP URL Requests 364

Denying HTTP Headers 365

Application Redirection 367

Overview 369

Cache Redirection Environment 369

Additional Application Redirection Options 370

Cache Redirection Configuration Example 371

RTSP Cache Redirection 376

IP Proxy Addresses for NAT 379

Excluding Noncacheable Sites 381

Content Intelligent Cache Redirection 382

URL-Based Cache Redirection 383

HTTP Header-Based Cache Redirection 391

Browser-Based Cache Redirection 392

URL Hashing for Cache Redirection 393

RTSP Streaming Cache Redirection 398

HTTP Redirection 402

Configure SLB Strings for HTTP Redirection 402

IP based HTTP redirection 405TCP Service Port Based HTTP Redirection 408

MIME Type Header-Based Redirection 410

URL-Based Redirection 412

Source IP from HTTP header and Host Header-Based Redirection 414

HTTP to HTTPS Redirection 415

Part 4: Advanced Switching 417

Health Checking 419

Real Server Health Checks 421

Advanced Group Health Check 422

Disabling the Fast Link Health Check 423

DSR Health Checks 424Link Health Checks 425





Configuring Link Health Checks 425

TCP Health Checks 426

ICMP Health Checks 426

Script-Based Health Checks 427Configuring Script-Based Health Checks 427

Script Formats 428

Scripting Commands 431

Scripting Guidelines 432

Script Configuration Examples 433

Application-Specific Health Checks 437

HTTP Health Checks 438

UDP-Based DNS Health Checks 440

TFTP Health Check 441

SNMP Health Check 442

FTP Server Health Checks 444

POP3 Server Health Checks 445

SMTP Server Health Checks 445IMAP Server Health Checks 447

NNTP Server Health Checks 448

RADIUS Server Health Checks 449

HTTPS/SSL Server Health Checks 451

WAP Gateway Health Checks 452

LDAP Health Checks 458

ARP Health Checks 460Failure Types 461

Service Failure 461

Server Failure 461

High Availability 463

VRRP Overview 464

Standard VRRP Components 464Alteon OS Extensions to VRRP 468

Failover Methods and Configurations 479

Active-Standby Redundancy 480

Active-Active Redundancy 484

Hot-Standby Redundancy 494

Tracking Virtual Routers 502

Service-Based Virtual Router Groups 504

Alt OS 22 0 2 A li ti G id





Virtual Router Deployment Considerations 509

Mixing Active-Standby and Active-Active Virtual Routers 509

Eliminating Loops with STP and VLANs 509

Assigning VRRP Virtual Router ID 511Configuring VRRP Peers for Synchronization 511

Synchronizing Active/Active Failover 512

Stateful Failover of Persistent Sessions 513

What Happens When a Switch Fails 514

Viewing Statistics on Persistent Port Sessions 516

Persistence 517

Overview of Persistence 518

Using Source IP Address 518

Using Cookies 519

Using SSL Session ID 519

HTTP and HTTPS Persistence Based on Client IP 520

Cookie-Based Persistence 522

Permanent and Temporary Cookies 523

Cookie Formats 523

Cookie Properties 524

Client Browsers that Do Not Accept Cookies 524

Cookie Modes of Operation 525

Configuring Cookie-Based Persistence 528

Server-Side Multi-Response Cookie Search 534SSL Session ID-Based Persistence 535

How SSL Session ID-Based Persistence Works 535

Configuring SSL Session ID-Based Persistence 537

Advanced Denial of Service Protection 539

Background 540

Security Inspection Workflow 540Other Types of Security Inspection 540

IP Address Access Control Lists 542

Configuring Blocking with IP Access Control Lists 543

Viewing IP ACL statistics 543

Protection Against Common Denial of Service Attacks 544

Configuring Ports with DOS Protection 544

Viewing DOS statistics 544

Alteon OS 22 0 2 Application Guide





Viewing DOS statistics per port 545

Understanding the types of DOS attacks 545

Preventing other types of DOS attack 547

Protocol-Based Rate Limiting 548Time Windows and Rate Limits 548

Hold Down Periods 549

UDP and ICMP Rate Limiting 549

TCP Rate Limiting 549

Configuring Protocol-Based Rate Limiting Filters 550

Protection Against UDP Blast Attacks 555

Configuring UDP Blast Protection 555

TCP or UDP Pattern Matching 556

Pattern Criteria 556

Matching Groups of Patterns 558

Firewall Load Balancing 565

Firewall Overview 566

Basic FWLB 568

Basic FWLB Implementation 569

Configuring Basic FWLB 571

Four-Subnet FWLB 580

Four-Subnet FWLB Implementation 582

Configuring Four-Subnet FWLB 583

Advanced FWLB Concepts 601Free-Metric FWLB 601

Adding a Demilitarized Zone (DMZ) 605

Firewall Health Checks 607

Virtual Private Network Load Balancing 609

Overview 610

How VPN Load Balancing Works 610VPN Load-Balancing Configuration 612

Configure the First Clean-Side Application Switch-CA 613

Configure the Second Clean-Side Application Switch-CB 616

Configure the First Dirty-Side Application Switch-DA 618

Configure the Second Dirty-Side Application Switch-DB 621

Test Configurations and General Topology 624

Test the VPN 625






Global Server Load Balancing 627

Enabling GSLB on the Switch 628

DSSP version 1 vs. version 2 628

Migrating Old GSLB Configurations into Alteon OS 22.0 629GSLB License Key 629

GSLB Overview 630

Benefits 630

How GSLB Works 631

GSLB Enhancements 633

GSLB Metrics 633

Metric preferences 636

Rules 636

Configuring Basic GSLB 637

Basic GSLB Requirements 638

Example GSLB Topology 638

Configuring a Standalone GSLB Domain 652

GSLB Topology with a Standalone GSLB Site 652Configuring GSLB with Rules 656

Configuring Time-Based Rules 657

Using the Availability Metric in a Rule 659

Configuring GSLB Network Preference 660

Configuring GSLB with Proxy IP for Non-HTTP Redirects 663

How Proxy IP Works 665

Configuring Proxy IP Addresses 666Using Border Gateway Protocol for GSLB 667

Verifying GSLB Operation 668

Bandwidth Management 669

Enabling Bandwidth Management 670

Contracts 671

Classification Rules 672Grouped Bandwidth Contracts 674

IP User Level Contracts for Individual Sessions 676

Policies 677

Bandwidth Policy Index 677

Time Policy 678

Enforcing Policies 678

Rate Limiting 679






Rate Limiting Timeslots 681

Traffic Shaping 681

Data Pacing for Traffic Shaping Contracts 681

Bandwidth Management Information 682Viewing BWM Statistics 683

Configuring BWM History 683

Sending BWM History 683

Statistics and Management Information Bases 683

Synchronizing BWM Configurations in VRRP 684

Packet Coloring (TOS bits) for Burst Limit 684

Configuring Bandwidth Management 684

Additional BWM Configuration Examples 688

Configuring User/Application Fairness 688

Configuring Grouped Contracts for Bandwidth Sharing 690

Configuring a IP User-Level Rate Limiting Contract 694

Configuring BWM Preferential Services 695

Configuring Content Intelligent Bandwidth Management 698

Configuring Cookie-Based Bandwidth Management 703

Configuring Security Management 706

Configuring Time and Day Policies 708

Configuring Egress Bandwidth Tuning for Connections to Lower Speed

Networks 710

Overwriting the TCP Window Size 710

Configuring Intelligent Traffic Management 711

Troubleshooting 713

Port Mirroring 714

Mirroring Individual Ports 714

Mirroring VLANs on a Port 716

Filtering the Session Dump 717

Layer 7 String Handling 719

Exclusionary String Matching for Real Servers 720

Configuring Exclusionary URL String Matching 720

Regular Expression Matching 722

Standard Regular Expression Characters 722

Configuring Regular Expressions 723

Content Precedence Lookup 724




pp


Requirements 725

Using the or / and Operators 725

Assigning Multiple Strings 726

String Case Insensitivity 727Configurable HTTP Methods 728




315394-J, January 200519

Figures

RADIUS Authentication and Authorization: How It Works 54

Example 1: Multiple VLANs with VLAN-Tagged Gigabit Adapters 78

Example 2: Parallel Links with VLANs 80Default Gateways per VLAN 81

Jumbo Frame VLANs 86

Port Trunk Group 90

Port Trunk Group Configuration Example 92

Multiple Instances of Spanning Tree Protocol 106

VLAN 3 Isolated in a Single Spanning Tree Group 107

Implementing Multiple Spanning Tree Groups 108The Router Legacy Network 117

Switch-Based Routing Topology 118

DHCP Relay Agent Configuration 126

iBGP and eBGP 130

Distributing Network Filters in Access Lists and Route Maps 132

BGP Failover Configuration Example 138

Route Aggregation and Default Route Redistribution 141

OSPF Area Types 147

OSPF Domain and an Autonomous System 148

Injecting Default Routes 155

OSPF Authentication 157

A Simple OSPF Domain 165

Configuring a Virtual Link 167

Summarizing Routes 171

Configuring OSPF Host Routes 174Traditional Versus SLB Network Configurations 183

Web Hosting Configuration Without SLB 185

Web Hosting with SLB Solutions 185

SLB Client/Server Traffic Routing 186

Example Network for Client/Server Port Configuration 187

URL-Based Server Load Balancing 203

Using URL hashing to Load Balance Nontransparent Caches 214Basic Virtual Port to Real Port Mapping Configuration 226




315394-J, January 200520 Figures

Direct Server Return 229

Mapped and Nonmapped Server Access 233

DoS SYN Attacks without Delayed Binding 234

Repelling DoS SYN Attacks With Delayed Binding 235LDAP Load Balancing 243

Layer 4 DNS Load Balancing 246

Load Balancing DNS Queries 250

Load Balancing RTSP Servers 255

Layer 7 RTSP Load Balancing 259

Load Balancing WAP Gateways 264

Server Load Balancing and IDS Load Balancing to a Single Group 278

Server Load Balancing and IDS Load Balancing 282

Load Balancing IDS Servers Across Two Switches 287

SIP Load Balancing 294

Outbound Traffic 301

Inbound Traffic for non-SLB server 304

Inbound Traffic for SLB group 305

Simple WAN Link Load Balancing 310

WAN Link Load Balancing with SLB 320Assigning Filters According to Range of Coverage 334

Assigning Filters to Overlapping Ranges 335

Assigning a Default Filter 335

VLAN-based Filtering 340

Security Topology Example 345

Static Network Address Translation 352

Dynamic Network Address Translation 353Active FTP for Dynamic NAT 355

TCP ACK Matching Network 357

Configuring a Deny Filter with Layer 7 Lookup for HTTP URL, HTTP Header, or UDP

Strings 363

Traditional Network Without Cache Redirection 369

Network with Cache Redirection 370

RTSP Cache Redirection 376URL-Based Cache Redirection 384

URL Hashing for Application Redirection 396

Load Balancing RTSP Cache Servers 398

Virtual Interface Router 470

Active-Active Failover with Shared Interfaces 471

Service Based Virtual Router Groups 473

Active-Standby VRRP Routers 480

Non-Shared Active-Standby High-Availability Configuration 482




315394-J, January 2005Figures 21

Active-Active High-Availability Configuration 484

Hot-Standby Configuration 496

Service-Based Virtual Router Groups—Active-Standby Configuration 504

Loops in Active-Active Configuration 509Cross-Redundancy Creates Loops, but STP Resolves Them 510

Using VLANs to Create Non-Looping Topologies 510

Stateful Failover Example when the Master Switch Fails 514

Cookie-Based Persistence: How It Works 522

Insert Cookie Mode 525

Passive Cookie Mode 526

Rewrite Cookie Mode 527

SSL Session ID-Based Persistence 536

Configuring Clients with Different Rates 550

Limiting User Access to Server 553

IP Packet Format 557

Typical Firewall Configuration Before FWLB 566

Basic FWLB Topology 568

Basic FWLB Process 569

Basic FWLB Example Network 571Four-Subnet FWLB Topology 580

Four-Subnet FWLB Process 582

Four-Subnet FWLB Example Network 583

Basic FWLB Example Network 601

Four-Subnet FWLB Example Network 603

Typical Firewall Load-Balancing Topology with DMZ 605

Basic Network Frame Flow and Operation 611VPN Load-Balancing Configuration Example 612

Checkpoint Rules for Both VPN Devices as Seen in the Policy Editor 624

DNS Resolution with Global Server Load Balancing 631

GSLB Topology Example 1 638

GSLB Topology Example 2—with Standalone GSLB 652

Configuring Client Proximity Table 661

HTTP and Non-HTTP Redirects 664POP3 Request Fulfilled via IP Proxy 665

Bandwidth Management: How It Works 672

Bandwidth Rate Limits 679

Real-time Clocks and Theoretical Departure Times 682

URL-Based SLB with Bandwidth Management 699

Cookie-Based Bandwidth Management 703

Cookie-Based Preferential Services 705

Content Precedence Lookup Protectors Example 725




315394-J, January 200522 Figures

Content Precedence Lookup Multiple Strings Example 726



315394-J, January 200523

Tables

Table 2-1 Alteon OS User Accounts and Access Levels 56

Table 2-2 Alteon OS-Proprietary Attributes for Radius 57

Table 2-3 Alteon OS-Proprietary Attributes for TACACS+ 59Table 3-1 Route Cache Example 82

Table 4-1 Actor vs. Partner LACP configuration 95

Table 5-1 Ports, Trunk Groups, and VLANs 100

Table 5-2 Multiple Spanning Tree Groups per VLAN 109

Table 6-1 Subnet Routing Example: IP Address Assignments 119

Table 6-2 Subnet Routing Example: IP Interface Assignments 119

Table 6-3 Subnet Routing Example: Optional VLAN Ports 121Table 6-4 Local Routing Cache Address Ranges 123

Table 9-1 Route Maps 161

Table 10-1 Web Host Example: Real Server IP Addresses 188

Table 10-2 Web Host Example: Port Usage 190

Table 10-3 Well-Known Application Ports 192

Table 10-4 Proxy Example: Port Usage 223

Table 11-1 Setting Up IDS Servers 276

Table 12-1 WAN Link Load Balancing versus BGP 298Table 12-2 Configuration Summary 308

Table 12-3 Configuring Simple WAN Link Load Balancing 311

Table 12-4 ISP links: Real Server IP Addresses 311

Table 12-5 Configuring WAN Link Load Balancing with SLB 321

Table 12-6 ISP links: Real Server IP Addresses 321

Table 13-1 Well-Known Protocol Types 333

Table 13-2 Filtering IP Address Ranges 337Table 13-3 Web Cache Example: Real Server IP Addresses 346

Table 13-4 ICMP Message Types 361

Table 14-1 Cache Redirection Example: Real Server IP Addresses 371

Table 14-6 Example HTTP Redirection Strings 403

Table 15-1 WAP Gateway Health Checks 452

Table 16-1 Active-Active Failover with Shared Interfaces 471

Table 16-2 VRRP Tracking Parameters 476Table 16-3 Active-Standby Configuration 481




315394-J, January 200524 : Tables

Table 17-1 Comparison Among the Three Cookie Modes 525

Table 21-1 GSLB Example: San Jose Real Server IP Addresses 641

Table 21-2 GSLB Example: San Jose Alteon Switch Port Usage 642

Table 21-3 Denver Real Server IP Addresses 648Table 21-4 Web Host Example: Port Usage 649

Table 21-5 HTTP Versus Non-HTTP Redirects 664

Table 22-1 Bandwidth Reallocation in Grouped Contracts 675

Table 22-2 Bandwidth Rate Limits 680

Table 22-3 Standard Regular Expression Special Characters 722

Table 22-4 Real Server Content 727



315394-J, January 200525

Preface

This Application Guide describes how to configure and use the Alteon OS software on the

Alteon 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

configuring and maintaining a network. The administrator should be familiar with Ethernet

concepts, IP addressing, Spanning Tree Protocol, and SNMP configuration parameters.

What You’ll Find in This Guide

This guide will help you plan, implement, and administer Alteon OS software. Where possible,

each section provides feature overviews, usage examples, and configuration instructions.

Part 1: Basic Switching

Chapter 1, “Accessing the Switch,” describes how to access the Alteon Application

Switch to configure, view information and run statistics on the switch using the CLI,

Alteon EMS, the Browser-Based Interface, SNMP, and the Management port.

Chapter 2, “Securing the Switch,” describes how to protect the switch from attacks, unau-

thorized access, and also discusses different methods to manage the switch for remote

administrators using specific IP addresses, RADIUS authentication, Secure Shell (SSH),

and Secure Copy (SCP).

Chapter 3, “VLANs,” describes how to configure 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.




315394-J, January 200526 Preface

Chapter 4, “Port Trunking,” describes how to group multiple physical ports together to

aggregate the bandwidth between large-scale network devices.

Chapter 5, “Spanning Tree Protocol,” discusses how Spanning Trees configure the net-

work so that the switch uses the most efficient path when multiple paths exist.

Part 2: IP Routing

Chapter 6, “Basic IP Routing,” describes how to configure the Alteon Application Switch

for IP routing using IP subnets, and DHCP Relay.

Chapter 7, “Routing Information Protocol,” describes how the Alteon OS software imple-

ments standard RIP for exchanging TCP/IP route information with other routers

Chapter 8, “Border Gateway Protocol,” describes BGP concepts and BGP features sup-

ported in Alteon OS.

Chapter 9, “Open Shortest Path First (OSPF),” describes OSPF concepts, how OSPF is

implemented in Alteon OS, and four examples of how to configure your switch for OSPF

support.

Part 3: Application Switching Fundamentals

Chapter 10, “Server Load Balancing,” describes how to configure the Alteon Application

Switch to balance network traffic among a pool of available servers for more efficient,

robust, and scalable network services.

Chapter 11, “Load Balancing Special Services,” describes how to extend server load bal-

ancing configurations to load balance services including source IP addresses, FTP, RTSP,

DNS, WAP, IDS, and Session Initiation Protocol (SIP).

Chapter 12, “WAN Link Load Balancing,” describes how to configure the Alteon Appli-

cation Switch to balance user session traffic among a pool of available WAN Links.

Chapter 13, “Filtering,” describes how to configure and optimize network traffic filters for

security and Network Address Translation.

Chapter 14, “Application Redirection,” describes how to use filters for redirecting traffic

to such network streamlining devices as caches.

Chapter 15, “Health Checking,” describes how to configure the Alteon Application

Switch to recognize the availability of the various network resources used with the various

load-balancing and application redirection features.

Chapter 16, “High Availability,” describes how to use the Virtual Router Redundancy

Protocol (VRRP) to ensure that network resources remain available if one Alteon Applica-

tion Switch is removed for service.




315394-J, January 2005Preface 27

Part 4: Advanced Switching

Chapter 17, “Persistence,” describes how to ensure that all connections from a specific cli-

ent session reach the same server. Persistence can be based on cookies or SSL session ID.

Chapter 18, “Advanced Denial of Service Protection,” describes the advanced Denial of

Service protection features in Alteon OS that can be used to prevent a wide range of net-

work attacks.

Chapter 19, “Firewall Load Balancing,” describes how to combine features to provide a

scalable solution for load balancing multiple firewalls.

Chapter 20, “Virtual Private Network Load Balancing,” describes using your Alteon

Application Switch to load balance secure point-to-point links.

Chapter 21, “Global Server Load Balancing,” describes configuring Server Load Balanc-

ing across multiple geographic sites. This chapter also describes new GSLB features

added in this release.

Chapter 22, “Bandwidth Management,” describes how to configure the Alteon Applica-

tion Switch for allocating specific portions of the available bandwidth for specific users or

applications.

Appendix A, “Troubleshooting,” discusses two tools for troubleshooting your application

switch—monitoring ports and filtering session dumps.

Appendix B, “Layer 7 String Handling,” 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.

Related Documentation

Alteon OS 22.0.2 Release Notes (Part Number 315397-J)

Provides up-to-date information about Alteon OS 22.0.2 installation, upgrade, and known

issues.

Alteon OS 22.0.2 Command Reference (Part Number. 315393-J)

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

Alteon OS Browser-Based Interface (BBI) Quick Guide (315395-C rev 01)

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

Table 1 Typographic Conventions

Typeface or

Symbol

Meaning Example

AaBbCc123 This type is used for names of commands,

files, and directories used within the text.

View the readme.txt file.

It also depicts on-screen computer output and prompts. Main#

AaBbCc123 This bold type appears in command exam-

ples. It shows text that must be typed in

exactly as shown.

Main# sys

<AaBbCc123> 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.

To establish a Telnet session, enter:

host# telnet <IP address>

This also shows book titles, special terms, or

words to be emphasized.

Read your User’s Guide thoroughly.

[* ] Command items shown inside brackets are

optional and can be used or excluded as the

situation demands. Do not type the brackets.

host# ls [-a]




315394-J, January 2005Preface 29

How to Get Help

If you purchased a service contract for your Nortel Networks product from a distributor or autho-

rized reseller, contact the technical support staff for that distributor or reseller for assistance.

If you purchased a Nortel Networks service program, contact one of the following Nortel Net-

works Technical Solutions Centers:

Additional information about the Nortel Networks Technical Solutions Centers is available at

the following URL:

http://www.nortelnetworks.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 sup-

porting that product or service. To locate an ERC for your product or service, refer to the fol-

lowing URL:

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

Technical Solutions Center Telephone

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

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

Asia Pacific (61) (2) 8870-8800

China (800) 810-5000








315394-J, January 2005

Part 1: Basic SwitchingThis part describes how to access and manage the switch, and how to configure basic Layer 1–

2 switching functions.

Chapter 1, “Accessing the Switch”

Chapter 2, “Securing the Switch”

Chapter 3, “VLANs”

Chapter 4, “Port Trunking”

Chapter 5, “Spanning Tree Protocol”




315394-J, January 200532 : Basic Switching



315394-J, January 200533

CHAPTER 1

Accessing the Switch

The Alteon OS software provides means for accessing, configuring, and viewing informationand statistics about the Alteon Application Switch. The following topics are addressed in this

chapter:

“Using the CLI” on page 34

“Using SNMP” on page 35

“Using Alteon EMS” on page 43

“Using the Browser-Based Interface” on page 45

“Using the Management Port” on page 46




315394-J, January 200534 Chapter 1: Accessing the Switch

Using the CLI

The Command Line Interface (CLI) is a built-in, text-based menu system for access via local

terminal or remote Telnet session. The CLI is the most direct method for collecting switch

information and performing switch configuration. The Main Menu of the CLI with administra-

tor privileges is displayed in the following table:

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

Using a serial connection via the console port

You can access and configure the application switch by using a computer running terminal

emulation software.

Using the management port

The management port is a Fast Ethernet port on the Alteon Application Switch that is used

exclusively for managing the switch.

For more information on the management port, see “Using the Management Port” on page

46.

[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]


U i T l i h k



315394-J, January 2005Chapter 1: Accessing the Switch 35

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 adminis-

trator access as those available through the console port.

To establish a Telnet connection with the switch, run the Telnet program on your worksta-

tion and issue the Telnet command, followed by the 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 anetwork to execute commands remotely. As a secure alternative to using Telnet to manage

switch configuration, SSH ensures that all data sent over the network is encrypted and

secure. For more information, see “Secure Shell and Secure Copy” on page 61.

For more information on the CLI, see the Alteon OS Command Reference.

Using SNMP

Alteon OS provides SNMP v1.0 and SNMP v3.0 support for access through any network man-

agement software, such as Alteon EMS or HP-OpenView.

SNMP v1.0

To access the SNMP agent on the Alteon Application Switch, the read and write community

strings on the SNMP manager should be configured to match those on the switch. The default

read community string on the switch is public and the default write community string is

private.

The read and write community strings on the switch can be changed using the following com-

mands on the CLI:

and

The SNMP manager should be able to reach the management interface (management port) or

any one of the IP interfaces on the switch.

telnet <switch IP address>

>> /cfg/sys/ssnmp/rcomm

>> /cfg/sys/ssnmp/wcomm


SNMP 3 0




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 secu-

rity and authentication features that provide data origin authentication, data integrity checks,

timeliness indicators and encryption to protect against threats such as masquerade, modifica-

tion of information, message stream modification and disclosure.

SNMP v3 ensures that the client can use SNMP v3 to query the MIBs, mainly for security pur-

poses.

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

For more information on SNMP MIBs and the commands used to configure SNMP on the

switch, see the Alteon OS Command Reference.

Default configuration

Alteon OS 22.0 has two users by default. Both the users 'adminmd5' and 'adminsha' will have

access to all the MIBs supported by the switch.

1. username 1: adminmd5/password adminmd5. Authentication used is MD5.

2. username adminsha/password adminsha. Authentication used is SHA.

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

User Configuration

Users can be configured to use the authentication and privacy options. Currently Alteon OS

supports two authentication algorithms: MD5 and SHA. Authentication and privacy options

can be specified using the following command:

>> # /cfg/sys/ssnmp/snmpv3

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

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


1 To configure a user with name 'test' authentication type MD5 and authentication pass




1. To configure a user with name test , authentication type MD5, and authentication pass-

word of 'test', privacy option DES with privacy password of 'test', enter the following

CLI commands.

2. Once a user is configured, specify the access level for this user along with the views to

which the user is allowed access. This is specified in the access table.

3. Link the user to a particular access group.

If you want to allow the user access only certain MIBs, see “View based Configurations” on

page 38.

>> # /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

>> # /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"

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


View based Configurations




View based Configurations

To configure an SNMP user equivalent to the CLI access level for user, use the following

configuration:

/cfg/sys/ssnmp/snmpv3/usm 4name "usr"/cfg/sys/ssnmp/snmpv3/access 3name "usrgrp"rview "usr"

wview "usr"nview "usr"/cfg/sys/ssnmp/snmpv3/group 4

uname usrgname usrgrp/cfg/sys/ssnmp/snmpv3/view 6name "usr"tree "1.3.6.1.4.1.1872.2.5.1.2"/cfg/sys/ssnmp/snmpv3/view 7name "usr"tree "1.3.6.1.4.1.1872.2.5.1.3"

/cfg/sys/ssnmp/snmpv3/view 8name "usr"tree "1.3.6.1.4.1.1872.2.5.2.2"/cfg/sys/ssnmp/snmpv3/view 9name "usr"tree "1.3.6.1.4.1.1872.2.5.2.3"/cfg/sys/ssnmp/snmpv3/view 10name "usr"tree "1.3.6.1.4.1.1872.2.5.3.2"

/cfg/sys/ssnmp/snmpv3/view 11name "usr"tree "1.3.6.1.4.1.1872.2.5.3.3"/cfg/sys/ssnmp/snmpv3/view 12name "usr"tree "1.3.6.1.4.1.1872.2.5.4.2"/cfg/sys/ssnmp/snmpv3/view 13name "usr"tree "1.3.6.1.4.1.1872.2.5.4.3"

/cfg/sys/ssnmp/snmpv3/view 14name "usr"tree "1.3.6.1.4.1.1872.2.5.5.2"/cfg/sys/ssnmp/snmpv3/view 15name "usr"tree "1.3.6.1.4.1.1872.2.5.5.3"/cfg/sys/ssnmp/snmpv3/view 16name "usr"

tree "1.3.6.1.4.1.1872.2.5.6.2"


To configure an SNMP user equivalent to the CLI access level for oper, use the following




o co gu e SN use equ v e o e C ccess eve o oper, use e o ow g

configuration:

/cfg/sys/ssnmp/snmpv3/usm 5

name "slboper"/cfg/sys/ssnmp/snmpv3/access 4name "slbopergrp"rview "slboper"

wview "slboper"nview "slboper"/cfg/sys/ssnmp/snmpv3/group 4

uname slbopergname slbopergrp/cfg/sys/ssnmp/snmpv3/view 20name "slboper"tree "1.3.6.1.4.1.1872.2.5.1.2"/cfg/sys/ssnmp/snmpv3/view 21name "slboper"tree "1.3.6.1.4.1.1872.2.5.1.3"/cfg/sys/ssnmp/snmpv3/view 22name "slboper"

tree "1.3.6.1.4.1.1872.2.5.2.2"/cfg/sys/ssnmp/snmpv3/view 23name "slboper"tree "1.3.6.1.4.1.1872.2.5.2.3"/cfg/sys/ssnmp/snmpv3/view 24name "slboper"tree "1.3.6.1.4.1.1872.2.5.3.2"/cfg/sys/ssnmp/snmpv3/view 25name "slboper"

tree "1.3.6.1.4.1.1872.2.5.3.3"/cfg/sys/ssnmp/snmpv3/view 26name "slboper"tree "1.3.6.1.4.1.1872.2.5.4"/cfg/sys/ssnmp/snmpv3/view 27name "slboper"tree "1.3.6.1.4.1.1872.2.5.4.1"type excluded/cfg/sys/ssnmp/snmpv3/view 28name "slboper"tree "1.3.6.1.4.1.1872.2.5.5.2"/cfg/sys/ssnmp/snmpv3/view 29name "slboper"tree "1.3.6.1.4.1.1872.2.5.5.3"/cfg/sys/ssnmp/snmpv3/view 30name "slboper"tree "1.3.6.1.4.1.1872.2.5.6.2"


Configuring SNMP Trap Hosts




g g p

SNMPv1 trap host

1. To configure a SNMPv1 trap host, first configure a user with no authentication and pass-word.

2. Configure an access group and group table entries for the user. The nview command can

be 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.

3. Configure an entry in the notify table.

4. 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/usm 10name "v1trap"

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

>> # /cfg/sys/ssnmp/snmpv3/group 10

>> SNMPv3 vacmSecurityToGroup 10 # model snmpv1>> SNMPv3 vacmSecurityToGroup 10 # uname v1trap>> SNMPv3 vacmSecurityToGroup 10 # gname v1trap

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

>> SNMPv3 vacmSecurityToGroup 10 # tag v1trap

>> # /cfg/sys/ssnmp/snmpv3/taddr 10 (Access the targetAddr Table Menu)

>> SNMPv3 snmpTargetAddrTable 10 # name v1trap

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

>> # /cfg/sys/ssnmp/snmpv3/tparam 10 (Access the targetParams table menu) >> SNMPv3 snmpTargetParamsTable 10 # name v1param >> SNMPv3 snmpTargetParamsTable 10 # mpmodel snmpv1>> SNMPv3 snmpTargetParamsTable 10 # uname v1trap

>> SNMPv3 snmpTargetParamsTable 10 # model snmpv1


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




SNMPv2 trap host configuration

The v2 trap host configuration is similar to the SNMPv1 trap host configuration. Wherever you

specify the model make sure to specify snmpv2 instead of snmpv1.

>> # /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

/cfg/sys/ssnmp/snmpv3/usm 10name "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 configuration




To configure 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 configured in the access table using the following commands:

The user in the user table should also be configured accordingly from the SNMPv3 usmUser 1

Menu, which is accessed from the following command:

It is not necessary to configure the community table for SNMPv3 traps because the community

string is not used by SNMPv3.

The following example shows how to configure an SNMPv3 user 'v3trap' with authenticationonly:

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

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

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

/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 name v3param uname v3trap level authNoPriv/cfg/sys/ssnmp/snmpv3/notify 11 name v3trap tag v3trap


Using Alteon EMS




g

The Alteon Element Management System (EMS) is a Java GUI application that runs on many

platforms used for configuring and monitoring Alteon Application Switches. The applicationcommunicates with the switches via the SNMP protocol. Alteon EMS can be integrated into

larger Network Management platforms such as HP OpenView.

Alteon EMS 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 func-

tions that EMS allows you to perform are the following:

Manage multiple switches simultaneously

EMS has a tree control and a view panel similar to Windows Explorer. View panels can be

“torn off” and docked back into the view. EMS allows you to view multiple aspects of a

single switch, or compare the same view of two different switches.

Configure the switch

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

View switch summary

EMS provides an overall summary of the switch, such as port level statistics, layer 3 sta-

tistics, server load balancing health, Syslog viewer, MP statistics, and sessions.

View server load balancing summary

EMS 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

Configure filters

EMS allows you to insert a new filter, move a block of filters, or assign filters to ports.

Monitor the switch

EMS monitors data in tables and graphs. You must first select a few items in the table

before the graph icons are enabled. EMS generates line, bar, or pie charts.


Export data to a file such as an Excel spreadsheet

Th f ll i h f th S L d B l i fi ti b d




The following screen shows a summary of the Server Load Balancing configuration based

on the real servers. In this view you can see the affected services when a real server goes

down. This view can also be summarized based on the state of the virtual servers.


Using the Browser-Based Interface




Alteon OS Browser-based Interface (BBI) is a Web-based management interface for interac-

tive switch access through your Web browser.

Configuring BBI Access via HTTP

To enable BBI access on the switch via HTTP, use the following command:

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

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.

Configuring 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:

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

command:

/cfg/sys/access/http ena

/cfg/sys/access/wport <x>

/cfg/sys/access/https/https ena

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


Accessing the BBI via HTTPS requires that you generate a certificate to be used during the key

exchange A default certificate is created the first time HTTPS is enabled but you can create a




exchange. A default certificate is created the first time HTTPS is enabled, but you can create a

new certificate defining the information you want to be used in the various fields.

The certificate can be saved to flash 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

certificate and can verify that the fields are what expected. Once BBI access is granted to theclient, 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 Alteon 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 (EMS), or HTTP (Alteon OS Browser-Based Interface—Alteon OS 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

>> /cfg/sys/access/https/generateCountry Name (2 letter code) [ ]: <country code>

State or Province Name (full name) []: <state>

Locality Name (eg, city) []: <city>

Organization Name (eg, company) []: <company>

Organizational Unit Name (eg, section) []: <org. unit>

Common Name (eg, YOUR name) []: <name>

Email (eg, email address) []: <email address>

Confirm generating certificate? [y/n]: yGenerating certificate. Please wait (approx 30 seconds)restarting SSL agent


performing TFTP functions (ptimg, gtimg, ptcfg, gtcfg, ptdmp)

i th SMTP




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 Alteon OS

Command Reference.

Setting Up the Management Port

1. Configure a static IP address.

2. Enable the management port.

When the management port is enabled, you can use it to access the switch via Telnet, SSH,

BBI, and SNMP (EMS), provided the commands are enabled on the switch. These commands

can occur simultaneously on both the management port and the data ports.

NOTE – You can have a maximum of four Telnet sessions on the Alteon Application Switchover the management port and the data ports together.

3. Configure the default port type for each management function.

Select the management port or the default data port for each management function. For exam-

ple, select the management port for NTP, Radius, and Syslog functions only. SMTP, TFTP,

and SNMP traps are configured to use the default data ports.

>> # /cfg/sys/mmgmt/addr 10.10.10.1 (Configure a static IP address)

>> Management Port# mask 255.255.255.0 (Configure a network mask)

>> # /cfg/sys/mmgmt/ena (Enable the management port)

>> # /cfg/sys/mmgmt/ntp mgmt (Select the management port for NTP)

>> Management Port # radius mgmt (Select the management port for

radius)

>> Management Port # syslog mgmt (Select the management port for

syslog)


NOTE – The default for TFTP can be overridden by using the – data or – mgmt option after a

ti ti t f t f td d




gtimg, ptimg, gtcfg, ptcfg, or ptdmp command.

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

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

>> Management Port # cur (View current settings)

>> Management Port # save (Save for restore after reboot)



315394-J, January 200549

CHAPTER 2

Securing the Switch

Secure switch management is necessary for environments in which significant management

functions are performed across the Internet. The following topics are addressed in this section:

“Protecting Switch-Owned Addresses from Attacks” on page 49

“Setting Allowable Source IP Address Ranges for Switch Management” on page 52

“RADIUS Authentication and Authorization” on page 53

“TACACS+ Authentication” on page 58

“Secure Shell and Secure Copy” on page 61

“End User Access Control” on page 67

“Deny Routes” on page 72

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 Alteon 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 configured limit has been reached, packets will be dropped. Themaximum rate (packets per second) can be configured differently for each of the supported

protocols.


How Different Protocols Attack the Switch

With t th t id t li iti d bl d th f ll i t l k t d



315394-J, January 200550 Chapter 2: Securing the Switch

Without the system-wide rate limiting commands enabled, the following protocol packets des-

tined to a switch-owned management interface could potentially overwhelm its management

processor’s 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 address—including Telnet

sessions, HTTP requests via the Browser-Based Interface, and BGP peer connections to

the switch. “TCP Rate Limiting” on page 549 should also be configured to limit TCP

packets destined to a switch virtual server IP (vip) address.

UDP packets sent to a switch interface address—including routing information protocol

(RIP) and simple network management protocol (SNMP) packets.

Configuring Denial of Service Protection

1. Set the rate limit for the desired protocol.

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

3. Apply and save the configuration.

>> /cfg/sys/access/rlimitEnter protocol [arp|icmp|tcp|udp]: arpCurrent max rate: 0Enter new max rate: 1000 (Set rate to 1000 packets per second)


Viewing Dropped Packets

You can view the number of dropped packets for each protocol which is configured for sys



315394-J, January 2005Chapter 2: Securing the Switch 51

You can view the number of dropped packets for each protocol which is configured for sys-

tem-wide rate limiting. The information is available on a per-switch processor (SP) basis by

entering the following command:

>> Main# stats/sp/maintEnter SP number: (1-4) 2------------------------------------------------------------------Maintenance statistics for SP 2: Receive Letter success from MP: 2295509 Receive Letter success from SP 1: 0 Receive Letter success from SP 3: 0 : (Protocol-based discards are shown at the bottom of the screen)

arpDiscards: 0 icmpDiscards: 1482tcpDiscards: 68 udpDiscards: 351


Setting Allowable Source IP Address

Ranges for Switch Management




Ranges for Switch Management

To limit access to the switch without having to configure filters for each switch port, you can

set a source IP address (or range) that will be allowed to connect to the switch IP interface

through Telnet, SSH, SNMP, or the Alteon OS Browser-Based Interface (BBI). This will also

help to prevent spoofing or attacks on the switch’s TCP/IP stack.

When an IP packet reaches the application switch, the source IP address is checked against

range of addresses defined 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 packetaddressed to a switch IP interface with a source IP address outside this range is discarded.

Up to five management IP address and mask pairs can be configured on the switch. For exam-

ple, to define a range of allowed source IP addresses between 192.192.192.1 to

192.192.192.127, enter the following:

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 defined range and

would be allowed to access the switch.

A host with a source IP address of 192.192.192.192 falls outside the defined range and isnot granted access. To make this source IP address valid, you would need to shift the host

to an IP address within the valid range specified 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).

>> Main# /cfg/sys/access/mgmt add

Enter Management Network Address:192.192.192.0Enter Management Network Mask: 255.255.255.128


RADIUS Authentication and Authorization




Alteon OS 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 switch—is 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 in Alteon OS

Alteon OS supports the following Radius authentication features:

Supports Radius client on the switch, based on the protocol definitions 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 authen-

tication server. Use the /cfg/sys/radius/cur command to show the currently

active RADIUS authentication server.

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

Time-out value = 1-10 seconds

Retries = 1-3

The switch will time out if it does not receive a response from the RADIUS server in 1-3

retries. The switch will also automatically retry connecting to the RADIUS server before it

declares the server down.

Supports user-configurable RADIUS application port.

The default is 1645/UDP-based on RFC 2138. Port 1812 is also supported.

Allows network administrator to define privileges for one or more specific users to access

the switch at the RADIUS user database.

Supports SecurID if the RADIUS server can do an ACE/Server client proxy. The pass-

word is the PIN number, plus the token code of the SecurID card.


How Radius Authentication Works

In Figure 2-1, the Alteon Application Switch—acting as the RADIUS client—communicates




g pp g

to the RADIUS server to authenticate and authorize a remote administrator using the protocol

definitions specified in RFC 2138 and 2866. Transactions between the client and the RADIUSserver 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.

Figure 2-1 RADIUS Authentication and Authorization: How It Works

1. Remote administrator connects to the switch and provides user name and password.

2. Using Authentication/Authorization protocol, the switch sends request to authentication

server.

3. Authentication server checks the request against the user ID database.

4. Using RADIUS protocol, the authentication server instructs the switch to grant or deny

administrative access.

Internet

1. Remote administrator connects to

switch and provides user name

and password

2. Using Authentication/Authorization

protocol, the switch sends request

to authentication server

3. Authentication server

checks request against

the user ID database

4. Using RADIUS protocol,

the authentication serverinstructs the switch to

grant or deny admim access

Authentication

Servers

Alteon Application Switch


Configuring RADIUS Authentication on the Switch

1. Turn RADIUS authentication on, then configure the Primary and Secondary RADIUS




, g y y

servers.

2. Configure the RADIUS secret.

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

The well-known port for RADIUS is 1645.

4. Configure the number retry attempts for contacting the RADIUS server, and the timeout

period.


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

>> RADIUS Server# on (Turn RADIUS on)

Current status: OFFNew status: ON>> RADIUS Server# prisrv 10.10.1.1 (Enter primary server IP)

Current primary RADIUS server: 0.0.0.0New pending primary RADIUS server: 10.10.1.1>> RADIUS Server# secsrv 10.10.1.2 (Enter secondary server IP)

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

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

!CAUTION—If you configure the RADIUS secret using any method other than a direct console

connection, the secret may be transmitted over the network as clear text.

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

>> RADIUS Server# retriesCurrent RADIUS server retries: 3Enter new RADIUS server retries [1-3]: < server retries>

>> RADIUS Server# timeCurrent RADIUS server timeout: 3Enter new RADIUS server timeout [1-10]: 10 (Enter the timeout period in minutes)


Switch User Accounts

The user accounts listed in Table 2-1 are provided as a reference here for understanding user




levels that can be defined in the RADIUS server dictionary file (see page 57), or for defining

Class of Service for the End User Access Control feature (see page 67).

Table 2-1 Alteon OS User Accounts and Access Levels

User Account Description and Tasks Performed Password

User 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.

user

SLB Operator 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.

slboper

Layer 4 Operator 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 managingtraffic on the line leading to the shared Internet services.

l4oper

Operator The Operator manages all functions of the switch. In addition to

SLB Operator functions, the Operator can reset ports or the

entire switch.

oper

SLB Administrator 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 param-

eters on the SLB menus, with the exception of not being able to

configure filters or bandwidth management.

slbadmin

Layer 4 Administrator 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 config-

ure all parameters on the SLB menus, including filters and band-

width management.

l4admin

Administrator The super-user Administrator has complete access to all menus,

information, and configuration commands on the switch, includ-

ing the ability to change both the user and administrator pass-

words.

admin


RADIUS Attributes for Alteon OS User Privileges

When the user logs in, the switch authenticates his/her level of access by sending the RADIUS

h i h li h i i h RADIUS h i i




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 will

verify 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 defined in the

RADIUS dictionary. Radius attribute 6 which is built into all Radius servers defines theadministrator. The file name of the dictionary is RADIUS vendor-dependent. The following

Radius attributes are defined for Alteon OS user privileges levels:

Table 2-2 Alteon OS-Proprietary Attributes for Radius

User Name/Access User-Service-Type Value

user Vendor-supplied 255

slboper Vendor-supplied 254

l4oper Vendor-supplied 253

oper Vendor-supplied 252

slbadmin Vendor-supplied 251

l4admin Vendor-supplied 250admin Vendor-supplied 6 (pre-defined)


TACACS+ Authentication

Alt OS t th ti ti d th i ti ith t k i th Ci S t




Alteon OS supports authentication and authorization with networks using the Cisco Systems

TACACS+ protocol. The Alteon Application Switch functions as the Network Access Server(NAS) by interacting with the remote client and initiating authentication and authorization ses-

sions with the TACACS+ access server. The remote user is defined as someone requiring man-

agement access to the Alteon 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 encryp-

tion in authentication requests.

TACACS+ separates authentication, authorization and accounting.

TACACS+

How TACACS+ Authentication Works

TACACS+ works much in the same way as RADIUS authentication as described on page 54.

1. Remote administrator connects to the switch and provides user name and password.

2. Using Authentication/Authorization protocol, the switch sends request to authentication

server.

3. Authentication server checks the request against the user ID database.

4. Using TACACS+ protocol, the authentication server instructs the switch to grant or deny

administrative access.

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 Alteon Application

Switch authenticates on a Kerberos server, it requests authorization information from a

TACACS+ server without requiring re-authentication. The Alteon 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 Alteon Application Switch

checks with a TACACS+ server to determine if the user is granted permission to use a particu-

lar command.




TACACS+ Authentication Features in Alteon OS

Authentication is the action of determining the identity of a user, and is generally done when

the user first attempts to log in to a device or gain access to its services. Alteon OS 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 user’s privileges on the device, and usually takes

place after authentication.

The mapping between TACACS+ authorization levels and Alteon OS management access lev-

els is shown in Table 2-3.

Table 2-3 Alteon OS-Proprietary Attributes for TACACS+

Alteon OS User Access Level TACACS+ level

user 0

slboper 1

l4oper 2

oper 3

slbadmin 4

l4admin 5

admin 6


Configuring TACACS+ Authentication on the Switch

1. Turn TACACS+ authentication on, then configure the Primary and Secondary

TACACS+ servers




TACACS+ servers.

2. Configure the TACACS+ secret.

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

The well-known port for TACACS+ is 49.

4. Configure the number retry attempts for contacting the TACACS+ server, and the time-

out period.


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

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

Current status: OFFNew status: ON>> TACACS+ Server# prisrv 10.10.1.1 (Enter primary server IP)

Current primary TACACS+ server: 0.0.0.0New pending primary TACACS+ server: 10.10.1.1>> TACACS+ Server# secsrv 10.10.1.2 (Enter secondary server IP)

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

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

!CAUTION—If you configure the TACACS+ secret using any method other than a direct con-

sole connection, the secret may be transmitted over the network as clear text.

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

>> TACACS+ Server# retriesCurrent TACACS+ server retries: 3Enter new TACACS+ server retries [1-3]: < server retries>

>> TACACS+ Server# timeCurrent TACACS+ server timeout: 3Enter new TACACS+ server timeout [1-10]: 10(Enter the timeout period in minutes)


Secure Shell and Secure Copy

The Telnet method of managing an Alteon Application Switch does not provide a secure con-




The Telnet method of managing an Alteon Application Switch does not provide a secure con

nection. Secure Shell (SSH) and Secure Copy (SCP) however, use secure tunnels so that mes-sages 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 files securely from one machine to another. SCP uses SSH for

encryption of data on the network. On an Alteon Application Switch, SCP is used to download

and upload the switch configuration via secure channels.

The Alteon OS implementation of SSH supports both versions 1.5 and 2.0. and supports SSH

clients version 1.5—2.x. The following SSH clients have been tested:

SSH 1.2.23 and SSH 1.2.27 for Linux (freeware)

SecureCRT 3.0.2 and SecureCRT 3.0.3 for Windows NT (Van 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 connec-

tions.

Configuring SSH/SCP features on the switchSSH/SCP parameters can be configured via the console port only, using the CLI. However,

SCP putcfg and TFTP getcfg can also change the SSH/SCP configuration. When SSH is

enabled, SCP is also enabled. The switch SSH daemon uses TCP port 22 only and is not con-

figurable.

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:

# / f / / hd/ (Turn SSH on)




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:

Configuring the SCP Administrator Password

To configure the scpadm (SCP Administrator) password, first connect to the switch via the

RS-232 management console. For security reasons, the scpadm password may only be config-

ured when connected directly to the switch console.

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

Current status: OFFNew status: ON

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

Current status: ON

New status: OFF

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

SSHD# apply (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 don't rebootthe box immediately. RSA server key generation starts............................................................RSA server key generation completes (lasts 75503 ms)RSA server key is being saved to Flash ROM, please don't rebootthe box immediately.------------------------------------------------------------------Apply complete; don't forget to "save" updated configuration.

>> # /cfg/sys/sshd/dis (Disable SSH/SCP apply and save)


To configure the password, enter the following command via the CLI. At factory default set-

tings, the current SCP administrator password is admin.

>> /cfg/sys/sshd/scpadm




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 switch’s configuration to the remote host via SCP.

putcfg is used to upload the switch’s configuration from a remote host to the switch; the

diff command is automatically executed at the end of putcfg to notify the remote cli-

ent of the difference between the new and the current configurations.

putcfg_apply runs the apply command after the putcfg is done.

putcfg_apply_save saves the new configuration to the flash 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 use

205.178.15.157 as the IP address of a sample switch.

Logging into the switch:

Syntax:

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.

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


Example:

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




Downloading the switch configuration using SCP:

Syntax:

Example:

Uploading the configuration to the switch:

Syntax:

Example:

Applying and saving the configuration

The apply and save commands are still needed after the last command (scp ad4.cfg

205.178.15.157:putcfg). Or, instead, you can use the following commands:

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 configurations.

putcfg_apply runs the apply command after the putcfg is done.

putcfg_apply_save saves the new configuration to the flash 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.

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

>> # scp 205.178.15.157:getcfg ad4.cfg

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

>> # scp ad4.cfg 205.178.15.157:putcfg

>> # scp ad4.cfg 205.178.15.157:putcfg_apply>> # scp ad4.cfg 205.178.15.157:putcfg_apply_save


SSH and SCP Encryption of Management Messages

The following encryption and authentication methods are supported for SSH and SCP:

Server Host Authentication: Client RSA authenticates the switch at the beginning of




Server Host Authentication: Client RSA authenticates the switch at the beginning of

every connection

Key Exchange: RSA

Encryption: 3DES-CBC, DES

User Authentication: Local password authentication, RADIUS, SecurID (via

RADIUS, for SSH only—does 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 Alteon Application switch. The server key

is 768 bits and is used to make it impossible to decipher a captured session by breaking into the

Alteon switch at a later time.

When the SSH server is first enabled and applied, the switch automatically generates the RSA

host and server keys and is stored in the FLASH memory.

To configure RSA host and server keys, first connect to the switch via the console port. (com-

mands are not available via Telnet connection), and enter the following commands to generate

the keys manually

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

When the switch reboots, it will retrieve the host and server keys from the FLASH memory. If

these two keys are not available in the flash 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/sshd/hkeygen (Generates the host key)

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

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


The number of hours must range between 0–24. A value of 0 denotes that RSA server key

autogeneration is disabled. When greater than 0, the switch will autogenerate the RSA server

key every specified 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 Alteon switch will perform only one session of key/cipher generation at a time.

Thus, an SSH/SCP client will 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 will fail if

an SSH/SCP client is logging in at that time.

SSH/SCP Integration with Radius AuthenticationSSH/SCP is integrated with RADIUS authentication. After the RADIUS server is enabled on

the switch, all subsequent SSH authentication requests will be redirected to the specified

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 connec-

tion.

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 ses-

sion.

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 pass-

word (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 configure a regular administrator with a fixed password in the RADIUS server if

it can be supported. A regular administrator with a fixed password in the RADIUS server

can perform both SSH and SCP with no additional authentication required.

Using an SCP-only administrator password.




g y p

Use the command, /cfg/sys/sshd/scpadm to bypass the checking of SecurID.

An SCP-only administrator’s password is typically used when SecurID is used. For exam-

ple, it can be used in an automation program (in which the tokens of SecurID are not avail-

able) to back up (download) the switch configurations each day.

NOTE – The SCP-only administrator’s password must be different from the regular adminis-

trator’s password. If the two passwords are the same, the administrator using that passwordwill not be allowed to log in as a SSH user because the switch will recognize him as the SCP-

only administrator and only allow the administrator access to SCP commands.

Alternately, you can configure a regular administrator with a fixed password in the RADIUS

server if it can be supported. A regular administrator with a fixed password in the RADIUS

server can perform both SSH and SCP with no additional authentication required.

End User Access Control

Alteon OS allows an administrator to define end user accounts that permit end users to opera-

tionally act on their own real servers via the switch CLI commands. Once end user accounts

are configured and enabled, the switch will require 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 Configuring End User Accounts

Only one user ID can be assigned to a real server resource to enable or disable a realserver. Consequently, a single end user may be assigned the maximum number of real

servers that can be configured 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 will not automatically vali-

date configurations. The criterion for displaying virtual service information for end users

will be based on the validation of ownership of the first real server in the group for a given




virtual server port.

Alteon OS 22.0 supports end user support for Console and Telnet access to the switch. As

a result, only very limited access will be 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 Alteon Application Switch. Also note that the password change

command on the switch ONLY modifies 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.

User Access Control Menu

The end user access control menu is located in the System access menu.

Setting up User IDs

Up to 10 user IDs can be configured.

>> # /cfg/sys/access/user

/cfg/sys/access/user/uid 1


Defining User Names and Passwords

>> User ID 1 # name jane (Assign name “jane” to user ID 1)

Current user name:New user name: jane




Changing Passwords

Defining a User’s 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 Table 2-1“Alteon OS User Accounts and Access Levels” on page 56.

To change the user’s level, enter the class of service cos command, and select one of the fol-

lowing options:

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 can-

not be assigned to any other user.

>> User ID 1 # passwdChanging 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.

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

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


Validating a User’s Configuration

User ID 2 # cur name jane , dis, cos user , password valid, offline real servers:




Listing Current Users

The cur command displays defined user accounts and whether or not each user is currentlylogged into the switch.

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

# /cfg/sys/access/user/cur

Usernames: user - Enabled slboper - Disabled l4oper - Disabled oper - Disabled slbadmin - Disabled l4admin - Disabled admin - Always Enabled

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 will recognize and permit login under

the account. Once enabled, the switch will require any user to enter both username and pass-

d




word.

Logging into an End User Account

Once an end user account is configured and enabled, the user can login to the switch username/

password combination. The level of switch access will be determined by the CoS establishedfor the end user account.

Performing Operational Commands on Real Servers

when Logged Into an End User Account

The operational commands available to the end user are dependent on the CoS level of access

(i.e, user, slboper, l4oper, oper, slbadmin, l4admin, admin). Only end users with a

CoS of user are restricted to operational commands on real servers assigned to them. End

users with a CoS lever higher than user can perform operational commands on any configured

real servers.

Operationally disable real servers

Operationally enable real servers

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

>> # /oper/slb/real <#>/dis

>> # /oper/slb/real <#> ena


Deny Routes

A deny route, or black hole route, can be configured to deny Layer 3 routable packets to desti-

nations covered by a static route A deny route is created by setting the gateway address in a




nations covered by a static route. A deny route is created by setting the gateway address in astatic route to 0. If the longest prefix match route (which is obtained via route lookup) is deny

route, the packet will be dropped.

A deny route may be configured when an administrator finds a specific user or network that is

under attack. For example, IP addresses in the 62.x.x.x network are under attack from an

unknown source. The Alteon Application Switch can be configured temporarily with a deny

route so that any traffic destined to this network is dropped. In the meantime the attack pattern

and source can be detected.

This feature is similar to a deny filter, except that it will work only on routable Layer 3 traffic;

it will not deny Layer 2 traffic.

Configuring a Deny Route

To deny traffic to the destination network 62.62.0.0, enter the following commands.

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

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

Enter destination IP address: 62.62.0.0 (Of this IP network address)

Enter destination subnet mask: 255.255.0.0(And this 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 don’t enter one here.)

!CAUTION—Do not configure a deny route that covers the destination/mask pair of an existing

IP interface’s 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 traffic to the interface as well as the sub-

net will be denied—which 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 rout-

ing table in bold.

Status code: * - best




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* 62.62.0.0 255.255.0.0 0.0.0.0 deny static





C 3



315394-J, January 200575

CHAPTER 3

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 man-ageable 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” on page 76

“VLAN Tagging” on page 76

“VLANs and the IP Interfaces” on page 77

This section briefly 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” on page 77

This section discusses how you can logically connect users and segments to a host that

supports many logical segments or subnets by using the flexibility of the multiple VLAN

system.

“VLANs and Default Gateways” on page 81

NOTE – Basic VLANs can be configured during initial switch configuration (see “Using the

Setup Utility” in the Alteon OS Command Reference). More comprehensive VLAN configura-

tion can be done from the Command Line Interface (see “VLAN Configuration” as well as

“Port Configuration” in the Alteon OS Command Reference).


VLAN ID Numbers

Alteon OS supports up to 255 VLANs per switch. Even though the maximum number of

VLANs supported at any given time is 255, each can be identified with any number between 1

and 4090



315394-J, January 200576 Chapter 3: VLANs

and 4090.

VLANs are defined 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” on page 76).

Each port in the switch has a configurable default VLAN number, known as its PVID. The fac-

tory default value for all PVIDs is 1. This places all ports on the same VLAN initially,

although each port’s PVID is configurable to any VLAN number between 1 and 4090.

Any untagged frames (those with no VLAN specified) are classified with the sending port’s

PVID.

VLAN TaggingAlteon OS software supports 802.1Q VLAN tagging, providing standards-based VLAN sup-

port for Ethernet systems.

Tagging places the VLAN identifier in the frame header, allowing multiple VLANs per port.

When you configure 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.



315394-J, January 2005Chapter 3: VLANs 77

You can access the switch for remote configuration, trap messages, and other management

functions only from stations on VLANs that include an IP interface to the switch (see “IP Inter-

face Menu” section in the Alteon OS Command Reference). Likewise, you can cut off access to

management functions to any VLAN by excluding IP interfaces from the VLAN’s member-

ship.

For example, if all IP interfaces are left on VLAN 1 (the default), and all ports are configured

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 Alteon OS software has a single VLAN configured on every port. This config-

uration 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 configured

per port.

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. Alteon

Application Switches and VLAN-tagging server adapters support multiple VLANS on a per- port or per-interface basis, allowing very flexible configurations.

You can configure multiple VLANs on a single VLAN-tagging server adapter, with each

VLAN being configured through a logical interface and logical IP address on the host system.

Each VLAN configured on the server adapter must also be configured on the switch port to

which it is connected. If multiple VLANs are configured on the port, tagging must be turned

on.

Using this flexible 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

Server #1

VLAN #3

Server #2

Gigabit/Tagged

adapter

(All VLANs)




Figure 3-1 Example 1: Multiple VLANs with VLAN-Tagged Gigabit Adapters

The features of this VLAN are described below:

Component Description

Application

Switch

This switch is configured for three VLANs that represent three differ-

ent IP subnets. Two servers and five clients are attached to the switch.

Server #1 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.

Server #2 This high-use server needs to be accessed from all VLANs and IP sub-

nets. The server has a VLAN-tagging adapter installed with VLAN tag-

ging turned on. The adapter is attached to one of the application

switch's 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.

PC #1

VLAN #2

PC #2

VLAN #2

PC #3

VLAN #1

PC #4

VLAN #3

PC #5

Gigabit/Taggedadapter

VLANs #1 & #2

Shared Media



PCs #1 and #2 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.

Component Description




NOTE – VLAN tagging is required only on ports that are connected to other Alteon Applica-

tion Switches or on ports that connect to tag-capable end-stations, such as servers with VLAN-tagging adapters.

PC #3 A member of VLAN 1, this PC can minimize its broadcast domain to

Server 2 and PC 5.

PC #4 A member of VLAN 3, this PC can minimize its broadcast domain to

Server 1 and Server 2.

PC #5 A member of both VLAN 1 and VLAN 2, this PC has VLAN-taggingGigabit 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.


Example 2: Parallel Links with VLANs

Example 2 shows how it is possible, through the use of VLANs, to create configurations where

there are multiple links between two switches, without creating broadcast loops.

In Figure 3-2, two Alteon Application switches are connected with two different GigabitEthernet links Without VLANs this configuration would create a broadcast loop To prevent




Ethernet links. Without VLANs, this configuration would create a broadcast loop. To prevent

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.

Figure 3-2 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 Chapter 5, “Spanning Tree Protocol.”

Alteon Application Switch #1


Gigabit Ethernet Port 26

VLAN #32, VLAN #109

Gigabit Ethernet Port 25

VLAN #10, VLAN #22


VLANs and Default Gateways

Alteon OS allows you to assign different gateways for each VLAN. You can effectively map

multiple customers to specific gateways on a single switch. The benefits of segregating cus-

tomers to different default gateways are:




Resource optimization

Enhanced customer segmentation

Improved service differentiation

Segregating VLAN TrafficDeploy this feature in an environment where you want to segregate VLAN traffic to a config-

ured default gateway. In Figure 3-3, VLANs 2 and 3 have different routing requirements.

VLAN 2 is required to route traffic through default gateway 5 and VLAN 3 is required to route

traffic through default gateway 6.

Figure 3-3 Default Gateways per VLAN

You can configure up to 255 gateways with one gateway per VLAN with values starting from

5 through 259. If the gateways per VLAN fail, then traffic 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 specific gateway that has been assigned to a VLAN is down.

nortelnetworks.com

192.168.20.200

yahoo.com

200.1.2.200

VLAN 2 using Gateway 5

172.21.2.1

Internet

VLAN 3 using Gateway 6

172.21.3.1

Gateway 5: 10.10.1.20Gateway 6: 10.10.1.30

Gateway 1: 10.10.4.1

Router 2

VLAN 4

10.10.1.30

Router 3

VLAN 1

10.10.4.1

IF 1: 10.10.1.1

IF 2: 10.10.4.40

IF 3: 172.21.2.200

IF 4: 172.21.3.200

Router 1

VLAN 410.10.1.20

Alteon Application

Switch

26

725

827


In the example shown in Figure 3-3, if gateways 5 or 6 fail, then traffic is directed to default

gateway 1, which is configured with IP address 10.10.4.1. If default gateways 1 through 4 are

not configured 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 will display the entries in the route cache similar to those




dump on the switch command line will display the entries in the route cache similar to those

shown in Table 3-1. The destination IP addresses (see the last two rows) are associated with

the MAC addresses of the gateways.

As shown in Table 3-1, traffic from VLAN 2 uses Gateway 5 to access destination IP address

192.168.20.200. If traffic from VLAN 3 requests the same destination address, then traffic isrouted 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 con-

figured default Gateway.

Table 3-1 Route Cache Example

Destination IP

address

Flags MAC address VLAN Port Referenced

SPs

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

10.10.1.20 00:60:cf:44:cd:a0 4 25

(Gig)

empty

10.10.1.30 00:60:cf:42:3b:40 4 26

(Gig)

empty

10.10.4.1 00:60:cf:42:77:e0 1 27

(Gig)

empty

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

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

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

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

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

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

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


Configuring the Local Network

To completely segregate VLAN traffic to its own default gateway, you can configure the local

network addresses of the VLAN. This will ensure that all traffic from VLAN 2 is forwarded to

Gateway 5 and all traffic from VLAN 3 is forwarded to Gateway 6.

Typically, the switch routes traffic based on the routes in the routing table. The routing table




will contain an entry of the configured local network with the default gateway. The route cache

will not contain the route entry. This configuration provides a more secure environment, but

affects performance if the routing table is close to its maximum capacity.

Configuring Gateways per VLAN

Follow this procedure to configure the example shown in Figure 3-3 on page 81:

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

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

>> /cfg/l3/if 1 (Select IP interface 1 for gateway 5 &

6 subnet)

>> IP Interface 1# addr 10.10.1.1 (Assign IP address for interface 1)>> IP Interface 1# mask 255.255.255.0 (Assign mask for IF 1)

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

>> IP Interface 1# /cfg/l3/if 2 (Select IP interface 2 for gateway 1)

>> IP Interface 2# addr 10.10.4.40 (Assign IP address for interface 2)

>> IP Interface 2# mask 255.255.255.0 (Assign mask for IF 2)


>> IP Interface 2# /cfg/l3/if 3 (Select IP interface 3 for VLAN 2

subnet)




>> IP Interface 3# /cfg/l3/if 4 (Select IP interface 4 for VLAN 3)

subnet)





3. Configure the default gateways.

Configuring gateways 5 and 6 for VLANs 2 and 3 respectively. Configure default gateway 1

for load balancing session requests and as backup when gateways 5 and 6 fail.

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

>> Default gateway 5# addr 10.10.1.20 (Assign IP address for gateway 5)

>> Default gateway 5# /cfg/l3/gw 6 (Select default gateway 6)




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 configure two default gateways with the same IP

address for two different VLANs.

4. Add the VLANs to the gateways and enable them.

5. Apply and verify your configuration.

6. (Optional) Configure the local networks using address and mask pairs to ensure that the

VLANs use the configured default gateways.

7. Apply and save your new configuration changes.




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

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

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

>> Default gateway 5# /cfg/l3/gw 6 (Select gateway 6)

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

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


>> Default gateway 1# ena (Enable gateway 1 for all VLAN s)

>> Default gateway 1# /cfg/l3/cur (View current L3 settings)

>> Default gateway 1# /cfg/l3/frwd/local (Select the local network Menu)

>> IP Forwarding# add 10.10.0.0 255.255.0.0 (Specify the network for routers 1, 2, & 3)

>> IP Forwarding# add 172.21.2.0 255.255.255.0(Specify the network for VLAN 2)>> IP Forwarding# add 172.21.3.0 255.255.255.0(Specify the network for VLAN 3)

>> IP Forwarding# apply

>> IP Forwarding# save


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 Alteon application

switches running operating Alteon OS 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




g y g j

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 down-

link ports. For information on uplink vs. downlink ports on your particular switch model,

please read your Alteon Application Switch Hardware Installation Guide.

Jumbo frames is not supported if Bandwidth Management is enabled on the switch.

Isolating Jumbo Frame Traffic using VLANs

Jumbo frame traffic must not be used on a VLAN where there is any device that cannot process

frame sizes larger than Ethernet maximum frame size. On Alteon 2000 and 3000 series appli-

cation switches, additional VLANs can be configured on the adapters and switches to support

non-jumbo frame VLANs for servers and workstations that do not support extended frame

sizes. End-stations installed with jumbo frames-capable Gigabit adapters, and attached toapplication switches can communicate across both the jumbo frame VLANs and regular frame

VLANs at the same time.

In the example illustrated in Figure 3-4 on page 86, 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 configured for half-duplex mode.


Jumbo Frame

VLAN




Figure 3-4 Jumbo Frame VLANs

Configuring VLANs for Jumbo and Non-Jumbo FramesTo configure an Alteon 2424 for jumbo and non-jumbo frame traffic, configure two VLANs:

Normal Frame

VLAN

Normal Frame

VLAN


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

>> Main# /cfg/l2/vlan 2

VLAN number 2 with name "VLAN 2" created.

------------------------------------------------------------[VLAN 2 Menu] name - Set VLAN name




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

stg - Assign VLAN to a Spanning Tree Group cont - Set BW contract add - Add port to VLAN rem - Remove port from VLAN def - Define VLAN as list of ports jumbo - Enable/disable Jumbo Frame support

learn - Enable/disable smac learning ena - Enable VLAN dis - Disable VLAN del - Delete VLAN cur - Display current VLAN configuration

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

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

>> VLAN 2#

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

>> apply>> save





CHAPTER 4

Port Trunking



315394-J, January 200589

Port Trunking

Trunk groups can provide super-bandwidth, multi-link connections between Alteon Applica-

tion 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

configuration background and examples for trunking multiple ports together either in a static

(manually configured) trunk group, or dynamic trunk group using Link Aggregation Control

Protocol.


“Overview” on this page

“Static Port Trunking Example” on page 92

“Link Aggregation Control Protocol Trunking” on page 95


Overview

When using port trunk groups between two Alteon Application Switches as shown in Figure

4-1, 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.



315394-J, January 200590 Chapter 4: Port Trunking

Figure 4-1 Port Trunk Group

Trunk groups are also useful for connecting an Alteon Application Switch to third-party

devices that support link aggregation, such as Cisco routers and switches with EtherChannel

technology (not ISL trunking technology) and Sun's Quad Fast Ethernet Adapter. Nortel Net-

works trunk group technology is compatible with these devices when they are configured man-

ually.

Statistical Load Distribution

Network traffic is statistically load balanced between the ports in a trunk group. The Alteon

OS-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 traffic distribution

in trunk groups. In some port trunking systems, only Layer 2 MAC addresses are considered inthe distribution algorithm. Each packet’s 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 traffic distribution becomes relatively

even. In some topologies, however, only a limited number of Layer 2 devices (such as a hand-

ful of routers and servers) feed the trunk lines. When this occurs, the limited number of MAC

address combinations encountered results in a lopsided traffic distribution, which can reduce

the effective combined bandwidth of the trunked ports.

Aggregate

Port Trunk




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



315394-J, January 2005Chapter 4: Port Trunking 91

g

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 XOR'ed

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 Alteon switches including Alteon 180 and AD

series, Alteon Switched Firewall Accelerator, and Alteon 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

For L2 forwarding of IP frames:A = lower 16 bits of source IP address

B = lower 32 bits of source MAC address

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

A = lower 32 bits of destination IP

B = lower 16 bits of source MAC

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

A = lower 32 bits of source IP

B = lower 16 bits of destination MAC

NOTE – L4 trunk hashing is currently supported only in Alteon OS 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 Alteon Application Switches.

Figure 4-2 Port Trunk Group Configuration Example

Prior to configuring each switch in the above example, you must connect to the appropriate

switch’s Command Line Interface (CLI) as the administrator.

NOTE – For details about accessing and using any of the menu commands described in this

example, see the Alteon OS Command Reference.



Trunk 1: Ports 2, 12, and 25 on Switch 1

Trunk 3: Ports 6, 11, and 26 on Switch 2

6

2 12

26

25

11


In this example, two Alteon Application Switches are used. If a third-party device supporting

link aggregation is used (such as Cisco routers and switches with EtherChannel technology or

Sun's Quad Fast Ethernet Adapter), trunk groups on the third-party device should be config-

ured manually. Connection problems could arise when using automatic trunk group negotia-

tion 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




1. Connect the switch ports that will be involved in the trunk group.

2. On application switch 1, define a trunk group.

3. Apply and verify the configuration.

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

4. Save your new configuration changes.

5. Repeat the process on application switch 2.

! individual ports belonging to any trunk group.

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

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



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

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

>> Trunk group 1# cur (View current trunking configuration)

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

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




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

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

>> Trunk group 3# cur (View current trunking configuration)

>> Trunk group 3# save (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.

f i b h i h fi d k ill b di l d k h

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




Information about each port in each configured trunk group will be 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 configured for

the same speed.

Trunking from non-Alteon devices must comply with Cisco® EtherChannel® technology.


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, traffic is reassigneddynamically 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. Please refer to IEEE

802.3ad-2002 for full description of the standard.

When using LACP, any trunk groups you may have already configured according to the man-

ual procedure described in “Static Port Trunking Example” on page 92 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 1–12, and LACP

trunks use IDs 13 through 40.

The Alteon OS 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 configured in a trunk. The switch will automatically

assign any non-trunked LACP-configured ports as standby ports for the LACP trunk. If any ofthe eight primary LACP ports fails, the switch will dynamically replace it with the standby

port.

The Alteon 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 will

be 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 Table 4-1.

Table 4-1 Actor vs. Partner LACP configuration

Actor Switch Partner Switch 1

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





In the configuration shown in Table 4-1, Actor switch ports 1-4 can aggregate to form an

LACP trunk group with the Partner switch ports 1-4. Please note that port admin key value has

local significance 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 Alteon Application Switch can have one of the following LACP modes.

off (default)

The ser can config re this port into a reg lar static tr nk gro p




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

active

The port is capable of forming an LACP trunk. This port sends LACPDU packets to part-

ner 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 port’s 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 port’s LACP mode to active to activate LACP negotiation.

You can set other port’s LACP mode to passive, to reduce the amount of LACPDU traffic, at

the initial trunk-forming stage.

NOTE – LACP implementation in Alteon OS 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. Please refer to 802.3ad-2002 for details.


Configuring LACP

Use the following procedure to configure LACP for port 1 through port 4 for the actor switch

to participate in link aggregation.

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

1. Set the LACP mode on port 1.

# / f /l2/l / t 1/ d (S l t t 1 f LACP d f ti )




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

trunk group.

3. Set the LACP mode on ports 2 to 4.

4. Define the admin key on ports 2 to 4.



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

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

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

>> # /cfg/l2/lacp/port 1/adminkey 100 (Set port 1 adminkey to 100)

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

>> # /cfg/l2/lacp/port 2/mode active (Select port 2 mode of operation)



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

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

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

>> LACP port 4# cur (View current trunking configuration)

>> LACP port 4# save (Save for restore after reboot)





CHAPTER 5

Spanning Tree Protocol



315394-J, January 200599

When multiple paths exist on a network, Spanning Tree Protocol (STP) configures the network

so that a switch uses only the most efficient path.


“Overview” on page 100

“Bridge Protocol Data Units (BPDUs)” on page 101

“Spanning Tree Group Configuration Guidelines” on page 103

“Multiple Spanning Trees” on page 106


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 configures the network so that a switch uses only the most efficient path.If that path fails, Spanning Tree automatically sets up another active path on the network to

sustain network operations.



315394-J, January 2005100 Chapter 5: Spanning Tree Protocol

The relationship between port, trunk groups, VLANs, and Spanning Trees is shown in

Table 5-1.

NOTE – Due to Spanning Tree’s 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” on page 509.

Table 5-1 Ports, Trunk Groups, and VLANs

Switch Element Belongs to

Port Trunk group

or

One or more VLANs

Trunk group One or more VLANs

VLAN One Spanning Tree group


Bridge Protocol Data Units (BPDUs)

To create a Spanning Tree, the application switch generates a configuration 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 networkthrough an exchange of BPDUs.

A BPDU is a 64-byte packet that is sent out at a configurable interval, which is typically set for



315394-J, January 2005Chapter 5: Spanning Tree Protocol 101

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 will transmit. 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 infor-

mation 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 efficient path for forwarding.

For more information on bridge priority, port priority, and port cost, refer to the Alteon OS

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-Mbpslink 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, configure the bridge priority lower than all other switches and

bridges on your network. The lower the value, the higher the bridge priority. The bridge prior-

ity is configured using the /cfg/l2/stg/brg/prior command in the CLI.


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 configured 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




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 indicatesthat the default cost will be computed for an auto-negotiated link speed.

Spanning Tree Compatibility between Cisco and Nortel

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 aBPDU. 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 Alteon 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 Alteon Application Switch when it isconnected it to a Nortel product that uses tagging. Use the following commands to enable

Nortel tagged BPDU format:

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

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


Spanning Tree Group Configuration

Guidelines

This section provides important information on configuring Spanning Tree Groups (STGs):

Adding a VLAN to a Spanning Tree Group

If VLAN i b d h d f l VLAN 1 “C i VLAN” 103 f




If no VLANs exist beyond the default VLAN 1, see “Creating a VLAN” on page 103 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

You cannot delete or move VLAN1 from STG1.

VLANs must be contained within a single STG; a VLAN cannot span multiple STGs. By

confining VLANs within a single STG, you avoid problems with spanning tree blocking

ports and causing a loss of connectivity within the VLAN. When a VLAN spans multiple

switches, the VLAN must be within the same spanning tree group (have the same STG ID)

across all the switches.

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 distin-

guish the BPDUs of one STG from those of another STG.

An untagged port cannot span multiple STGs.

Adding and removing ports from 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 will not be 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 will become part of STG1.

If you add untagged port 5 (which is a member to STG2) to STG1, the switch will prompt

you to change the PVID from 2 to 1:

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.

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


Spanning Tree Implementations in Trunk Groups

In both Cisco and Nortel spanning tree implementation as described in “Spanning Tree

Compatibility between Cisco and Nortel BPDU Formats” on page 102, the

trunking methodology applies for both the default and non-default spanning tree groups.

Make surethat all members of the trunk group are configured 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 configured 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, first remove individual members from the trunk group before

changing their spanning tree parameters.


Multiple Spanning Trees

Alteon OS supports up to 16 instances of Spanning Trees or Spanning Tree groups. Each

VLAN can be placed in only one Spanning Tree group per switch except for the default Span-

ning Tree group (STG 1). The default Spanning Tree group (1) can have more than one VLAN.All other Spanning Tree groups (2-16) can have only one VLAN associated with it. Spanning

Tree can be enabled or disabled for each port. Multiple Spanning Trees can be enabled on

tagged or untagged ports.




NOTE – By default, all newly created VLANs are members of Spanning Tree Group 1.

Why Do We Need Multiple Spanning Trees?

Figure 5-1 shows a simple example of why we need multiple Spanning Trees. Two VLANs,

VLAN 1 and VLAN 100 exist between Alteon Application Switch A and Alteon 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 instancesof Spanning Tree separate the topology without forming a loop. Both VLANs can forward

packets between the application switches without losing connectivity.

Figure 5-1 Multiple Instances of Spanning Tree Protocol

Spanning Tree Group 1: VLAN 1

Spanning Tree Group 2: VLAN 100

VLAN 1

VLAN 100 Alteon Application

Switch B

Alteon Application

Switch A


Four-Switch Topology with a Single Spanning Tree

In the four-switch topology example shown in Figure 5-2 on page 107, and assuming Alteon

switch A has a higher priority, you can have at least three loops on the network:

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

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

Data flowing 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 Figure 5-2 you will have two links




With a single Spanning Tree environment, as shown in Figure 5-2, you will have two links

blocked to prevent loops on the network. It is possible that the blocks may be between applica-

tion switches C and D and between application switches B and C, depending on the bridge pri-

ority, port priority, and port cost. The two blocks would prevent looping on the network, butthe blocked link between application switches B and C will inadvertently isolate VLAN 3 alto-

gether.

NOTE – For more information on bridge priority, port priority, and port cost see the Alteon OS

Command Reference.

Figure 5-2 VLAN 3 Isolated in a Single Spanning Tree Group

STG 1

V L A N

1

V L A N 1

V L A N 2

V L A N

3

Alteon Application

Switch B

Alteon Application

Switch C

Alteon Application

Switch D

Alteon Application

Switch A

V L A

N

1

Blocked Port


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.

Figure 5-3 shows the same four-switch topology as in Figure 5-2 on page 107, but with multi-

ple Spanning Trees enabled. The VLANs are identified on each of the three shaded areas con-

necting 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.

Alteon Application




Figure 5-3 Implementing Multiple Spanning Tree Groups

STG 1

STG 1

VLAN 1

Alteon Application

Switch B

Alteon Application

Switch A

VLAN 2

VLAN 3

Port 1

Port 1

Port 1

Port 2

Port 2

Port 8

STG 2Port 8

Port 1STG 1

Port 8STG 2

Port 8

STG 2STG 1

Alteon Application

Switch D

Alteon Application

Switch C


Three instances of Spanning Tree are configured in the example shown in Figure 5-3. Refer to

Table 5-2 on page 109 to identify the Spanning Tree group a VLAN is participating in for each

switch.

Table 5-2 Multiple Spanning Tree Groups per VLAN

VLAN 1 VLAN 2 VLAN 3

Alteon Applica-

tion

Switch A

Spanning Tree Group

1

Ports 1 and 2

Spanning Tree Group

2

Port 8




Switch-Centric Spanning Tree Protocol

In Figure 5-3 on page 108, VLAN 2 is shared by application switch A and B on ports 8 and 1

respectively. Alteon Application Switch A identifies VLAN 2 in Spanning Tree group 2 and

application switch B identifies VLAN 2 in Spanning Tree group 1. Spanning Tree group is

switch-centric—it 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 configuration of that switch.

Alteon Applica-

tion

Switch B

Spanning Tree Group

1

Port 1

Spanning Tree Group

2

Port 8

Alteon Applica-

tion

Switch C

Spanning Tree Group

1

Ports 1 and 2

Spanning Tree Group

2 Port 8

Alteon Applica-

tion

Switch D

Spanning Tree Group

1

Ports 1 and 8


VLAN Participation in Spanning Tree Groups

The VLAN participation for each Spanning Tree group in Figure 5-3 on page 108 is discussed

in the following sections:

VLAN 1 Participation

If application switch A is the root bridge, then application switch A will transmit the

BPDU for VLAN 1 on ports 1 and 2. Alteon Application Switch C receives the BPDU on

its port 2 and application switch D receives the BPDU on its port 1. Alteon Application

Switch D will block port 8 or application switch C will block port 1 depending on the




information provided in the BPDU.


Alteon Application Switch A, the root bridge generates another BPDU for Spanning Tree

Group 2 and forwards it out from port 8. Alteon 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.


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 8. Alteon Application Switch C receives this BPDU on

port 8 and is identified as participating in VLAN 3, Spanning Tree group 2. Since applica-

tion 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.


Configuring Multiple Spanning Tree Groups

This configuration shows how to configure the three instances of Spanning Tree groups on the

application switches A, B, C, and D illustrated in Figure 5-3 on page 108.

By default Spanning Trees 2-15 are empty, and Spanning Tree Group 1 contains all configured

VLANs until individual VLANs are explicitly assigned to other Spanning Tree groups. You

can have only one VLAN per Spanning Tree group except for Spanning Tree group 1.

1. Configure the following on application switch A:

Add t 8 t VLAN 2 d d fi S i T 2 f VLAN 2




Add port 8 to VLAN 2 and define Spanning Tree group 2 for VLAN 2.

VLAN 2 is automatically removed from Spanning Tree Group 1.

2. Configure the following on application switch B:

Add port 1 to VLAN 2, port 8 to VLAN 3 and define Spanning Tree groups 2 for VLAN 3.

VLAN 3 is automatically removed from Spanning Tree group 1 and by default VLAN 2

remains in Spanning Tree group 1.

NOTE – Each instance of Spanning Tree group is enabled by default.

>> # /cfg/l2/vlan 2 (Select VLAN 2 menu)

>> VLAN 2# add 8 (Add port 8)>> VLAN 2# /cfg/l2/stg 2 (Select Spanning Tree Group 2)

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


>> VLAN 2# add 1 (Add port 1)

>> VLAN 2# /cfg/l2/vlan 3 (Select VLAN 3 menu)


>> VLAN 3# /cfg/l2/stg 2 (Select Spanning Tree Group 2)

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


3. Configure the following on application switch C:

Add port 8 to VLAN 3 and define Spanning Tree group 3 for VLAN 3.

VLAN 3 is automatically removed from Spanning Tree group 1 and by default VLAN 2

remains in Spanning Tree Group 1.



>> VLAN 3# /cfg/l2/stg 2 (Select Spanning Tree Group 2)>> Spanning Tree Group 2# add 3 (Add VLAN 3)




p g p

NOTE – Alteon Application Switch D does not require any special configuration for multiple

Spanning Trees, because it configured for the default Spanning Tree group (STG 1) only.



315394-J, January 2005

Part 2: IP RoutingThis section discusses Layer 3 switching functions. In addition to switching traffic at near line

rates, the application switch can perform multi-protocol routing. This section discusses basic

routing and advanced routing protocols:

Chapter 6, “Basic IP Routing”

Chapter 7, “Routing Information Protocol”

Chapter 8, “Border Gateway Protocol

Chapter 9, “Open Shortest Path First (OSPF)




315394-J, January 2005114 : IP Routing

CHAPTER 6

Basic IP Routing



315394-J, January 2005115

This chapter provides configuration background and examples for using the Alteon Application

Switch to perform IP routing functions.


“IP Routing Benefits” on page 116

“Routing Between IP Subnets” on page 116

“Example of Subnet Routing” on page 119

“Defining IP Address Ranges for the Local Route Cache” on page 123

“Dynamic Host Configuration Protocol” on page 124


IP Routing Benefits

The Alteon Application Switch uses a combination of configurable IP switch interfaces and IP

routing options. The switch IP routing capabilities provide the following benefits:

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 combina-

tion) to server subnets that are separate from backbone subnets.

Provides another means to invisibly introduce Jumbo frame technology into the server-

it h d t k b t ti ll f ti UDP J b f h ti t



315394-J, January 2005116 Chapter 6: Basic IP Routing

switched network by automatically fragmenting UDP Jumbo frames when routing to non-

Jumbo frame VLANs or subnets.

Provides the ability to route IP traffic between multiple Virtual Local Area Networks(VLANs) configured 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 areincreasingly intelligent. Alteon Application Switches are intelligent and fast enough to per-

form routing functions on a par with wire speed Layer 2 switching.

The combination of faster routing and switching in a single device provides another service—

it allows you to build versatile topologies that account for legacy configurations.


For example, consider the following topology migration:

Admin/Sales

Switch

Eng/Staff2/Sales

Switch

Admin. Subnet

Hub

Eng. Subnet

Hub



315394-J, January 2005Chapter 6: Basic IP Routing 117

Figure 6-1 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 flooded with cross-

subnet communication. This compromises efficiency 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.

Traffic to the router increases, increasing congestion.

Even if every end-station could be moved to better logical subnets (a daunting task), competi-tion for access to common server pools on different subnets still burdens the routers.

This problem is solved by using Alteon Application Switches with built-in IP routing capabili-

ties. Cross-subnet LAN traffic 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 reconfiguring each and every end-station with new IP addresses.

Server

Subnet

Router

Staff/Eng2

Switch

FDDI

Internet

Alteon Switch

Server

Subnet

Staff Subnet

Hub

Internet

FDDI Router


Take a closer look at the Alteon Application Switch in the following configuration example:

Second Floor

10/100 Client Subnet131.15.15.2-254

First Floor

10/100 Client Subnet100.20.10.2-254

1000 Mbps

Primary DefaultRouter: 205.21.17.1

100.20.10.1 131.15.15.1




Figure 6-2 Switch-Based Routing Topology

The Alteon Application Switch connects the Gigabit Ethernet and Fast Ethernet trunks from

various switched subnets throughout one building. Common servers are placed on another sub-

net 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 fills 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 Alteon Application Switch, routing between different

IP subnets can be accomplished entirely within the switch. This leaves the routers free to han-

dle inbound and outbound traffic for this group of subnets.

To make implementation even easier, UDP Jumbo frame traffic is automatically fragmented to

regular Ethernet frame sizes when routing to non-Jumbo frame VLANS or subnets. This auto-

matic frame conversion allows servers to communicate using Jumbo frames, all transparently

to the user.

1000 Mbps 100 Mbps

Alteon Application SwitchSecondary Default

Router: 205.21.17.2

Server Subnet:

206.30.15.2-254

IF#1 IF#4

IF#2 IF#3

IP Routing

205.21.17.3

131.15.15.1

206.30.15.1


Example of Subnet Routing

Prior to configuring, you must be connected to the switch Command Line Interface (CLI) as

the administrator.

NOTE – For details about accessing and using any of the menu commands described in this

example, see the Alteon OS Command Reference.

1. Assign an IP address (or document the existing one) for each real server, router, and cli-

ent orkstation




ent workstation.

In the example topology in Figure 6-2 on page 118, the following IP addresses are used:

2. 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:

Table 6-1 Subnet Routing Example: IP Address Assignments

Subnet Devices IP Addresses

1 Primary and Secondary Default Routers 205.21.17.1 and 205.21.17.2

2 First Floor Client Workstations 100.20.10.2-254

3 Second Floor Client Workstations 131.15.15.2-254

4 Common Servers 206.30.15.2-254

Table 6-2 Subnet Routing Example: IP Interface Assignments

Interface Devices IP Interface Address

IF 1 Primary and Secondary Default Routers 205.21.17.3

IF 2 First Floor Client Workstations 100.20.10.1

IF 3 Second Floor Client Workstations 131.15.15.1

IF 4 Common Servers 206.30.15.1


IP interfaces are configured using the following commands at the CLI:

>> # /cfg/l3/if 1 (Select IP interface 1)

>> IP Interface 1# addr 205.21.17.3 (Assign IP address for the interface)

>> IP Interface 1# ena (Enable IP interface 1)

>> IP Interface 1# /cfg/l3/if 2 (Select IP interface 2)










3. Set each server and workstation’s default gateway to the appropriate switch IP interface

(the one in the same subnet as the server or workstation).

4. Configure the default gateways to the routers’ addresses.

Configuring the default gateways allows the switch to send outbound traffic to the routers:

5. Enable, apply, and verify the configuration.

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




>> IP Interface 5# /cfg/l3/gw 1 (Select primary default gateway)

>> Default gateway 1# addr 205.21.17.1 (Assign IP address for primary router)

>> Default gateway 1# ena (Enable primary default gateway)

>> Default gateway 1# /cfg/l3/gw 2 (Select secondary default gateway)

>> Default gateway 2# addr 205.21.17.2 (Assign address for secondary router)

>> Default gateway 2# ena (Enable secondary default gateway)

>> Default gateway 2# /cfg/l3/fwrd (Select the IP Forwarding Menu)

>> IP Forwarding# on (Turn IP forwarding on)

>> IP Forwarding# apply (Make your changes active)

>> IP Forwarding# /cfg/l3/cur (View current IP settings)

>> IP# save (Save for restore after reboot)


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 cre-

ate one VLAN for the client trunks, one for the routers, and one for the servers.

In this example, you are adding to the previous configuration.

1. Determine which switch ports and IP interfaces belong to which VLANs.

The following table adds port and VLAN information:




2. Add the switch ports to their respective VLANs.

The VLANs shown in Table 6-3 are configured as follows:

Table 6-3 Subnet Routing Example: Optional VLAN Ports

VLAN Devices IP Interface Switch Port VLAN #

1 First Floor Client Workstations 2 1 1

Second Floor Client Workstations 3 2 1

2 Primary Default Router 1 3 2

Secondary Default Router 1 4 2

3 Common Servers 1 4 5 3

Common Servers 2 4 6 3

>> # /cfg/l2/vlan 1 (Select VLAN 1)>> VLAN 1# add port 1 (Add port for 1st floor to VLAN 1)

>> VLAN 1# add port 2 (Add port for 2nd floor to VLAN 1)

>> VLAN 1# ena (Enable VLAN 1)

>> VLAN 1# /cfg/l2/vlan 2 (Select VLAN 2)

>> VLAN 2# add port 3 (Add port for default router 1)

>> VLAN 2# add port 4 (Add port for default router 2)


>> VLAN 2# /cfg/l2/vlan 3 (Add port for default router 3)>> VLAN 3# add port 5 (Select VLAN 3)

>> VLAN 3# add port 6 (Select port for common server 1)



Each time you add a port to a VLAN, you may get the following prompt:

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 Table 6-3 on page 121, the settings are made as fol-

lows:

Port 4 is an untagged port and its current PVID is 1.Confirm changing PVID from 1 to 2 [ y/n]?







>> VLAN 3# /cfg/l3/if 1 (Select IP interface 1 for def. routers)

>> IP Interface 1# vlan 2 (Set to VLAN 2)>> IP Interface 1# /cfg/l3/if 2 (Select IP interface 2 for first floor)

>> IP Interface 2# vlan 1 (Set to VLAN 1)

>> IP Interface 2# /cfg/l3/if 3 (Select IP interface 3 for second floor)


>> IP Interface 3# /cfg/l3/if 4 (Select IP interface 4 for servers)


>> IP Interface 5# apply (Make your changes active)

>> IP Interface 5# /info/l2/vlan (View current VLAN information)

>> Layer 2# /info/port (View current port information)

>> Information# save (Save for restore after reboot)


Defining IP Address Ranges for the Local

Route Cache

A local route cache lets you use switch resources more efficiently. The local network address

and local network mask parameters (accessed via the /cfg/l3/frwd/local/add com-

mand) define a range of addresses that will be cached on the switch. The local network address

is used to define 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.




g

By default, the local network address and local network mask are both set to 0.0.0.0. This pro-duces 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 configure the parameters as shown in

the following example:

NOTE – Static routes must be configured within the configured range. All other addresses that

fall outside the defined range are forwarded to the default gateway.

Table 6-4 Local Routing Cache Address Ranges

Local Host Address Range Local Network Address Local Network Mask

0.0.0.0 - 127.255.255.255 0.0.0.0 128.0.0.0

128.0.0.0 - 128.255.255.255 128.0.0.0 128.0.0.0 or 255.0.0.0

205.32.0.0 - 205.32.255.255 205.32.0.0 255.255.0.0


Dynamic Host Configuration Protocol

Dynamic Host Configuration Protocol (DHCP) is a transport protocol that provides a frame-

work for automatically assigning IP addresses and configuration information to other IP hosts

or clients in a large TCP/IP network. Without DHCP, the IP address must be entered manuallyfor 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 differ-

ent 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 configuration parameters for client operation.

Built on the client/server model, DHCP allows hosts or clients on an IP network to obtain their

configurations from a DHCP server, thereby reducing network administration. The most sig-

nificant configuration the client receives from the server is its required IP address; (other

optional parameters include the “generic” file 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 onthe 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 Alteon 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 defines the methods through which clients can be assigned an IP address for a finite

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 configuration parameters it needs

to operate in the TCP/IP network.

In the DHCP environment, the Alteon 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




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 configured 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 desti-

nation IP (DIP) addresses. The request is then forwarded as a UDP Unicast MAC layer mes-

sage to two BOOTP servers whose IP addresses are configured 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 onwhich VLAN to send the server response to the client.


DHCP Relay Agent Configuration

To enable the Alteon Application switch to be the BOOTP forwarder, you need to configure

the DHCP/BOOTP server IP addresses on the switch. Generally, you should configure 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 figure shows a basic DHCP network example:

Boston Atlanta

20.1.1.1 10.1.1.2




Figure 6-3 DHCP Relay Agent Configuration

In Alteon Application switch implementation, there is no need for primary or secondary serv-

ers. The client request is forwarded to the BOOTP servers configured on the switch. The use of

two servers provide failover redundancy. However, no health checking is supported.

Use the following commands to configure the switch as a DHCP relay agent:

Additionally, DHCP Relay functionality can be assigned on a per interface basis. Use the fol-

lowing command to enable the Relay functionality:

>> # /cfg/l3/bootp>> Bootstrap Protocol Relay# addr (Set IP address of BOOTP server)

>> Bootstrap Protocol Relay# addr2 (Set IP address of 2nd BOOTP server)

>> Bootstrap Protocol Relay# on (Globally turn BOOTP relay on)

>> Bootstrap Protocol Relay# off (Globally turn BOOTP relay off)

>> Bootstrap Protocol Relay# cur (Display current configuration)

>> # /cfg/l3/if <interface number>/relay ena

DHCP Client Alteon Application SwitchDHCP Relay Agent

DHCP Server

CHAPTER 7Routing 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



315394-J, January 2005127

routes. Routers can learn about available routes dynamically using the Routing Information

Protocol (RIP). The Alteon OS software implements standard RIP for exchanging TCP/IProute 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 identifies network reach-

ability based on cost, and cost is defined as hop count. One hop is considered to be the distancefrom one switch to the next which is typically 1. This cost or hop count 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 version 1 was distributed in the early years of the Internet and advertised default class

address without subnet masking. RIP is stable, widely supported, and easy to configure. Use

RIP in stub networks and in small autonomous systems that do not have many redundant paths.

RIP includes a number of other stability features that are common to many routing protocols.

For example, RIP implements the split horizon and holddown mechanisms to prevent incorrect

routing information from being propagated.

RIP prevents routing loops from continuing indefinitely by implementing a limit on the num-

ber 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 infinity). This limits the maximum diame-

ter of a RIP network to less than 16 hops.


Routing Updates

RIP sends routing-update messages at regular intervals and when the network topology

changes. RIP uses broadcast User Datagram Protocol (UDP) data packets to exchange routing

information. Each router “advertises” routing information by sending a routing information

update every 30 seconds. If a router does not receive an update from another router within 90

seconds, it marks the routes served by the non-updating router as being unusable. If no update

is received within 240 seconds, the router removes all routing table entries for the non-updat-

ing router.

When a router receives a routing update that includes changes to an entry, it updates its routing

table to reflect the new route. The metric value 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



315394-J, January 2005128 Chapter 7: Routing Information Protocol

indicated as the next hop. RIP routers maintain only the best route (the route with the lowest

metric value) to a destination.

CHAPTER 8Border Gateway Protocol

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



315394-J, January 2005129

g g

space they can access within their network and with routers on external networks. BGP allowsyou 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 defined in RFC 1771.

Alteon 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 resil-

ience and flexibility in balancing traffic from the Internet.


“Internal Routing Versus External Routing” on page 130

“Forming BGP Peer Routers” on page 131

“What is a Route Map?” on page 131

“Aggregating Routes” on page 134

“Redistributing Routes” on page 135

“BGP Attributes” on page 136

“Selecting Route Paths in BGP” on page 137

“BGP Failover Configuration” on page 138

“Default Redistribution and Route Aggregation Example” on page 141

BGP-based Global Server Load Balancing utilizes the Internet’s routing protocols to localize

content delivery to the most efficient and consistent site. For more information on BGP-based

GSLB, see “Using Border Gateway Protocol for GSLB” on page 667.


Internal Routing Versus External Routing

To ensure effective processing of network traffic, 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, inter-

nal 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 gate-

way 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

i k l k ( h id ) h



315394-J, January 2005130 Chapter 8: Border Gateway Protocol

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 net-

work. 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 Figure 8-1.

Figure 8-1 iBGP and eBGP

AS 11

AS 50

AS 20

eBGP Internet

ISP A

ISP B

iBGP Alteon

ApplicationSwitches


Typically, an AS has one or more border routers —peer routers that exchange routes with other

ASs—and 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 autono-

mous 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 tocarry that data to its destination.

Forming BGP Peer Routers

Two BGP routers become peers or neighbors once you establish a TCP connection between



315394-J, January 2005Chapter 8: Border Gateway Protocol 131

p g y

them. For each new route, if a peer is interested in that route (for example, if a peer would liketo 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 define conditions

for redistributing routes from one routing protocol to another or controlling routing informa-

tion 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 specific 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 define 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 Configuration” on page 138.

>> # /cfg/l3/rmap 1 (Select a route map)




Precedence

You can set a priority to a route map by specifying a precedence value with the following

command:

The smaller the value the higher the precedence. If two route maps have the same precedence

value, the smaller number has higher precedence.

Configuration Overview

To configure route maps, you need to do the following:

>> /cfg/l3/rmap <x>/pre (Specify a precedence)




g p , y g

1. Define network filter.

Enter a filter number from 1 to 256. Specify the IP address and subnet mask of the network thatyou want to match. Enable the network filter. You can distribute up to 256 network filters

among 32 route maps each containing eight access lists.

2. (Optional) Define the criteria for the access list and enable it.

Specify the access list and associate the network filter number configured in Step 1.

Steps 2 and 3 are optional, depending on the criteria that you want to match. In Step 2, the net-

work filter number is used to match the subnets defined in the network filter. 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 filter) and access path (AS filter) to configure the route

maps.

>> # /cfg/l3/nwf 1 (Specify a network filter number)

>> IP Network Filter 1# addr <IP address> (Specify network address)

>> IP Network Filter 1# mask <IP mask> (Specify network mask)

>> IP Network Filter 1# ena (Enable network filter)

>> # /cfg/l3/rmap 1 (Specify a route map number)>> IP Route Map 1# alist 1 (Specify the access list number)

>> IP Access List 1# nwf 1 (Specify the network filter number)

>> IP Access List 1# metric (Define a metric)

>> IP Access List 1# action deny (Specify action for the access list)

>> IP Access List 1# ena (Enable the access list)


3. (Optional) Configure the attributes in the AS filter menu.

4. Set up the BGP attributes.

If you want to overwrite the attributes that the peer router is sending, then define the following

BGP attributes:

Specify the AS numbers that you want to prepend to a matched route and the local prefer-

ence for the matched route.

>> # cfg/l3/rmap 1/aspath 1 (Specify the attributes in the filter)

>> AS Filter 1# as 1 (Specify the AS number)

>> AS Filter 1# action deny (Specify the action for the filter)

>> AS Filter 1# ena (Enable the AS filter)




Specify the metric [Multi Exit Discriminator (MED)] for the matched route.

5. Enable the route map.

6. Assign the route map to a peer router.

Select the peer router and then add the route map to the incoming route map list,

or to the outgoing route map list.

Aggregating RoutesAggregation 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 configure

aggregate routes in BGP either by redistributing an aggregate route into BGP or by creating an

aggregate entry in the BGP routing table.

>> # /cfg/l3/rmap 1 (Specify a route map number)

>> IP Route Map 1# ap (Specify the AS numbers to prepend)

>> IP Route Map 1# lp (Specify the local preference)

>> IP Route Map 1# med (Specify the metric)

>> # /cfg/l3/rmap 1/en (Enable the route map)

>> # /cfg/l3/bgp/peer 1/addi (Add to the incoming route map)

>> # /cfg/l3/bgp/peer 1/addo (Add to the outgoing route map)


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 dis-

abled. To define the route to aggregate, use the following commands:

An example of creating a BGP aggregate route is shown in “Default Redistribution and Route

Aggregation Example” on page 141.

>> # /cfg/l3/bgp (Specify BGP)

>> Border Gateway Protocol# aggr 1 (Specify aggregate list number)

>> BGP aggr 1 # addr (Enter aggregation network address)

>> BGP aggr 1 # mask (Enter aggregation network mask)

>> BGP aggr 1 # ena (Enable aggregation)




Redistributing Routes

In addition to running multiple routing protocols simultaneously, Alteon OS 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

defining a method known as route maps between the two domains. For more information on

route maps, see “What is a Route Map?” on page 131. Redistributing routes is another way of

providing policy control over whether to export OSPF routes, fixed routes, static routes, and

virtual IP address routes. For an example configuration, see “Default Redistribution and Route

Aggregation Example” on page 141.

Default routes can be configured using the following methods:

Import

Originate—The router sends a default route to peers even though it does not have any

default routes in its routing table.


Redistribute—Default routes are either configured 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/lpThis 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 defaultvalue 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 mak-

ing within the AS. When BGP sends that update to another AS, the metric is reset to 0.


Unless otherwise specified, the router compares metric attributes for paths from external

neighbors that are in the same AS.

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 Alteon

Application switches uses the following criteria to select a path when the same route is

received from multiple peers.

1. Local fixed and static routes are preferred over learned routes.




2. With iBGP peers, routes with higher local preference values are selected.

3. 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. The lower cost to the next hop of routes is selected.

6. In the case of equal cost, the eBGP route is preferred over iBGP.

7. If all routes are from eBGP, the route with the lower router ID is selected.

When the path is selected, BGP puts the selected path in its routing table and propagates the

path to its neighbors.


BGP Failover Configuration

Use the following example to create redundant default gateways for an Alteon Application

switch at a Web Host/ISP site, eliminating the possibility, should one gateway go down, that

requests will be forwarded to an upstream router unknown to the switch.

As shown in Figure 8-3, 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 Appli-

cation switch.

ISP 2Peer 1 Router

(P i ) AS 100

ISP 1

AS

Peer 2 Router

(S d )




Figure 8-3 BGP Failover Configuration Example

On the Application switch, one peer router (the secondary one) is configured 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 configured with a metric of “3,” thereby

appearing to the switch to be three router hops away.

Default gateway,with routes havingshorter AS PATH

VIP: 200.200.200.200IP: 200.200.200.1IP:210.210.210.1

Alteon Applicationswitchannouncesroutes withmetric of "3"

(Primary)IP: 200.200.200.2

AS 100 AS 200

Real server 2IP: 200.200.200.11

Real server 1IP: 200.200.200.10

AS 300AS 300

(Secondary)IP: 210.210.210.2

Alteon metric = AS pathlength (metric of '3' = localAS repeated 3 times


1. Configure 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.

Define each real server.

Define a real server group.

Define a virtual server.

Define the port configuration.

For more information about SLB configuration, refer to Chapter 10, “Server Load Balancing.”

2. Define the VLANs.

For simplicity, both default gateways are configured in the same VLAN in this example. The

gateways could be in the same VLAN or different VLANs.




3. Define the IP interfaces.

The switch will need an IP interface for each default gateway to which it will be connected.

Each interface will need to be placed in the appropriate VLAN. These interfaces will be used

as the primary and secondary default gateways for the switch.

4. Enable IP forwarding.

IP forwarding is enabled by default and is used for VLAN-to-VLAN (non-BGP) routing. Make

sure IP forwarding is enabled if the 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/l2/vlan 1 (Select VLAN 1)

>> vlan 1# add < port number > (Add a port to the VLAN membership)

>> /cfg/l3/arp/rearp 10 (Set re-ARP period for interface to 10)

>> IP# /cfg/l3/metric strict (Set metric for default gateway)

>> IP# if 1 (Select default gateway interface 1)

>> IP Interface 1# ena (Enable switch interface 1)

>> IP Interface 1# addr 200.200.200.1 (Configure IP address of interface 1)

>> IP Interface 1# mask 255.255.255.0 (Configure IP subnet address mask)

>> IP Interface 1# /cfg/l3/if 2 (Select default gateway interface 2)

>> IP Interface 2# ena (Enable switch interface 2)>> IP Interface 2# addr 210.210.210.1 (Configure IP address of interface 2)

>> IP Interface 2# mask 255.255.255.0 (Configure IP subnet address mask)

>> /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.

6. Configure BGP peer router 1 and 2.

Peer 1 is the primary gateway router. Peer 2 is configured with a metric of “3.” The metric

option is key to ensuring gateway traffic is directed to Peer 1, as it will make 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/on




The metric command in the peer menu tells the Alteon Application switch to create an AS path

of “3” when advertising via BGP.

7. On the switch, apply and save your configuration changes.

>> # /cfg/l3/bgp/peer 1 (Select BGP peer router 1)

>> BGP Peer 1# ena (Enable this peer configuration)

>> BGP Peer 1# addr 200.200.200.2 (Set IP address for peer router 1)

>> BGP Peer 1# if 200.200.200.1 (Set IP interface for peer router 1)

>> BGP Peer 1# ras 100 (Set remote AS number)

>> BGP Peer 1# /cfg/l3/bgp/peer 2 (Select BGP peer router 2)


>> BGP Peer 2# addr 210.210.210.2 (Set IP address for peer router 2)>> BGP Peer 2# if 210.210.210.1 (Set IP interface for peer router 2)


>> BGP Peer 2# metric 3 (Set AS path length to 3 router hops)

>> BGP Peer 2# apply (Make your changes active)

>> save (Save for restore after reboot)


Default Redistribution and Route

Aggregation Example

This example shows you how to configure the switch to redistribute information from one

routing protocol to another and create an aggregate route entry in the BGP routing table to min-imize the size of the routing table.

As illustrated in Figure 8-4, you have two peer routers: an internal and an external peer router.

Configure the Alteon Application switch to redistribute the default routes from AS 200 to AS

135. At the same time, configure for route aggregation to allow you to condense the number of

routes traversing from AS 135 to AS 200.




Figure 8-4 Route Aggregation and Default Route Redistribution

1. Configure the IP interface.

2. Configure the AS number (AS 135) and router ID number (10.1.1.135).

The router ID number must be a unique number and does not have to be an IP address. How-

ever, for convenience, this id is typically one of IP addresses assigned in IP interfaces.

>> # /cfg/l3/bgp (Select the BGP menu)

>> Border Gateway Protocol# as 135 (Specify an AS number)

>> Border Gateway Protocol# /cfg/l3/rtrid 10.1.1.135(Specify the router ID number)

Aggregate routes 135.0.0.0/8traversing from

AS 135 to AS 200

AS 200

135.110.0.0/16

135.120.0.0/16

AS 135

Internal peer router 110.1.1.4

10.1.1.135Alteon Application

switch

0.0.0.0/0Default routes towards

internal peer router

External peer router 220.20.20.2

20.20.20.135


3. Configure internal peer router 1 and external peer router 2.

4. Configure redistribution for Peer 1.

>> # /cfg/l3/bgp/peer 1 (Select internal peer router 1)




>> BGP Peer 1# /cfg/l3/bgp/peer 2 (Select external peer router 2)




>> # /cfg/l3/bgp/peer 1/redist (Select redistribute)

>> BGP Peer 1# default redistribute (Set default to redistribute)

>> BGP Peer 1# fixed ena (Enable fixed routes)




5. Configure aggregation policy control.

Configure the routes that you want aggregated.


>> BGP Peer 1# fixed ena (Enable fixed routes)

>> # /cfg/l3/bgp/aggr 1 (Set aggregation number)

>> BGP Aggr 1# addr 135.0.0.0 (Add IP address to aggregate 1)

>> BGP Aggr 1# mask 255.0.0.0 (Add IP mask to aggregate 1)

>> BGP Aggr 1# ena (Enable route aggregation)

>> # apply>> # save

Part 3: Application Switching



315394-J, January 2005

Part 3: Application SwitchingFundamentals

Internet traffic 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. Applica-tion switching goes beyond IP and makes intelligent switching decisions based on the applica-

tion and its data. This sections details the following fundamental switching features:

Chapter 10, “Server Load Balancing”

Chapter 11, “Load Balancing Special Services”

Chapter 12, “WAN Link Load Balancing”

Chapter 13, “Filtering”

Chapter 14, “Application Redirection”

Chapter 15, “Health Checking”

Chapter 16, “High Availability”




315394-J, January 2005144 : Application Switching Fundamentals

CHAPTER 9Open Shortest Path First (OSPF)

Alteon OS supports the Open Shortest Path First (OSPF) routing protocol. The Alteon OS

implementation conforms to the OSPF version 2 specifications detailed in Internet RFC 1583.




315394-J, January 2005145

“OSPF Overview” on 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 in Alteon OS” on page 151. This section describes how OSPF is

implemented in Alteon OS, such as configuration parameters, electing the designated

router, summarizing routes, defining route maps and so forth.

“OSPF Configuration Examples” on page 164. This section provides step-by-step instruc-

tions on configuring four different configuration examples:

Creating a simple OSPF domain

Creating virtual links

Summarizing routes

Creating host routes


OSPF Overview

OSPF is designed for routing traffic 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). TheLSDB for all routing devices within an area is identical but is not exchanged between different

areas. Only routing updates are exchanged between areas, thereby significantly reducing the

overhead for maintaining routing information on a large, dynamic network.

The following sections describe key OSPF concepts.

Equal Cost Multipath Routing Support



315394-J, January 2005146 Chapter 9: Open Shortest Path First (OSPF)

q p g ppEqual-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. Alteon OS 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 sum-

mary routing information into the backbone, which then distributes it to other areas as needed.

As shown in Figure 9-1, OSPF defines the following types of areas:

Stub Area—an area that is connected to only one other area. External route information isnot 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 Area—an 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.

BackboneArea 0

Stub Area

Not-So-Stubby Area(NSSA)

Transit Area

No External Routesfrom Backbone

(Also a Transit Area)

Internal LSA Routes

ABR ABRABR

Virtual

Link

ABR



315394-J, January 2005Chapter 9: Open Shortest Path First (OSPF) 147

Figure 9-1 OSPF Area Types

(NSSA)

Stub Area, NSSA,

or Transit Area

Connected to Backbone

via Virtual Link

External LSA Routes

ASBR

Non-OSPF AreaRIP/BGP AS

ABR

ABR = Area Border Router

ASBR = Autonomous System

Boundary Router


Types of OSPF Routing Devices

As shown in Figure 9-2, OSPF uses the following types of routing devices:

Internal Router (IR)—a router that has all of its interfaces within the same area. IRs main-

tain 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.

BackboneArea 3BGP

OSPF Autonomous System




Figure 9-2 OSPF Domain and an Autonomous System

ac bo eArea 0

Area 3

Area 2Area 1

Inter-Area Routes(Summary Routes)

ABR

ABRABR

ASBR

InternalRouterASBR

ExternalRoutes

BGP

RIP


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 estab-

lish 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 parame-

ters respond to each other’s 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 area’s Designated Router

(DR) and one as the area’s 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 data-base information to the DR which relays the information to the other neighbors




base 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 data-

base 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 will take over the task of distributing database infor-

mation 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 flooding to distribute

LSAs between routing devices.

When LSAs result in changes to the routing device’s 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 configured to receive staticroutes 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 (Dijkstra’s 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 lowercost indicates a higher bandwidth.

Internal Versus External Routing

To ensure effective processing of network traffic, 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 autono-

mous systems is known as external routing .

Typically, an AS will have 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 in Alteon OS

Alteon OS supports a single instance of OSPF and up to 4 K routes on the network. The follow-

ing sections describe OSPF implementation in Alteon OS:

“Configurable Parameters” on page 151 “Defining Areas” on page 152

“Interface Cost” on page 154

“Electing the Designated Router and Backup” on page 154

“Summarizing Routes” on page 154

“Default Routes” on page 155

“Virtual Links” on page 156

“Router ID” on page 157

“A h i i ” 157“H R f L d B l i ” 160




“Authentication” on page 157“Host Routes for Load Balancing” on page 160

Configurable Parameters

In Alteon OS, OSPF parameters can be configured through the Command Line Interface (CLI),

Alteon OS Browser-Based Interface (BBI) for Alteon Application Switches, or through

SNMP. For more information, see Chapter 1, “Accessing the Switch.”

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) interval—Time interval between successive calculations of the

shortest path tree using the Dijkstra’s algorithm.

Stub area metric—A stub area can be configured to send a numeric metric value such that

all routes received via that stub area carry the configured metric to potentially influence

routing decisions.

Default routes—Default 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 traffic to external networks.


Defining Areas

If you are configuring multiple areas in your OSPF domain, one of the areas must be desig-

nated 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 configure virtual links to reconnect the parti-

tioned areas (see “Virtual Links” on page 156).

Up to three OSPF areas can be connected to the Alteon Application Switch with Alteon OS

software. To configure an area, the OSPF number must be defined and then attached to a net-

work interface on the switch. The full process is explained in the following sections.

An OSPF area is defined by assigning two pieces of information—an area index and an area

h d d fi OS i f ll




ID. The command to define an OSPF area is as follows:

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 defined in theareaid 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 configura-

tion simplicity, it should where possible.

For example, both of the following sets of commands define OSPF area 0 (the backbone) and

area 1 because that information is held in the area ID portion of the command. However, the

first set of commands is easier to maintain because the arbitrary area indexes agree with the

area IDs:

Area index and area ID agree

/cfg/l3/ospf/aindex 0/areaid 0.0.0.0 (Use index 0 to set area 0 in ID octet format)/cfg/l3/ospf/aindex 1/areaid 0.0.0.1 (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 (Use index 1 to set area 0 in ID octet format)

/cfg/l3/ospf/aindex 2/areaid 0.0.0.1 (Use index 2 to set area 1 in ID octet format)

>> # /cfg/l3/ospf/aindex <area index>/areaid <n.n.n.n>


Using the Area ID to Assign the OSPF Area Number

The OSPF area number is defined 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 net-

work 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 exam-

ple, the Cisco IOS-based router command “network1.1.1.0 0.0.0.255 area 1”

defines the area number simply as “area 1.” On the application switch, using the last

octet in the area ID, “area1” 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 specified directly on the Alteon

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 defined, 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:

For example, the following commands could be used to configure IP interface 14 for a pres-

ence on the 10.10.10.1/24 network, to define OSPF area 1, and to attach the area to the net-work:

>> # /cfg/l3/ospf/if <interface number>/aindex <area index>

>> # /cfg/l3/if 14 (Select menu for IP interface 14)

>> IP Interface 14# addr 10.10.10.1 (Define IP address on backbone

network)

>> IP Interface 14# mask 255.255.255.0 (Define IP mask on backbone)


>> IP Interface 14# /cfg/l3/ospf/aindex 1 ( Select menu for area index 1)

>> OSPF Area (index) 1 # areaid 0.0.0.1 (Define area ID as OSPF area 1)

>> OSPF Area (index) 1 # ena (Enable area index 1)

>> OSPF Area (index) 1 # /cfg/l3/ospf/if 14(Select OSPF menu for interface 14)

>> OSPF Interface 14# aindex 1 (Attach area to network on interface

14)

>> OSPF Interface 14# enable (Enable interface 14 for area index 1)


Interface Cost

The OSPF link-state algorithm (Dijkstra’s 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:

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 influenced by

>> # /cfg/l3/ospf/if <OSPF interface number >/cost <cost value (1-65535)>




g p y

assigning a priority value to the OSPF interfaces on the Alteon Application Switch. The com-

mand is as follows:

A priority value of 127 is the highest, and 1 is the lowest. A priority value of 0 specifies thatthe interface cannot be used as a DR or BDR. In case of a tie, the routing device with the low-

est 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 summa-rization, 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 impor-

tance of route summarization increases with network size.

Summary routes can be defined for up to 16 IP address ranges using the following command:

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 configuration example, see

“Example 3: Summarizing Routes” on page 171.

>> # /cfg/l3/ospf/if <OSPF interface number>/prio <priority value (0-127)>

>> # /cfg/l3/ospf/range <range number>/addr <IP address>/mask

<mask>


Default Routes

When an OSPF routing device encounters traffic for a destination address it does not recog-

nize, it forwards that traffic along the default route. Typically, the default route leads upstream

toward the backbone until it reaches the intended area or an external router.

Each Alteon 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 Figure 9-3), any traffic for IP address destinations outside the area is forwarded

to the switch’s IP interface, and then into the connected transit area (usually the backbone).

Since this is automatic, no further configuration is required for such areas.

IF 1 IF 2

Backbone Stub AreaStub Area

Area 2Area 1 Area 0

ABR

IRPriorityDefaultRoute

IR Metric:900

Metric:201




Figure 9-3 Injecting Default Routes

In more complex OSPF areas with multiple ABRs or ASBRs (such as area 0 and area 2 in Fig-

ure 9-3), there are multiple routes leading from the area. In such areas, traffic for unrecognized

destinations cannot tell which route leads upstream without further configuration.

To resolve the situation and select one default route among multiple choices in an area, you

can manually configure 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 set-

ting the metric value:

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 influencing routing decisions for external routes.

>> # /cfg/l3/ospf/default <metric value> <metric type (1 or 2)>

IF 2 IF 1

IF 1 IF 2

ABR

ASBR toExternal Networks

ABR

Metric:10

DefaultRoute

Route PriorityDefaultRoute

Metric:200


To clear a default route metric from the switch, use the following command:

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 a virtual link . Virtual links are created to connect one

area to the backbone through another non-backbone area (see Figure 9-1 on page 147).

The area which contains a virtual link must be a transit area and have full routing information.

Virtual links cannot be configured inside a stub area or NSSA. The area type must be defined

as transit using the following command:

>> # /cfg/l3/ospf/default none

>> # /cfg/l3/ospf/aindex <area index>/type transit




The virtual link must be configured on the routing devices at each endpoint of the virtual link,

though they may traverse multiple routing devices. To configure an Alteon Application Switch

as one endpoint of a virtual link, use the following command:

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 configuring a virtual link in the other

direction. To provide the Alteon Application Switch with a router ID, see the following section

Router ID.

For a detailed configuration example on Virtual Links, see “Example 2: Virtual Links” on page

167.

>> # /cfg/l3/ospf/virt <link number>/aindex <area index>/nbr <router

ID>


Router ID

Routing devices in OSPF areas are identified 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 inter-

face range or in any OSPF area.

The router ID can be configured in one of the following two ways:

Dynamically—OSPF protocol configures the lowest IP interface IP address as the router

ID. This is the default.

Statically—Use the following command to manually configure the router ID:

To modify the router ID from static to dynamic, set the router ID to 0.0.0.0, save the con-

figuration, and reboot the Alteon Application Switch. To view the router ID, enter:

>> # /cfg/l3/rtrid <IP address>

>> # /info/l3/ospf/gen




Authentication

OSPF protocol exchanges can be authenticated so that only trusted routing devices can partici-

pate. 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 predefined passwords. Alteon OS supports

simple password (type 1 plain text passwords) and MD5 cryptographic authentication. This

type of authentication allows a password to be configured per area.

Figure 9-4 shows authentication configured for area 0 with the password test. Simple authenti-

cation is also configured for the virtual link between area 2 and area 0. Area 1 is not configured

for OSPF authentication.

Figure 9-4 OSPF Authentication

IF 1

Area 1 Area 0

ABR

ABR

ASBR toExternal Networks

Area 2 Virtual linkkey=alteon

Simple authentication

key=test

IF 3

IF 4

IF 2

IF 5

Alteon Webswitch 1

Alteon Web

switch 2

Alteon Webswitch 3

Alteon Web switch 5

Alteon

Web switch 4


To configure simple plain text OSPF passwords on the Alteon switches shown in Figure 9-4

use the following commands:

1. Enable OSPF authentication for Area 0 on Alteon switches 1, 2, and 3.

2. Configure a simple text password up to eight characters for each OSPF IP interface in

Area 0 on Alteon switches 1, 2, and 3.

>> # /cfg/l3/ospf/aindex 0/auth password(Turn on OSPF password authenti-

cation)

>> # /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




3. Enable OSPF authentication for Area 2 on Alteon Application Switch 4.

4. Configure a simple text password up to eight characters for the virtual link between Area

2 and Area 0 on Alteon switches 2 and 4.

Use the following commands to configure MD5 authentication on the Alteon switches shown

in Figure 9-4:

1. Enable OSPF MD5 authentication for Area 0 on Alteon switches 1, 2, and 3.

2. Configure MD5 key ID for Area 0 on Alteon switches 1, 2, and 3.

>> OSPF Interface 3 # key test

>> # /cfg/l3/ospf/aindex 2/auth password

(Turn on OSPF password authenti-

cation)

>> # /cfg/l3/ospf/virt 1/key alteon

>> # /cfg/l3/ospf/aindex 0/auth md5 (Turn on MD5 authentication)

>> # /cfg/l3/ospf/md5key 1/key test


3. Assign MD5 key ID to OSPF interfaces on Alteon Application switches 1, 2, and 3.

4. Enable OSPF MD5 authentication for Area 2 on Alteon Application Switch 4.

5. Configure MD5 key for the virtual link between Area 2 and Area 0 on Alteon switches 2

and 4.

>> # /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

>> # /cfg/l3/ospf/aindex 2/auth md5

>> # /cfg/l3/ospf/md5key 2/key alteon




6. Assign MD5 key ID to OSPF virtual link on Alteon switches 2 and 4.

# /cfg/l3/ospf/md5key 2/key alteon

>> # /cfg/l3/ospf/virt 1/mdkey 2




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?” on page 131.

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 route’s cost includes or excludes external costs of the route. If you want to remove

a previous configuration to export all the routes of a protocol, then use the parameter “none” to

the export command.

Using Route Maps to Export Selected Routes

Use route maps to specify which routes of the protocol that you want exported into OSPF.

Table 9-1 shows the tasks that you can perform using route maps.

/cfg/l3/ospf/redist < protocol name>/export none

Table 9-1 Route MapsTask Command

Adding a route map for a particu-

lar protocol

/cfg/l3/ospf/redist < protocol name>/add <route map numbers>

Adding all 32 route maps /cfg/l3/ospf/redist < protocol name>/add all

Removing a route map for a partic-

ular protocol

/cfg/l3/ospf/redist < protocol name>/rem <route map numbers>

Removing all 32 route maps for a

particular protocol /cfg/l3/ospf/redist < protocol name

>/rem all


OSPF does not require you to set all the fields in the route map menu. However, set the follow-

ing parameters in the route maps and network filter menu:

1. Enable the route map.

2. Assign the metric value in the AS-External LSA.

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 redistrib-

uted into OSPF using the metric and metric type assigned for that route map. Metric sets the

priority for choosing this switch for default route.

3. Enable the access list.

/cfg/l3/rmap <route map number>/ena

/cfg/l3/rmap <route map number>/metric <metric value>




4. Set the action to permit for the access list.

To redistribute routes matched by the route map, the action in the alist must be set to per-

mit. If the action is set to deny the routes matched by the route map will not be redistributed.

5. Link a network filter to the access list.

6. Enable the network filter.

7. Specify the IP address and mask for the network filter.

/cfg/l3/rmap <route map number>/alist <access list number>/ena

/cfg/l3/rmap <route map number>/alist <access list number>/action permit

/cfg/l3/rmap <route map number>/alist <access list number>/nwf <network filter num-

ber>

/cfg/l3/nwf <network filter number>/ena

/cfg/l3/nwf 1/addr < IP address>/mask < IP mask>


Optional Parameters for Route Maps

Set the following optional parameters (metric type and metric) for route redistribution

into OSPF:

1. Assign the metric type in the AS-External LSA.

Metric type determines the method for influencing routing decisions for external routes.

2. Match the metric of the protocol route.

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.

/cfg/l3/rmap <route map number>/type [1|2]

/cfg/l3/rmap <l>/alist <access list number>/metric <metric value>




Exporting All Routes Except a Few Selected Routes

This method is a combination of the previous two methods. The basic steps to configure this

method are outlined below:

1. Configure OSPF to export all routes of the protocol using the export command as

described in the first method (“Exporting All Routes” on page 161).

2. Use route maps to configure routes to be denied by setting the action in the access list of

the route map to deny.

The configuration of the route map is similar to that described in the second method except that

the action is set to deny.

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

Configuring OSPF on non-broadcast multi-access networks (such as frame relay, X.25,

and ATM)


OSPF Configuration Examples

A summary of the basic steps for configuring OSPF on the Alteon Application Switch is listed

here. Detailed instructions for each of the steps is covered in the following sections:

1. Configure IP interfaces.

One IP interface is required for each desired network (range of IP addresses) being assigned to

an OSPF area on the Alteon Application Switch.

2. (Optional) Configure the router ID.

The router ID is required only when configuring virtual links on the Alteon Application

Switch.

3. Enable OSPF on the switch.

4. Define the OSPF areas.




5. Configure OSPF interface parameters.

IP interfaces are used for attaching networks to the various areas.

6. (Optional) Configure route summarization between OSPF areas.

7. (Optional) Configure virtual links.

8. (Optional) Configure host routes.


Example 1: Simple OSPF Domain

In this example, two OSPF areas are defined—one 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 traffic for IP address destinations outside the stub area will be forwarded to

the stub area’s IP interface, and then into the backbone.

Figure 9-5 A Simple OSPF Domain

Area 0(0.0.0.0)

IF 110.10.7.1

IF 210.10.12.1

Area 1(0.0.0.1)

Backbone Stub Area

Network

10.10.7.0/24

Network

10.10.12.0/24Alteon Applicationswitch




Follow this procedure to configure OSPF support as shown in Figure 9-5:

1. Configure IP interfaces on each network that will be attached to OSPF areas.

In this example, two IP interfaces are needed: one for the backbone network on 10.10.7.0/24and one for the stub area network on 10.10.12.0/24.

2. Enable OSPF.


>> IP Interface 1 # addr 10.10.7.1 (Set IP address on backbone network )

>> IP Interface 1 # mask 255.255.255.0 (Set IP mask on backbone network )

>> IP Interface 1 # enable (Enable IP interface 1)

>> IP Interface 1 # /cfg/l3/if 2 (Select menu for IP interface 2)

>> IP Interface 2 # addr 10.10.12.1 (Set IP address on stub area network )>> IP Interface 2 # mask 255.255.255.0 (Set IP mask on stub area network )


>> IP Interface 2 # /cfg/l3/ospf/on (Enable OSPF on the Alteon switch)


3. Define the backbone.

The backbone is always configured as a transit area using areaid 0.0.0.0.

4. Define the stub area.

5. Attach the network interface to the backbone.

>> Open Shortest Path First # aindex 0 (Select menu for area index 0)

>> OSPF Area (index) 0 # areaid 0.0.0.0 (Set the ID for backbone area 0)

>> OSPF Area (index) 0 # type transit (Define backbone as transit type)

>> OSPF Area (index) 0 # enable (Enable the 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 (Set the area ID for OSPF area 1)

>> OSPF Area (index) 1 # type stub (Define area as stub type)





6. Attach the network interface to the stub area.

7. Apply and save the configuration changes.

>> OSPF Area 1 # /cfg/l3/ospf/if 1 (Select OSPF menu for IP interface 1)

>> OSPF Interface 1 # aindex 0 (Attach network to backbone index)

>> OSPF Interface 1 # enable (Enable the backbone interface)

>> OSPF Interface 1 # /cfg/l3/ospf/if 2 (Select OSPF menu for IP interface 2)

>> OSPF Interface 2 # aindex 1 (Attach network to stub area index)

>> OSPF Interface 2 # enable (Enable the stub area interface)

>> OSPF Interface 2 # apply (Global command to apply all changes)

>> OSPF Interface 2 # save (Global command to save all changes)


Example 2: Virtual Links

In the example shown in Figure 9-6, area 2 is not physically connected to the backbone as is

usually required. Instead, area 2 will be connected to the backbone via a virtual link through

area 1. The virtual link must be configured at each endpoint.

Figure 9-6 Configuring a Virtual Link

Configuring OSPF for a Virtual Link on Switch #1

Router ID:10.10.10.1

Router ID:10.10.14.1

AlteonApplicationswitch #1

AlteonApplicationswitch #2

Virtual Link 1

Area 0(0.0.0.0)

IF 110.10.7.1

IF 210.10.12.1

Area 1(0.0.0.1)

Backbone Transit Area

IF 110.10.12.2

IF 210.10.24.1

10.10.7.0/24

Network

10.10.12.0/24

Network

10.10.24.0/24

Network

Area 2(0.0.0.2)

Stub Area




1. Configure IP interfaces on each network that will be 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.

2. Configure the router ID.

A router ID is required when configuring virtual links. Later, when configuring the other end

of the virtual link on Alteon Application Switch 2, the router ID specified here will be used as

the target virtual neighbor (nbr) address.

3. Enable OSPF.


>> IP Interface 1 # addr 10.10.7.1 (Set IP address on backbone network)




>> IP Interface 2 # addr 10.10.12.1 (Set IP address on transit area network )

>> IP Interface 2 # mask 255.255.255.0 (Set IP mask on transit area network )

>> IP Interface 2 # enable (Enable interface 2)

>> IP Interface 2 # /cfg/l3/rtrid 10.10.10.1 (Set static router ID on Alteon switch 1)

>> IP # /cfg/l3/ospf/on (Enable OSPF on Alteon switch 1)



5. Define the transit area.

The area that contains the virtual link must be configured as a transit area.



>> OSPF Area (index) 0 # areaid 0.0.0.0 (Set the area ID for backbone area 0)





>> OSPF Area (index) 1 # type transit (Define area as transit type)


>> OSPF Area (index) 1 # /cfg/l3/ospf/if 1 (Select OSPF menu for IP interface 1)




7. Attach the network interface to the transit area.

8. Configure the virtual link.

The nbr router ID configured in this step must be the same as the router ID that will be config-ured for Switch #2 in Step 2 on page 169.


Configuring OSPF for a Virtual Link on Switch #2





>> OSPF Interface 2 # aindex 1 (Attach network to transit area index)

>> OSPF Interface 2 # enable (Enable the transit area interface)

>> OSPF Interface 2 # /cfg/l3/ospf/virt 1 (Specify a virtual link number)

>> OSPF Virtual Link 1 # aindex 1 (Specify the transit area for the virtual link)

>> OSPF Virtual Link 1 # nbr 10.10.14.1 (Specify the router ID of the recipient)

>> OSPF Virtual Link 1 # enable (Enable the virtual link)




1. Configure IP interfaces on each network that will be 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.

2. Configure the router ID.

A router ID is required when configuring virtual links. This router ID should be the same one

specified as the target virtual neighbor (nbr) on Alteon switch 1 in Step 8 on page 168.


>> IP Interface 1 # addr 10.10.12.2 (Set IP address on transit area net-

work )>> IP Interface 1 # mask 255.255.255.0 (Set IP mask on transit area network )



>> IP Interface 2 # addr 10.10.24.1 (Set IP address on stub area network)

>> IP Interface 2 # mask 255.255.255.0 (Set IP mask on stub area network )





3. Enable OSPF.


This version of Alteon OS requires that a backbone index be configured on the non-backbone

end of the virtual link as follows:

5. Define the transit area.

>> IP Interface 2 # /cfg/l3/rtrid 10.10.14.1 (Set static router ID on Alteon switch 2)

>> IP# /cfg/l3/ospf/on (Enable OSPF on Alteon switch 2)

>> Open Shortest Path First # aindex 0 (Select the menu for area index 0)




>> OSPF Area (index) 1 # areaid 0.0.0.1 (Set the area ID for OSPF area 1)>> OSPF Area (index) 1 # type transit (Define area as transit type)





8. Attach the network interface to the transit area.






>> OSPF Interface 1 # aindex 1 (Attach network to transit area index)

>> OSPF Interface 1 # enable (Enable the transit area interface)







9. Configure the virtual link.

The nbr router ID configured in this step must be the same as the router ID that was config-

ured for Alteon Application Switch #1 in Step 2 on page 167.


Other Virtual Link Options

You can use redundant paths by configuring multiple virtual links.

Only the endpoints of the virtual link are configured. The virtual link path may traverse

multiple routers in an area as long as there is a routable path between the endpoints.

>> OSPF Interface 2 # /cfg/l3/ospf/ virt 1 (Specify a virtual link number)

>> OSPF Virtual Link 1 # aindex 1 (Specify the transit area for the virtual link)

>> OSPF Virtual Link 1 # nbr 10.10.10.1 (Specify the router ID of the recipient)

>> OSPF Virtual Link 1 # enable (Enable the virtual link)




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 con-

figure 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.

IF 110.10.7.1

IF 236.128.192.1

Area 1(0.0.0.1)

Area 0(0.0.0.0)

Stub AreaBackbone

Alteon Applicationswitch




Figure 9-7 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.

36.128.192.x to36.128.254.x

SummaryRoute

ABR

36.128.192.0/18Network

10.10.7.0/24Network


Follow this procedure to configure OSPF support as shown in Figure 9-7:

1. Configure IP interfaces for each network which will be attached to OSPF areas.

2. Enable OSPF.





>> IP Interface 1 # ena (Enable IP interface 1)>> IP Interface 1 # /cfg/l3/if 2 (Select menu for IP interface 2)


>> IP Interface 2 # mask 255.255.192.0 (Set IP mask on stub area network )

>> IP Interface 2 # ena (Enable IP interface 2)

>> IP Interface 2 # /cfg/l3/ospf/on (Enable OSPF on the Alteon switch)















>> OSPF Area (index) 1 # /cfg/l3/ospf/if 1(Select OSPF menu for IP interface 1)







7. Configure route summarization by specifying the starting address and mask of the range

of addresses to be summarized.

8. Use the hide command to prevent a range of addresses from advertising to the backbone.


>> OSPF Interface 2 # /cfg/l3/ospf/range 1 (Select menu for summary range)

>> OSPF Summary Range 1 # addr 36.128.192.0 (Set base IP address of summary range)

>> OSPF Summary Range 1 # mask 255.255.192.0 (Set mask address for summary range)

>> OSPF Summary Range 1 # aindex 0 (Inject summary route into backbone)

>> OSPF Summary Range 1 # enable (Enable summary range)

>> OSPF Interface 2 # /cfg/l3/ospf/range 2 (Select menu for summary range)

>> OSPF Summary Range 2 # addr 36.128.200.0 (Set base IP address)

>> OSPF Summary Range 2 # mask 255.255.255.0 (Set mask address)

>> OSPF Summary Range 2 # hide enable (Hide the range of addresses)

>> OSPF Summary Range 2 # apply (Global command to apply all changes)

>> OSPF Summary Range 2 # save (Global command to save all changes)




>> OSPF Summary Range 2 # save (Global command to save all changes)


Example 4: Host Routes

The Alteon OS implementation of OSPF includes host routes. Host routes are used for adver-

tising 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 Figure 9-8. Both Alteon Application Switches have access to

servers with identical content and are configured with the same virtual server IP addresses:

10.10.10.1 and 10.10.10.2. Alteon Application Switch #1 is given a host 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. Alteon Application Switch #2 is configured 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. Trafficcomes 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 Alteon switches and uses the host route with the lowest

cost for each. Traffic for 10.10.10.1 goes to Alteon switch #1 because its host route has the

lowest cost for that address. Traffic for 10.10.10.2 goes to Alteon switch #2 because its host




g

route has the lowest cost. This effectively shares the load among ABRs. Both Alteon switches

then use standard server load balancing to distribute traffic among available real servers.

In addition, if one of the Alteon switches were to fail, the upstream routing device would for-ward the traffic to the ABR whose host route has the next lowest cost. In this example, the

remaining Alteon switch would assume the entire load for both virtual servers.

Figure 9-8 Configuring OSPF Host Routes

ABR Load Sharing Standard SLB

Preferred path(lowest cost)

to Host Route10.10.10.1

Preferred path(lowest cost)to Host Route

10.10.10.2

Virtual Servers/Host Routes:10.10.10.1, Cost 110.10.10.2, Cost 100


Alteon Application Switch #2Virtual Servers/Host Routes:10.10.10.1, Cost 10010.10.10.2, Cost 1

Area 1Stub Area

Area 0Backbone

Real Serverswith Identical

Content


Configuring OSPF for Host Routes on Alteon Application Switch #1

1. Configure IP interfaces for each network that will be attached to OSPF areas.

2. Configure basic SLB parameters.

Alteon 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.

>> Virtual server 1 # /cfg/l3/if 1 (Select menu for IP interface 1)



>> IP Interface 1 # /cfg/l3/if 2 (Select menu for IP interface 2)>> IP Interface 2 # addr 100.100.100.40 (Set IP address on stub area network)


>> # /cfg/slb/real 1 (Select menu for real server 1)

>> Real server 1 # rip 100.100.100.25 (Set the IP address for real server 1)

>> Real server 1 # ena (Enable the real server)

>> Real server 1 # /cfg/slb/real 2 (Select menu for real server 2)




3. Configure client and server processing on specific ports.

4. Enable direct access mode.

ea se ve # /c g/s b/ ea (Select menu for real server 2)


>> Real server 2 # ena (Enable the real server)

>> Real server 2 # /cfg/slb/group 1 (Select menu for real server group 1)

>> Real server group 1 # add 1 (Add real server 1 to group)


>> Real server group 1 # enable (Enable the group)

>> Real server group 1 # /cfg/slb/on (Turn SLB on)

>> Layer 4# /cfg/slb/port 4(Select switch port 4)

>> SLB Port 4 # client ena (Enable client processing on Port 4)

>> SLB Port 4 # /cfg/slb/port 5 (Select switch Port 5)

>> SLB Port 5 # server ena (Enable server processing on Port 5)

>> Layer 4 Port 5# /cfg/slb/adv (Select the SLB advance menu)

>> Layer 4 Advanced# direct ena (Enable DAM)>> Layer 4 Advanced# .. (Return to the SLB menu)


5. Configure the primary virtual server.

Alteon Application Switch # 1 will be preferred for virtual server 10.10.10.1.

6. Configure the backup virtual server.

Alteon Application Switch # 1 will act as a backup for virtual server 10.10.10.2. Both virtual

servers in this example are configured with the same real server group and provide identical

services.

>> Layer 4 # /cfg/slb/ virt 1 (Select menu for virtual server 1)

>> Virtual server 1 # vip 10.10.10.1 (Set the IP address for virtual server 1)

>> Virtual server 1 # ena (Enable the virtual server)

>> Virtual server 1 # service http (Select menu for service on virtual server)>> 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 # service http (Select menu for service on virtual server)




7. Enable OSPF on Alteon Application Switch 1.



>> Virtual server 1 # group 1 (Use real server group 1 for http service)

>> IP Interface 2 # /cfg/l3/ospf/ospf/on (Enable OSPF on Alteon switch 1)



>> OSPF Area (index) 0 # type transit (Define backbone as transit type)>> OSPF Area (index) 0 # enable (Enable the area)


>> OSPF Area (index) 1 # areaid 0.0.0.1 (Set the ID for stub area 1)






12. Configure host routes.

One host route is needed for each virtual server on Alteon Application Switch 1. Since virtualserver 10.10.10.1 is preferred for Alteon Application Switch 1, its host route has a low cost.

Because virtual server 10.10.10.2 is used as a backup in case Alteon 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 configure

virtual server routes as host routes.

NOTE – When a service goes down, the corresponding host route is removed from advertising.


>> OSPF Interface 2 # /cfg/l3/ospf/host 1 (Select menu for host route 1)

>> OSPF Host Entry 1 # addr 10.10.10.1 (Set IP address same as virtual server 1)

>> OSPF Host Entry 1 # aindex 0 (Inject host route into backbone area)

>> OSPF Host Entry 1 # cost 1 (Set low cost for preferred path)

>> OSPF Host Entry 1 # enable (Enable the host route)

>> OSPF Host Entry 1 # /cfg/l3/ospf/host 2 (Select menu for host route 2)


>> OSPF Host Entry 2 # aindex 0 (Inject host route into backbone area)>> OSPF Host Entry 2 # cost 100 (Set high cost for use as backup path)


>> OSPF Host Entry 2 # apply (Global command to apply all changes)

>> OSPF Host Entry 2 # save (Global command to save all changes)


Configuring OSPF for Host Routes on Alteon Application Switch 2

1. Configure basic SLB parameters.

Alteon 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.

2. Configure the virtual server parameters.

>> # /cfg/slb/real 1 (Select menu for real server 1)>> Real server 1 # rip 100.100.100.27 (Set the IP address for real server 1)

>> Real server 1 # enable (Enable the real server)

>> Real server 1 # /cfg/slb/real 2 (Select menu for real server 2)


>> Real server 2 # enable (Enable the real server)

>> Real server 2 # /cfg/slb/group 1 (Select menu for real server group 1)


>> Real server group 1 # add 2 (Add real server 2 to group)>> Real server group 1 # enable (Enable the group)

>> Real server group 1 # /cfg/slb/on (Turn SLB on)




The same virtual servers are configured as on Alteon Application Switch 1.

3. Configure IP interfaces for each network that will be attached to OSPF areas.

>> Layer 4 # /cfg/slb/ virt 1 (Select menu for virtual server 1)>> Virtual server 1 # vip 10.10.10.1 (Set the IP address for virtual server 1)

>> Virtual server 1 # enable (Enable the virtual server)

>> Virtual server 1 # service http (Select menu for service on virtual server)

>> 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 # enable (Enable the virtual server)

>> Virtual server 1 # service http (Select menu for service on virtual server)>> Virtual server 1 # group 1 (Use real server group 1 for http service)

>> Virtual server 1 # /cfg/l3/if 1 (Select menu for IP Interface 1)



>> IP Interface 1 # /cfg/l3/if 2 (Select menu for IP Interface 2)




4. Enable OSPF on Alteon Application Switch #2.




>> IP Interface 2 # /cfg/l3/ospf/on (Enable OSPF on Alteon switch #2)






>> OSPF Area (index) 1 # areaid 0.0.0.1 (Set the ID for stub area 1)>> OSPF Area (index) 1 # type stub (Define area as stub type)













9. Configure host routes.

Host routes are configured just like those on Alteon Application Switch 1, except their costs

are reversed . Since virtual server 10.10.10.2 is preferred for Alteon 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 Alteon switch 1 fails, its host route has been given a high cost.


>> OSPF Interface 2 # /cfg/l3/ospf/host 1 (Select menu for host route 1)>> OSPF Host Entry 1 # addr 10.10.10.1 (Set IP address same as virtual server 1)


>> OSPF Host Entry 1 # cost 100 (Set high cost for use as backup path)


>> OSPF Host Entry 1 # /cfg/l3/ospf/host 2 (Select menu for host route 2)



>> OSPF Host Entry 2 # cost 1 (Set low cost for primary path)>> OSPF Host Entry 2 # enable (Enable the host route)





Verifying OSPF Configuration

Use the following commands to verify the OSPF configuration 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 Alteon OS Command Reference for information on the above commands.


>> OSPF Host Entry 2 # save (Global command to save all changes)

CHAPTER 10

Server Load Balancing

Server Load Balancing (SLB) allows you to configure the Alteon Application Switch to bal-

ance user session traffic among a pool of available servers that provide shared services.


“Understanding Server Load Balancing” on page 182. This section discusses the benefits

of server load balancing and how it works.

“Implementing Basic Server Load Balancing” on page 185. This section discusses how

implementing SLB provides reliability performance and ease of maintenance on your



315394-J, January 2005181

implementing SLB provides reliability, performance, and ease of maintenance on your

network.

“Network Topology Requirements” on page 186. This section provides key require-ments to consider before deploying server load balancing.

“Configuring Server Load Balancing” on page 188.

“Additional Server Load Balancing Options” on page 191.

“Extending SLB Topologies” on page 218. This section discusses proxy IP addresses,

mapping a virtual port to real ports, monitoring real server ports, and delayed binding.

For additional information on SLB commands, see your Alteon OS Command Reference.


Understanding Server Load Balancing

SLB benefits your network in a number of ways:

Increased efficiency for server utilization and network bandwidth

With SLB, your Alteon Application Switch is aware of the shared services provided by

your server pool and can then balance user session traffic among the available servers.Important session traffic gets through more easily, reducing user competition for connec-

tions on overutilized servers. For even greater control, traffic 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

As users are added and the server pool’s capabilities are saturated, new servers can be

added to the pool transparently.



315394-J, January 2005182 Chapter 10: Server Load Balancing

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 server’s capacity.

Your NT and UNIX 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 can’t afford to continue using an inferior load-balancing technique, such as DNS

round robin or a software-only system.


How Server Load Balancing 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 traf-

fic to an appropriate server, based on a variety of load-balancing algorithms.

RetailTrading

Lending

Retail

TradingLending

Retail

Trading

Lending

Retail

TradingLending



315394-J, January 2005Chapter 10: Server Load Balancing 183

Figure 10-1 Traditional Versus SLB Network Configurations

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 file system or database server).

Clients Clients

R e t a i l

Retail Trading T r a

d i n g

T r a d i n g

T r a d i n g

T r a

d i n

g

T r a

d i n

g Alteon Applicationswitch


The Alteon Application Switch, with SLB software, acts as a front-end to the servers, inter-

preting user session requests and distributing them among the available servers. Load balanc-

ing in Alteon OS can be done in the following ways:

Virtual server-based load balancing

This is the traditional load balancing method. The switch is configured to act as a virtual

server and is given a virtual server IP address (or range of addresses) for each collection ofservices it will distribute. 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 will 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 fields 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 filter allows you to control the types of traffic permitted through the switch Filters are




A filter allows you to control the types of traffic permitted through the switch. Filters are

configured to allow, deny, or redirect traffic according to the IP address, protocol, or

Layer 4 port criteria. In filtered-based load balancing, a filter is used to redirect traffic to areal server group. If the group is configured with more than one real server entry, redi-

rected traffic is load balanced among the available real servers in the group.

Firewalls, WAP with RADIUS snooping, IDS, and WAN links use redirection filters to

load balance traffic.

Content-based load balancing

Content-based load balancing uses Layer 7 application data (such as URL, cookies, andHost 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 num-

ber of simultaneous Web connection requests also increases.

Web Server

NFS Server

Web Clients

Internet

Web Host

Router

As clients increase, the server becomes overloaded




Figure 10-2 Web Hosting Configuration Without SLB

Such a company has three primary needs:

Increased server availability

Server performance scalable to match new customer demands

Easy administration of network and servers

Figure 10-3 Web Hosting with SLB Solutions

Web Server Farm

NFS Server

Alteon Application

Switch

AB

C

Web Clients

Internet

Web Host

Routers

Layer 4 Switching &


Layer 2

Switching

Layer 2

Switching


All the issues can be addressed by adding an Alteon Application Switch with SLB software.

Reliability is increased by providing multiple paths from the clients to the Alteon Applica-

tion 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 interrupt-

ing 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 thereal servers must pass through the switch, as shown in Figure 10-4. If there is a path between

the client and the real servers that does not pass through the switch, the Alteon Application

Switch can be configured to proxy requests in order to guarantee that responses use the correct

path (see “Proxy IP Addresses” on page 219).




Figure 10-4 SLB Client/Server Traffic Routing

Identical content must be available to each server in the same pool. Either of these meth-

ods 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 file

system or back-end database server.

ClientsSwitch

Internet NFS Server

Server Pool #1

Server Pool #2

Switch

Alternate path is not valid with

Layer 4 services. IP proxy

addresses must be used on the


Alteon ApplicationSwitch

Router

Router


Some services require that a series of client requests go to the same real server so that ses-

sion-specific state data can be retained between connections. Services of this nature

include Web search results, multi-page forms that the user fills in, or custom Web-based

applications typically created using cgi-bin scripts. Connections for these types of ser-

vices must be configured as persistent (see Chapter 17, “Persistence”) or must use the

minmisses, hash, phash metrics (see “Metrics for Real Server Groups” on page 195).

Clients and servers can be connected through the same switch port. Each port in use on theswitch can be configured to process client requests, server traffic, or both. You can enable

or disable processing on a port independently for each type of Layer 4 traffic.

Layer 4 client processing: Ports that are configured to process client request traffic

provide address translation from the virtual server IP to the real server IP address.

Layer 4 server processing: Ports that are configured to process server responses to cli-

ent 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 Alteon Appli-

cation Switch directly or through a hub, router, or another switch.

NOTE – Switch ports configured for Layer 4 client/server processing can simultaneously pro-

vide Layer 2 switching and IP routing functions.




Consider the following network topology:

Figure 10-5 Example Network for Client/Server Port Configuration

In Figure 10-5, the switch load balances traffic 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.

Alteon Applicationlteon pplication

Switchwitch

Router

DNS

ServerPool

WebServer

Pool

Internet

C

S

Client Processing

Server Processing

S

C

Clients on the Internetinitiate HTTP sessions which

are load balanced to Web servers

Web servers initiate DNS requestswhich are load balanced

to DNS servers

S

C

port 11

port 14

port 25

port 13


Configuring Server Load Balancing

This section describes the steps for configuring 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” on page 191 for more options. Before you start configuring, you

must be connected to the switch CLI as the administrator.

NOTE – For details about any of the menu commands described in this example, see your

Alteon OS Command Reference.

1. Assign an IP address to each of the real servers in the server pool.

The real servers in any given real server group must have an IP route to the switch that per-

forms 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” on

page 186.

For this example, the three hosts (real servers) have been given the following IP addresses on

the same IP subnet:




NOTE – An imask option can be used to define a range of IP addresses for real and virtual

servers (see “IP Address Ranges Using imask” on page 194).

2. Define 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 configure an IP interface for this example, enter these commands from the CLI:

Table 10-1 Web Host Example: Real Server IP Addresses

Real Server IP address

Server A 200.200.200.2

Server B 200.200.200.3

Server C 200.200.200.4





NOTE – 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 configuration for the ports or IP interface.

3. Define each real server.

For each real server, you must assign a real server number, specify its actual IP address, andenable the real server. For example:

4. Define a real server group and add the three real servers to the service group.

>> IP Interface 1# /cfg/slb/real 1 (Server A is real server 1)

>> Real server 1# rip 200.200.200.2 (Assign Server A IP address)

>> Real server 1# ena (Enable real server 1)

>> Real server 1# /cfg/slb/real 2 (Server B is real server 2)

>> Real server 2# rip 200.200.200.3 (Assign Server B IP address)

>> Real server 2# ena (Enable real server 2)>> Real server 2# /cfg/slb/real 3 (Server C is real server 3)

>> Real server 3# rip 200.200.200.4 (Assign Server C IP address)





>> Real server 3# /cfg/slb/group 1 (Select real server group 1)

>> Real server group 1# add 1 (Add real server 1 to group 1)




5. Define a virtual server.

All client requests will be addressed to a virtual server IP address on a virtual server defined on

the switch. Clients acquire the virtual server IP address through normal DNS resolution. In this

example, HTTP is configured as the only service running on this virtual server, and this service

is associated with the real server group. For example:

NOTE – This configuration is not limited to HTTP Web service. Other TCP/IP services can be

configured in a similar fashion. For a list of other well-known services and ports, see “Well-Known Application Ports” on page 192. To configure multiple services, see “Configuring

Multiple Services” on page 194.

6. Define the port settings.

In this example the following ports are being used on the Alteon Application Switch:

>> Real server group 1# /cfg/slb/virt 1 (Select virtual server 1)>> Virtual server 1# vip 200.200.200.1 (Assign a virtual server IP address)

>> Virtual server 1# ena (Enable the virtual server)

>> Virtual server 1# service http (Select the HTTP service menu)

>> Virtual server 1 http Service# group 1 (Associate virtual port to real group)




In this example, the following ports are being used on the Alteon Application Switch:

Table 10-2 Web Host Example: Port Usage

Port Host L4 Processing

1 Server A serves SLB requests. Server

2 Server B serves SLB requests. Server

3 Server C serves SLB requests. Server

4 Back-end NFS server provides centralized content for all three realservers. This port does not require switching features.

None

5 Client router A connects the switch to the Internet where client

requests originate.

Client

6 Client router B connects the switch to the Internet where client

requests originate.

Client


The ports are configured as follows:



>> Virtual server 1# /cfg/slb/port 1 (Select physical switch port 1)

>> SLB port 1# server ena (Enable server processing on port 1)

>> SLB port 1# /cfg/slb/port 2 (Select physical switch port 2)



>> SLB port 3# server ena (Enable server processing on port 3)>> SLB port 3# /cfg/slb/port 5 (Select physical switch port 5)

>> SLB port 5# client ena (Enable client processing on port 5)



>> SLB port 6# /cfg/slb (Select the SLB Menu)

>> Layer 4# on (Turn Server Load Balancing on)

>> Layer 4# apply (Make your changes active)

>> Layer 4# cur (View current settings)





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.

Check that all SLB parameters are working according to expectation. If necessary, make any

appropriate configuration changes and then check the information again.

Additional Server Load Balancing Options

In the previous section (“Configuring Server Load Balancing” on page 188), many of the SLB

options are left to their default values. The following configuration options can be used to cus-

tomize SLB on your Alteon Application Switch:

>> Layer 4# save (Save for restore after reboot)

>> Layer 4# /info/slb/dump (View SLB 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 old 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:

When the current session count on your server falls to zero, you can shut down your

server.

If you have configured persistence on the real server, use the following command with the

p (persistent) option to suspend connection assignments (except for persistent http 1.0 ses-

sions) to the real server:

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 Chapter 17 “Per

>> # /oper/slb/dis <real server number> n

>> # /oper/slb/dis <real server number> p




real server), you can shut down your server. For more information (see Chapter 17, Per-

sistence”). When maintenance is complete, use the following command to enable the real server:

The switch will resume assignment of connections to this real server immediately.

>> # /oper/slb/ena <real server number>


IP Address Ranges Using imask

The imask option lets you define a range of IP addresses for the real and virtual servers con-

figured 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 configured with an IP address of 172.16.10.1.

Real servers 172.16.20.1 and 172.16.30.1 are assigned to service 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 config-

ured as part of each service For more information see “Configuring Multiple Services” on




ured as part of each service. For more information, see Configuring Multiple Services on

page 194. 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:

For more complex health-checking strategies, see Chapter 15, “Health Checking.”

Configuring Multiple Services

When you configure multiple services in the same group, their health checks will be dependenton 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.”

>> # /cfg/slb/real <real server number> (Select the real server)

>> Real server# inter 4 (Check real server every 4 seconds)>> Real server# retry 6 (Declare down after 6 checks fail)


Independent Services. If you are configuring two independent services such as FTP and

SMTP—where the real server failure on one service does not affect other services that the real

server supports, then configure two groups with the same real servers, but with different ser-

vices. If a real server configured for both FTP and SMTP fails FTP, the real server is still avail-

able for SMTP. This allows the services to act independently even though they are using the

same real servers.

Dependent Services. If you are configuring two dependent services such as HTTP andHTTPS—where the real server failure on one service blocks the real server for other services,

then configure a single group with multiple services. If a real server configured for both HTTP

and HTTPS fails for the HTTP service, then the server is blocked from supporting any HTTPS

requests. The switch will block HTTPS requests, (even though HTTPS has not failed) until the

HTTP service becomes available again. This helps in troubleshooting so you know which ser-

vice has failed.

Metrics for Real Server Groups

Metrics are used for selecting which real server in a group will receive the next client connec-

tion. 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.




are explained in detail below. The default metric is leastconns.

To change a real server group metric to minmisses, for example, enter:

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 persis-

tency when servers are removed from service. This metric should be used only when persis-

tence 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 traffic should be sent to when the minmiss metric is selected. In AlteonOS 22.0 you can select all the 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:

>> # /cfg/slb/group <group number> (Select the real server group)

>> Real server group# metric minmisses (Use minmisses metric)


For application redirection, the client destination IP address is used. All requests for a spe-

cific 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 bal-

ancing 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 specific client are sent to the same server. This metric is useful for applicationswhere client information must be retained on the server between sessions. With this met-

ric, server load becomes most evenly balanced as the number of active clients with differ-

ent 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 firewall load balancing, since the real server IP

addresses used in calculating the score for this metric are different on each side of the firewall.

Hash

The hash metric uses IP address information in the client request to select a server. The spe-

cific IP address information used depends on the application:




For Application Redirection, the client destination IP address is used. All requests for a

specific IP destination address will be 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 specific client will be

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 flows of a given session are redirected to the same firewall.

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 sta-

ble. 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” on page 197.


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 significantly 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 met-

ric 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 config-

ured 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 find an available server.

If all the servers are available, then phash operates exactly like hash. When a configured

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 distri



315394-J, January 2005 Chapter 10: Server Load Balancing 197

With phash however, when more servers go down, then you will not have an even load distri-

bution as you would with the standard hash metric.

Tunable Hash

By default, the hash metric has used the client’s source IP address as the parameter for direct-

ing 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 will be 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 con-

nections over time.


Round Robin

With the roundrobin metric, new connections are issued to each server in turn; that is, the

first real server in the group gets the first connection, the second real server gets the next con-

nection, 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 first 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 will receive a weight twice as large.

NOTE – The effects of the response weighting apply directly to the real servers and are not

necessarily confined 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 fluc-

tuations in traffic distribution for the real server groups that use the leastconns or roun-




tuations in traffic distribution for the real server groups that use the leastconns or roun

drobin 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 band-

width used, the smaller the weight assigned to the server. Based on this weighting, the subse-

quent 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 confined 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 band-

width weights are applied on top of the leastconns or round-robin calculations for the

affected real servers. Since the bandwidth weight changes dynamically, this can produce

fluctuations in traffic distribution for the real server groups that use the leastconns or roun-

drobin 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 specified 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 timesthe number of connections as a server with a weight of 1. To set weights, enter the following

commands:

Readjusting server weights based on SNMP health check response


>> Real server# weight 10 (10 times the number of connections)




Readjusting server weights based on SNMP health check response

Alteon OS can be configured 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:

For more information on configuring SNMP health checks, see “SNMP Health Check” on

page 442.

>> # /cfg/slb/adv/snmphc < SNMP health script number>

>> SNMP Health Check 1# weight e (Enable weighting via SNMP

health check)


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:

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:

Values average from approximately 500 HTTP connections for slower servers to 1500 for

>> # /cfg/slb/real <real server number> (Select the real server)>> Real server# tmout 4 (Specify an even numbered interval)


>> Real server# maxcon 1600 (Allow 1600 connections maximum)




quicker, multiprocessor servers. The appropriate value also depends on the duration of eachsession 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 traffic accessing a

real server. The CLI specifies a range of 0 to 200K connections per real server. A maxcon

value of 0 allows the specified real server to handle up to its maximum number of connections,

or the switch’s maximum of 2 Million connections.


1. To configure unlimited connections, set the real server maxcon value to zero.


Backup/Overflow Servers

A real server can backup other real servers and can handle overflow traffic 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 defines real server 4 as a backup for real

servers 1 and 2:

>> # Main# /cfg/slb/real <x>/maxconCurrent max connections: 200000Max connections 0 means unlimited connectionsEnter new max connections [0-200000]: 0Current max connections: 200000Pending max connections: 0

>> # apply>> # save

>> # /cfg/slb/real 4 (Select real server 4 as backup)




In a similar fashion, a backup/overflow server can be assigned to a real server group. If all real

servers in a real server group fail or overflow, the backup comes online.

Real server groups can also use another real server group for backup/overflow:

( p)

>> Real server 4# rip 200.200.200.5 (Assign backup IP address)>> Real server 4# ena (Enable real server 4)

>> Real server 4# /cfg/slb/real 1 (Select real server 1)

>> Real server 1# backup 4 (Real server 4 is backup for 1)


>> Real server 2# backup 4 (Real server 4 is backup for 2)

>> # /cfg/slb/group <real server group number> (Select real server group)

>> Real server group# backup r4 (Assign real server 4 as backup)

>> # /cfg/slb/group <real server group number> (Select real server group)

>> Real server group# backup g2 (Assign real server group 2 asbackup)


Content Intelligent Server Load Balancing

Alteon OS allows you to load balance HTTP requests based on different HTTP header infor-

mation, such as “Cookie:” header for persistent load balancing, “Host:” header for virtual host-

ing, or “User-Agent” for browser-smart load balancing.

URL-Based Server Load Balancing on this page

“Virtual Hosting” on page 207

“Cookie-Based Preferential Load Balancing” on page 210

“URL Hashing for Server Load Balancing” on page 214

“Header Hash Load Balancing” on page 216

URL-Based Server Load Balancing

URL-based SLB allows you to optimize resource access and server performance. Content dis-

persion can be optimized by making load-balancing decisions on the entire path and filename

of each URL.

NOTE – Both HTTP 1.0 and HTTP 1.1 requests are supported.




For URL matching you can configure up to 512 strings comprised of 40 bytes each. Each URL

request is then examined against the URL strings defined for each real server. URL requests

are load balanced among multiple servers matching the URL, according to the load balancing

metric configured for the real server group (leastConns is the default).

In Figure 10-6, the following criteria are specified 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 serv-

ers have been defined with the “any” string.


Figure 10-6 URL-Based Server Load Balancing

Alteon Application

Switch

String matching for:

images

/product

.gif

.jpg


/product

.cgi

.bin

.exe


/product .htmlIn groups with multiple servers,

traffic is distributed within the

group via standard SLB metric

or URL hashing

GET/www.foo.com/event/reg.bin

GET/www.foo.com/product/abc.html

GET/www.foo.com/images/abc.gif

1

2

34

5 6

2




Configuring URL-Based Server Load BalancingTo configure URL-based SLB, perform the following steps:

1. Before you can configure SLB string-based load balancing, ensure that the switch has

already been configured 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.


Define an IP interface on the switch.


Define a real server group and set up health checks for the group.

Define a virtual server on virtual port 80 (HTTP), and assign 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 configure your network for SLB, see “Server Load Balancing” on

page 181.


2. Define the string(s) to be used for URL load balancing.

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 cacherequests. 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

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

>> # /cfg/slb/layer7/slb/addstr|remstr <l7lkup|pattern>




g g g

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 defined 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 configured with the load balance string ( / ) only, it will only handle requests to

the root directory. For example, the server will handle any files in the root directory:

//index.htm /default.asp

/index.shtm

3. Apply and save your configuration changes.

4. Identify the defined string IDs.

For easy configuration and identification, each defined string is assigned an ID number, asshown in the following example:

>> # /cfg/slb/layer7/slb/cur

ID SLB String

1 any

2 .gif




5. Configure one or more real servers to support URL-based load balancing.

6. Add the defined string(s) to the real server using the following command:

where ID is the identification number of the defined string.

NOTE – If you don't add a defined string (or add the defined string “any”) the server will han-dle any request.

A server can have multiple defined strings. For example:

“/images”

3 /sales

4 /xitami

5 /manual

6 .jpg

>> # /cfg/slb/real 2/layer7/addlb <ID>


“/sales”

“.gif”

With these defined 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.

8. Enable DAM on the switch or configure proxy IP addresses and enable proxy on the cli-

ent port.

DAM and proxy IPs allow you to perform port mapping for URL load balancing.

Enable DAM

Configure a proxy IP address and enable proxy on the client port

>> # /cfg/slb/on (Turn SLB on)

>> # /cfg/slb/adv/direct ena

>> # /cfg/slb/direct dis>> # /cfg/slb/pip>> Proxy IP Address# add 12.12.12.12

dd # (U b d IP)




For more information on proxy IP addresses, see “Proxy IP Addresses” on page 219.

9. Enable URL-based SLB on the virtual server(s).

Statistics for URL-Based Server Load Balancing

To show the number of hits to the SLB or cache server, use this command:

>> Proxy IP Address# type port (Use port-based proxy IP)>> # /cfg/slb/port 2/proxy ena (Enable proxy on client port)

>> # /cfg/slb/virt <virtual server number >/service 80/httpslb urlslb

>> # /stats/slb/layer7/str


Sample Statistics:

Virtual HostingAlteon OS 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 incl de the host header Alteon OS enables ser ice pro iders to create a single ir

ID SLB String Hits

1 any 73881

2 .gif 0

3 /sales 0

4 /xitami 162102

5 /manual 0

6 .jpg 0




207

HTTP 1.1 to include the host header, Alteon OS enables service providers to create a single vir-tual 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 configuration information.

An HTTP/1.0 request sent to an origin server (not a proxy server) is a partial URL insteadof 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:



Host: www.nortelnetworks.com


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 will forward the request to servers representing dif-

ferent customers’ Web sites.

The network administrator needs to define a domain name as part of the 128 supported

URL strings.

The switch performs string matching; that is, the string “nortelnetworks.com” or

“www.nortelnetworks.com” will match “www.nortelnetworks.com.”

Virtual Hosting Configuration OverviewThe sequence of events for configuring virtual hosting based on HTTP Host: headers is

described below:

1. The network administrator defines a domain name as part of the 128 supported URL

strings.

Both domain names “www.company-a.com” and “www.company-b.com” resolve to the same

IP address In this example the IP address is for a virtual server on the switch



315394-J, January 2005208

Chapter 10: Server Load Balancing

IP address. In this example, the IP address is for a virtual server on the switch.

2. “www.company-a.com” and “www.company-b.com” are defined as URL strings.

3. Server Group 1 is configured with Servers 1 through 8.

Servers 1 through 4 belong to “www.company-a.com” and Servers 5 through 8 belong to

“www.company-b.com.”

4. The network administrator assigns string “www.company-a.com” to Servers 1 through 4

and string “www.company-b.com” to Servers 5 through 8.

5. The application switch inspects the HTTP host header in requests received from the cli-

ent.

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.


Configuring the “Host” Header for Virtual Hosting

To support virtual hosting, configure the switch for Host header-based load balancing with the

following procedure:

1. Before you can configure host header-based server load balancing, ensure that the switch

has already been configured for basic SLB:

Assign an IP address to each of the real servers in the server pool. Define an IP interface on the switch.


Assign servers to real server groups.

Define virtual servers and services.

For information on how to configure your network for server load balancing, see “Server Load

Balancing” on page 181.

2. Turn on URL parsing for the virtual server for virtual hosting.

3 Define the host names

>> # /cfg/slb/virt 1 (Select the virtual IP for host

header-based SLB)

>> Virtual Server 1 # service 80 (Select the HTTP service)

>> Virtual Server 1 http Service # httpslb host




209

3. Define the host names.

4. Configure the real server(s) to handle the appropriate load balancing string(s).

To add a defined string:


NOTE – If you don't add a defined string (or add the defined string “any”), the server will han-

dle any request.

>> # /cfg/slb/layer7/slb/addstr "www.customer1.com">> Server Loadbalance Resource# addstr "www.customer2.com">> Server Loadbalance Resource# addstr "www.customer3.com"

>> # /cfg/slb/real 2 ( Select the real server)

>> Real Server 2 # Layer7

>> Real Server 2 Layer 7 Commands # addlb < ID>(Specify the string ID)


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 iden-

tify them as “Gold,” “Silver,” or “Bronze” customers. Using cookies, you can distinguish indi-

viduals 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 Chapter 17 “Persistence”.”

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 fol-

lowing methods:

Individual User



315394-J, January 2005210


Individual User

Specific individual user could be distinguished by IP address, login authentication, or per-

manent HTTP cookie.

User Communities

Some set of users, such as “Premium Users” for service providers who pay higher mem-

bership fees than “Normal Users” could be identified by source address range, login

authentication, or permanent HTTP cookie.

Applications

Users could be identified by the specific application they are using. For example, priority

can be given to HTTPS traffic that is performing credit card transactions versus HTTP

browsing traffic.

Content

Users could be identified by the specific content they are accessing.

Based on one or more of the criteria above, you can load balance requests to different server

groups.


Configuring Cookie-Based Preferential Load Balancing

To configure cookie-based preferential load balancing, perform the following procedure.

1. Before you can configure header-based load balancing, ensure that the switch has



Define an IP interface on the switch. Define each real server.




page 181.

2. Turn on URL parsing for the virtual server.

>> # /cfg/slb/virt 1>> Virtual Server 1 # service 80>> Virtual Server 1 http Service # httpslb cookieEnter Cookie Name: sidEnter the starting point of the Cookie value [1-64]: 1Enter the number of bytes to extract [1-64]: 6

Look for Cookie in URI [e|d]: d




211

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)

d = looks for the cookie in the cookie header instead of the URI (disables searching for cookie

in the URI)

3. Define the cookie values.

Since a session cookie does not exist in the first request of an HTTP session, a default server or“any” server is needed to assign cookies to a “None” cookie HTTP request.

|

>> # /cfg/slb/layer7/slb/addstr "Gold">> # addstr "Silver">> # addstr "Bronze"


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 defined 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 will be forwarded to Real Server 1.

Request 3 comes in with “Silver” cookie; it will be forwarded to Real Server 2.

Request 4 comes in with “Bronze” cookie; it will be forwarded to Real Server 3.

Request 5 comes in with “Titanium” cookie; it will be forwarded to Real Server 4, since itdoes not have an exact cookie match (matches with “any” configured at Real Server 4).

4. Configure the real server(s) to handle the appropriate load balance string(s).






315394-J, January 2005212


g


dle any request.

5. Enable DAM on the switch or configure proxy IP addresses and enable proxy on the cli-

ent port.

To use cookie-based preferential load balancing without DAM, you must configure 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 configure the

remaining ports with proxy disabled.


Browser-Smart Load Balancing

HTTP requests can be directed to different servers based on browser type by inspecting the

“User-Agent” header. For example,



Accept: text/html, image/gif, image/jpegTo allow the switch to perform browser-smart load balancing, perform the following proce-

dure.

1. Before you can configure browser-based load balancing, ensure that the switch has






2. Turn on URL parsing for the virtual server for “User-Agent:” header.

>> # /cfg/slb/virt 1/service 80/httpslb browser




213


4. Configure the real server(s) to handle the appropriate load balancing string(s).


dle any request.

Use the following command to add a defined string:


>> # /cfg/slb/layer7/slb/addstr "Mozilla">> Server Loadbalance Resource# addstr "Internet Explorer">> Server Loadbalance Resource# addstr "Netscape"



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 algo-

rithm 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 client’s browser is configured to send Web requests to a non-

transparent cache (the IP address of the configured 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.

Virtual Server IP Address:

$

$$




315394-J, January 2005214


Figure 10-7 Using URL hashing to Load Balance Nontransparent Caches

Configuring 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 configuring hash or minmisses as the

metric, the switch uses the number of bytes in the URI to calculate the hash key.

If the host field exists and the switch is configured to look into the Host: header, the switch

uses the Host: header field to calculate the hash key.

Client's browser is configured

to send Web requests to the

origin server via the virtual server

205.178.13.243

Non-Transparent

Cache Farm

$


To configure URL hashing, perform the following procedure:

1. Before you can configure URL hashing, ensure that the switch has already been config-

ured for basic SLB with the following tasks:






Configure load-balancing algorithm for hash or minmiss.

Enable SLB.

For information on how to configure your network for SLB, see “Server Load Balancing”

on page 181.”

Define server port and client port.

2. Enable URL hashing.

H hi i b d th URL i l di th HTTP H t h d (if t) t i

>> # /cfg/slb/virt 1>> Virtual Server 1 # service 80>> Virtual Server 1 http Service # httpslb urlhashEnter new hash length [1-255]: 25




Hashing is based on the URL, including the HTTP Host: header (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>


Header Hash Load Balancing

Alteon OS allows you to hash on any selected HTTP header. To configure the application

switch for load balancing based on header hash, perform the following procedure:

1. Ensure that the switch has already been configured for basic SLB:





2. Enable header hashing.


>> # /cfg/slb/virt 1>> Virtual Server 1 # service 80>> Virtual Server 1 http Service # httpslb headerhashSelect Operation: noneEnter new HTTP header name: User-agentEnter new hash length [1-255]: 25

>> # /cfg/slb/group 1/metric <hash| minmisses>





Inserting the “X-Forwarded-For” Header in HTTP

Requests

Alteon OS 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 cli-

ent 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 configure the application switch to insert the “X-Forwarded-For” header, perform the fol-

lowing procedure:

1. Ensure that the switch has already been configured for basic SLB:






2. Enable client proxy operation mode on the real servers used in load balancing.

3 On the virtual server attached to the real servers enable the X Forwarded For header

>> # /cfg/slb/real 1/proxy ena




3. On the virtual server attached to the real servers, enable the X-Forwarded-For header.


>> # /cfg/slb/virt 1/service 80/xforward ena

>> # apply>> # save


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 Alteon Application Switch. In complex

network topologies, routers and other devices can create alternate paths around the Alteon

Application Switch managing SLB functions (see Figure 10-4 on page 186). Under such con-

ditions, the Alteon Application Switch with Alteon OS provides the following solutions:

“Virtual Matrix Architecture” on page 218

“Proxy IP Addresses” on page 219

“Mapping Ports” on page 225

“Direct Server Return” on page 228

“Direct Access Mode” on page 230

“Delayed Binding” on page 234

Virtual Matrix Architecture

Virtual Matrix Architecture (VMA) is a hybrid architecture that takes full advantage of the dis-

tributed processing capability in Alteon Application Switches. With VMA, the switch makes

optimal use of system resources by distributing the workload to multiple processors, therebyimproving switch performance and increasing session capacity. VMA also removes the topol-




ogy constraints introduced by using Direct Access Mode (DAM). By default, VMA is enabled

on the Alteon Application Switch (/cfg/slb/adv/matrix).


Proxy IP Addresses

In complex network topologies (see Figure 10-4 on page 186), SLB functions can be managed

using a proxy IP address on the client switch ports.

When the client requests services from the switch’s virtual server, the client sends its own IP

address for use as a return address. If a proxy IP address is configured for the client port on the

switch, the switch replaces the client’s source IP address with the switch’s 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 switch’s proxy IP address as the destination address for any response.

SLB traffic 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 cli-

ent 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” on page 230).




Proxy IP Address Configuration

Starting from Alteon OS 22.0, proxy IP addresses are no longer tied to the switch processor.

The proxy address can be associated with port or VLAN. A proxy IP address can be based on a

port or a VLAN. Up to 32 proxy IP addresses may be configured as needed for SLB.

When configuration is port-based, the Alteon Application Switch uses the ingress port to

select a proxy IP address.

When configuration 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” on page 221).

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

To allow selection of a proxy IP address based on the port, and to assign a proxy IP address,

enter the following commands from the CLI:

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 be configured, are

now inactive on the Alteon Application Switch.

NOTE – WAN Link Load Balancing (see Chapter 12) requires use of port-based proxy IP

addresses; VLAN-based proxy IP addresses cannot be used.

>> # /cfg/slb/pip/type port (Select port-based proxy IP address)

>> # /cfg/slb/pip/add (Add a proxy IP address)

Enter Proxy IP address: 10.10.10.1

Enter port <1 to 28> or block <first-last>: e.g. 1 2 3-101-3 (Add proxy IP address to ports 1-3)

New pending: 1: 10.10.10.1 port 1-3





VLAN-based Proxy IP Addresses

Since traffic is usually segregated by VLANs, selection of proxy IP address can be determined

based on the VLAN information contained in the packet.

To allow selection of the proxy IP address to be based on the ingress VLAN, enter the follow-

ing command from the CLI:

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. How-

ever, 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 filter. Egress port or VLAN-based

proxy IP address should be applied only to Web Cache Redirection (WCR) filtering.

>> # /cfg/slb/pip/type vlan (Choose VLAN as the pip type)

>> Proxy IP Address# add (Add a proxy IP address)

Enter Proxy IP address: 10.10.10.1Enter VLAN <1 to 4090> or block <first-last>: e.g. 1 2 3-102 (Assign proxy IP address to VLAN 2)

New Pending: 1: 10.10.10.1 vlan 2

>> # /cfg/slb/virt<x>

/service<y>

/epip ena(Select proxy IP based on egress port

or VLAN for this virtual service)

>> # /cfg/slb/filt <x>/adv/epip ena (Select proxy IP based on egress port




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.

or VLAN for a WCR filter)


Proxy IP Addresses in Filters

In releases of Alteon OS prior to version 22.0, only four proxy IP addresses could be config-

ured, and client proxy was enabled in the filtering advanced menu. The application switch used

the configured proxy IP address for the VMA switch port (SP) to replace client’s source IP

address. With the current Alteon OS software, you can configure a unique proxy IP address for

a filter in the filtering advanced menu. To configure a proxy IP address on a filter, enter the fol-

lowing commands.

If no proxyip is configured in Filter Advanced menu then the Alteon Application Switch uses

the proxy IP address configured in /cfg/slb/pip menu. If proxy IP addresses are configured 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.

Source Grouping: Using a Virtual Server IP Address as

the Proxy IP Address

For outgoing proxy servers that initiate flows from within the server farm, a virtual server IP

dd fi d th Alt A li ti S it h b b tit t d th ’

>> # /cfg/slb/filt <filter #>/adv/proxyipCurrent proxy IP address: anyEnter 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)



315394-J, January 2005

222 Chapter 10: Server Load Balancing

address configured on the Alteon Application Switch can be substituted as the proxy server’s

source IP address. To do so, the Alteon Application Switch allows a virtual server IP address

configured 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 Alteon OS, 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 traffic.

In the current release, Alteon OS can mask real IP addresses of the servers in the server farm

with the virtual server IP address configured on the Alteon Application Switch, when the real

servers initiate traffic flows. The benefit 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 embedthat address as their source IP address, thus conserving use of Public IP addresses.


For example, if virtual server IP 50.50.50.1 is configured on the switch, and proxy servers are

to share this address, configure both proxy and virtual server IPs with the same address:

Configuring Proxy IP Addresses

The following procedure can be used for configuring proxy IP addresses:

1. Disable server processing on affected switch ports.

When implementing proxies, switch ports can be reconfigured to disable server processing.

Referring to the Table 10-2 on page 190, the following revised port conditions are used:

>> # /cfg/slb/virt 1/vip 50.50.50.1>> # /cfg/slb/pip/add 50.50.50.1

Table 10-4 Proxy Example: Port Usage

Port Host L4 Processing

1 Server A None

2 Server B None

3 Server C None

4 Back-end NFS server provides centralized content for all three real

servers. This port does not require switching features.

None

5 Client router A connects the switch to the Internet where all client Client



315394-J, January 2005

Chapter 10: Server Load Balancing 223

The following commands are used to disable server processing on ports 1-3:

5 Client router A connects the switch to the Internet where all client

requests originate.

Client

6 Client router B also connects the switch to the Internet where all client

requests originate.

Client

>> # /cfg/slb/port 1 (Select switch port 1)

>> SLB port 1# server dis (Disable server processing on port 1)

>> SLB port 1# /cfg/slb/port 2 (Select switch port 2)


>> SLB port 2# /cfg/slb/port 3 (Select switch port 3)



2. Configure a unique proxy address and enable proxy for the client ports.

Configure a unique proxy IP address and enable proxy on the client ports:

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 youmust 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.

>> # /cfg/slb/pip (Select proxy IP menu)

>> Proxy IP Address# type port (Set proxy IP base type to port)

>> Proxy IP Address# add 200.200.200.68 (Set proxy IP address)

>> # /cfg/slb/port 5/proxy ena (Select network port 5 and enable proxy)

>> SLB port 5# /cfg/slb/port 6 (Select network port 6)>> SLB port 6# proxy ena (Enable proxy)



315394-J, January 2005



Mapping Ports

An Alteon 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” on

page 232), mapping is required when administrators choose to execute their real server pro-

cesses 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 configuration.

Port mapping is configured 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 follow-

ing:

NOTE – If filtering is enabled, a proxy IP address is configured, or URL parsing is enabled on

any switch port, then port mapping is supported with Direct Access Mode (DAM). For infor-

mation about DAM, refer to “Direct Access Mode” on page 230.

>> # /cfg/slb/virt 1/service 80 (Select virtual server port 80)

>> Virtual Server 1 http Service# rport 8004 (Map to real port 8004)



315394-J, January 2005


Mapping a Single Virtual Server Port to Multiple Real

Server Ports

To take advantage of multi-CPU or multi-process servers, Alteon OS can be configured to map

a single virtual port to multiple real ports. This capability allows the site managers, for exam-

ple, to differentiate users of a service by using multiple service ports to process client requests.

An Alteon Application Switch supports up to 16 real ports per server when multiple rports

are enabled. This feature allows the network administrator to configure 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 Alteon Applica-

tion Switch treats the real server IP address/port mapping combination as a distinct real server.

NOTE – For each real server, you can only configure one service with multiple real ports.


Consider the following network:

Figure 10-8 Basic Virtual Port to Real Port Mapping Configuration

Domain Name Virtual Server IP

Address

Ports Activated Port Mapping Real Server IP

Address

www.right.com 192.168.2.100 80 (HTTP) 8001 (rport 1)

8002 ( 2)

192.168.2.1 (RIP 1)

192 168 2 2 (RIP 2)

Real Servers

Alteon Application

Switch

Web Clients

Internet

Web Host

Routers

192.168.2.1

192.168.2.2

192.168.2.3

192.168.2.4

8001

8002

8001

8002

8001

8002

8001

8002



315394-J, January 2005


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. Sinceeach 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

8002 (rport 2) 192.168.2.2 (RIP 2)

192.168.2.3 (RIP 3)

192.168.2.4 (RIP 4)




4. Turn on multiple rport for Port 80.

5. Add the ports to which the Web server listens.

Direct Server Return

Some clients may need direct access to the real servers (for example, to monitor a real server

from a management workstation). The 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

flowing from servers to clients, such as with content providers or portal sites that typically

have asymmetric traffic 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 splic-

>> # /cfg/slb/virt 1/service 80/rport 0

>> # /cfg/slb/real 1/addport 8001 (Add port 8001 to real server 1)

>> # addport 8002 (Add port 8002 to real server 1)

>> # /cfg/slb/real 2/addport 8001 (Add port 8001 to real server 2)>> # addport 8002 (Add port 8002 to real server 2)







315394-J, January 2005


g g q g p

ing.

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 Figure 10-9:

Figure 10-9 Direct Server Return

1. A client request is forwarded to the Alteon Application Switch.

2. Because only MAC addresses are substituted, the switch forwards the request to the best

server, based on the configured load-balancing policy.

3. The server responds directly to the client, bypassing the switch, and using the virtual

server IP address as the source IP address.

To set up DSR, use the following commands:

>> # /cfg/slb/real <real server number>/submac ena

Internet

2

Layer 2 Switch

Alteon Application

SwitchServer farm

Client

1

3



315394-J, January 2005


g>> # /cfg/slb/virt <virtual server number>/service <service number>/nonat ena


Direct Access Mode

Direct Access Mode (DAM) allows any client to communicate with any real server’s load-bal-

anced service. Also, with DAM enabled, any number of virtual services can be configured to

load balance a real service.

Direct Access Mode enables both Client and Server processing on the same port to handle traf-

fic that requires direct access to real servers.

Configuring Global Direct Access Mode

Direct access mode can be configured globally on the switch using the following command:

When DAM (/cfg/slb/adv/direct) is enabled on a switch, any client can communicate

with any real server’s load-balanced service. Also, with DAM enabled, any number of virtual

services can be configured to load balance a real service.

With Direct Access Mode, traffic 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:

>> Main# /cfg/slb/adv/direct eCurrent Direct Access Mode: disabled

New Direct Access Mode: enabled



315394-J, January 2005


Direct access to real servers for management or administration

One real server serving multiple virtual server IP (VIP) addresses

Content intelligent switching, which requires traffic to go to specific real servers based on

inspection of HTTP headers, content identifiers such as URLs and cookies, and the pars-ing of content requests.

For more information see “Content Intelligent Server Load Balancing” on page 202.

NOTE – When DAM is enabled on a switch, port mapping and default gateway load balancing

is supported only when filtering is enabled, a proxy IP address is configured, 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” on page 202.

However, you also wish to load balance a stateless protocol such as UDP, which by its nature

cannot be recorded in a session entry in the switch’s session table.

In order to block use of DAM for the UDP protocol (service port 9200), enter the following

commands:

NOTE – 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 dis-

abled 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 DAM cannot be disabled for FTP and RTSP services

>> Main# /cfg/slb/adv/direct e (Enable DAM globally on the switch)

>> /cfg/slb/virt 1/service 9200/direct disable



315394-J, January 2005


NOTE – 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 AddressesProxy IP addresses are used primarily to eliminate SLB topology restrictions in complex net-

works (see “Proxy IP Addresses” on page 219). Proxy IP addresses can also provide direct

access to real servers.

If the switch is configured with proxy IP addresses and the client port is enabled for proxy, the

client can access each real server directly using the real server’s 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 beenabled on the server port regardless of the proxy setting and SLB is still accessed using the

virtual server IP address.

Mapping Ports

When SLB is used without proxy IP addresses and without DAM, the Alteon 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 bemishandled by SLB processing as it returns through the Alteon Application Switch, with the

real server IP address getting remapped back to the virtual server IP address on the Alteon

Application Switch



315394-J, January 2005


Application Switch.

First, two port processes must be executed on the real server. One real server port will handle

the direct traffic, and the other will handle SLB traffic. Then, the virtual server port on the

Alteon Application Switch must be mapped to the proper real server port.


In Figure 10-10, clients can access SLB services through well-known TCP port 80 at the vir-tual server’s IP address. The Alteon 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 server’s IP address.

Figure 10-10 Mapped and Nonmapped Server Access

NOTE – Port mapping is supported with DAM when filtering is enabled, a proxy IP address is

configured, or URL parsing is enabled on any switch port.

For more information on how to map a virtual server port to a real server port, see “Mapping

Ports” on page 225.

Monitoring Real Servers

Typically, the management network is used by network administrators to monitor real servers

80

8000

80

Virtual Server on the

Alteon Application

Switch Real

Server

Client

Network

Direct Access

via Real Server IP & Port

Layer 4 Mapped Access

via Virtual Server IP & Port



315394-J, January 2005


Typically, the management network is used by network administrators to monitor real servers

and services. By configuring the mnet and mmask options of the SLB Configuration 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 cannotaccess the virtual services being load balanced.

The mnet and mmask options are described below:

mnet: If defined, management traffic with this source IP address is 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 traffic 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 sat-

urated with invalid traffic.

Typically, a three-way handshake occurs before a client connects to a server. The client sends

out a synchronization (SYN) request to the server. The server allocates an area to process the

client requests, and acknowledges the client by sending a SYN ACK. The client then acknowl-

edges the SYN ACK by sending an acknowledgement (ACK) back to the server, thus complet-

ing the three-way handshake.

Figure 10-11 on page 234 illustrates a classic type of SYN DoS attack. If the client does not

acknowledge the server’s 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.

ClientServer

Normal Request

Client sends a SYN request

Server reserves session and sends SYN ACK

Client sends an ACK or DATA REQ

Server responds with DATA

ClientServer

DoS SYN Attack




315394-J, January 2005


Figure 10-11 DoS SYN Attacks without Delayed Binding

C eServer reserves session and sends SYN ACK

Server continues reserving sessions.Server is eventually saturated and

cannot process legitimate requests.

Client ignores SYN ACK and continues to send new SYN requests


Using an Alteon Application Switch with delayed binding, as illustrated in Figure 10-12 on page 235, the Alteon Application Switch intercepts the client SYN request before it reaches the

server. The Alteon Application Switch responds to the client with a SYN ACK that contains

embedded client information. The Alteon Application Switch does not allocate a session until

a valid SYN ACK is received from the client or the three-way handshake is complete.

Internet

Client Alteon Application Switch

Normal Request with Delayed Binding


Switch responds with special SYN ACK

Client sends an ACK or DATA REQ

Switch sends a SYN request to server

Switch recognizes valid three-way handshake

Server responds with SYN ACK

Server responds with DATA and switch splices connection to client

Switch sends ACK or DATA REQ

Server

Internet

Client Alteon Application Switch

DoS SYN Attack with Delayed Binding


Server



315394-J, January 2005


Figure 10-12 Repelling DoS SYN Attacks With Delayed Binding

Once the Alteon Application Switch receives a valid ACK or DATA REQ from the client, the

Alteon 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 Alteon Application Switch delays binding the client session to the serveruntil the proper handshakes are complete.

q

Switch responds with special SYN ACK

Switch responds with another SYN ACK

Client sends new SYN requests No session entry is made until a validthree-way handshake is complete.

Switch and server resources are

protected for legitimate requests


Thus, with delayed binding, two independent TCP connections span a session: one from theclient to the Alteon 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.

Configuring Delayed Binding

To configure your switch for delayed binding, use the following command:

NOTE – Enable delayed binding without configuring any HTTP SLB processing or persistent

binding types.

To configure delayed binding for cache redirection, see “Delayed Binding for Cache Redirec-

tion” on page 375.

Detecting SYN Attacks

In Alteon OS, SYN attack detection is enabled by default, whenever delayed binding is

>> # /cfg/slb/virt <virtual server number>/service <service type>/dbind



315394-J, January 2005


, y , y g

enabled. SYN attack detection:

Provides a way to track half open connections

Activates a trap notifying that the configured threshold is exceeded

Monitors DoS attacks and proactively signals alarm

Provides enhanced security

Improves visibility and protection for DoS attacks

The probability of a SYN attack is higher if excessive half-open sessions are being generated

on the Alteon Application Switch. Half-open sessions show an incomplete three-way hand-

shake 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 Alteon 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.



315394-J, January 2005





315394-J, January 2005


CHAPTER 11

Load Balancing Special Services

This chapter discusses server load balancing based on special services, such as source IP

addresses, FTP, LDAP, RTSP, DNS, WAP, IDS, and SIP.


“IP Server Load Balancing” on page 239 “FTP Server Load Balancing” on page 240

“TFTP Server Load Balancing” on page 241

“Lightweight Directory Access Server SLB” on page 242

“Domain Name Server (DNS) SLB” on page 245

“Real Time Streaming Protocol SLB” on page 253

“Wireless Application Protocol SLB” on page 263

“Intrusion Detection System SLB” on page 274

“Session Initiation Protocol Server Load Balancing” on page 293




315394-J, January 2005

239


IP Server Load Balancing

IP server load balancing allows you to configure your Alteon Application Switch for server

load balancing based on client’s IP address only. Typically, the client IP address is used with

the client port number to produce a session identifier. When the Layer 3 option is enabled, the

switch uses only the client IP address as the session identifier.

To configure the switch for IP load balancing:

>> # /cfg/slb/virt <virtual server number>

>> Virtual Server 1# layr3 ena>> Virtual Server 1# service ip>> Virtual Server 1 IP Service# group <group number >


IP server load balancing must be used if IP traffic is totally encrypted and you do not haveaccess to the content.

FTP Server Load Balancing

As defined in RFC 959, FTP uses two connections—one 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 will issue 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 ini-

tiates the connection to the control channel, the passive FTP mode does not pose a prob-

lem with firewalls and is the most common mode of operation.

Alteon OS supports both active and passive modes of FTP operation. You can switch from

active to passive or vice versa in the same FTP session.

FTP Network Topology Restrictions

FTP network topology restrictions are listed below:

FTP control and data channels must be bound to the same real server



315394-J, January 2005

240 Chapter 11: Load Balancing Special Services

FTP control and data channels must be bound to the same real server.

FTPP with port mapping is not supported.

Configuring FTP Server Load Balancing1. Make sure that a proxy IP address is enabled on the client port(s) or DAM is enabled.

2. Make sure the virtual port for FTP is set up for the virtual server.

3. Enable FTP parsing on both services FTP and FTP-Data.

>> # /cfg/slb/virt 1/service ftp

>> # /cfg/slb/virt 1/service 20/ftpp ena


4. To make your configuration changes active, enter apply at any prompt in the CLI.

TFTP Server Load Balancing

As defined in RFC 1350, Trivial File Transfer Protocol (TFTP) can only read and write filesfrom/to a remote server. TFTP uses UDP datagrams to transfer data. A transfer begins with a

request to read or write a file, which also serves to request a connection. If the server grants the

request, the connection is opened and the file is sent in fixed length blocks of 512 bytes.

Each data packet contains one block of data, and must be acknowledged by an acknowledg-

ment packet before the next packet can be sent. A data packet of less than 512 bytes signals ter-

mination of a transfer.

TFTP server load balancing server is similar to other types of server load balancing. It uses

configured SLB metric to select TFTP server. No additional commands are required to load

balance to TFTP servers.

Requirements

Load balancing service port 69 must be selected.

DAM must be enabled.

UDP must be enabled (/cfg/slb/virt <x>/service tftp/udp ena)

PIP i d b h i h d PIP f ll i

>> Virtual Server 1 ftp Service# apply



315394-J, January 2005

Chapter 11: Load Balancing Special Services 241

PIP is not supported because the server port is changed. PIP uses server port for allocating

a pport.

Multiple rports are not supported.

Configuring TFTP Server Load Balancing

1. Make sure that Direct Access Mode (DAM) is enabled.

2. Make sure the virtual port for FTP is set up for the virtual server.

3. Enable FTP parsing on both services FTP and FTP-Data.

>> # /cfg/slb/virt 1/service tftp

>> Virtual Server 1 ftp Service# ftpp ena

>> # /cfg/slb/virt 1/service 20/ftpp ena


4. To make your configuration changes active, enter apply at any prompt in the CLI.

Lightweight Directory Access Server SLB

As defined in RFC 2251, Lightweight Directory Access Protocol (LDAP) is an application-

level protocol between LDAP clients and servers, which allows clients to retrieve LDAP direc-

tory 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

A LDAP i i i L4 l d b l i d i b d d Af h

>> Virtual Server 1 ftp Service# apply



315394-J, January 2005


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 will disconnect the connection to the read serverand reinitiate another connection with the write server without the client’s knowledge. Once

the connection is set up with write server, all the later requests will go to the write server until

unbind request is received by the switch. All these operations occur within one TCP connec-

tion.

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 con-

nection is spliced.


Selectively Resetting a Real Server If a long-lived LDAP connection exceeds the Alteon Application Switch’s maximum session

length (32,768) minutes, the session will age out before the LDAP connection is closed. The

Alteon Application Switch may then create another session to accept the same connection data.

To prevent this, Alteon OS can be configured 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 follow-ing command:

Figure 11-2 shows four LDAP servers load balancing LDAP queries.

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

Al

Group 1LDAP

Internet

Real servers 20

21

22

10.10.10.20

10.10.10.21

10.10.10.22

10.10.10.26

vip 20.20.20.20

26



315394-J, January 2005


Figure 11-1 LDAP Load Balancing

Configuring LDAP SLB

1. Enable server load balancing.

>> # /cfg/slb/on

Alteon

Application

Switch

Client


2. Configure the four real LDAP servers and their real IP addresses.

3. Configure group 1 for LDAP.

>> # /cfg/slb/real 20>> Real server 20 # ena (Enable real server 20)

>> Real server 20 # rip 10.10.10.20 (Specify the IP address)

>> Real server 20 # layer7/ (Select the Layer 7 menu)

>> Real Server 20 Layer 7 Commands# ldapwr e (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)

>> # /cfg/slb/group 1 (Select real server group 1)

>> Real server group 1 # metric roundrobin (Specify the load balancing

metric for group 1)

>> Real server group 1 # add 20 (Add real server 20)>> Real server group 1 # add 21 (Add real server 21)

>> Real server group 1 # add 22 (Add real server 22)

>> Real server group 1 # add 26 (Add real server 26)



315394-J, January 2005


1. Configure and enable a virtual server IP address 1 on the switch.

2. Set up the LDAP service for the virtual server, and add real server group 1.

3. Enable delayed binding.

>> # /cfg/slb/virt 1/vip 20.20.20.20 (Specify the virt server IP

address)

>> Virtual Server 1# ena (Enable the virtual server)

>> Virtual Server 1# service ldap (Specify the LDAP service)

>> Virtual Server 1 LDAP Service# group 1 (Select the real server group)


Delayed binding is required in order to process session requests with a TCP three-way hand-shake.

4. Enable LDAP load balancing.

5. (Optional) Enable session reset for long LDAP connections.

6. Apply and save your configuration.

Domain Name Server (DNS) SLB

In Alteon OS, 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 groupof 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.

>> Virtual Server 1 LDAP Service# dbind ena(Enable delayed binding)

>> # /cfg/slb/virt 1/service ldap/ldapslb ena (Enable LDAP balancing)

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

>> Virtual Server 1 LDAP Service# apply>> Virtual Server 1 LDAP Service# save



315394-J, January 2005



Figure 11-2 shows four real servers load balancing UDP and TCP queries between two groups.

Figure 11-2 Layer 4 DNS Load Balancing

Alteon

Application

Switch

Group 1

UDPhealth udpdns

Internet

Group 2

TCPhealth dns

Real servers

Real servers

20

21

22

26

Client

10.10.10.20

10.10.10.21

10.10.10.22

10.10.10.26

vip 20.20.20.20



315394-J, January 2005246 Chapter 11: Load Balancing Special Services

NOTE – You can configure both UDP and TCP DNS queries for the same virtual server

IP address.

Preconfiguration Tasks


>> # /cfg/slb/on




Configuring UDP-based DNS Load Balancing

1. Configure and enable a virtual server IP address 1 on the switch.

2. Set up the DNS service for the virtual server, and add real server group 1.

3. Disable delayed binding.

Delayed binding is not required because UDP does not process session requests with a TCP

three-way handshake.

4. Enable UDP DNS queries.



address)


>> Virtual Server 1# service dns (Specify the DNS service)

>> Virtual Server 1 DNS Service# group 1 (Select the real server group)

>> Virtual Server 1 DNS Service# dbind dis (Disable delayed binding)

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

>> Virtual Server 1 DNS Service# apply>> Virtual Server 1 DNS Service# save




Configuring TCP-based DNS Load Balancing

1. Configure and enable the virtual server IP address 2 on the switch.

2. Set up the DNS service for virtual server, and select real server group 2.


address)


>> Virtual Server 2# service dns (Specify the DNS service)

>> Virtual Server 2 DNS Service# group 2 (Select the real server group)


3. Enable delayed binding.

4. As this is TCP-based load balancing, make sure to disable UDP DNS queries.


>> Virtual Server 2 DNS Service# dbind ena(Enable delayed binding)

>> Virtual Server 2 DNS Service# udp dis (Disable UDP balancing)

>> Virtual Server 2 DNS Service# apply>> Virtual Server 2 DNS Service# save



315394-J, January 2005Chapter 11: Load Balancing Special Services 249


Layer 7 DNS Load BalancingThe 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, Alteon OS allows you to load balance traffic based on

DNS names. To load balance DNS names, the host name is extracted from the query, pro-

cessed by the regular expressions engine, and the request is sent to the appropriate real server.

For example, Figure 11-3 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.

ClientAlteon Application

Switch

DNS Server Farm

DNS Queries A - G

DNS Queries H - M

Server 1

Server 2




Figure 11-3 Load Balancing DNS Queries

DNS Queries N - T

Server 3

DNS Queries U - Z

Server 4


To configure the switch for DNS load balancing, perform the following procedure:

1. Before you can configure DNS load balancing, ensure that the switch has already been

configured for basic SLB with the following tasks:



Define each real server (DNS server address).

Assign servers to real server groups. Define virtual servers and services.

Enable SLB.

For information on how to configure your network for SLB, see Chapter 10, “Server Load

Balancing.”

Define server port and client port.

2. Enable DNS load balancing.

3. If using a TCP-based DNS server, enable delayed binding (if using a UDP-based DNS

server, do not enable delayed binding).


>> # /cfg/slb/virt 1 ( Select the virtual server)

>> Virtual Server 1 # service 53 ( Select the DNS service)

>> Virtual Server 1 DNS Service # dnsslb ena( Enable DNS SLB)

>> Virtual Server 1 DNS Service# dbind ena





>> # /cfg/slb/layer7/slb/addstr www.[abcdefg]*.com >> Server Loadbalance Resource# addstr www.[hijklm]*.com

>> Server Loadbalance Resource# addstr www.[nopqrst]*.com >> Server Loadbalance Resource# addstr www.[uvwxyz]*.com



For easy configuration and identification, each defined string has an ID attached, as shown in


7. Add the defined string IDs to the real server using the following command:

NOTE – If you don't add a defined string (or add the defined string “any”) the server will han-

dle any request.


ID SLB String

1 any, cont 1024

2 www.[abcdefg]*.com, cont 1024

3 www.[hijklm]*.com, cont 1024

4 www.[nopqrst]*.com, cont 1024

5 www.[uvwxyz]*.com, cont 1024

>> # /cfg/slb/real 1/layer7/addlb 2>> # /cfg/slb/real 2/layer7/addlb 3>> # /cfg/slb/real 3/layer7/addlb 4





Real Time Streaming Protocol SLB

Real Time Streaming Protocol (RTSP) 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 Trans-

port Protocol) to format packets of multimedia content. RTSP is designed to efficiently broad-

cast 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 flow 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.

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

configured load-balancing metric. Typically, an RTSP client establishes a control connectionto an RTSP server over TCP port 554 and the data flows over UDP or TCP.

Alteon OS 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





For information on using RTSP with cache redirection, see “RTSP Cache Redirection” on page 376.

NOTE – This feature is not applicable if the streaming media (multimedia) servers use HTTP

protocol to tunnel RTSP traffic. To ensure that RTSP server load balancing works, make sure

the streaming media server is configured for RTSP protocol.


Supported RTSP ServersIn a typical scenario, the RTSP client issues several sequences of commands to establish con-

nections for each component stream of a presentation. There are several variations to this pro-

cedure, 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 proto-

cols 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 flow in the TCP

control connection itself. If UDP transport is chosen, the client and server negotiate a cli-

ent UDP port, which is manually configurable.

The real media files that the Real Server plays have the extension “.rm”, “.ram” or “.smil”.

QuickTime Streaming Server

QuickTime Streaming Server from Apple Incorporated supports a QuickTime presenta-

tion 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 configurable. The QuickTime files have the extension “.mov”.

Alteon OS can also support other RTSP-compliant applications (excludes Windows Media

Player because it is not RTSP compliant).

Configuring RTSP Load Balancing




In this example, the Alteon Application Switch is load balancing RTSP traffic between two

media server farms as shown in Figure 11-4. One group of media servers consist of QuickTimeservers and the other group of servers consist of RealNetworks servers. Each group has its own

virtual server IP address. For example, three Real Networks servers host media files for Nortel-

News; similarly, another three QuickTime servers host media files for AlteonNews. The con-

tent is duplicated among the servers in each group. Depending on the client request type, the

Alteon Application Switch is configured to load balance in the following way:

Retrieving files 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 files from the QuickTime server groupRTSP://www.NortelNews.com/*.mov is load balanced among the Quick Time media

servers using virtual IP address 40.40.40.100.

Figure 11-4 Load Balancing RTSP Servers

Follow this procedure to configure the topology illustrated in Figure 11-4:

1. At the Alteon Application Switch, before you start configuring RTSP load balancing:

Connect each QuickTime server to the layer 2 switch

2431314

1525

Clients

Alteon

Application

Switch

Internet

Router

IP 120.120.120.5

IP 40.40.40.10

IP 30.30.30.10

End-user streaming request

Video, audio, and text

IP 30.30.30.20

IP 30.30.30.30

IP 40.40.40.20

IP 40.40.40.30

QuickTime serversvirtual IP address 40.40.40.100

Real Networks servers

virtual IP address 30.30.30.100




Connect each RealNetworks server to the layer 2 switch

Configure the IP addresses on all devices connected to the Alteon Application Switch Configure the IP interfaces on the switch

Enable Virtual Matrix Architecture (VMA)

Enable Direct Access Mode (DAM)

Disable Bandwidth Management

Disable proxy IP addressing


>> # /cfg/slb/on


3. Configure IP addresses for the real servers.

4. Create a group to support RealNetworks servers.

5. Create a group to support QuickTime servers.

6. Create a virtual server for the RealNetworks servers.

To configure a virtual server for layer 4 load balancing of RTSP, select rtsp or port 554 as aservice for the virtual server.

>> # /cfg/slb/real 1/rip 30.30.30.10/ena (Define IP address for Real server 1)






>> # /cfg/slb/group 100 (Define a group)

>>Real Server Group 100# add 1 (Add real server 1)







>> # /cfg/slb/virt 1 (Select the virtual server)

>>Virtual Server 1# vip 30.30.30.100 (Set IP address for the virtual server

>>Virtual Server 1# service 554 (Add the RTSP service for the virtual

server)




server)

>>Virtual Server 1 rtsp Service# group 100 (Set the real server group)

>>Virtual Server 1 rtsp Service# /cfg/slb/ virt 1/ena(Enable virtual server)


7. Create a virtual server for the QuickTime servers.

To configure a virtual server for Layer 4 load balancing of RTSP, select rtsp or port 554 as

a service for the virtual server.

8. Enable server and client processing at the port level.





server)

>>Virtual Server 2 rtsp Service# group 200 (Set the Quicktime server group)>>Virtual Server 2 rtsp Service# /cfg/slb/virt ena(Enable virtual server)

>> # /cfg/slb/port 25 (Select the client port)

>>SLB port 25# client ena (Enable client processing)

>>SLB port 1# /cfg/slb/port 2 (Select the server port)

>>SLB port 2# server ena (Enable server processing)>>SLB port 2# /cfg/slb/port 3 (Select the server port)

>>SLB port 3# server ena (Enable server processing)







>>SLB port 14# /cfg/slb/port 15 (Select the server port)>>SLB port 15# server ena (Enable server processing)

>> SLB port 15# applySLB t 15#




Clients retrieving files of type RTSP://nortelnews.com/headlines.ram use virtual IP

address 30.30.30.100 of the RealNetworks server group and clients retrieving files of type

RTSP://nortelnews.com/headlines.mov use virtual IP address 40.40.40.100 of the

QuickTime server group.

>> SLB port 15# save


Content-Intelligent RTSP Load BalancingAlteon OS supports RTSP load balancing based on URL hash metric or string matching to load

balance media servers that contain multimedia presentations. Because multimedia presenta-

tions 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” on page 253.

Figure 11-5 shows two groups of media servers: Group 1 is configured for URL hashing and

group 2 is configured for string matching. The media servers are cache servers configured 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 Figure

11-5, an ISP is hosting audio-video files for NortelNews on media servers 1, 2, 3, and 4. The

domain name nortelnews.com associated with the virtual IP address 120.10.10.10 is config-

ured for URL hash.

The first request for http://nortelnews.com/saleswebcast.rm hashes to media

server 1. Subsequent requests for http://nortelnews.com/saleswebcast.rm fromother 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, pro-

vided saleswebcast and marketingwebcast media files are located in the origin servers.

Typically, a set of related files (audio, video, and text) of a presentation are usually placed

under the same directory (called container directory) Alteon OS URL hashing ensures that the




under the same directory (called container directory). Alteon OS 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-specific informa-

tion. For example, you have clients accessing audio-video files on StarWars1 and clients

accessing audio-video files on StarWars2. You can host the StarWars1 media files on media

servers 5 and 6 and host StarWars2 media files on media servers 7 and 8.


First request for

http://nortelnews.com/saleswebcast.rm

hashes to server 1

Alteon Application

Switch

Internet

Router

IP 120.120.120.5/24

IP 10.10.10.1

IP 10.10.10.2IP 10.10.10.3


URL hash

IP 10.10.10.5

IP 10.10.10.7

IP 10.10.10.6

IP 10.10.10.4

IP 10.10.10.8

1

2 3 4

5

6

7

8

RTSP load balancing

../starwars1.mov files

RTSP load balancing

../starwars2.mov files


String matching

Specialized cache servers

in reverse proxy mode

origin servers

Servers 1-4 hosting Sales

Webcast media files

Subsequent requests

http://nortelnews.com/saleswebcast.rm

hashes to server 1

1.

2.

7

23

4 5

86

9

25

1

2 3 4

56

7

8




Figure 11-5 Layer 7 RTSP Load Balancing


1. Before you start configuring RTSP load balancing, configure the application switch for

standard server load balancing as described in “Configuring Server Load Balancing” on

page 188:

Connect each Media server to the application switch

Configure the IP addresses on all devices connected to the switch

Configure 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)



Disable Bandwidth Management


2. Configure IP addresses for the real servers.

3. Create a group to support RealNetworks servers.

4. Create a group to support QuickTime servers.





>> # /cfg/slb/real 5/rip 10.10.10.5/ena (Define IP address for Real server 5)>> # /cfg/slb/real 6/rip 10.10.10.6/ena (Define IP address for Real server 6)








>> # /cfg/slb/gro p 200 (Define a group)










5. Create a virtual server for group 1 media servers.Configure a virtual server and select rtsp or port 554 as a service for the virtual server.

6. Configure 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.

7. Create another virtual server for group 2 media servers.

Configure a virtual server and select rtsp or port 554 as a service for the virtual server.

8. Configure string matching-based RTSP load balancing for group 2 servers.

Enable layer 7 pattern matching.




server)


>>Virtual Server 1 rtsp Service# /cfg/slb/virt 1 ena(Enable virtual server)

>> Virtual Server 1 rtsp Service# rtspslb hash


>>Virtual Server 2# vip 120.10.10.20 (Set IP address for the virtual server)


server)


>>Virtual Server 2 rtsp Service# /cfg/slb/virt 2 ena(Enable virtual server)

>> Virtual Server 2 rtsp Service# rtspslb pattern(E bl L 7 tt t hi )




Add URL strings.

Apply and save the configuration.

(Enable Layer 7 pattern matching)

>> # /cfg/slb/layer7/slb/addstr starwars1.mov(Add URL strings)

>> Server Loadbalance Resource# addstr starwars2.mov

>> Server Loadbalance Resource# apply>> Server Loadbalance Resource# save




Wireless Application Protocol SLBWireless Application Protocol (WAP) is an open, global specification 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 systems—with the

goal of inter-operability. A WAP Gateway translates Wireless Markup Language (WML)—

which is a WAP version of HTML—into HTML/HTTP so that requests for information can be

serviced by traditional Web servers.

To load balance WAP traffic among available parallel servers, the switch must provide persis-

tency so that the clients can always go to the same WAP gateway to perform WAP operation.





Figure 11-6 shows the user is first authenticated by the remote access server. In this example

the RADIUS servers are integrated with the WAP gateways.

Figure 11-6 Load Balancing WAP Gateways

Alteon OS allows you to configure the Alteon 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 i RADIUS/WAP i

Clients

Alteon Application

Switch

Virtual IP address: 10.10.10.10

Internet

RADIUS/WAP servers

Group 100

CDMA

GSM

Remote

Access

Server

34

1

2

3

Real 1: 1.1.1.100

Real 2: 2.2.2.100

Real 3: 3.3.100

1

2




RADIUS snooping, or RADIUS/WAP persistence.

The following topics are discussed in this section:

“WAP SLB with RADIUS Static Session Entries” on page 265

“WAP SLB with RADIUS Snooping” on page 267

“WAP SLB with Radius/WAP Persistence” on page 270


WAP SLB with RADIUS Static Session EntriesRADIUS, a proposed IETF standard is a client/server protocol that enables remote access serv-

ers 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 profiles in a

central database that all remote servers can share. It provides better security, allowing a com-

pany 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 shouldreceive 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 Alteon proprietary protocol that is used to establish communication between the

RADIUS servers and the Alteon 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 num-

ber, 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 trans-

mission. 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 traffic that does not

belong to that WAP gateway. If a Delete Session request is lost, it will be overwritten by

another Add Session request.




How WAP SLB Works with Static Session Entries

1. On dialing, the user is first 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 ses-

sion 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 traffic 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.

Configuring WAP SLB using Static Session Entries


1. Before you start configuring WAP load balancing:

Enable layer 3 server load balancing.

Enable UDP under the WAP services (ports 9200 to 9203) menu.

Configure for RADIUS services 1812, 1813, and 1645.

NOTE – The radius service number specified on the switch must match with the service speci-

fied on the server.

2. At the Alteon Application Switch, configure the switch for basic SLB.

>> # /cfg/slb/virt <number>/layr3 ena

>> # /cfg/slb/virt <number>/service <name|number>/udp ena





3. Configure IP addresses for the RADIUS/WAP Gateways.

>> # /cfg/slb/on

>> # /cfg/slb/real 1/rip 1.1.1.100 (Define address for WAP Gateway1)


>> # /cfg/slb/real 2/rip 2.2.2.100 (Define address for WAP Gateway 2)


>> # /cfg/slb/real 3/rip 3.3.3.100 (Define address for WAP Gateway 3)>> Real server 3# ena (Enable real server 3)


4. Create a group to load balance the WAP Gateways.

5. Enable the external notification from WAP gateway to add and delete session request if

you are using static session via TPCP.

6. Enable TPCP for adding and deleting WAP sessions.


WAP SLB with RADIUS Snooping

RADIUS snooping is similar to the static session entry method in the way that a static sessionentry is added to (or removed from) the switch for the WAP traffic for a user; it is different

from the static session entry method in the way that RADIUS accounting packets are snooped

by the Alteon switch instead of by the RADIUS server using TPCP.

Radius snooping allows the Alteon Application Switch to examine RADIUS accounting pack-

ets for client information. This information is needed to add to or delete static session entries in

the switch’s session table so that it can perform the required persistency for load balancing. A





>> # cfg/slb/adv/tpcp ena

>> # cfg/slb/wap/tpcp ena

>> WAP Options# apply>> WAP Options# save




p q p y g

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 traffic using the same virtual server IP address.

How WAP SLB Works with RADIUS Snooping

Before the RAS allows the WAP traffic 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 user’s name. If it

finds this information, the switch adds a session entry to its session table. If any of this infor-

mation is missing, the switch will 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 finds the needed information in a RADIUS Accounting Stop packet, it removes

the corresponding session entry from its table. The following steps occur for RADIUS snoop-

ing:

1. The user is authenticated on dialing.

2. The RAS establishes a session with the client and sends a RADIUS Accounting Start mes-

sage with the client IP address to the RADIUS server.

3. The switch snoops on the RADIUS accounting packet and adds a session entry if it finds

enough information in the packet.

4. The switch load balances the WAP traffic to a specific WAP gateway.

5. 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.

Consider the following items before configuring RADIUS snooping:

The same virtual server IP address must be used when load balancing both the RADIUS

accounting traffic and WAP traffic.

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 subse-

quent 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 gate-

ways 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.




g , , p

Persistence cannot be maintained if the user moves from one ISP to another, or if the base

of the user's 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.

Configuring WAP SLB using Radius Snooping


1. Before you start configuring WAP load balancing:


Enable layer 3 server load balancing.

Enable UDP under the WAP services (ports 9200 to 9203) menu.

Configure for RADIUS services 1812, 1813, and 1645.

NOTE – The radius service number specified on the switch must match with the service speci-

fied on the server.


3. Configure IP addresses for the RADIUS/WAP Gateways.

4. Create a group to load balance the WAP Gateways.

>> # /cfg/slb/virt <number>/layr3 ena



>> # /cfg/slb/on

>> # /cfg/slb/real 1/rip 1.1.1.100 (Define address for WAP Gateway1)










5. Enable the external notification from WAP gateway to add and delete session request if

you are using static session via TPCP.

6. Enable TPCP for adding and deleting WAP sessions.

/ g/ /g p ( f g p)

>>Real Server Group 100# add 1 (Add real server 1)>>Real Server Group 100# add 2 (Add real server 2)


>> # cfg/slb/adv/tpcp ena

>> # cfg/slb/wap/tpcp ena


7. Configure the following filter on the switch to examine a RADIUS accounting packet. Set

the basic filter parameters.

8. Enable proxy and RADIUS snooping.


NOTE – Alteon OS supports Virtual Router Redundancy Protocol (VRRP) and stateful

failover, using both static session entries and RADIUS snooping. However, active-active con-

figuration with Stateful Failover is not supported.

>> # /cfg/slb/filt 1 (Select the filter)

>> Filter 1 # ena (Enable the filter)

>> Filter 1 # dip 10.10.10.100 (Set the destination IP address)

>> Filter 1 # dmask 255.255.255.255 (Set the destination IP mask)

>> Filter 1 # proto udp (Set the protocol to UDP)

>> Filter 1 # dport 1813 (Set the destination port)

>> Filter 1 # action redir (Set the action to redirect)

>> Filter 1 # group 1 (Set the group for redirection)

>> Filter 1 # rport 1813 (Set server port for redirection)

>> Filter 1 # adv (Select the advanced filter menu)

>> Filter 1 Advanced# proxy ena (Enable proxy)>> Filter 1 Advanced# layer7 (Select the Layer 7 advanced

menu)

>> Layer 7 Advanced# rdsnp ena (Enable RADIUS snooping)

>> Layer 7 Advanced# apply

>> Layer 7 Advanced# save




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 first 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:

1. 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 authen-

tication request to the bound server.

2. The RAS establishes a session with the client and sends a RADIUS Accounting Start mes-sage to the RADIUS server on UDP port 1813.

3. 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 specific 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 9200–9203,

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.




Configuring WAP SLB using Radius/WAP Persistence



>> # /cfg/slb/on




8. Enable client and server ports and enable filtering on client ports.


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 organi-

zation).

Intrusion detection functions include:

Monitoring and analyzing both user and system activities

Analyzing system configurations and vulnerabilities

Assessing system and file integrity

Recognizing patterns typical of attacks

A l i b l ti it tt

>> # /cfg/slb/port 1/client ena

>> SLB port 1# filt ena (Enable filtering on port 1)

>> SLB port 1# /cfg/slb/port 2>> SLB port 2# /cfg/slb/server ena>> SLB port 1# /cfg/slb/port 3>> SLB port 3# /cfg/slb/server ena>> SLB port 3# /cfg/slb/port 4

>> SLB port 4# /cfg/slb/server ena

>> SLB port 4# apply>> SLB port 4# save




Analyzing abnormal activity patterns

Tracking user policy violations

Intrusion detection devices inspect every packet before it enters a network, looking for any

signs of an attack. The attacks are recorded and logged 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 WorksAlteon OS 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 configuring IDS load balancing:

1. Set up the IDS servers.

Determine if you want to setup the IDS servers in stealth mode (without IP addresses) or with

non-routable IP addresses. See Table 11-1 on page 276 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 traffic based on protocols.

Choose the metric for the group: hash

Choose the health check for the group: link, icmp, arp, or snmp

Enable IDS on the group

Select the type of traffic that is captured by the group by defining the IDS rport value.(The default for IDS rport is any).

If multiple groups are configured for the same rport then only ONE of the groups will be

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 Alteon Application Switch to make a copy of the

frames ingressing the port and forward the copy to the IDS server group




frames ingressing the port and forward the copy to the IDS server group.

4. Configure filter 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 filter is configured to hash on both the client and server IP address, then this will

ensure that both client and server traffic belonging to the same session is sent to the same IDS

server. For more information, see “Example 2: Load Balancing to Multiple IDS Groups” on

page 282. If the port is configured for client processing only, then the switch hashes on the

source IP address only.


Setting Up IDS ServersTable 11-1 shows how an Alteon Application Switch can be configured depending on the type

of IDS server.

Table 11-1 Setting Up IDS Servers

IDS Server

Configuration

Health Check

Type

Port Configuration Explanation

Stealth mode

(without IP

addresses or

dummy IP

addresses)

Link –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 con-

nect IDS servers to separate switch ports and associate

them with different VLANs and tag the packets accord-

ingly. 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 thedestination IDS server. However, if the ingress packet

is already tagged, then you must use different switch

ports for different IDS servers.

Stealth mode

(without IP

addresses or

dummy IP

addresses)

SNMP IDS servers need not be

directly connected to the

application switch.The IDS

servers may be connected to

another switch via an inter-switch 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 con-

nect 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 tothe 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 differ-

ent IDS servers.

With IP

addresses

ICMP or ARP IDS servers need not be

directly connected to the

The data packet is modified, so that it is addressed to

the IDS servers Destination MAC address is changed




IDS Load Balancing Configurations

The following three examples illustrate IDS load balancing in two different network environ-

ments. In “Example 1: Load Balancing to a Single IDS Group” on page 277, one switch is ded-

icated 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” on

addresses directly connected to the

application switch.The IDS

servers may be connected

via an Alteon Application

Switch or a Layer 2 switch.

the IDS servers. Destination MAC address is changed

to Real server MAC address.


page 282, a single switch is performing both IDS load balancing and standard server load bal-

ancing. In example 2, two IDS groups are configured—IDS group 51 is for HTTP traffic only

and IDS group 52 is for all other traffic. In “Example 3: Load Balancing IDS Servers Across

Multiple Switches” on page 287, two switches in a high availability configuration are con-

nected to each other via a trunked interswitch link that is associated with all VLANs config-

ured 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 traffic to reach real servers even when one switch goes into the

Standby state.

Example 1: Load Balancing to a Single IDS Group

Figure 11-7 illustrates a basic configuration for load balancing client and server traffic to the

IDS servers. Alteon Application Switch 1 (an Alteon 2424) is performing IDS load balancing

and Alteon Application Switch 2 is performing standard server load balancing. IDS is enabled

on the client port (port 25) and both the firewall ports (ports 26 and 27).





NOTE – While this example assumes use of an Alteon Application Switch 2424, you mayadapt this example according the ports available on your particular Alteon Application Switch

model.

Figure 11-7 Server Load Balancing and IDS Load Balancing to a Single Group

When the client request enters port 25 on Alteon 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 configured load balancing metric (hash). The original data packet however, enters

Alteon Application Switch 2 through the firewall and Alteon Application Switch 2 performsd d l d b l i h li d b h h l h li

7

2725

26

6

2 3 426

27

Clients

Alteon Application

Switch 1

Internet

IDS servers

Router

A

C

B

1

2

IP 170.10.10.8

IP 210.210.210.10

IP 120.120.120.5

Real server 6

IP 6.6.6.6

Real server 7

IP 7.7.7.7

1 2 3

Firewall 1 Firewall 2

Alteon ApplicationSwitch 2

Real server 1

IP 10.10.10.1

Real server 2

IP 10.10.10.2

Real server 3

IP 10.10.10.3




teo pp cat o Sw tc t oug t e ewa a d teo pp cat o Sw tc pe o sstandard server load balancing on the client data between the three real servers. The client

request is processed and returned to Alteon Application Switch 1 via the firewall. An allow fil-

ter at ports 26 and port 27 causes the Alteon Application Switch to make a copy of the request

and directs the copy to the IDS server group.


Follow this procedure to configure the topology illustrated in Figure 11-7 on page 278:


To configure 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 (with-

out IP addresses); but, they can also be set up with non-routable IP addresses. See Table 11-1

on page 276 for more information about setting up IDS servers.

2. At the Alteon Application Switch, configure the IDS servers as real servers.

In Figure 11-7 the IDS servers are configured in stealth mode. Match the real server number

with the physical port number to which the IDS servers are connected, and configure dummy

IP addresses. The real servers must be numbered between 1-63.

3. Create a group and add the IDS servers.

The group must be numbered between 1–63.

4. Define the group metric for the IDS server group.

IDS server load balancing supports the hash metric only.

5. Define the health check for the group.

>> # /cfg/slb/real 6/rip 6.6.6.6/ena (Define a dummy IP address for IDS

server 6)

>> # /cfg/slb/real 7/rip 7.7.7.7/ena (Define a dummy IP address for IDS

server 7)


>>Real Server Group 50# add 6 (Add IDS server 6)


>>Real Server Group 50# metric hash (Set the metric to hash)




g p

Configure link health check which is specifically developed for IDS servers set up in stealth

mode (without IP addresses).

6. Define the group for IDS server load balancing.

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

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


7. Select the rport for the IDS group.

8. Enable IDS on the client and server ports.

This enables frames ingressing the port to be copied to the IDS servers.

In addition to enabling IDS at the port level, a filter must be configured 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 filter and configure the filter 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 traffic goes to the same IDS

server. If the port is configured 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 filter to ports 25, 26, and 27.

The allow filter must be applied on all ports that require layer 4 traffic to be routed to the IDS

servers.

>>Real Server Group 50# idsrprt any

>># /cfg/slb/port 25/ids ena (Enable IDS processing for port 25)

>>SLB port 25# /cfg/slb/port 26/ids ena (Enable IDS processing for port 26)>>SLB port 26# /cfg/slb/port 27/ids ena (Enable IDS processing for port 27)

>> # /cfg/slb/filt 2048 (Select the menu for Filter 2048)

>> Filter 2048# sip any (From any source IP address)

>> Filter 2048# dip any (To any destination IP address)

>> Filter 2048# action allow (Allow matching traffic to pass)

>> Filter 2048# ena (Enable the filter)

>> Filter 2048# adv/idshash both (Set the hash metric parameter)




>> Filter 2048# /cfg/slb/port 25 (Select the client port)

>> SLB Port 25# add 2048 (Apply the filter to the client port)

>> SLB Port 25# filt ena (Enable the filter)

>> SLB Port 25# /cfg/slb/port 26 (Select port 26)

>> SLB Port 26# add 2048 (Apply the filter to port 26)






All ingressing traffic at these ports that match any of the filters configured for that port will be

load balanced to the IDS groups. The allow filter is used at the end of the filter list to make sure

that all traffic matches a filter. A deny all filter could also be used as the final filter instead of

an allow all filter.


12. Configure Alteon Application Switch 2 to load balance the real servers as described in



Configure the SLB real servers and add the real servers to the group

Configure the virtual IP address

Configure the SLB metric

Enable SLB

A copy of layer 4 traffic from clients A, B, and C and from the real servers are directed to the

IDS servers and load balanced between IDS servers 6 and 7.

>> SLB Port 25# apply>> SLB Port 25# save





Example 2: Load Balancing to Multiple IDS Groups

Figure 11-8 illustrates a single Alteon Application Switch performing both standard server

load balancing and IDS server load balancing. In this example, two IDS groups are config-

ured—IDS group 51 is for HTTP traffic only and IDS group 52 is for all other traffic.

Figure 11-8 Server Load Balancing and IDS Load Balancing

When the same Alteon Application Switch is configured to load balance real servers and IDS

servers as shown in Figure 11-8, filter processing is not required on the client processing port

(port 25). To maintain session persistency however, if you add the filter to the client port, the

78

25

2 34 6

6Clients

Alteon Application

Switch

IDS servers

Router

A

C

B

7

8

1

3

2

IP 170.10.10.8

IP 210.210.210.10

IP 120.120.120.5

Real server 7

IP 10.20.20.2

Real server 6

IP 10.20.20.1

Real server 1

IP 10.10.10.1

Real server 2

IP 10.10.10.2

FTP server

Real server 3

IP 10.10.10.3

virtual IP addresses:

120.10.10.10

120.10.10.11

Real server 8

IP 10.20.20.3

Web servers

Group 51

Group 52Internet




switch can be configured to hash on both the client IP and virtual server IP. This will ensure

that both client and server traffic belonging to the same session is sent to the same IDS server.

If you do not add the filter on port 25, then the switch hashes on the client IP address only.

NOTE – While this example assumes use of an Alteon Application Switch 2424, you may

adapt this example according the ports available on your particular Alteon Application Switch

model.




Refer to Table 11-1 on page 276 for information on setting up the IDS servers. To configure

the IDS servers as real servers you must consider the following:

Connecting the IDS servers

Choosing the health check

Configuring the IP addresses

For more information on each of the above items, see Step 1 on page 279.

2. Configure the IDS servers as real servers.

In Figure 11-8 the IDS servers are setup with non-routable IP addresses. The real servers must

be numbered 1-63.

3. Create two IDS groups and add the IDS servers.

Define the two IDS groups 51 and 52. The IDS group numbers must be between 1 to 63.

>> # /cfg/slb/real 6/rip 10.20.20.1/ena (Specify IP address for IDS

server 6)


server 7)


server 8)




>>Real Server Group 51# /cfg/slb/group 52 (Define another group)






4. Define the group metric for the IDS server groups.


The hash metric is implemented in two ways. For more information, see Step 4 on page 279.


Configure ICMP health check for the group.



8. Enable IDS on the client and server processing ports.

This enables frames ingressing the port to be copied to the IDS servers.


>>Real Server Group 51# /cfg/slb/group 52 (Select the other IDS group)


>>Real Server Group 51# health icmp (Set the health check to ICMP)


>>Real Server Group 52# health arp (Set the health check to ARP)

>>Real Server Group 51# idslb ena (Enable IDS for the IDS server group)


>>Real Server Group 52# idslb ena (Enable IDS for the IDS server group)

>> # /cfg/slb/group 51 (Select the IDS group)>>Real Server Group 51# idsrprt http (Select HTTP traffic for IDS group)

>>Real Server Group 51# /cfg/slb/group 52 (Select the IDS group)

>>Real Server Group 52# idsrprt any(Select non-HTTP traffic for IDS

group)





entry for non-SLB frames ingressing the port. IDS load balancing requires a session entry to becreated to store the information regarding which IDS server to send to.

>># /cfg/slb/port 25/idslb ena (Enable IDS SLB for port 25)

>>SLB port 25# /cfg/slb/port 2/idslb ena (Enable IDS SLB for port 2)







server. By default, the IDS hash metric hashes on the source IP address only.

10. Apply the filter to ports 2, 3, 4 and 25 only.

Enable filter processing on all ports that have IDS enabled.

If you add the allow filter to the client port 25, the switch will hash on client IP and virtualserver IP address for both client and server frames. This will ensure that both client and server

traffic belonging to the same session is sent to the same IDS server. If you do not add the allow

filter 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.






>> Filter 2048# adv/idshash both (Set the hash metric parameter)

>> # /cfg/slb/port 2 (Select the port menu)


>> SLB Port 2# filt ena (Enable the filter)>> SLB Port 2# /cfg/slb/port 3 (Select port 3)















A copy of layer 4 Web traffic from clients A, B, and C and from the real servers 1, 2, and 3 is

load balanced between IDS servers 6 and 7. A copy of all non-HTTP traffic is directed to IDS

server 8.

12. Configure the switch for server load balancing the real servers as described in “Config-

uring Server Load Balancing” on page 188.


Configure and create a group for the SLB real servers



Enable SLB






Example 3: Load Balancing IDS Servers Across Multiple Switches

Alteon OS supports load balancing IDS servers across multiple Application switches in a high

availability configuration. 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 Figure 11-9, the switches are connected to each other via a trunked interswitch link (ports 25

and 26) that is associated with all VLANs configured on the switch. Each switch is connected

to IDS servers that are each on different VLANs but belong to the same IDS group. ForVLAN-based IDS load balancing, the ingress packets are copied by the master switch and

flooded 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 flooded to the IDS VLAN on the standby switch.

Internet

1

VLAN 1003

VLAN 1004

VLAN 1001 VLAN 1002

Switch 2

Switch 1Trunked ports 25, 26tagged for VLANs1000, 1001, 10021003, 1004

idslb filter

idslb filter on trunked ports 27, 28

2827

26

25

2

4

4

Web servers

87

1 2

4

IDS group 1

3

3




Figure 11-9 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 flooded to the IDS VLAN over the interswitch link.

VLAN 1003

IDS group 1


In a high availability configuration, the standby switch becomes the master if the current mas-

ter switch fails. The new master switch forwards traffic between clients and servers. Becausethe 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 traffic,

the request packets would not normally reach the real servers.

Alteon OS 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 Alteon Application Switch 2424, you may

adapt this example according the ports available on your particular Alteon Application Switch

model.



Refer to Table 11-1 on page 276 for information on setting up the IDS servers. To configure

the IDS servers as real servers you must consider the following:

Connecting the IDS servers

Choosing the health check—in this case, use SNMP health check

Configuring the IP addresses

For more information on each of the above items, see Step 1 on page 279.

2. On the Alteon Application Switch, configure the interswitch link ports for the IDS

VLAN.

/cfg/port 25/tag ena/pvid 1000

/cfg/port 26/tag ena/pvid 1000




3. Configure trunk groups.

4. Configure an IP interface for the SNMP health check to the other switch.

/cfg/l2/trunk 1/ena/add 25/add 26 (Add ports 25, 26 to trunk group 1)

/cfg/l2/trunk 2/ena/add 27/add 28 (Add ports 27, 28 to trunk group 2)

/cfg/l3/if 3/addr 11.11.11.1/mask 255.255.255.255/vlan 1000


5. Configure VLANs. Make sure to disable source MAC address learning only on the IDS

VLANs.

The following VLANS are configured on the switch:

VLAN 1: for load balancing traffic to the real servers

VLAN 1000: for performing SNMP health check on switch 2

VLAN 1001: for IDS server 1



VLAN 1004: for IDS server 4.

>> Main# /cfg/l2/vlan 1001/ena>> VLAN 1001# learn dis (Disable source MAC learning on the

IDS VLAN)

:>> VLAN 1001# add 25/add 26 (Set port members of the VLAN)

Port 25 is an UNTAGGED port and its current PVID is 1.Confirm changing PVID from 1 to 1001 [y/n]: yPort 26 is an UNTAGGED port and its current PVID is 1.Confirm changing PVID from 1 to 1001 [y/n]: y

>> Layer 2# /cfg/l2/vlan 1001/ena/learn dis/add 25/add 26>> Layer 2# /cfg/l2/vlan 1002/ena/learn dis/add 25/add 26>> Layer 2# /cfg/l2/vlan 1003/ena/learn dis/add 25/add 26

>> Layer 2# /cfg/l2/vlan 1004/ena/learn dis/add 25/add 26





6. Configure the IDS servers as real servers.

In Figure 11-8 the IDS servers are setup with non-routable IP addresses. The real servers must

be numbered 1-63. SNMP health checks are configured to check the status of the ports on

switch 2 that are connected to the IDS servers.

7. Create an IDS group and add the IDS servers.

Define the IDS group. The IDS group numbers must be between 1 to 63.

>> # /cfg/slb/real 1/rip 11.11.11.1/ena (Set IP address for IDS server 1)

>> Real server 1 # ids/idsvlan 1001 (Set IDS VLAN for IDS server 1)

>> Real Server 1 IDS# idsport 25 (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)


>>Real Server Group 53# add 1 (Add IDS server 1)>>Real Server Group 53# add 2 (Add IDS server 2)





8. Define the group metric for the IDS server group.


p ( )







12. Enable IDS on the client and server ports.

This enables frames ingressing the traffic ports to be copied to the IDS servers.


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. Configure 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

configured in the rcvcnt field, 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. .

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

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

>>Real Server Group 50# idsrprt 80 (Set for service HTTP)

/cfg/slb/port 4/ids ena (Enable IDS processing for port 4)

>>SLB port 4# /cfg/slb/port 7 ids ena (Enable IDS processing for port 7)>>SLB port 7# /cfg/slb/port 8 ids ena (Enable IDS processing for port 8)

>>SLB port 7# /cfg/slb/port 27/ids ena (Enable IDS processing for port 27)

>>SLB port 27# /cfg/slb/port 28/ids ena (Enable IDS processing for port 28)

>>SLB port 27# /cfg/slb/advhc/snmphc 1/rcvcnt “1”








server. If the port is configured 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 filter to ports 4, 7, 8, 27, and 28, to enable filter processing on all ports

that have IDS enabled.

If you add the allow filter to the client port 4, the switch will hash on client IP and virtual

server IP address for both client and server frames. This will ensure that both client and server

traffic belonging to the same session is sent to the same IDS server. If you do not add the allow

filter 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 filter must be applied on all ports

that require layer 4 traffic to be routed to the IDS servers.

>> Filter 2048# /cfg/slb/port 4 (Select the client port)>> SLB Port 4# add 2048 (Apply the filter to the IDS port)


>> SLB Port 4# /cfg/slb/port 7 (Select the IDS server 7 port)

>> SLB Port 7# add 2048 (Apply the filter to the IDS port)


>> SLB Port 7# /cfg/slb/port 8 (Select the IDS server 8 port)

>> SLB Port 2# add 2048 (Apply the filter to the client port)


>> SLB Port 2# /cfg/slb/port 27 (Select the interswitch link for IDS)

>> SLB Port 27# add 2048 (Apply the filter to traffic port 27)


>> SLB Port 27# /cfg/slb/port 28 (Select the interswitch link for IDS)

>> SLB Port 28# add 2048 (Apply the filter to traffic port 28)





All ingressing traffic at these ports that match any of the filters configured for that port will be

load balanced to the IDS groups. The allow filter is used at the end of the filter list to make sure

that all traffic matches a filter. A deny all filter could also be used as the final filter instead of

an allow all filter.



17. Configure Alteon Application Switch 2 to load balance the real servers as described in



Configure the SLB real servers and add the real servers to the group



Enable SLB

Session Initiation Protocol Server LoadBalancing

Session Initiation Protocol (SIP) is an application-level control (signalling) protocol for Inter-

net multimedia conferencing, telephony, event notification, and instant messaging. The proto-

col 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 Communica-

tions Server). Alteon OS 22.0 supports UDP-based SIP server load balancing only.





SIP Processing on the Switch

SIP processing provides the capability to scan and hash calls based on a SIP Call-ID header to

an MCS server. The Call-ID uniquely identifies a specific SIP session. Future messages from

the same Call-ID is switched to the same MCS server. This involves stateful inspection of SIP

messages.


SIP is a text based protocol with header lines preceding the content. Like HTTP, the first

header line has the method specification followed by other header lines that specify other parameters like Call-ID etc.

Configuring SIP Server Load Balancing

Figure 11-8 illustrates an Alteon Application Switch performing UDP-based SIP server load

balancing. In this example, three SIP proxy servers are configured in a Real Server Group 100.

The application switch is configured for SIP service (port 5060) for virtual server40.40.40.100.

Figure 11-10 SIP Load Balancing


1. At the Alteon Application Switch, before you start configuring SIP load balancing:

7

525 6

Clients


Internet

SIP Proxy

Servers

Router

A

C

B

1

IP 170.10.10.8

IP 210.210.210.10

IP 120.120.120.5

3

Real server 1

IP 10.10.10.1

2 Real server 2

IP 10.10.10.2

Real server 3IP 10.10.10.3

Virtual IP address:

40.40.40.100




pp , y g g g

Connect each SIP proxy server to the application switch

Configure the IP addresses on all devices connected to the application switch

Configure the IP interfaces on the application switch







9. Enable SIP server load balancing.

10. Enable DAM.

11. Enable UDP load balancing.

12. Increase the timeout for idle sessions.

SIP sessions are quite long and data may be flowing 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.

13. Enable server and client processing at the port level.

>>Virtual Server 1 sip Service # sip ena (Enable SIP for virtual server 1)

>>Virtual Server 1 sip Service # direct ena(Enable DAM)

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

>> # /cfg/slb/real 1/tmout 30 (Increase Real 1 session timeout)




>>SLB port 25# client ena (Enable client processing)





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






CHAPTER 12

WAN Link Load Balancing

WAN Link Load Balancing allows you to configure the Alteon Application Switch to balance

user session traffic among a pool of available WAN Links. The following sections in this chap-

ter provides conceptual information on WAN Link Load balancing:

“Multi-homing” on page 297. This section provides an overview of the product and bene-

fits of WAN link load balancing.

“How WAN Link Load Balancing Works” on page 300. This section discusses in detail

the path of the outbound and inbound traffic in a WAN link load balancing environment.

“Configuring WAN Link Load Balancing” on page 306. This section provides step-by-

step procedures to configure the Alteon Application Switch for load balancing the WAN

links in different environments.

“Example 1: Simple WAN Link Load Balancing” on page 309

“Example 2: WAN Link Load Balancing with Server Load Balancing” on page 320

For additional information on WAN link commands, see your Alteon OS Command Reference.

Multi-homing

WAN link load balancing enables the Alteon Application Switch to provide Fast Ethernet and

Gigabit connectivity from corporate resources to multiple ISP links to the Internet.



315394-J, January 2005297

To handle the high volume of data on the Internet, corporations are using more than one Inter-

net Service provider (ISP) as a way to increase reliability of Internet connections. Such enter-

prises 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 con-

nections 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 otherclear opportunities for enterprises to intelligently manage how WAN links are used. With link

load balancing organizations have greater flexibility to scale bandwidth and reduce spending

for corporate connectivity.

Alteon Application Switch software provides a solution for enterprises that wish to optimize

utilization of Internet connectivity. This comprehensive solution helps enterprises to direct

traffic over the best connection to maximize performance, maximize corporate bandwidth

investments, and effectively remove existing deployment and management barriers for multi-

homed networks.

Benefits of WAN Link Load Balancing

Traditionally, corporations have used Border Gateway Protocol (BGP) to determine the opti-

mal path of the WAN link for load balancing traffic. However, Table 12-1 shows the advan-

tages of implementing WAN link load balancing versus using BGP.

Table 12-1 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 Alteon

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.



315394-J, January 2005298 Chapter 12: WAN Link Load Balancing


WAN link load balancing benefits 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 efficiency for WAN link utilization and network bandwidth

Your Alteon Application Switch is aware of the shared services provided by your WAN

link pool and can then balance user traffic among the available WAN links. Important

WAN link traffic gets through more easily, reducing user competition for connections on

overutilized links. For even greater control, traffic is distributed according to a variety of

user-selectable rules.

Increased reliability

Reliability is increased by providing multiple paths from the clients to the Alteon Applica-

tion 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 traffic increases and the WAN link pool’s capabilities are saturated, new WAN links

can be added to the pool transparently.

For ease of maintenance, WAN links can be added or removed dynamically, without inter-

rupting traffic.

Identifying Your Network Needs

WAN Link Load balancing may be the right option for addressing these vital network con-

cerns:

A single WAN link no longer meets the demand for increased traffic.

The connection from your LAN to the Internet overloads the WAN link’s 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 cus-

tomers. It must not become overloaded or unavailable.

You want to use multiple WAN links or hot-standby WAN links for maximum server

uptime.



315394-J, January 2005Chapter 12: WAN Link Load Balancing 299

p

You must be able to scale your applications to meet client and LAN request capacity.

You can’t afford to continue using an inferior load-balancing technique, such as DNS

round robin or a software-only system.


What is Load Balancing?

The Alteon 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 Alteon OS

can be done in the following ways:

Filtered-based load balancing

A filter allows you to control the types of traffic permitted through the Alteon Application

Switch. Filters are configured to allow, deny, or redirect traffic according to the IP

address, protocol, or Layer 4 port criteria. In filtered-based load balancing, a filter is used

to redirect traffic to a real server group. If the group is configured with more than one real

server entry, redirected traffic is load balanced among the available real servers in the

group.

WAN links use redirection filters to load balance outbound traffic. For more information,

see “Outbound Traffic” on page 301.

Virtual server-based load balancing

This is the traditional load balancing method. The Alteon Application Switch is config-

ured 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 dif-

ferent services (up to a total of 8192 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 Alteon 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 fields in each frame from virtual addresses to

real address.

This method of load balancing is used to load balance inbound traffic. For more informa-

tion, see “Inbound Traffic” on page 302.

How WAN Link Load Balancing Works




To effectively use multiple ISP links, it is recommended that both traffic—outbound and

inbound is load balanced on the Alteon Application Switch. Alteon OS can be configured to

load balance up to 8 ISP links. The Alteon Application Switch regularly checks the health of

the upstream routers and measures the condition of the link. When traffic is to be sent to thelink, the Alteon Application Switch chooses the most optimal link for that session.


The next two sections explain how WAN link load balancing works differently for outbound

traffic versus inbound traffic.

Outbound Traffic

Outbound traffic is data from the intranet that accesses content across the Internet. Alteon OS

load balances outbound traffic using redirection filters to redirect traffic initiated from within

the user’s network to a group of devices that exist at the other end of the WAN link. These fil-

ters determine which link is the best at the time the request is generated.

The design of outbound WAN link load balancing is identical to standard redirection, except

that Alteon OS 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 Figure 12-1, client 1 at IP address 1.1.1.2 sends a HTTP request to the Internet. Outbound

traffic from client 1 reaches port 5 on the Alteon Application Switch which is configured witha redirection filter for link load balancing. The traffic is load balanced between ports 2 and 7

depending on the metric of the WAN group (configured as real server 1 and 2).

Figure 12-1 Outbound Traffic

The outbound traffic resolution in Figure 12-1 is described in detail in the following section:

1. Client 1 makes a data request for content on the Internet.

2. When the request reaches port 5, the redirection filter is triggered and the Alteon Appli-

Outbound

traffic

2

7

5

Real 1 to ISP A

IP 50.1.1.1

Real 2 to ISP B

IP 80.1.1.1

Content

Server

1

2

IF 1: 1.1.1/24

Client 1

1.1.1.2

IF 2: 50.1.1.2/24

pip 1

vip 1: 50.1.1.100

IF 7: 80.1.1.2/24

pip 2

vip 2: 80.1.1.100

Internet




cation Switch selects the optimal WAN link.

3. Before the packets leave the WAN link ports, the client IP address is substituted with the

configured proxy IP address on port 2 or 7. Proxy IP address maintains persistency for

the returning request.

4. The Alteon Application Switch sends the request to the destination IP address.


5. 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. Theselected ISP processes the packet.

6. The Application Switch converts the proxy IP address to the client IP address and the

request is returned to the client.

Inbound Traffic

Inbound traffic is data from an external client on the Internet that enters the Alteon ApplicationSwitch to access an internal service, such as corporate Web servers or FTP servers.

Alteon OS allows you to load balance the inbound traffic by providing access to the external

client with the best available WAN link. This is implemented by configuring the Alteon Appli-

cation 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

configured 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” on page

195. 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” on page 199.

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 traffic takes the same ISP

path as the incoming traffic. RTS is enabled on the incoming WAN ports (port 2 and 7) to

maintain persistence for the returning traffic. Data leaves the Alteon 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 configure VLAN for

gateways as described in “VLANs and Default Gateways” on page 81.

Tracing the Data Path

In Figure 12-2, the client request enters the Alteon Application Switch via ISP A or ISP B. ISP

A is configured as real server 1 and ISP B is configured as real server 2. A virtual server IP

address is configured for each ISP and each domain. The virtual server IP addresses for each

ISP must be configured in the ISP’s address range.

As shown in Figure 12-2, two virtual server IP addresses—virtual server IP address 1 and vir-

tual server IP address 2 are configured for nortelnetworks.com in each of the ISP’s

address range. Once the application switch responds with the best virtual server IP address, all

subsequent traffic 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 Figure 12-2, a client request for http://www.nortelnetworks.com enters the

Alteon 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 configured on the Alteon

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.

Figure 12-2 Inbound Traffic for non-SLB server

The inbound traffic resolution in Figure 12-2 is described in detail in the following section:

1. Client makes a request to www.nortelnetworks.com.

2. The client query does not exist in local DNS database. Local DNS queries the Domain

Inbound traffic

2 7

Client

5

Local DNS

server

3

1

www.nortelnetworks.com

Real 1 to ISP AIP 50.1.1.1

Real 2 to ISP BIP 80.1.1.1

1 2

RTS

vip 1: 50.1.1.100

RTS

vip 2: 80.1.1.100

Alteon Link Optimizer

Authoritative Name Server

Non-SLB server

Real 4 IP address: 2.2.2.100

RIP address: 2.2.2.100

Internet




q y q

Name Server on the Alteon Application Switch.

3. The Alteon 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. Client again requests www.nortelnetworks.com with the provided virtual IP address.


5. The server responds to the content request.

An allow filter at port 5 processes the data for the services configured on the server. For example, if the client sends HTTP request to server 3, then the allow filter should be configured for

source port 80. Similarly, if the client sends SMTP request to server 3, then the allow filter

should be configured for source port 25.

6. The RTS feature on the WAN ports maintains persistency, so that the traffic returns via

the same ISP.

External client accessing data from an SLB group

In Figure 12-3, the client request is for www.nortelnetworks.com . The client request

should be load balanced between SLB servers 5 and 6.

Inbound traffic

2 7

Client

Local DNS

server

1

virtual IP address30.30.30.2

11

Real 1 to ISP A

IP 50.1.1.1

Real 2 to ISP B

IP 80.1.1.11 2

RTS

vip 1: 50.1.1.100

RTS

vip 2: 80.1.1.100


Authoritative Name Server


Internet


SLB servers5

6




Figure 12-3 Inbound Traffic for SLB group

The inbound traffic resolution in Figure 12-3 is described in detail in the following section:

1. Client makes a request to www.nortelnetworks.com.



2. The client query does not exist in local DNS database. Local DNS queries the Domain

Name Server on the Alteon Application Switch.

3. The Alteon Application Switch monitors WAN links and responds with the virtual IP

address of the optimal ISP.

4. Client makes the request again to www.nortelnetworks.com with the provided virtual IP

address.

5. The SLB servers responds to the content request, because real server 7 IP address on the

Alteon Application Switch is the virtual server address of nortelnetworks.com.

The session request egresses from port 1 and port 11 of the Alteon Application Switch where it

is then load balanced between the SLB servers. The virtual server IP address for the SLB serv-

ers on the application switch is configured as a real server IP address (Real 7 IP: 30.30.30.2) on

the Alteon Application Switch. Real 7 is added to a group on the Alteon Application Switch.

6. The returning data from the SLB server reaches port 1, which is enabled for server pro-

cessing.

For information on server processing, see “Network Topology Requirements” on page 186.

The RTS feature on the WAN ports maintains persistency, so that the traffic returns via the

same ISP.

Configuring WAN Link Load Balancing

This section provides step-by-step procedures to configure the Alteon Application Switch for

load balancing the WAN links in different environments:

“Before You Begin” on page 306

“Configuration Summary” on page 308

“Example 1: Simple WAN Link Load Balancing” on page 309

“Example 2: WAN Link Load Balancing with Server Load Balancing” on page 320

B f Y B i




Before You Begin

The following is required prior to configuration:

You must be connected to the Alteon Application Switch Command Line Interface (CLI)as the administrator.

Connect each WAN link to a separate port on the Alteon Application Switch.


Do not connect two or more WAN links to the same Alteon 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 configure your WAN link ports into trunk groups.





Configuration Summary

Table 12-2 summarizes the steps involved to configure the Alteon Application Switch for

WAN link load balancing.

Table 12-2 Configuration Summary

Configuring Outbound Traffic Configuring Inbound Traffic

1. Configure the basic parameters.

This includes configuring VLAN, IP interfaces, and defininggateways per VLAN.

1. Configure the basic parameters.

This includes configuring VLAN, IP interfaces, and defininggateways 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

2. Configure the load balancing parameters for the ISP WAN

links.

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.

Configure proxy IP address

3. Configure the WAN link ports.

Enable client processing

Enable RTS

Enable DAM

4. Configure the outbound client ports. Configure the redirection filter and enable it for link load

balancing

Apply the filter to the client ports

4. Configure the inbound server 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

Alteon Application Switch.

5. Configure virtual server IP addresses and services for eachISP.

For each ISP link, configure a virtual server IP address per

domain.

6 Config re the Alteon Application S itch to beha e like a




6. Configure the Alteon 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, see your

Alteon OS Command Reference.

In the following procedure, many of the load balancing options are left to their default values.

See “Additional Server Load Balancing Options” on page 191 for details on other options.

Example 1: Simple WAN Link Load Balancing

Figure 12-4 illustrates a simple topology with two WAN links. Two ISPs, a server, and a client

are directly connected to the Alteon Application Switch. The Alteon Application Switch load

balances traffic between the two WAN links for both inbound and outbound traffic.





The server hosting www.nortelnetworks.com is directly connected to a port on the

application switch. To illustrate outbound traffic, a client is directly connected to another porton the application switch.

Figure 12-4 Simple WAN Link Load Balancing

Inbound traffic

Outbound traffic

25 26

15

Router 1 to ISP1

IP 50.1.1.1

Router 2 to ISP2

IP 80.1.1.1

Web Server

1 2

Client

2.2.2.2Client 1

Real server 3

1.1.1.2

3

IF 7: 80.1.1.2/24

VIP 2: 80.1.1.100IF 2: 50.1.1.2/24

VIP 1: 50.1.1.100

IF 1: 1.1.1/24

IF 5: 2.2.2.1/24



Internet





Table 12-3 gives an overview of the steps described in the following procedure.

To configure the topology illustrated in Figure 12-4, follow this procedure on the Alteon

Application Switch:

Step 1: Configure basic parameters on the Alteon Application Switch

This includes configuring VLAN, IP interfaces, and defining gateways per VLAN. Gateways

per VLAN is recommended if you have not configured other routing protocols. For each ISP,

configure a default gateway for each VLAN.

1. 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:

Table 12-3 Configuring Simple WAN Link Load Balancing

For outbound traffic For inbound traffic


Step 2: Configure the load balancing parameters for ISP routers

Step 3a (outbound traffic): Configure the WAN

link ports

Step 3b (inbound traffic): Configure the WAN link

ports

Step 4a (outbound traffic): Configure the client

ports

Step 4b (inbound traffic): Configure server ports

Step 5: Configure the virtual server IP address and

the services for each ISP

Step 6: Configure the Application Switch as a

Domain Name Server

Step 7: Apply and save your changes

Table 12-4 ISP links: Real Server IP Addresses

WAN links IP address




ISP 1 80.1.1.1

ISP 2 30.1.1.1


2. Configure the IP interfaces on the Alteon Application Switch.

The Alteon Application Switch must have an IP route to all of the real servers that receiveswitching services. For load balancing the traffic, the Alteon Application Switch uses this path

to determine the level of TCP/IP reach of the WAN links.

>> # /cfg/if 2 (Define interface 2 for ISP 1)

>> IP Interface 2# ena (Enable interface 2)

>> IP Interface 2# addr 50.1.1.2 (Define the IP address for interface 2)

>> IP Interface 2# mask 255.255.255.0 (Define the mask for interface 2)

>> IP Interface 2# broad 50.1.1.255 (Define the broadcast for interface 2)>> IP Interface 2# vlan 2 (Specify the VLAN for interface 2)

>> # /cfg/if 7 (Define interface 7 for ISP 2)




>> IP Interface 7# broad 80.1.1.255 (Define the broadcast for interface 7)

>> IP Interface 7# vlan 7 (Specify the VLAN for interface 7)

>> # /cfg/if 1 (Define interface 1 for Real server 3)






>> # /cfg/if 5 (Define interface 5 for internal client)



>> IP Interface 5# mask 255.255.255.0 (Define the mask for interface 5)>> IP Interface 5# broad 2.2.2.255 (Define the broadcast for interface 5)






3. Configure VLANs.

The real server IP addresses (WAN links and real server 3) and the respective IP interfacesmust be on different VLANs. The pvid command sets the default VLAN number which will

be used to forward frames which are not VLAN tagged. The default number is 1.


On the Alteon Application Switch, configure the ISP routers with load balancing parameters:

real servers, group, metric, and health.

1. At the Alteon Application Switch, configure IP addresses for WAN link routers.

Proxy is disabled on the real servers, so that the original destination IP address is preserved.

2. Create a group to load balance the WAN link routers.

>> # /cfg/port 25/pvid 2 (Sets the default VLAN number)




>> # /cfg/vlan 2/ena (Enable VLAN 2)>> # /cfg/vlan 2/def 25 (Add port 25 to VLAN 2)

>> # /cfg/vlan 7/ena (Enable VLAN 7)

>> # /cfg/vlan 7/def 26 (Add port 26 to VLAN 7)





>> # /cfg/stp 1/off (Disable STP)

>> # /cfg/stp 1/clear (Clear STP)

>> # /cfg/stp 1/add 1 25 26 5 (Add ports 1, 25, 26, 5 to STP 1)

>> # /cfg/slb/real 1/rip 50.1.1.1 (Define IP address for WAN link 1)


>> Real server 1# proxy dis (Disable proxy)








3. 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 rec-

ommended.

4. Configure health check for the WAN link group.

5. Enable SLB.

Step 3a (outbound traffic): Configure the WAN link ports

1. Configure proxy IP addresses on ports 25 and 26 for WAN link load balancing.

Each proxy IP address must be unique on your network.

>>Real Server Group 100# health icmp (Set health check to ICMP)

>> # /cfg/slb/on (Enable load balancing)

>> # /cfg/slb/pip/type port (Set base type of proxy IP address)

>> # /cfg/slb/pip

>> Proxy IP Address# add 50.1.1.2 25 (Set proxy IP address for port 25)>> Proxy IP Address# add 80.1.1.7 26 (Set proxy IP address for port 26)





Step 3b (inbound traffic): Configure the WAN link ports

1. Enable client processing for ports 25 and 26.

This enables inbound traffic to access the virtual server IP address.

2. Enable the Return to Sender (RTS) feature for ports 25 and 26.

Enable RTS to ensure the returning traffic from all servers to go back to the same ISP router.

3. Enable WAN link load balancing.

4. 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” on page 230.

>> # /cfg/slb/port 25/client ena (Enable client processing for port 25)


>> # /cfg/slb/port 25/rts ena (Enable rts for port 25)

>> # /cfg/slb/port 26/rts ena (Enable rts for port 26)

>> # /cfg/slb/linklb (Select the link load balancing menu)>> # /cfg/slb/linklb/group 100 (Specify the ISP group of real servers)

>> # /cfg/slb/linklb/ena (Enable link load balancing)






Step 4a (outbound traffic): Configure the client ports

Configure the redirection filter and enable the filter for link load balancing. This is required totranslate (NAT) the client IP address to the proxy IP address.

1. Define the WAN link load balancing redirection filter.

2. Enable WAN link load balancing for the redirection filter.

3. Add the link load balancing filter 100 to the outbound client port.

If you are configuring link load balancing for outbound traffic only, then go to “Step 7: Apply

and save your changes” on page 319. The remaining steps in this procedure are used for load

balancing of inbound traffic only.

Step 4b (inbound traffic): Configure server ports

For each real server connected to the Alteon Application Switch, assign a real server number,

specify its IP address and enable the real server. Define a real server group and add the real

server to the group.

1. Configure real server and create a group.

>> # /cfg/slb/filt 100>> Filter 100# ena>> Filter 100# action redir

>> Filter 100# group 100 (Select the ISP group of real servers)

>> Filter 100# adv>> Filter 100 Advanced# linklb ena

>> # /cfg/slb/port 5 (Select port 5)

>> SLB Port 5# add 100 (Add filter 100 to port 5)


>> # /cfg/slb/real 3/rip 1.1.1.2 (Define IP address for real server 3)



>> Real server Group 3# add 3 (Add Real server 3)




2. Enable server processing.

3. Enable filter on server port 1.

>> # /cfg/slb/port 1/server ena (Enable server processing for port 1)


Filter is enabled on port 1, because you want the Alteon Application Switch to look up the ses-

sion table for the RTS entry.

Step 5: Configure the virtual server IP address and the services foreach ISP

All client requests will be addressed to a virtual server IP address defined on the Alteon Appli-cation Switch. Clients acquire the virtual server IP address through normal DNS resolution. In

this example, HTTP and FTP are configured as the services running on this virtual server, and

this service is associated with the real server group.

Other TCP/IP services can be configured in a similar fashion. For a list of other well-known

services and ports, see Table 10-3 “Well-Known Application Ports” on page 192. To configure

multiple services, see “Configuring Multiple Services” on page 194.

NOTE – Define a virtual server IP address for each ISP.

Step 5a: Configure the virtual server IP address and the services for ISP 1

Define a virtual server and add the services and real server group for ISP 1.

1. Configure a virtual server for ISP 1.

2. Add HTTP and FTP services for the virtual server.




>>Virtual Server 1# vip 50.1.1.100 (Set IP address from the ISP 1 subnet)

>>Virtual Server 1# ena (Enable virtual server)

>> # /cfg/slb/virt 1 (Select the virtual server)>>Virtual Server 1# service 80 (Add the HTTP service)

>>Virtual Server 1 HTTP Service# ena (Enable the service)

>>Virtual Server 1 HTTP Service# group 3 (Add real server group)

>>Virtual Server 1 HTTP Service# .. (Go to the virtual server menu)

>>Virtual Server 1# service ftp (Add the FTP service)

>>Virt al Ser er 1 ftp Ser ice# ena (Enable the service)




Step 5b: Configure the virtual server IP address and the services for ISP 2


>>Virtual Server 1 ftp Service# ena (Enable the service)

>>Virtual Server 1 ftp Service# group 3 (Add real server group)




Step 6: Configure the Application Switch as a Domain Name Server Define the domain record name and map the virtual server and real server (ISP router) for each

WAN link.

1. Configure the Domain record for the application switch to behave as a Domain Name

Server.





>>Virtual Server 2# service 80 (Add the HTTP service)

>>Virtual Server 2 HTTP Service# ena (Enable the service)>>Virtual Server 2 HTTP Service# group 3 (Add real server group)

>>Virtual Server 2 HTTP Service# .. (Go to the virtual server menu)




>> # /cfg/slb/linklb/drecord 1 (Select the Domain record menu)

>> Domain Record 1# ena (Enable the Domain)>> Domain record 1# domain nortelnetworks.com (Define the Domain name)





2. Configure 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 parame-

ters—virtual 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 mea-

sure the ISP load and ISP health. These commands map the two parameters to the ISP link.


You must apply in order for these changes to take effect, and you must save changes if youwish them to remain in effect after reboot.




3. Check the load balancing information.

Check that all load balancing parameters are working according to expectation. If necessary,

make any appropriate configuration changes and then check the information again.

>> Domain record 1# entry 1/ena (Define entry for ISP 1)

>> Virt Real Mapping# virt 1 (Select virtual server 1 for ISP 1)

>> Virt Real Mapping# real 1 (Select real server for ISP 1)












Example 2: WAN Link Load Balancing with Server Load

BalancingIn this example (shown in Figure 12-5), the Alteon Application Switch is configured for stan-

dard server load balancing. The Alteon Application Switch is configured to load balance the

WAN links for both outbound and inbound traffic and perform server load balancing for

inbound traffic.

The configuration is similar to Example 1 except that the virtual server IP addresses on the

application switch is configured as real server IP addresses and are added to a group.

Inbound traffic

Outbound traffic

Real 1 to ISP1

IP 50.1.1.1

Real 2 to ISP2

IP 80.1.1.1

Content Server

IF 1: 1.1.1.1/24

1.1.1.20

1.1.1.10

3

46

1 2

External Client

5

Client 1

Client 2

VIP 2: 80.1.1.100

VIP 4: 80.1.1.200


www xyz com

VIP 1: 50.1.1.100

VIP 3: 50.1.1.200



www.abc.com

VIP 1: 1 1 1 100

Layer 2 switch

1

2625

Internet




Figure 12-5 WAN Link Load Balancing with SLB

4 www.xyz.com

VIP 2: 1.1.1.200

VIP 1: 1.1.1.100


Table 12-5 gives an overview of the steps described in the following procedure.

To configure the topology illustrated in Figure 12-5, follow this procedure on the Alteon

Application Switch:


This includes configuring VLAN, interfaces, and defining gateways per VLAN. Gateways per

VLAN is recommended if you have not configured other routing protocols. Configure a

default gateway per VLAN for each ISP.

1. 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:

Table 12-5 Configuring WAN Link Load Balancing with SLB

For outbound traffic For inbound traffic



Step 3a (outbound traffic): Configure the WAN

link ports

Step 3b (inbound traffic): Configure the WAN link

ports

Step 4a (outbound traffic): Configure the internal

network port

Step 4b (inbound traffic): Configure the internal

network

Step 5: Configure the virtual server IP address and

the services for each ISP

Step 6: Configure the Application Switch as a

Domain Name Server


Table 12-6 ISP links: Real Server IP Addresses

WAN links IP address

ISP 1 80.1.1.1




S 80. . .

ISP 2 30.1.1.1



The Alteon Application Switch must have an IP route to all of the real servers that receiveswitching services. For load balancing the traffic, the Alteon Application Switch uses this path

to determine the level of TCP/IP reach of the WAN links.


4. On the Alteon Application Switch, configure VLANs.

>> # /cfg/if 1 (Define interface 1)


>> IP Interface 1# addr 1.1.1.1 (Define the IP address for interface 1)>> IP Interface 1# mask 255.255.255.0 (Define the mask for interface 1)



>> # /cfg/if 2 (Define interface 2)





>> IP Interface 2# vlan 2 (Specify the VLAN for interface 2)>> # /cfg/if 7 (Define interface 7)


















>> # /cfg/stp 1/off (Disable STP)






>> # /cfg/stp 1/add 1 25 26 5 (Add ports 1, 25, 26, 5 to STP 1)



On the Alteon Application Switch, configure the ISP routers as if they were real servers, withSLB parameters: real servers, group, metric, and health.

1. Configure IP addresses for WAN link routers.

Proxy is disabled on the real servers, because link load balancing and full NAT cache redirec-

tion cannot coexist.

2. Create a group to load balance the WAN link routers.

3. Assign the response metric for the WAN link group.

Any of the server load balancing metrics may be used, but response or bandwidth metric is rec-

ommended.

4. Configure health check for the WAN link group.

5. Enable SLB.










>>Real Server Group 100# metric response (Set the metric to response)

>>Real Server Group 100# health icmp (Set health check to ICMP)

>> # /cfg/slb/on (Enable load balancing)





Step 3a (outbound traffic): Configure the WAN link ports

1. Configure proxy IP addresses on ports 25 and 26.

Each proxy IP address must be unique on your network.

Step 3b (inbound traffic): Configure the WAN link ports

1. Enable client processing at ports 25 and 26.

This enables inbound traffic to access the virtual server IP address.

2. Enable RTS for ports 25 and 26.

Enable RTS to ensure the returning traffic from all servers to go back to the same ISP router.

3. Enable WAN link load balancing.

>> # /cfg/slb/pip/type port (Set base type of proxy IP address)

>> # /cfg/slb/pip

>> Proxy IP Address# add 50.1.1.2 25 (Set proxy IP address for port 25)

>> Proxy IP Address# add 80.1.1.7 26 (Set proxy IP address for port 26)



>> # /cfg/slb/port 25/rts ena (Enable rts for port 25)>> # /cfg/slb/port 26/rts ena (Enable rts for port 26)

>> # /cfg/slb/linklb (Select the link load balancing menu)

>> # /cfg/slb/linklb/group 100 (Specify the ISP group of real servers)

>> # /cfg/slb/linklb/ena (Enable link load balancing)





4. 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” on page 230.

Step 4a (outbound traffic): Configure the internal network port

Configure the redirection filter and enable the filter for link load balancing. This is required to

translate (NAT) the client IP address to the proxy IP address.

1. Define the WAN link load balancing redirection filter.

2. Enable WAN link load balancing for the redirection filter.

3. Add the link load balancing filter 100 to the outbound client port.

If you are configuring link load balancing for outbound traffic only, then go to “Step 7: Apply

and save your changes” on page 319. The remaining steps in this procedure are for load bal-

ancing inbound traffic only.


>> # /cfg/slb/filt 100

>> Filter 100# ena>> Filter 100# action redir

>> Filter 100# group 100 (Select the ISP group of real servers)

>> Filter 100# adv>> Filter 100 Advanced# linklb ena








Step 4b (inbound traffic): Configure the internal network

Configure the virtual server IP addresses on the Alteon Application Switch as real server IPaddresses. In this example, you will configure two real server IP addresses for each of the two

virtual server IP addresses. Then, define a real server group and add the real servers to the

group.


The real server IP address must be the virtual server IP address of the SLB servers that are

hosting abc.com .


The real server IP address must be the virtual server IP address of the SLB servers that are

hosting xyz.com .

3. Enable filter on server port 1.

Filter is enabled on port 1, because you want the Alteon Application Switch to look up the ses-

sion table for the RTS entry.

4. Enable server processing on port 1.

>> # /cfg/slb/real 7/rip 1.1.1.100 (Define IP address for www.abc.com)




>> # /cfg/slb/real 8/rip 1.1.1.200 (Define IP address for xyz.com)






>> # /cfg/slb/port 1/server ena (Enable server processing for port 1)





5. Configure an allow filter for health checks to occur.

If you have enabled link load balancing filter and server processing on the same port, then anallow filter must be configured for health checks. The allow filter is activated before the link

load balancing filter, so that the health check traffic does not get redirected to the WAN links.

For more information on health checking, see “Health Checks for Real Servers” on page 194.

6. Add the allow filter 50 to port 1.

NOTE – If you are using two Alteon Application Switches for redundancy, then must add

allow filters for VRRP before the redirection filter. For more information on VRRP, see Chap-

ter 16, “High Availability.”

Step 5: Configure the virtual server IP address and the services foreach ISP

All client requests will be addressed to a virtual server IP address on a virtual server defined on

the Alteon Application Switch. Clients acquire the virtual server IP address through normal

DNS resolution. In this example, HTTP and FTP are configured as the services running on this

virtual server, and this service is associated with the real server group.

Other TCP/IP services can be configured in a similar fashion. For a list of other well-known

services and ports, see Table 10-3 “Well-Known Application Ports” on page 192. To configure

multiple services, see “Configuring Multiple Services” on page 194.

NOTE – Define a virtual server IP address for each ISP.

>> # /cfg/slb/filt 50>> Filter 50# sip 1.1.1.0 (From server subnet)

>> Filter 50# smask 255.255.255.0>> Filter 50# dip 1.1.1.1 (To IF 1 on the Alteon Application Switch)

>> Filter 50# action allow >> Filter 50# ena








Step 5a: Configure the virtual server IP address and the services for ISP 1




Step 5b: Configure the virtual server IP address and the services for ISP 2









>>Virtual Server 1 HTTP Service# ena (Enable the service)

>>Virtual Server 1 HTTP Service# group 3 (Add real server group)

>>Virtual Server 1 HTTP Service#.. (Go to the virtual server menu)




>> # /cfg/slb/virt 2 (Select the virtual server)>>Virtual Server 2# vip 80.1.1.100 (Set IP address from the ISP 1 subnet)




>>Virtual Server 2 HTTP Service# ena (Enable the service)>>Virtual Server 2 HTTP Service# group 3 (Add real server group)

>>Virtual Server 2 HTTP Service#.. (Go to the virtual server menu)







NOTE – Repeat Steps 5a and 5b for virtual server 3 and 4 and add group 4 for each of the ser-

vices. This allows inbound traffic to access SLB servers hosting the XYZ.com.


Step 6: Configure the Application Switch as a Domain Name Server

This involves configuring the domain record name and mapping the virtual server and realserver (ISP router) for each WAN link.

You must map the domain record, nortelnetworks.com to each ISP. Each ISP has two parame-

ters—virtual 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 mea-

sure the ISP load and ISP health. These commands map the two parameters to the ISP link

1. Configure the Domain record for abc.com .

2. Configure an entry for each ISP and specify the virtual and real server (ISP router).

3. Configure the Domain record for xyz.com .


>> Domain Record 1# ena (Enable the Domain)

>> Domain record 1# domain abc.com (Define the Domain name)








>> Domain Record 2# ena (Enable the Domain)

>> Domain record 2# domain xyz.com (Define the Domain name)

drecord 1: abc.com

entry 1 : VIP 1 and Real 1 (for ISP 1)


drecord 2: xyz.com







4. Configure an entry for each ISP and specify the virtual and real server (ISP router).

Step 7: Apply and save your changesYou 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.




3. Check the load balancing information.

Check that all load balancing parameters are working according to expectation. If necessary,

make any appropriate configuration changes and then check the information again.

>> Domain record 2# entry 1/ena (Define entry for ISP 1)>> Virt Real Mapping# virt 3 (Select virtual server 3 for ISP 1)












CHAPTER 13

Filtering

This chapter provides a conceptual overview of filters and includes configuration examples

showing how filters can be used for network security and Network Address Translation

(NAT).


“Overview” on page 332. This section describes the benefits and filtering criteria to allow

for extensive filtering at the IP and TCP/UDP levels.

“Filtering Benefits” on page 332

“Filtering Criteria” on page 333

“Stacking Filters” on page 334

“Overlapping Filters” on page 335

“The Default Filter” on page 335

“VLAN-based Filtering” on page 340

“Optimizing Filter Performance” on page 336

“Filter Logs” on page 337

“IP Address Ranges” on page 337

“Cached versus Non-cached Filters” on page 338

“Tunable Hash for Filter Redirection” on page 344 allows you to select any hash parame-

ter for filter redirection.

“Filter-based Security” on page 345. This section provides an example of configuring fil-

ters for providing the best security.

“Network Address Translation” on page 351. This section provides two examples: Inter-

nal client access to the Internet and external client access to the server.

“Matching TCP Flags” on page 357 and “Matching ICMP Message Types” on page 361.

Describes the ACK filter criteria which provides greater filtering flexibility and lists

ICMP message types that can be filtered respectively.



315394-J, January 2005331

“Deny Filter Based on Layer 7 Content Lookup” on page 363

“Filtering on 802.1p Priority Bit in a VLAN Header” on page 342


Overview

Alteon Application Switches are used to deliver content efficiently and secure your servers

from unauthorized intrusion, probing, and Denial-of-Service (DoS) attacks. Alteon OS

includes extensive filtering capabilities at the Layer 2 (MAC), Layer 3 (IP) and Layer 4 (TCP/

UDP) levels.

Filtering Benefits

Filtering give the network administrator a powerful tool with the following benefits:

Filtering of Layer 2 non-IP frames. In Alteon OS 22.0,a filter 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 traffic permitted through the

switch. Filters can be configured to allow or deny traffic from Layer 2 - Layer 7: MAC

address, IP address, protocol, and Layer 4 port, and Layer 7 string or pattern content.Layer 2 only filters, as described in “MAC-Based Filters for Layer 2 Traffic” on page 339

can be configured to allow or deny non-IP traffic.

You can also secure your switch from further virus attacks by allowing you to configure

the switch with a list of potential offending string patterns. For more information, see

“Deny Filter Based on Layer 7 Content Lookup” on page 363.

Any filter can be optionally configured 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 traffic to or from advertised network IP

addresses and ports.



315394-J, January 2005332 Chapter 13: Filtering


Filtering Criteria

Up to 2048 filters can be configured on the Alteon Application Switch. Descriptive names can be used to define filters. Each filter can be set to perform Filtering Actions, based on any com-

bination of the following filter options:

smac: source MAC address.

dmac: destination MAC address.

sip: source IP address or range (see “IP Address Ranges” on page 337)

dip: destination IP address or range (dip and dmask)

proto: protocol number or name as shown in Table 13-1 on page 333.

sport: TCP/UDP application or source port as shown in Table 10-3 on page 192, or

source port range (such as 31000-33000)

NOTE – The service number specified on the switch must match the service specified on the server.

dport: TCP/UDP application or destination port as shown in Table 10-3 on page 192, or

destination port range (such as 31000-33000)

invert: reverse the filter logic in order to activate the filter whenever the specified condi-

tions are not met. Advanced filtering options such as TCP flags ( page 357) or ICMP message types ( page 361)

are also available.

Using these filter criteria, you could create a single filter that blocks external Telnet traffic to

your main server except from a trusted IP address. Another filter could warn you if FTP access

is attempted from a specific IP address. Another filter could redirect all incoming e-mail traffic

to a server where it can be analyzed for spam. The options are nearly endless.

Table 13-1 Well-Known Protocol Types

Number Protocol Name

1

2

6

17

89

112

icmp

igmp

tcp

udp

ospf

vrrp



315394-J, January 2005Chapter 13: Filtering 333


Filtering Actions

A filtering action (/cfg/slb/filt/action) instructs the filter what to do once the filteringcriteria are matched.

allow —Allow the frame to pass (by default).

deny —Discard frames that fit this filter’s profile. This can be used for building basic

security profiles.

redir —Redirect frames that fit this filter’s profile, such as for web cache redirection. In

addition, Layer 4 processing must be activated using the /cfg/slb/on command). nat —Perform 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.

goto —Allows the user to specify a target filter ID that the filter search should jump to

when a match occurs. The “goto” action causes filter processing to jump to a designated

filter, effectively skipping over a block of filter IDs. Filter searching will then continuefrom the designated filter ID. To specify the new filter to goto, use the /cfg/slb/filt/

adv/goto command.

Stacking Filters

Stacking filters are assigned and enabled on a per-port basis. Each filter can be used by itself or

in combination with any other filter on any given switch port. The filters are numbered 1

through 2048 on Alteon Application Switches. When multiple filters are stacked together on a

port, the filter’s number determines its order of precedence: the filter with the lowest number is

checked first. When traffic is encountered at the switch port, if the filter matches, its config-

ured action takes place and the rest of the filters are ignored. If the filter criteria do not match,

the next filter is tried.

As long as the filters do not overlap, you can improve filter performance by making sure that

the most heavily utilized filters are applied first. For example, consider a filter system wherethe Internet is divided according to destination IP address:

Figure 13 1 Assigning Filters According to Range of Coverage

Allow Deny Redirect

Filtering by Destination IP Address Ranges

Deny

0.0.0.0 255.255.255.255

Filter 1Filter 3Filter 4Filter 2




Figure 13-1 Assigning Filters According to Range of Coverage

Assuming that traffic 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.




In this example, the default filter is defined 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 filter acts

on the traffic, Filter 2048 processes it, denying and logging unwanted traffic.

Default filters are recommended (but not required) when configuring filters for IP traffic con-

trol and redirection. Using default filters can increase session performance but takes some of

the session binding resources. If you experience an unacceptable number of binding failures, asshown in the Server Load Balancing Maintenance Statistics (/stats/slb/maint), you may

wish to remove some of the default filters.

Optimizing Filter Performance

Filter efficiency can be increased by placing filters that are used most often near the beginning

of the filtering list.

It is a recommended practice to number filters in small increments (5, 10, 15, 20, etc.) to make

it easier to insert filters into the list at a later time. However, as the number of filters increases,

you can improve performance by minimizing the increment between filters. For example, fil-

ters numbered 2, 4, 6, and 8 are more efficient than filters numbered 20, 40, 60, and 80. Peak

processing efficiency is achieved when filters are numbered sequentially beginning with 1.

>> # /cfg/slb/filt 2048 (Select the default filter)

>> Filter 2048# sip any (From any source IP addresses)

>> Filter 2048# dip any (To any destination IP addresses)

>> Filter 2048# proto any (For any protocols)

>> Filter 2048# action deny (Deny matching traffic)

>> Filter 2048# name deny unwanted traffic (Provide a descriptive name for the

filter)

>> Filter 2048# ena (Enable the default filter)

>> Filter 2048# adv (Select the advanced menu)

>> Filter 2048 Advanced# log enable (Log matching traffic to syslog)





IP Address Ranges

You can specify a range of IP addresses for filtering both the source and/or destination IPaddress for traffic. When a range of IP addresses is needed, the source IP (sip) address or des-

tination IP (dip) address defines 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 request’s 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 configured with two filters so that each would handletraffic filtering for one half of the Internet. To do this, you could define the following parameters:

Filter Logs

To provide enhanced troubleshooting and session inspection capability, packet source and des-

tination IP addresses are included in filter log messages. Filter log messages are generated

when a Layer 3/Layer 4 filter 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 significant number of ICMP frames on one

portion of the network and wants to determine the specific sources of the ICMP messages. The

administrator uses the Command Line Interface (CLI) to create and apply the following filter:

Table 13-2 Filtering IP Address Ranges

Filter Internet Address Range dip dmask

1 0.0.0.0 - 127.255.255.255 0.0.0.0 128.0.0.0

2 128.0.0.0 - 255.255.255.255 128.0.0.0 128.0.0.0

>> # /cfg/slb/filt 15 (Select filter 15)



>> Filter 15# action allow (Allows matching traffic to pass)>> Filter 15# name allow matching traffic (Provide a descriptive name for the

filter)

>> Filter 15# proto icmp (For the ICMP protocol)


>> Filter 15# adv/log enable (Log matching traffic to syslog)

>> Filter 15 Advanced# /cfg/slb/port 7 (Select a switch port to filter)

>> SLB port 7# add 15 (Add the filter to the switch port)




>> SLB port 7# filt ena (Enable filtering on the switch port)>> SLB port 7# apply (Apply the configuration changes)

>> SLB port 7# save (Save the configuration changes)


When applied to one or more switch ports, this simple filter rule will produce log messages

that show when the filter 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 filter number, port, source

IP address, and destination IP address:

Cached versus Non-cached FiltersTo improve efficiency, by default, the Alteon Application Switch performs filter processing

only on the first 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 fil-

ters create a session entry in the application switch and are known as cached .

Some types of filtering (TCP flag and ICMP message type filtering) require each frame in the

session to be filtered separately. These filters are known as non-cached . A Layer 2 filter, whichspecifies only smac and dmac criteria, is a non-cached filter.

All filters are cached by default. To change the status of a filter, use the following commands:

NOTE – Cache-enabled filters should not be applied to the same ports as cache-disabled filters.

Otherwise, the cache-disabled filters could potentially be bypassed for frames matching the

cache-enabled criteria.

Logging Non-Cached Filter Hits

A non-cached filter hit occurs when a session entry is not cached. Cache-disabled filters are

used when a session is either very short-lived or contains minimal data.

In order to log cache-disabled filters without generating an excess amount of syslog messages,

the log message displays only a single NC filter message within a given window of time,

which includes the number of times the cache-disabled filter has fired.

1. To enable logging of both cached and cache-disabled filters, use the existing command:

slb: filter 15 fired on port 7, 206.118.93.110 -> 20.10.1.10

>> # /cfg/slb/filt <filter number>/adv (Select the advanced filter menu)

>> Filter 1 Advanced # cache ena|dis (Enable or disable filter caching)




>> # /cfg/slb/filt <#>/adv/log enable


2. Apply and save the configuration change.

An example of a Non-Cached Filter log message is as follows:

MAC-Based Filters for Layer 2 Traffic

In Alteon OS 22.0, filters can be configured based on MAC addresses to capture non-IP

frames. The benefits of a MAC-based filtering solution is that now a filter can be applied to

allow or deny non-IP traffic such as ARP, AppleTalk. While filtering has always allowed

MAC address criteria, only IP traffic was supported.

To configure a filter for non-IP traffic, specify only the source MAC (smac) and destination

MAC (dmac) addresses. Do not enter source or destination IP addresses on a MAC-based fil-

ter. MAC-based filtering of non-IP frames is supported for non-cached filters only. Even if

caching is enabled on this type of filter, it will not create a session entry.

To configure a MAC-based filter, specify only smac and dmac criteria without any IP-related

parameters. The only filtering actions supported for MAC-based filters are allow and deny.

MAC-based filters are supported for VLAN-based filters( page 340), and 802.1p bit filtering

( page 342).

For example:

>> Filter <#> Advanced# apply>> Filter <#> Advanced# save

Jun 28 3:57:57 WARNING slb: NON-cached filter 1 fired on port 1repeated 4 times.

>> # /cfg/slb/filt 23 (Select the menu for Filter 23)>>

Filter 23# smac any (From any source MAC address)

>> Filter 23# dmac 00:60:cf:40:56:00 (To this MAC destination address)>> Filter 23# action deny (Deny matching traffic)

>> Filter 23# ena (Enable this filter)





VLAN-based Filtering

Filters are applied per switch, per port, or per VLAN. VLAN-based filtering allows a single

application switch to provide differentiated services for multiple customers, groups, or depart-

ments. For example, you can define separate filters for Customers A and B on the same appli-

cation switch on two different VLANs. If VLANs are assigned based on data traffic, for

example, ingress traffic on VLAN 1, egress traffic on VLAN 2, and management traffic on

VLAN 3, filters can be applied accordingly to the different VLANs.

In the following example shown in Figure 13-4, Filter 2 is configured to allow local clients on

VLAN 20 to browse the Web, and Filter 3 is configured to allow local clients on VLAN 30 to

Telnet anywhere outside the local intranet. Filter 2048 is configured to deny ingress traffic

from VLAN 70.

Figure 13-4 VLAN-based Filtering

NOTE – While the following example is based on IP traffic, VLAN-based filtering can also be

used for non-IP traffic by specifying smac and dmac criteria instead of sip and dip.

ST PAlteon

ApplicationSwitch

Internet

Unique Filters perVLAN (up to 2048)

VLAN 20

VLAN 30

VLAN 70

F i l t e

r 2

Filter 3

F i l t e r 2 0 4 8





Configuring VLAN-based Filtering

1. Configure filter 2 to allow local clients to browse the Web and then assign VLAN 20 tothe filter.

The filter must recognize and allow TCP traffic from VLAN 20 to reach the local client destina-

tion IP addresses if originating from any HTTP source port:

All clients from other VLANs will be ignored.

2. Configure filter 3 to allow local clients to Telnet anywhere outside the local intranet and

then assign VLAN 30 to the filter.

The filter must recognize and allow TCP traffic to reach the local client destination IP

addresses if originating from a Telnet source port:



>> Filter 2# dip 205.177.15.0 (To base local network dest. address)>> Filter 2# dmask 255.255.255.0 (For entire subnet range)

>> Filter 2# proto tcp (For TCP protocol traffic)

>> Filter 2# sport http (From any source HTTP port)

>> Filter 2# dport any (To any destination port)


>> Filter 2# vlan 20 (Assign VLAN 20 to Filter 2)




>> Filter 3# dip 205.177.15.0 (To base local network dest. address)

>> Filter 3# dmask 255.255.255.0 (For entire subnet range)


>> Filter 3# sport telnet (From a Telnet port)


>> Filter 3# action allow (Allow matching traffic to pass)>> Filter 3# name allow clients to telnet (Provide a descriptive name for the

filter)







3. Configure Filter 2048 to deny traffic and then assign VLAN 70 to the filter.

As a result, ingress traffic from VLAN 70 is denied entry to the switch.

Filtering on 802.1p Priority Bit in a VLAN

Header

Alteon OS allows you to filter based on the priority bits in a packet’s VLAN header. (The pri-

ority bits are defined 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 prefer-

ence 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 traffic 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” traffic prioritization, and this is the

default when traffic priority has not been configured on your network. The Alteon ApplicationSwitch can only filter 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.






>> Filter 2048# sport http (From a Telnet port)


>> Filter 2048# action deny (Allow matching traffic to pass)







Classifying and Prioritizing Packets Based on 802.1p

Priority BitsTraffic is easily classified based on their 802.1p priority by applying a filter based on the prior-

ity bit value. The filtering advanced menu in Alteon OS provides the option to filter based on

the priority bit value. The filter will match if it finds the corresponding 802.1p bit value in the

packet. If the packet does not have the 802.1p bits the filter will not match.

Configuring a Filter to Classify Traffic Based on 802.1p Priority

To match on the 802.1p priority bit, go to the Filtering Advanced Menu. Then choose the

802.1p priority bit value (0-7).

1. Configure a filter and an action.

2. Go to the filtering advanced menu and select the 802.1p priority value.

3. Apply a BWM Contract to the Prioritized Filter.

You can apply an 802.1p-prioritized filter to a Bandwidth Management contract to establish

the rule for how the traffic that matches the defined 802.1p priority value.

For more information on configuring a Bandwidth Management contract, see “Contracts” on

page 671.

>> # /cfg/slb/filt <x>/ena (Enable the filter)

>> Filter 1 # action allow (Set filter action)

>> # /cfg/slb/filt <x>

>> 802.1p Advanced# adv/8021p/ (Select the 802.1p Advanced Menu)

>> 802.1p Advanced# match ena (Enable matching of 802.1p value)

>> # 802.1p Advanced# value 1 (Set the 802.1p priority value to

match)

>> # /cfg/slb/filt <x>/adv/cont 1 (Apply BWM contract 1 to this filter)





Tunable Hash for Filter Redirection

Alteon OS allows you to choose a number of options when using the hash parameter for filter

redirection. Hashing can be based on source IP address, destination IP address, both, or source

IP address and source port. For example:

1. Configure hashing based on source IP address:

Hashing on the 24-bit source IP address ensures that client requests access the same cache.


The source IP address is passed to the real server group for either of the two metrics.

NOTE – If firewall load balancing is enabled on the switch, the firewall load balancing filter

which hashes on source and destination IP addresses will override the tunable hash filter.

>> # /cfg/slb/filt 10/ena (Enable the filter)

>> Filter 10 # action redir (Specify the redir action)>> Filter 10 # proto tcp (Specify the protocol)

>> Filter 10 # group 1 (Specify the group of real servers)

>> Filter 10 # rport 3128 (Specify the redirection port)

>> Filter 10 # vlan any (Specify the VLAN)

>> Filter 10 # adv (Select the advanced filter menu)

>> TCP advanced menu # thash sip (Select source IP address for hashing)

>> # /cfg/slb/group 1 (Select the group of real servers)

>> Real server group 1 # metric minmiss (Set the metric to minmiss or hash)





Filter-based Security

This section provides an example of configuring filters for providing the best security. It is rec-

ommended that you configure filters to deny all traffic except for those services that you spe-

cifically wish to allow. Consider the following sample network:

Figure 13-5 Security Topology Example

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 filters to allow only the fol-

lowing traffic:

External HTTP access to the local Web server

External SMTP (mail) access to the local mail server

Local clients browsing the World Wide Web

Local clients using Telnet to access sites outside the intranet

DNS traffic

All other traffic is denied and logged by the default filter.

NOTE – Since IP address and port information can be manipulated by external sources, filter-

ing does not replace the necessity for a well-constructed network firewall.

Web Server

205.177.15.2

Mail Server

205.177.15.3

DNS

205.177.15.4


Local Clients

Internet

RouterClient Switch





Configuring a Filter-Based Security Solution

Before you begin, you must be connected to the switch CLI as the administrator.

In this example, all filters are applied only to the switch port that connects to the Internet . If

intranet restrictions are required, filters can be placed on switch ports connecting to local

devices.

Also, filtering is not limited to the few protocols and TCP or UDP applications shown in this

example. See Table 10-3 on page 192 for a list of well-known applications ports and Table

13-1 on page 333 for a list of supported protocols.

1. 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:

2. At the Application Switch, create a default filter to deny and log unwanted traffic.

The default filter is defined as Filter 2048 in order to give it the lowest order of precedence:

NOTE – Because the proto parameter is not tcp or udp, the source port (sport) and destina-

tion port (dport) values are ignored and may be excluded from the filter configuration.

Table 13-3 Web Cache Example: Real Server IP Addresses

Network Device IP address

Local Subnet 205.177.15.0 - 205.177.15.255

Web Server 205.177.15.2

Mail Server 205.177.15.3

Domain Name Server 205.177.15.4

>> # /cfg/slb/filt 2048 (Select the default filter)




>> Filter 2048# action deny (Deny matching traffic)

>> Filter 2048# name deny unwanted traffic (Provide a descriptive name for the filter)


>> Filter 2048# adv/log enable (Log matching traffic to syslog)





3. Create a filter that will allow external HTTP requests to reach the Web server.

The filter must recognize and allow TCP traffic with the Web server’s destination IP address

and HTTP destination port:

4. Create a pair of filters 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:

>> Filter 2048# /cfg/slb/filt 1 (Select the menu for filter 1)


>> Filter 1# dip 205.177.15.2 (To Web server dest. IP address)

>> Filter 1# dmask 255.255.255.255 (Set mask for exact dest. address)


>> Filter 1# sport any (From any source port)

>> Filter 1# dport http (To an HTTP destination port)


>> Filter 1# name allow matching traffic (Provide a descriptive name for the

filter)




>> Filter 2# dip 205.177.15.3 (To mail server dest. IP address)


>> Filter 2# proto tcp (For TCP protocol traffic)>> Filter 2# sport any (From any source port)

>> Filter 2# dport smtp (To a SMTP destination port)




>> Filter 3# sip 205.177.15.3 (From mail server source IP address)

>> Filter 3# smask 255.255.255.255 (Set mask for exact source address)

>> Filter 3# dip any (To any destination IP address)>> Filter 3# proto tcp (For TCP protocol traffic)

>> Filter 3# sport smtp (From a SMTP port)








5. Create a filter that will allow local clients to browse the Web.

The filter must recognize and allow TCP traffic to reach the local client destination IP addresses

if traffic originates from any HTTP source port:

6. Create a filter that will allow local clients to Telnet anywhere outside the local intranet.

The filter must recognize and allow TCP traffic to reach the local client destination IP

addresses if originating from a Telnet source port:

7. Create a series of filters to allow Domain Name System (DNS) traffic.

DNS traffic requires four filters; one pair is needed for UDP traffic (incoming and outgoing)and another pair for TCP traffic (incoming and outgoing).

>> Filter 3# /cfg/slb/filt 4 (Select the menu for Filter 4)





>> Filter 4# sport http (From any source HTTP port)



>> Filter 4# name allow clients Web browse (Provide a descriptive name for the

filter)






>> Filter 5# proto tcp (For TCP protocol traffic)>> Filter 5# sport telnet (From a Telnet port)








For UDP:

Similarly, for TCP:

>> Filter 5# /cfg/slb/filt 6 (Select the menu for Filter 6)>> Filter 6# sip any (From any source IP address)

>> Filter 6# dip 205.177.15.4 (To local DNS Server)


>> Filter 6# proto udp (For UDP protocol traffic)


>> Filter 6# dport domain (To any DNS destination port)


>> Filter 6# ena (Enable the filter)>> Filter 6# /cfg/slb/filt 7 (Select the menu for Filter 7)

>> Filter 7# sip 205.177.15.4 (From local DNS Server)



>> Filter 7# proto udp (For UDP protocol traffic)

>> Filter 7# sport domain (From a DNS source port)


>> Filter 7# action allow (Allow matching traffic to pass)>> Filter 7# ena (Enable the filter)



>> Filter 8# dip 205.177.15.4 (To local DNS Server)




>> Filter 8# dport domain (To any DNS destination port)




>> Filter 9# sip 205.177.15.4 (From local DNS Server)




>> Filter 9# sport domain (From a DNS source port)








8. Assign the filters to the switch port that connects to the Internet.

Alteon OS allows you to add and remove a contiguous block of filters with a single command.


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


11. Check the server load balancing information.



NOTE – Changes to filters on a given port do not take effect until the port’s session informa-

tion is updated (every two minutes or so). To make filter changes take effect immediately,

clear the session binding table for the port (see the /oper/slb/clear command in the Alteon

OS Command Reference).

>> Filter 9# /cfg/slb/port 5 (Select the SLB port 5 to the Internet)>> SLB Port 5# add 1-9 (Add filters 1-9 to port 5)

>> SLB Port 5# add 2048 (Add the default filter to port 5)

>> SLB Port 5# filt enable (Enable filtering for port 5)

>> SLB Port 5# apply (Make your changes active)

>> SLB Port 5# cur (View current settings)

>> SLB Port 5# save (Save for restore after reboot)

>> SLB Port 5# /info/slb/dump (View SLB information)





Network Address Translation

Network Address Translation (NAT) is an Internet standard that enables an Alteon Application

Switch to use one set of IP addresses for internal traffic and a second set of addresses for exter-

nal traffic. Alteon Application Switches use filters to implement NAT.

NAT serves two main purposes:

Provides a type of firewall by hiding internal IP addresses and increases network security.

Enables a company to use more internal IP addresses. Since they're used internally only,there's no possibility of conflict with public IP addresses used by other companies and

organizations.

In the following NAT examples, a company has configured 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 theswitch allow internal, private network IP addresses to be translated to valid, publicly adver-

tised IP addresses and back again. NAT can be configured in one of the following two ways:

Static NAT provides a method for direct mapping of one predefined 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 filters: one for the external client-side

switch port, and one for the internal, server-side switch port. The client-side filter translates

incoming requests for the publicly advertised server IP address to the server’s internal private

network address. The filter for the server-side switch port reverses the process, translating the

server’s private address information to a valid public address.





In this example, clients on the Internet require access to servers on the private network:

Figure 13-6 Static Network Address Translation

Configuring Static NAT

>> # /cfg/slb/filt 10 (Select the menu for outbound filter)

>> Filter 10# action nat (Perform NAT on matching traffic)

>> Filter 10# nat source (Translate source information)

>> Filter 10# sip 10.10.10.0 (From the clients private IP address)

>> Filter 10# smask 255.255.255.0 (For the entire private subnet range)

>> Filter 10# dip 205.178.13.0 (To the public network address)

>> Filter 10# dmask 255.255.255.0 (For the same subnet range)


>> Filter 10# adv/proxy disable (Override any proxy IP settings)

>> Filter 10 Advanced# /cfg/slb/filt 11 (Select the menu for inbound filter)

>> Filter 11# action nat (Use the same settings as outbound)

>> Filter 11# nat dest (Reverse the translation direction)

>> Filter 11# sip 10.10.10.0 (Use the same settings as outbound)

>> Filter 11# smask 255.255.255.0 (Use the same settings as outbound)

>> Filter 11# dip 205.178.13.0 (Use the same settings as outbound)

>> Filter 11# dmask 255.255.255.0 (Use the same settings as outbound)


>> Filter 11# adv/proxy disable (Override any proxy IP settings)

>> Filter 11 Advanced# /cfg/slb/port 1 (Select server-side port)

>> SLB port 1# add 10 (Add the outbound filter)

>> SLB port 1# filt enable (Enable filtering on port 1)

>> SLB port 1# /cfg/slb/port 2 (Select the client-side port)

>> SLB port 2# add 11 (Add the inbound filter)


>> SLB port 2# apply (Apply configuration changes)

>> SLB port 2# save (Save configuration changes)

Router

External Clients

Internet

Inbound filter:

NAT destinationto private address

Outbound filter:NAT source info

to public address

1 2

Public IP Address:

205.178.13.x

Server:

10.10.10.1(Private network)

Alteon Application

Switch





Note the following important points about this configuration:

Within each filter, the smask and dmask values are identical.

All parameters for both filters are identical except for the NAT direction. For Filter 10,

nat source is used. For Filter 11, nat dest is used.

Filters for static (non-proxy) NAT should take precedence over dynamic NAT filters (fol-

lowing example). Static filters should be given lower filter numbers.

Dynamic NATDynamic 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:

Figure 13-7 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 traffic for PING.

This example requires a NAT filter to be configured on the switch port that is connected to the

internal clients. When the NAT filter is triggered by outbound client traffic, 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 configured 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.

RouterLayer 2

switchInternal Clients

10.10.10.x

(Private network)

Internet

Inbound proxy on

public address


to public addressPublic IP Address:

205.178.17.12

1





Configuring Dynamic NAT

For more information on proxy IP address, see “Proxy IP Addresses” on page 219.

NOTE – The invert option in this example filter makes this specific configuration easier, but

is not a requirement for dynamic NAT.

NOTE – Filters for dynamic NAT should be given a higher numbers than any static NAT fil-ters (see “Static NAT” on page 351).

>> # /cfg/slb/filt 14 (Select the menu for client filter)>> Filter 14# invert ena (Invert the filter logic)

>> Filter 14# dip 10.10.10.0 (If the destination is not private)

>> Filter 14# dmask 255.255.255.0 (For the entire private subnet range)





>> Filter 14# adv/ proxy enable (Enable client proxy on this filter)>> Filter 14 Advanced# proxyip 205.178.17.12(Set the filter’s proxy IP address)

>> Filter 14 Advanced# /cfg/slb/port 1 (Select SLB port 1)

>> SLB port 1# add 14 (Add the filter 14 to port 1)


>> SLB port 1# proxy ena (Enable proxies on this port)







FTP Client NAT

Alteon Application Switches provide NAT services to many clients with private IP addresses.In Alteon OS, 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 chan-

nel, information that reveals their private IP address, out to the Internet. However, the switch

filter 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 defined on the switch. When a client in active FTP mode sends a port com-

mand 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.

Figure 13-8 Active FTP for Dynamic NAT

You may directly connect the real servers to the application switch if the total number of serv-

ers is less than or equal to the switch ports.

Router

Layer 2

switch

Real servers

10.10.10.x

(Private network)

Internet

Inbound proxy on

public address


to public address

1Public IP Address:

205.178.17.12

(Pool of proxy IPaddresses insteadof a single proxy

IP address)

Alteon

Application

Switch





Configuring Active FTP Client NAT

NOTE – The passive mode does not need this feature.

1. Make sure that a proxy IP address is enabled on the filter port.

2. Make sure that a source NAT filter is set up for the port.:


3. Enable active FTP NAT using the following command:

4. Apply and save the switch configuration.

>> # /cfg/slb/filt 14 (Select the menu for client filter)

>> Filter 14# invert ena (Invert the filter logic)>> Filter 14# dip 10.10.10.0 (If the destination is not private)

>> Filter 14# dmask 255.255.255.0 (For the entire private subnet range)





>> Filter 14# adv/ proxy enable (Allow proxy IP translation)

>> Filter 14 Advanced# proxyip 205.178.17.12(Set the filter’s proxy IP address)>> Proxy IP Address# /cfg/slb/port 1 (Select SLB port 1)

>> SLB port 1# add 14 (Add the filter to port 1)


>> SLB port 1# proxy ena (Enable proxies on this port)



>> # /cfg/slb/filt <filter number>/adv/layer7/ftpa ena





Matching TCP Flags

Alteon OS supports packet filtering based on any of the following TCP flags.

Any filter may be set to match against more than one TCP flag at the same time. If there is

more than one flag enabled, the flags are applied with a logical AND operator. For example, by

setting the switch to filter SYN and ACK, the switch filters all SYN-ACK frames.

NOTE – TCP flag filters must be cache-disabled. Exercise caution when applying cache-

enabled and cache-disabled filters to the same switch port. For more information, see “Cached

versus Non-cached Filters” on page 338.

Configuring the TCP Flag Filter

NOTE – By default, all TCP filter options are disabled. TCP flags will not be inspected unless

one or more TCP options are enabled.

Consider the following network:

Figure 13-9 TCP ACK Matching Network

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

Flag Description

URG Urgent

ACK Acknowledgement

PSH Push

RST ResetSYN Synchronize

FIN Finish

SMTP

Mail Server

Router

Alteon Application

Switch

Web Servers:

203.122.186.*

InternetInside/

Trusted LAN23

1




from the Internet, except for HTTP.


SMTP traffic 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 filter with the ACK flag closes one potential security hole. Without the filter, 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 server's buffer space to

fill, crashing the server or at least making it unavailable.

A filter with the ACK flag 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

flag turned off.

The following filters are required:

1. An allow filter for TCP traffic from LAN that allows the Web servers to pass SMTP

requests to the Internet.

2. A filter that allows SMTP traffic 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.

>> # /cfg/slb/filt 10 (Select a filter for trusted SMTP requests)

>> Filter 10# sip 203.122.186.0 (From the Web servers’ source IP address)

>> Filter 10# smask 255.255.255.0 (For the entire subnet range)


>> Filter 10# proto tcp (For TCP traffic)


>> Filter 10# dport smtp (To well-known destination SMTP port)


>> Filter 10# /cfg/slb/filt 15 (Select a filter for Internet SMTP ACKs)


>> Filter 15# sport smtp (From well-known source SMTP port)


>> Filter 15# dip 203.122.186.0 (To the Web servers’ IP address)

>> Filter 15# dmask 255.255.255.0 (To the entire subnet range)




>> Filter 15# adv/tcp (Select the advanced TCP menu)>> Filter 15 Advanced# ack ena (Match acknowledgments only)

>> Filter 15 Advanced# syn ena (Match acknowledgments only)





3. A filter that allows SMTP traffic 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.

4. A filter that allows trusted HTTP traffic from the Internet to pass through the switch to

the Web servers.

5. A filter that allows HTTP responses from the Web servers to pass through the switch to

the Internet.

>> Filter 15# /cfg/slb/filt 16 (Select a filter for Internet SMTP ACKs)


>> Filter 16# sport smtp (From well-known source SMTP port)






>> Filter 16# adv/tcp (Select the advanced TCP menu)

>> Filter 16 Advanced# ack ena (Match acknowledgments only)

>> Filter 16 Advanced# psh ena (Match acknowledgments only)

>> Filter 16 Advanced# /cfg/slb/filt 17(Select a filter for incoming HTTP traffic)


>> Filter 17# sport http (From well-known source HTTP port)




>> Filter 17# dport http (To well-known destination HTTP port)


>> Filter 17# /cfg/slb/filt 18 (Select a filter for outgoing HTTP traffic)

>> Filter 18# sip 203.122.186.0 (From the Web servers’ source IP address)

>> Filter 18# smask 255.255.255.0 (From the entire subnet range)>> Filter 18# sport http (From well-known source HTTP port)



>> Filter 18# dport http (To well-known destination HTTP port)







6. A default filter is required to deny all other traffic.

7. Apply the filters to the appropriate switch ports.

>> Filter 18# /cfg/slb/filt 2048 (Select a default filter)



>> Filter 2048# action deny (Block matching traffic)

>> Filter 2048# name deny matching traffic (Provide a descriptive name for the

filter)


>> Filter 2048# /cfg/slb/port 1 (Select the Internet-side port)

>> SLB port 1# add 15 (Add the SMTP ACK filter to the port)

>> SLB port 1# add 16 (Add the incoming HTTP filter)

>> SLB port 1# add 17 (Add the incoming HTTP filter)

>> SLB port 1# add 2048 (Add the default filter to the port)

>> SLB port 1# filt ena (Enable filtering on the port)

>> SLB port 1# /cfg/slb/port 2 (Select the first Web server port)

>> SLB port 2# add 10 (Add the outgoing SMTP filter to the port)>> SLB port 2# add 18 (Add the outgoing HTTP filter to the port)



>> SLB port 2# /cfg/slb/port 3 (Select the other Web server port)

>> SLB port 3# add 10 (Add the outgoing SMTP filter to the port)

>> SLB port 3# add 18 (Add the outgoing HTTP filter to the port)



>> SLB port 3# apply (Apply the configuration changes)

>> SLB port 3# save (Save the configuration changes)





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 Table 13-4. Although ICMP pack-

ets can be filtered using the proto icmp option, by default, the application switch ignores the

ICMP message type when matching a packet to a filter. To perform filtering based on specific

ICMP message types, ICMP message type filtering must be enabled.

Alteon OS software supports filtering on the following ICMP message types:

The command to enable or disable ICMP message type filtering is entered from the Advanced

Filtering menu as follows:

For any given filter, only one ICMP message type can be set at any one time. The any option

disables ICMP message type filtering. The list option displays a list of the available ICMP

message types that can be entered.

Table 13-4 ICMP Message Types

Type # Message Type Description

0 echorep ICMP echo reply

3 destun ICMP destination unreachable

4 quench ICMP source quench

5redir

ICMP redirect8 echoreq ICMP echo request

9 rtradv ICMP router advertisement

10 rtrsol ICMP router solicitation

11 timex ICMP time exceeded

12 param ICMP parameter problem

13 timereq ICMP timestamp request14 timerep ICMP timestamp reply

15 inforeq ICMP information request

16 inforep ICMP information reply

17 maskreq ICMP address mask request

18 maskrep ICMP address mask reply

>> # /cfg/slb/filt <filter number>/adv

>> Filter 1 Advanced# icmp <message type|number|any|list>





NOTE – ICMP message type filters must be cache-disabled. Exercise caution when applying

cache-enabled and cache-disabled filters to the same switch port. For more information, see

“Cached versus Non-cached Filters” on page 338.





Deny Filter Based on Layer 7 Content

LookupAlteon OS allows you to secure your switch from virus attacks or invalid data requests by con-

figuring the switch with filters 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 traffic. The switch exam-

ines the HTTP or UDP content of 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 theoffending client. SYSLOG messages and SNMP traps are generated warning operators of a

possible attack.

A layer string 7 deny filter works just like a basic deny filter, except that the deny action is

delayed until the string content is examined to see if the packet should be denied.

Figure 13-10 shows an incoming client requests with offending content. The application

switch is configured with a deny filter combined with the Layer 7 lookup feature. The filter blocks the incoming packet with the offending string or pattern, and prevents it from entering

the network.

Figure 13-10 Configuring a Deny Filter with Layer 7 Lookup for HTTP URL,

HTTP Header, or UDP Strings


Internet Real servers

Clients ida

%c1%9c

%c0%af

www.playdog.com

HTTPHDR:Host:www.playdog.com

AAAAAA

HTTPHDR:SOAPAction:*

STOP

2. Switch filter processesthe string and denies entryto the network.

1. Client sendsa requestcontaining a disallowedstring.





Denying HTTP URL Requests

1. Before creating a deny filter with Layer 7 lookup, ensure that the switch has already beenconfigured for basic switch functions:



For information on how to configure your network for the above tasks, see Chapter 10, “Server

Load Balancing.”

2. Define the virus string patterns or offending HTTP URL request to be blocked.

3. Identify the IDs of the defined strings.

Number of entries: 4

4. Assign the URL string IDs from Step 2 to the filter.

5. Enable Layer 7 lookup. This feature, when combined with the filter deny action, will

match and deny any traffic containing the strings you just added in Step 4.

>> # /cfg/slb/layer7/slb/addstr ida (Define the code red virus string)

>> Server Loadbalance Resource# add %c1%9c (Define the code blue virus string)

>> Server Loadbalance Resource# add %c0%af (Define the code blue virus string)

>> Server Loadbalance Resource# add playdog.com (Define offending URL request)

>> Server Loadbalance resource# cur

ID SLB String

1 ida

2 %c1%9c3 %c0%af

4 playdog.com

>> /cfg/slb/filt 1/adv/layer7 (Select the Filt. 1 L7 Advanced menu)

>> Layer 7 Advanced# addstr 1 (Add the code red virus string)

>> Layer 7 Advanced# addstr 2 (Add the code blue virus string)

>> Layer 7 Advanced# addstr 3 (Add the code blue virus string)

>> Layer 7 Advanced# addstr 4 (Add the offending URL request)

>> /cfg/slb/filt 1/adv/layer7/l7lkup ena (Enable the Layer 7 lookup feature)





6. Select the filter and enable the filter action to deny.


Denying HTTP Headers

Layer 7 deny filters can be configured 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=*

Configure a filter as described in “Denying HTTP URL Requests” on page 364.

1. Define the HTTP header strings to be blocked.



>> Filter 1 # action deny (Set the filter action to deny)

>> Filter 1 Advanced# apply (Apply the filter)

>> Filter 1 Advanced# save (Save the configuration)

>> /cfg/slb/layer7/slb/ (Select the Serverloadbalance Resource menu)

>> Server Loadbalance Resource# addEnter type of string [l7lkup|pattern]: l7lkupConfigure HTTP header string? [y/n] yEnter HTTP header name: Host (Define HTTP header name Host)

Enter SLB header value string: www.playdog.com (Define offending header content)

Configure URL string? [y/n] yEnter URL string: http://www.playdog.com

>> Server Loadbalance Resource# addEnter type of string [l7lkup|pattern]: l7lkupConfigure HTTP header string? [y/n] yEnter HTTP header name: SoapAction=* (Define SOAPAction header)

Enter SLB header value string:Configure URL string? [y/n] n






The strings in bold are used in this example.


3. Assign the HTTP host header string IDs from Step 1 to the filter.

4. Enable Layer 7 lookup. This feature, when combined with the filter deny action, will

match and deny any traffic containing the strings you just added in Step 3.

5. Set the filter action to deny.


ID SLB String

1 ida

2 %c1%9c

3 %c0%af

4 playdog.com

6 HTTPHDR:Host:www.playdog.com

7 HTTPHDR:SoapAction=*

>> /cfg/slb/filt 1/adv/layer7 (Select the Filt. 1 L7 Advanced menu)

>> Layer 7 Advanced# addstr 6 (Add the HTTP header host string)

>> Layer 7 Advanced# addstr 7 (Add the HTTP header SoapAction

string)

/cfg/slb/filt 1/adv/layer7/l7lkup ena (Enable the Layer 7 lookup feature)



>> Filter 1 Advanced# apply (Apply the filter)

>> Filter 1 Advanced# save (Save the configuration)




CHAPTER 14

Application Redirection

Application Redirection improves network bandwidth and provides unique network solutions.

Filters can be created to redirect traffic to cache and application servers improving speed of

access to repeated client access to common Web or application content and free valuable net-

work bandwidth.


“Overview” on page 369. Application redirection helps reduce the traffic congestion dur-ing peak loads by accessing locally cached information. This section also discusses how

performance is improved by balancing cached requests across multiple servers.

“Cache Redirection Configuration Example” on page 371. 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” on page 376. This section explains how to configure 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” on page 379. This section discusses the benefits of trans-

parent proxies when used with application redirection.

“Excluding Noncacheable Sites” on page 381. This section describes how to filter out

applications that prevent real-time session information from being redirected to cache

servers.

“Content Intelligent Cache Redirection” on page 382. This section describes how to redi-

rect cache requests based on different Layer 7 content.

“HTTP Redirection” on page 402. This section describes how use filters to redirect HTTP

requests to different gateways or servers.



315394-J, January 2005367


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 Alteon OS Command

Reference).



315394-J, January 2005368 Chapter 14: Application Redirection


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 traffic congestion during peak loads. When Appli-cation redirection filters are properly configured for the Alteon OS-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 client’s outbound request as one that

can be filled with cached information, the servers supply the information rather than send the

request across the Internet.

In addition to increasing the efficiency of your network, accessing locally cached informationcan 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.

Figure 14-1 Traditional Network Without Cache Redirection

Clients

Internet

Router

Client Switch

Client Switch

Congestion

Targets Router



315394-J, January 2005Chapter 14: Application Redirection 369


The network needs a solution that addresses the following key concerns:

The solution must be readily scalable

The administrator should not need to reconfigure all the clients’ browsers to use proxy

servers.

Figure 14-2 Network with Cache Redirection

If you have more clients than application switch ports, then connect the clients to a layer 2

switch.

Adding an Alteon 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” on page 191 for details.

AB

C

Clients

Internet

Router

HTTP

Requests

HTTP requests

are redirected

Cache farm proxiesclient requests





Cache Redirection Configuration Example

The following is required prior to configuration:

You must connect to the application switch Command Line Interface (CLI) as

the administrator.

Layer 4 (SLB) software must be enabled.

NOTE – For details about the procedures above, and about any of the menu commands

described in this example, see the Alteon OS Command Reference.

In this example, an Alteon Application Switch is placed between the clients and the border gate-

way to the Internet. The application switch will be configured 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, filters are not limited to the few protocols and TCP or UDP applications shown in this

example. See Table 10-3 on page 192 for a list of well-known applications ports and Table

13-1 on page 333 for a list of supported protocols.

1. 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 routeto 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 configuring IP proxy addresses (see “IP

Proxy Addresses for NAT” on page 379).

For this example, the three cache real servers have the following IP addresses on the same IPsubnet:

Table 14-1 Cache Redirection Example: Real Server IP Addresses

Cache Server IP address

Server A 200.200.200.2

Server B 200.200.200.3

Server C 200.200.200.4





2. Install transparent cache software on all three cache servers.

3. Define an IP interface on the application switch.

The application switch must have an IP interface on the same subnet as the three cache servers

because, by default, the application switch only remaps destination MAC addresses.

To configure an IP interface for this example, enter this command from the CLI:

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 con-

figuration for the ports or IP interface.

4. Define each real server on the switch.

For each cache real server, you must assign a real server number, specify its actual IP address,

and enable the real server. For example:

5. Define a real server group.

This places the three cache real servers into one service group:




>> # /cfg/slb/real 1 (Server A is real server 1)

>> Real server 1# rip 200.200.200.2 (Assign Server A IP address)


>> Real server 1# /cfg/slb/real 2 (Server B is real server 2)

>> Real server 2# rip 200.200.200.3 (Assign Server B IP address)


>> Real server 2# /cfg/slb/real 3 (Server C is real server 3)

>> Real server 3# rip 200.200.200.4 (Assign Server C IP address)










6. 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 ser-

vice:

7. 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 Alteon OS Command

Reference.

8. Create a filter that will intercept and redirect all client HTTP requests.

The filter must be able to intercept all TCP traffic for the HTTP destination port and must redi-

rect it to the proper port on the real server group:

The rport (redirection) parameter must be configured whenever TCP/UDP protocol traffic is

redirected. The rport parameter defines the real server TCP or UDP port to which redirected

traffic will be sent. The port defined 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 page 372),

the rport parameter must be configured for all application redirection filters. 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 specific software

package.

See “IP Proxy Addresses for NAT” on page 379 for more information on IP proxy addresses.

>> Real server group 1# metric minmisses (Metric for minimum cache misses.)

>> SLB port 6# /cfg/slb/filt 2 (Select the menu for Filter 2)






>> Filter 2# action redir (Set the action for redirection)

>> Filter 2# rport http (Set the redirection port)>> Filter 2# group 1 (Select real server group 1)






9. Create a default filter.

In this case, the default filter will allow all noncached traffic to proceed normally:

NOTE – When the proto parameter is not TCP or UDP, then sport and dport are ignored.

10. Assign the filters to the client ports.

Assuming that the redirected clients are connected to physical switch ports 5 and 6, both ports

are configured to use the previously created filters as follows:

11. Activate layer 4 services. Apply, and verify the configuration.

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 Alteon OS Command Reference).

12. Examine the resulting information from the cur command. If any settings are incorrect,

make appropriate changes.

>> Filter 2# /cfg/slb/filt 2048 (Select the default filter)




>> Filter 2048# action allow (Set the action to allow traffic)


>> Filter 2048# /cfg/slb/port 5 (Select the client port 5)>> SLB Port 5# add 2 (Add filter 2 to port 5)



>> SLB Port 5# /cfg/slb/port 6 (Select the client port 6)




>> SLB Port 6# /cfg/slb (Select Server Load Balancing Menu)

>> Layer 4# on (Activate Layer 4 software services)







Ch t 14 A li ti R di ti 375


14. Check the SLB information.



NOTE – Changes to filters on a given port only effect new sessions. To make filter changes

take effect immediately, clear the session binding table for the port (see the /oper/slb/clear command in the Alteon OS Command Reference).

Delayed Binding for Cache Redirection

To configure delayed binding on your application switch for cache redirection only, use thefollowing command:

For more conceptual information on delayed binding, see “Delayed Binding” on page 234.


>> Layer 4# /info/slb (View SLB information)

>> # /cfg/slb/filt <filter number>/adv/layer7/urlp ena





376 Chapter 14: Application Redirection

RTSP Cache Redirection

Alteon OS supports cache redirection for Real Time Streaming Protocol (RTSP). RTSP cache

redirection is similar to HTTP cache redirection in configuration 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 thecache 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 servers—Real Player and QuickTime—see

“Real Time Streaming Protocol SLB” on page 253.

You can also configure 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” on page 398.

Figure 14-3 RTSP Cache Redirection

25

23

6

Clients

Router

IP 120.120.120.5

Media server farm

Internet

IP 1.1.1.1

IP 1.1.1.2

12

4 5

IP 1.1.1.3

IP 1.1.1.4

3 4

RTSP Cache server farm is configured

in forward transparency mode

Alteon Application

Switch





Chapter 14: Application Redirection 377

Follow this procedure to configure to load balance RTSP cache servers for the topology illus-

trated in Figure 14-3:

1. Before configuring RTSP, do the following:

Connect each cache server to the application switch

Configure the IP addresses on all devices connected to the switch


2. At the application switch, configure RTSP cache servers and the IP addresses.

3. Define a group to load balance the RTSP cache servers.

4. Define the group metric for the RTSP cache servers.

RTSP supports all the standard load balancing metrics.

>> # /cfg/slb/real 1>> Real server 1# rip 1.1.1.1 (Configure RTSP cache server 1)

>> Real server 1# ena (Enable RTSP cache server 1)

>> Real server 1# /cfg/slb/real 2>> Real server 2# rip 1.1.1.2 (Configure RTSP cache server 2)






>> # /cfg/slb/group 1>> Real Server Group 1# add 1 (Add RTSP cache server 1 to group 1)

>> Real Server Group 1# add 2 (Add RTSP cache server 2 to group 1)>> Real Server Group 1# add 3 (Add RTSP cache server 3 to group 1)

>> Real Server Group 1# add 4 (Add RTSP cache server 4 to group 1)

>>Real Server Group 1# metric leastconn (Set the metric to leastconn)






5. Configure an RTSP redirection filter to cache data and balance the load among the cache

servers.

6. Configure a default allow filter to facilitate traffic.

7. Add and enable the redirection filter on the port to support basic cache redirection.


>> # /cfg/slb/filt 1 (Select the menu for filter 1)>> Filter 1# action redir (Set the action for redirection)

>> Filter 1# proto tcp (Enter TCP protocol)

>> Filter 1# dport rtsp (Enter service port for RTSP)

>> Filter 1# rport rtsp (Enter redirection port for RTSP)

>> Filter 1# group 1 (Select RTSP cache server group 1)

>> Filter 1# adv (Select advanced menu for filter 1)

>> Filter 1# Advanced# proxy disable (Disable proxy)

>> # /cfg/slb/filt 2048 (Select a default allow filter 2048)



>> Filter 2048# ena (Enable a default allow filter)

>> Filter 2048# action allow (Set the action to allow normal traffic)

>> # /cfg/slb/port 25 (Select the menu for port 25)

>> SLB Port 25# add 1 (Add RTSP filter 1 to port 25)

>> SLB Port 25# add 2048 (Add default filter 2048 to port 25)

>> SLB Port 25# filt ena (Enable filtering on port 25)






Chapter 14: Application Redirection 379

IP Proxy Addresses for NAT

Transparent proxies provide the benefits listed below when used with application redirection.

Application redirection is automatically enabled when a filter with the redir action is applied

on a port.

With proxy IP addresses configured on ports that use redirection filters, the application

switch can redirect client requests to servers 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 comprehen-sive, fully-transparent proxies. No additional client configuration is needed.

The following procedure can be used for configuring proxy IP addresses:

1. Configure proxy IP addresses and enable proxy for the redirection ports.

Each of the ports using redirection filters require proxy IP addresses.For more information on

proxy IP addresses, see “Proxy IP Addresses” on page 219.

In this example, proxy IP addresses are configured:

>> SLB port 3# /cfg/slb/pip (Select proxy IP address menu)

>> Proxy IP address# type port (Use port-based proxy IP)




>> Proxy IP Address# add 200.200.200.71 (Set proxy IP address)>> Proxy IP Address# /cfg/slb/port 1 (Select port 1)

>> SLB port 1# proxy ena (Enable proxy port 1)

>> SLB port 1# /cfg/slb/port 2 (Select port 2)





>> SLB port 4# proxy ena (Enable proxy port 4)>> SLB port 4# /cfg/slb/port 5 (Select port 5)






315394-J, January 2005p pp



2. Configure the application redirection filters.

Once proxy IP addresses are established, configure each application redirection filter (Filter 2

in our example) with the real server TCP or UDP port to which redirected traffic 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:

NOTE – This configuration is not limited to HTTP (Web) service. Other TCP/IP services can

be configured in a similar fashion. For example, if this had been a DNS redirect,rport would

be 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 Table 10-3 on page 192.


4. Check server statistics to verify that traffic has been redirected based on filtering criteria:


>> Filter 2# rport 8080 (Set proxy redirection port)

>> Filter 2# /cfg/slb/real 1/proxy enable (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)

>> # /info/slb/group <group number>/filter <filter number>



315394-J, January 2005


315394 J J 2005Chapter 14: Application Redirection 381

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 filter that allows this spe-

cific traffic to pass normally through the application switch. This filter must have a higher pre-

cedence (a lower filter number) than the application redirection filter.

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 configuration:

>> # /cfg/slb/filt 1 (Select the menu for filter 1)

>> Filter 1# dip 200.10.10.0 (To the site’s destination IP address)








>> Filter 1# /cfg/slb/port 5 (Select SLB port 5)


>> SLB port 5# /cfg/slb/port 6 (Select SLB port 6)






315394-J, January 2005


315394 J January 2005382 Chapter 14: Application Redirection

Content Intelligent Cache Redirection

Alteon OS allows you to redirect cache requests based on different Layer 7 content such as HTTPheader information, such as “Host:” header or “User-Agent” for browser-smart load balancing.

The No Cache/Cache Control for cache redirection feature in Alteon OS 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 client's 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 specified in the request.

The HTTP 1.0 Pragma: no-cache header is equivalent to the HTTP 1.1 Cache-Con-trol header. By enabling the Pragma: no-cache header, requests are forwarded to the ori-

gin 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” on page 383

“HTTP Header-Based Cache Redirection” on page 391

“Browser-Based Cache Redirection” on page 392

“URL Hashing for Cache Redirection” on page 393

“RTSP Streaming Cache Redirection” on page 398



315394-J, January 2005


315394-J January 2005Chapter 14: Application Redirection 383

URL-Based Cache Redirection

URL parsing for cache redirection operates in a manner similar to URL-based server load bal-

ancing—except 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


By separating static and dynamic content requests via URL parsing, Alteon OS enables you to

send requests with specific 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.

Examples of matching string expressions are:

/product

Any URL that starts with “/product,” including any information in the “/product” direc-

tory

product

Any URL that has the string “product”



315394 J, January 2005



Some of the common noncacheable items that you can configure the switch to add to, delete, or

modify are:

Dynamic content files: Common gateway interface files (.cgi)

cold fusion files (.cfm), ASP files (.asp)

BIN directory

CGI-BIN directory

SHTML (scripted html)

Microsoft HTML extension files (.htx)

executable files (.exe)

Dynamic URL parameters: +, !, %, =, &

Figure 14-4 URL-Based Cache Redirection

Requests matching the URL are load balanced among the multiple servers, depending on themetric specified for the real server group (leastconns is the default).

Alteon Application SwitchWeb Cache Redirector

N o n

- H T T P

G E T

G E T / w

w w. h o s

t c. c o m /

c g i - b i n / s c r i p t.

b i n

G E T / h t t p: / / f inance. ya hoo.com /q ?s = h w p % 2C+ i bm %d = v1

GET/product/Webswitch.htmlGET/company/information.html

G E T / c o m p a n y / i m a g e s / s w i t c h .g i f

Internet

Host A

Implicit load balancingwithin the group

/productinformation

Host B

Host C

images



, y



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 traffic 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 modifications 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 traffic 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 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.

Configuring URL-Based Cache Redirection

To configure URL-based cache redirection, perform the following steps:

1. Before you can configure URL-based cache redirection, configure the switch for basic

Server Load Balancing (SLB) with the following tasks:





page 181.

2. Configure the switch to support basic cache redirection.

For information on cache redirection, refer to “Application Redirection” on page 367.





3. Configure the parameters and file extensions that bypass cache redirection.

a) Add or remove string IDs that should not be cacheable.

b) Enable/disable ALLOW for non-GETS (such as HEAD, POST, and PUT) to the ori-

gin server, as described below.

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.

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


d) Enable/disable cache redirection of requests that contain “Cache-control:nocache” in the HTTP 1.1 header or “Pragma:no cache” in the HTTP 1.0 header

to the origin server.

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


>> # /cfg/slb/filt 1/adv/addstr|remstr < ID>

>> # /cfg/slb/layer7/slb/addstr|remstr < strings>

>> # /cfg/slb/layer7/redir/urlal ena|dis

>> # /cfg/slb/layer7/redir/cookie ena|dis

>> # /cfg/slb/layer7/redir/nocache ena|dis





4. Define the string(s) to be used for cache SLB. Refer to the parameters listed below:

addstr: Add a string or a path.

rem str: 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 Forwardslash (/)

A string that starts with a forwardslash ( / ), 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 Forwardslash (/)

A string that does not start out with a forwardslash ( / ) indicates that the server will processany requests that contain the defined 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 Forwardslash (/) Only

If a server is configured with the load balance string ( / ) only, it will only handle requests to

the root directory. For example, the server will handle any files in the ROOT directory:

/

/index.htm /default.asp/index.shtm

>> # /cfg/slb/layer7/slb/addstr|remstr < string >







For easy configuration and identification, each defined string has an ID attached, as shown in


7. Configure the real server(s) to support cache redirection.


dle any request.

Add the defined string(s) to the real servers:


The server can have multiple defined strings. For example: “/images”, “/sales”, “.gif”

With these defined strings, the server can handle requests that begin with “/images” or “/sales”

and any requests that contain “.gif”.

8. Define a real server group and add real servers to the group.

The following configuration combines three real servers into a group:


Table 2

ID SLB String

1 any

2 .gif

3 /sales

4 /xitami

5 /manual

6 .jpg


>> # /cfg/slb/group 1 (Select real server group 1)








9. Configure a filter to support basic cache redirection.

The filter must be able to intercept all TCP traffic for the HTTP destination port and must redi-

rect it to the proper port in the real server group:

10. Enable URL-based cache redirection on the same filter.

11. Select the appropriate NAT option.

The three NAT options are listed below. For more information about each option, see “Net-

work Address Translation Options” on page 385.

No NAT option:

Half NAT option:

Full NAT option:


>> # /cfg/slb/filt < filter number > (Select the menu for Filter #x)

>> Filter < filter number ># sip any (From any source IP addresses)

>> Filter < filter number ># dip any (To any destination IP addresses)

>> Filter < filter number ># proto tcp (For TCP protocol traffic)

>> Filter < filter number ># sport any (From any source port)

>> Filter < filter number ># dport http (To an HTTP destination port)

>> Filter < filter number ># action redir (Set the action for redirection)>> Filter < filter number ># rport http (Set the redirection port)

>> Filter < filter number ># group 1 (Select real server group 1)

>> Filter < filter number ># ena (Enable the filter)

>> # /cfg/slb/filt <filter number>/adv/layer7/l7lkup ena

>> # /cfg/slb/filter <filter number>/adv/proxy dis

>> # /cfg/slb/filter <filter number>/adv/proxy ena

>> # /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)





12. Create a default filter for noncached traffic on the switch.

NOTE – When the proto parameter is not tcp or udp, then sport and dport are ignored.

13. Turn on filtering for the port.

14. Add the filters to the client port.

15. Enable Direct Access Mode (DAM) on the switch.


Viewing Statistics for URL-Based Cache Redirection

To show the number of hits to the cache server or origin server, use this command:

>> # /cfg/slb/filt < filter number > (Select the default filter)

>> Filter < filter number ># sip any (From any source IP addresses)>> Filter < filter number ># dip any (To any destination IP addresses)

>> Filter < filter number ># proto any (For any protocol traffic)

>> Filter < filter number ># action allow (Set the action to allow traffic)

>> Filter < filter number ># ena (Enable the default filter)

>> Filter < filter number ># port < port number > (Assign the default filter to a port)

>> SLB < port number ># filt ena

>> SLB < port number ># add < filter number >

>> SLB < port number ># /cfg/slb/adv>> Layer 4 Advanced# direct ena

>> # /cfg/slb (Select the SLB Menu)

>> # on (Turn SLB on)

>> # apply (Make your changes active)

>> # cur (View current settings)

>> # /stats/slb/layer7/redirTotal URL based Web cache redirection stats:Total cache server hits: 73942Total origin server hits: 2244Total none-GETs hits: 53467Total 'Cookie: ' hits: 729Total no-cache hits: 43





HTTP Header-Based Cache Redirection

To configure the switch for cache direction based on the “Host:” header, use the following pro-

cedure:

1. Configure basic SLB.

Before you can configure header-based cache redirection, ensure that the switch has already

been configured for basic SLB (see “Server Load Balancing” on page 181) with the following

tasks:





2. Turn on Layer 7 lookup for the filter.

3. Enable header load balancing for the Host: header.



6. Identify the string ID numbers with this command.

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

>> # /cfg/slb/layer7/redir/header ena host

>> # /cfg/slb/layer7/slb/addstr ".com">> Server Load Balance Resource# add ".org">> Server Load Balance Resource# add ".net"






Each defined string has an associated ID number.

7. Configure the real server(s) to handle the appropriate load balance string(s).

Add the defined string IDs to the real servers:


NOTE – If you don’t add a defined string (or add ID=1), the server will handle any request.

Browser-Based Cache Redirection

Browser-based cache redirection uses the User-agent: header. To configure browser-

based cache redirection, perform the following procedure.

1. Before you can configure header-based cache redirection, ensure that the switch isalready configured for basic SLB with the following tasks:







3. Enable header load balancing for “User-Agent:” header.

Table 3

ID SLB String

1 any

2 .com

3 .org

4 .net


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

>> # /cfg/slb/layer7/redir/header ena useragent







6. Identify the string ID numbers with this command.

Each defined string has an ID number.

Number of entries: four

7. Add the defined string IDs to configure the real server(s) to handle the appropriate load

balance string(s).


NOTE – If you don't add a defined string (or add the ID 1), the server will handle any request.

URL Hashing for Cache RedirectionBy default, hashing algorithms use the source IP address and/or destination IP address

(depending on the application area) to determine content location. For example, firewall load

balancing uses both source and destination IP addresses, cache redirection uses only the desti-

nation 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 clientrequests going to the same page of an origin server to a specific cache server.

>> # /cfg/slb/layer7/slb/addstr "Mozilla"

>> Server Load Balance Resource# add "Internet Explorer">> Server Load Balance Resource# add "Netscape"


Table 4

ID SLB String

1 any

2 Mozilla

3 Internet Explorer

4 Netscape






For example the switch could use the string “nortelnetworks.com/products/2424/” for hashing

the following request:

GET http://products/2424/ HTTP/1.0HOST:www.nortelnetworks.com





To configure the switch for cache redirection based on a hash key, use the following procedure:

1. Configure basic SLB.

Before you can configure header-based cache redirection, ensure that the switch has already been configured for basic SLB (see “Server Load Balancing” on page 181) with the following

tasks:






Configure the load-balancing algorithm to hash or minmiss.


3. Enable hash to direct a cacheable URL request to a specific cache server.

By default, the host header field 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.

hash disable: Disables hashing based on the URL. Instead, the host header field to calcu-

late the hash key.

If the host header field does not exist in the HTTP header, then the switch uses the source

IP address as the hash key.

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

>> # /cfg/slb/layer7/redir/hash ena

Enter new hash length [1-255]: 24





Example 1: Hashing on the URL

In this example, URL hashing is enabled. If the Host field does not exist, the specified length

of the URL is used to hash into the cache server as shown in Figure 14-5 on page 396. If theHost field exists, the specified length of both the Host field 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.





Figure 14-5 URL Hashing for Application Redirection


Cache server farm

http://www.nortelnetworks.com

Clients 2

3

1

1

2

3

Internet





Example 2: Hashing on the Host Header Field Only

In this example, URL hashing is disabled. If you use the Host header field 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.



Example 3: Hashing on the Source IP address

In this example, URL hashing is disabled. Because the host header field does not exist in theHTTP 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.








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 amountof 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 connec-

tions 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” on page

376. For detailed information on two prominent commercial RTSP servers—Real Player and

QuickTime—see “Real Time Streaming Protocol SLB” on page 253.

In the scenario illustrated in Figure 14-6, the cache servers are configured for forward proxy

mode. The cache servers process the client request even though the destination IP address is

not destined for the cache servers.

Figure 14-6 Load Balancing RTSP Cache Servers

25

23 4 5

26

ClientsRouter

IP 120.120.120.5

IP 10.10.10.1

IP 10.10.10.2


IP 10.10.10.4

IP 10.10.10.3

RTSP servers

Internet

RTSP Cache server farm is configured

in forward transparency mode

12 3 4

condor.rm

cheetah.mov

Client 1 request

http://nortel.com/condor.rm

Client 2 request

http://alteon.com/cheetah.mov

tigon.rm





6. Configure a default allow filter to facilitate traffic.

7. Add and enable the redirection filter to the port.

8. Configure the parameters and file extensions that will bypass RTSP streaming cache

redirection. This is for user-defined non-cacheable content.

For example, QuickTime files are non-cacheable—RTSP files with the extension *.mov must

bypass the streaming cache redirection. Similarly, you can add other RTSP file extensions(such as *.smil, *.rm, *.ram, and so forth) to bypass the redirection.

A client request of the form RTSP://*.mov bypasses the cache servers and instead is routed

directly to the original servers.

9. Under the filter menu, add the string IDs that need to be excluded.

10. Define the RTSP file extensions to load balance among the cache servers.


>> # /cfg/slb/filt 2048 (Select a default allow filter 2048)

>> Filter 2048# sip any (From any source IP addresses)>> Filter 2048# dip any (To any destination IP addresses)

>> Filter 2048# ena (Enable a default allow filter)

>> Filter 2048# action allow (Set the action to allow normal traffic)

>> # /cfg/slb/port 25 (Select the menu for port 25)

>> SLB Port 25# add 100 (Add RTSP filter 100 to port 25)>> SLB Port 25# add 2048 (Add default filter 2048 to port 25)

>> SLB Port 25# filt ena (Enable filtering on port 25)

>> # /cfg/slb/layer7/slb (Select the SLB resource menu)

>> # addstr *.mov (Add non-cacheable RTSP strings)

>> /cfg/slb/filt 20/adv/layer7 (Select the Filtering L7 Adv. menu)

>> Layer 7 Advanced# addstr 2 (Add the string ID for *.mov)

>> # /cfg/slb/layer7/slb/addstr condor.rm >> Server Load Balance Resource# addstr tiger.rm





12. Identify the associated ID number for each of the defined RTSP file extension.

13. Assign the URL string ID to the cache servers.

NOTE – If no string is assigned to the server, the server will handle all requests.


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.


Table 5

ID SLB String

1 any

2 *.mov

3 condor.rm

4 tiger.rm

>> # /cfg/slb/real 1 ( Select the real server 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 4 Layer 7 Commands# apply>> Real Server 4 Layer 7 Commands# save





HTTP Redirection

Filters can be used to redirect HTTP requests to different gateways or servers. The followingHTTP redirection types are supported:

IP redirection —The application switch redirects client requests to different service gate-

ways based on the address range of the client device and requested URL. For details, see

“IP based HTTP redirection” on page 405.

Port redirection —The application switch examines traffic entering on a TCP service port

(such as HTTP port 80) and sends that traffic to a user-specified IP address on a differentservice port (such as 9090). For details, see “TCP Service Port Based HTTP Redirection”

on page 408.

MIME type redirection —The application switch examines the HTTP header or URL of

an incoming request for a specific Multipurpose Internet Mail Extensions (MIME) type,

and replaces the URL with another URL. For details, see “MIME Type Header-Based

Redirection” on page 410.

URL redirection —The application switch examines a URL and redirects it to a precon-

figured IP address or URL. For details, see “URL-Based Redirection” on page 412.

NOTE – The HTTP header redirection feature is not limited to the types of HTTP headers

listed below.

Configure SLB Strings for HTTP Redirection

All of the following HTTP filtering redirection examples require the following server load bal-

ancing (SLB) strings to be configured. Each defined string has an associated ID number. A fil-

ter is then configured to redirect from one configured string ID to another.





3. Use the same commands as Step 2 to configure the rest of the filter strings shown in Table

14-6 on page 403.

4. Identify the ID numbers of the defined strings.

5. Configure a port for client traffic. This configuration assumes client traffic enters the

application switch on port 1. Enabled filtering on the client port.

The basic HTTP redirection configuration is now complete and can be used for each of the

redirection options described in the following sections.


Number of entries: 141: any, cont 2562: HTTPHDR=Host:wap.example.com, cont 2563: HTTPHDR=Host:wap.yahoo.com, cont 2564: HTTPHDR=Host:wap.google.com, cont 256

5: HTTPHDR=Host:wap.p-example.com, cont 2566: HTTPHDR=Host:10.168.224.227=/top, cont 2567: jad, cont 2568: jar, cont 2569: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor, cont 25610: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL, cont 25611: HTTPHDR=Host:any, cont 25612: HTTPHDR=Host:any:90, cont 25613: HTTPHDR=Host:any:8080, cont 256

14: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 25615: HTTPHDR=Host:www.abc.com, cont 25616: HTTPHDR=Host:any:443, cont 256

>> /cfg/slb/port 1 (Select the SLB port 1 menu)

>> SLB port 1# filt en (Enable filtering on the port)Current port 1 filtering: disabledNew port 1 filtering: enabled





IP based HTTP redirection

In this example, the application switch will redirect Web pages requested from a mobile phone,

to a specific gateway based on the client’s IP address. A mobile phone is set to access its home page via the default device gateway.

Example client phone configuration:

Configuration rules

The following filter rules on the Application switch to filter 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, configure the switch with three filters to

redirect client requests from each subnet, to the URLs specified above. Use the string index

numbers in Table 14-6 on page 403 to configure a redirection map for each filter.

Device Gateway IP address 10.168.107.101Home page: http://wap.example.com

WAP port 9001, CSD number as 18881234567username: john





1. Identify the ID numbers of the defined strings. The strings in bold are used in this exam-

ple.

2. Configure filter 1.

>> # /cfg/slb/layer7/slb/curNumber of entries: 141: any, cont 2562: HTTPHDR=Host:wap.example.com, cont 2563: HTTPHDR=Host:wap.yahoo.com, cont 2564: HTTPHDR=Host:wap.google.com, cont 2565: HTTPHDR=Host:wap.p-example.com, cont 2566: HTTPHDR=Host:10.168.224.227=/top, cont 256

7: jad, cont 2568: jar, cont 2569: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor, cont 25610: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL, cont 25611: HTTPHDR=Host:any, cont 25612: HTTPHDR=Host:any:90, cont 25613: HTTPHDR=Host:any:8080, cont 25614: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 25615: HTTPHDR=Host:www.abc.com, cont 256

16: HTTPHDR=Host:any:443, cont 256

>> /cfg/slb/filt 1>> Filter 1 # sip 10.168.43.0 (From this source IP address range)

Current source address: anyNew pending source address: 10.168.43.0

>> Filter 1 # smask 255.255.255.0Current source mask: 0.0.0.0New pending source mask: 255.255.255.0>> Filter 1 # proto tcp (For TCP protocol traffic)

Current protocol: anyPending new protocol: tcp>> Filter 1 # dport http (To destination port HTTP)

Current destination port or range: anyPending new destination port or range: http

>> Filter 1 # action redir (Redirect the traffic)

Current action: allowPending new action: redir>> Filter 1 # /cfg/slb/filt/adv/layer7 (Access advanced Layer 7 menu)

>> Layer 7 Advanced# addrdEnter filtering string ID (1-512) to redirect from: 2(Redirect string 2 ..)

Enter filtering string ID (2-512) to redirect to: 3(to string 3)






4. Configure Filter 3.


>> /cfg/slb/filt 2

>> Filter 2 # sip 10.46.6.0.0Current source address: any

New pending source address: 10.46.6.0.0>> Filter 2 # smask 255.255.255.0Current source mask: 0.0.0.0New pending source mask: 255.255.255.0>> Filter 2 # proto tcpCurrent protocol: anyPending new protocol: tcp

>> Filter 2 # dport httpCurrent destination port or range: anyPending new destination port or range: http>> Filter 2 # action redirCurrent action: allowPending new action: redir>> Filter 2 # /cfg/slb/filt/adv/layer7>> Layer 7 Advanced# addrdEnter filtering string ID (1-512) to redirect from: 2

Enter filtering string ID (2-512) to redirect to: 4

>> /cfg/slb/filt 3>> Filter 3 # sip 10.23.43.0Current source address: anyNew pending source address: 10.23.43.0

>> Filter 3 # smask 255.255.255.0Current source mask: 0.0.0.0New pending source mask: 255.255.255.0>> Filter 3 # proto tcpCurrent protocol: anyPending new protocol: tcp>> Filter 3 # dport httpCurrent destination port or range: any

Pending new destination port or range: http>> Filter 3 # action redirCurrent action: allowPending new action: redir>> Filter 3 # /cfg/slb/filt/adv/layer7>> Layer 7 Advanced# addrdEnter filtering string ID (1-512) to redirect from: 5Enter filtering string ID (2-512) to redirect to: 6





TCP Service Port Based HTTP Redirection

In this example, the switch will redirect traffic entering the switch on one TCP service port,

and redirect it through another service port. Use the string index numbers in Table 14-6 on page 403 to configure a redirection map for each filter.

Filter 4: Configure a filter 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: Configure a filter on the switch that intercepts all traffic entering on TCP service

port 80, and send it to 10.168.120.129 on TCP service port 8080.

1. Identify the ID numbers of the defined strings. The strings in bold are used in

this example.


Number of entries: 141: any, cont 2562: HTTPHDR=Host:wap.example.com, cont 2563: HTTPHDR=Host:wap.yahoo.com, cont 2564: HTTPHDR=Host:wap.google.com, cont 2565: HTTPHDR=Host:wap.p-example.com, cont 2566: HTTPHDR=Host:10.168.224.227=/top, cont 2567: jad, cont 2568: jar, cont 2569: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor , cont 25610: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL, cont 256

11: HTTPHDR=Host:any, cont 25612: HTTPHDR=Host:any:90, cont 25613: HTTPHDR=Host:any:8080, cont 25614: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 25615: HTTPHDR=Host:www.abc.com, cont 25616: HTTPHDR=Host:any:443, cont 256

Alt OS 22 0 2 A li ti G id








>> /cfg/slb/filt 4>> Filter 4 # sip 10.46.6.231Current source address: anyNew pending source address: 10.46.6.231>> Filter 4 # smask 255.255.255.255Current source mask: 0.0.0.0New pending source mask: 255.255.255.255>> Filter 4 # proto tcpCurrent protocol: anyPending new protocol: tcp


Enter filtering string ID (2-512) to redirect to: 12

>> /cfg/slb/filt 5>> Filter 5 # sip 10.46.6.231Current source address: anyNew pending source address: 10.46.6.231

>> Filter 5 # smask 255.255.255.255Current source mask: 0.0.0.0New pending source mask: 255.255.255.255>> Filter 5 # proto tcpCurrent protocol: anyPending new protocol: tcp>> Filter 5 # dport httpCurrent destination port or range: anyPending new destination port or range: http>> Filter 5 # action redirCurrent action: allowPending new action: redir>> Filter 5 # /cfg/slb/filt/adv/layer7>> Layer 7 Advanced# addrdEnter filtering string ID (1-512) to redirect from: 11Enter filtering string ID (2-512) 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 Mul-

tipurpose Internet Mail Extensions (MIME) type header in the URL. If the URL contains a pre-defined MIME type, text, or URL, the switch will replace the URL. Use the string index num-

bers in Table 14-6 on page 403 to configure a redirection map for the filter.

Filter 6: The mobile client executes a request for a URL http://dev.exam-

ple.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/tog-gle.jad.

1. Identify the ID numbers of the defined strings. The strings in bold are used in this

example.



1: any, cont 2562: HTTPHDR=Host:wap.example.com, cont 2563: HTTPHDR=Host:wap.yahoo.com, cont 2564: HTTPHDR=Host:wap.google.com, cont 2565: HTTPHDR=Host:wap.p-example.com, cont 2566: HTTPHDR=Host:10.168.224.227=/top, cont 2567: jad, cont 2568: jar, cont 256

9: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor , cont 25610: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL, cont 25611: HTTPHDR=Host:any, cont 25612: HTTPHDR=Host:any:90, cont 25613: HTTPHDR=Host:any:8080, cont 25614: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 25615: HTTPHDR=Host:www.abc.com, cont 25616: HTTPHDR=Host:any:443, cont 256






2. Configure filter 6. This filter will intercept strings 7, 8, 9 and then redirect based on

string 10's information. The $HOST_URL will be replaced with the incoming request’s

HOST string and URL string.


>> /cfg/slb/filt 6>> Filter 6 # sip 10.46.6.231Current source address: anyNew pending source address: 10.46.6.231>> Filter 6 # smask 255.255.255.255Current source mask: 0.0.0.0New pending source mask: 255.255.255.255>> Filter 6 # proto tcp

Current protocol: anyPending new protocol: tcp>> Filter 6 # dport httpCurrent destination port or range: anyPending new destination port or range: http>> Filter 6 # action redirCurrent action: allowPending new action: redir>> Filter 6 # /cfg/slb/filt/adv/layer7>> Layer 7 Advanced# addrdEnter filtering string ID (1-512) to redirect from: 7Enter filtering string ID (2-512) to redirect to: 10>> Layer 7 Advanced# addrdEnter filtering string ID (1-512) to redirect from: 8Enter filtering string ID (2-512) to redirect to: 10>> Layer 7 Advanced# addrdEnter filtering string ID (1-512) to redirect from: 9

Enter filtering string ID (2-512) to redirect to: 10>> 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.

1. Identify the ID numbers of the defined strings. The strings in bold are used in this exam-

ple.


Number of entries: 141: any, cont 2562: HTTPHDR=Host:wap.example.com, cont 2563: HTTPHDR=Host:wap.yahoo.com, cont 2564: HTTPHDR=Host:wap.google.com, cont 2565: HTTPHDR=Host:wap.p-example.com, cont 2566: HTTPHDR=Host:10.168.224.227=/top, cont 2567: jad, cont 2568: jar, cont 2569: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor, cont 256

10: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL, cont 25611: HTTPHDR=Host:any, cont 25612: HTTPHDR=Host:any:90, cont 25613: HTTPHDR=Host:any:8080, cont 25614: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 25615: HTTPHDR=Host:www.abc.com, cont 25616: HTTPHDR=Host:any:443, cont 256




pp


2. Configure filter 7 to redirect the URL as described above.


>> /cfg/slb/filt 7>> Filter 7 # sip 10.46.6.231

Current source address: anyNew pending source address: 10.46.6.231>> Filter 7 # smask 255.255.255.255Current source mask: 0.0.0.0New pending source mask: 255.255.255.255>> Filter 7 # proto tcpCurrent protocol: anyPending new protocol: tcp







Source IP from HTTP header and Host Header-Based

Redirection

In this example, a filter is configured 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.


example.


Number of entries: 141: any, cont 2562: HTTPHDR=Host:wap.example.com, cont 2563: HTTPHDR=Host:wap.yahoo.com, cont 2564: HTTPHDR=Host:wap.google.com, cont 2565: HTTPHDR=Host:wap.p-example.com, cont 2566: HTTPHDR=Host:10.168.224.227=/top, cont 2567: jad, cont 2568: jar, cont 2569: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor , cont 25610: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL, cont 25611: HTTPHDR=Host:any, cont 25612: HTTPHDR=Host:any:90, cont 25613: HTTPHDR=Host:any:8080, cont 25614: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 25615: HTTPHDR=Host:www.abc.com, cont 256

16: HTTPHDR=Host:any:443, cont 256





1. Configure filter 8 redirect URL as described above.


HTTP to HTTPS Redirection

In this example, a filter is configured to redirect any HTTP requests to an HTTP connection as

follows:

Filter 9: Configure a filter on the switch that intercepts HTTP traffic to http://

www.abc.com and redirects it to https://www.abc.com.

>> /cfg/slb/filt 8>> Filter 8 # sip 10.46.6.231

Current source address: anyNew pending source address: 10.46.6.231>> Filter 8 # smask 255.255.255.255Current source mask: 0.0.0.0New pending source mask: 255.255.255.255>> Filter 8 # proto tcpCurrent protocol: anyPending new protocol: tcp








example.



>> # /cfg/slb/layer7/slb/curNumber of entries: 141: any, cont 2562: HTTPHDR=Host:wap.foo.com, cont 2563: HTTPHDR=Host:wap.yahoo.com, cont 2564: HTTPHDR=Host:wap.google.com, cont 2565: HTTPHDR=Host:wap.p-foo.com, cont 2566: HTTPHDR=Host:10.168.224.227=/top, cont 2567: jad, cont 256

8: jar, cont 2569: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor , cont 25610: HTTPHDR=Host:mobile.foo.com=/4g/w?url=$HOST_URL, cont 25611: HTTPHDR=Host:any, cont 25612: HTTPHDR=Host:any:90, cont 25613: HTTPHDR=Host:any:8080, cont 25614: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 25615: HTTPHDR=Host:www.abc.com, cont 25616: HTTPHDR=Host:any:443, cont 256

>> /cfg/slb/filt 9>> Filter 9 # proto tcpCurrent protocol: anyPending new protocol: tcp>> Filter 9 # dport http

Current destination port or range: anyPending new destination port or range: http>> Filter 9 # action redirCurrent action: allowPending new action: redir>> Filter 9 # /cfg/slb/filt/adv/layer7>> Layer 7 Advanced# addrd>> Layer 7 Advanced# l7lkup enCurrent layer 7 lookup: disabledNew layer 7 lookup: enabledEnter filtering string ID (1-512) to redirect from: 15Enter filtering string ID (2-512) to redirect to: 16



315394-J, January 2005

Part 4: Advanced SwitchingAlteon OS can parse requests and classify flows using URLs, host tags, and cookies so that

each request can be isolated and treated intelligently. This section describes the following

advanced switching applications:

Chapter 17, “Persistence”

Chapter 18, “Advanced Denial of Service Protection”

Chapter 19, “Firewall Load Balancing”

Chapter 20, “Virtual Private Network Load Balancing”

Chapter 21, “Global Server Load Balancing”

Chapter 22, “Bandwidth Management”




315394-J, January 2005418 : Advanced Switching



315394-J, January 2005419

CHAPTER 15

Health Checking

Health checking allows you to verify content accessibility in large Web sites. As content growsand information is distributed across different server farms, flexible, customizable content

health checks are critical to ensure end-to-end availability.

The following Alteon OS health-checking topics are described in this chapter.

“Real Server Health Checks” on page 421. This section explains the switch’s default

health check, which checks the status of each service on each real server every two

seconds. “DSR Health Checks” on page 424. 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” on page 425. This section describes how to perform Layer 1 health

checking on an Intrusion Detection Server (IDS).

“TCP Health Checks” on page 426. TCP health checks help verify the TCP applicationsthat cannot be scripted.

“ICMP Health Checks” on page 426. This section explains how ICMP health checks are

used for UDP services.

“Script-Based Health Checks” on page 427. This section describes how to configure 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” on page 438. This section provides examples of HTTP-based

health checks using hostnames.

“UDP-Based DNS Health Checks” on page 440. This section explains the functional-

ity of the DNS Health Checks using UDP packets.




315394-J, January 2005420 Chapter 15: Health Checking

“TFTP Health Check” on page 441. This section explains how to health check a real

server using the TFTP protocol.

“SNMP Health Check” on page 442. This section explains how to perform SNMP

health checks to real servers running SNMP Agents.

“FTP Server Health Checks” on page 444. This section describes how the File Trans-

fer Protocol (FTP) server is used to perform health checks and explains how to con-

figure the switch to perform FTP health checks.

“POP3 Server Health Checks” on page 445. This section explains how to use Post

Office Protocol Version 3 (POP3) mail server to perform health checks between a cli-

ent system and a mail server and how to configure the switch for POP3 health checks.

“SMTP Server Health Checks” on page 445. 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 configure the switch for SMTP health checks.

“IMAP Server Health Checks” on page 447. 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” on page 448. This section explains how to use Net-

work News Transfer Protocol (NNTP) server to perform health checks between a cli-

ent system and a mail server and how to configure the switch for NNTP health checks

“RADIUS Server Health Checks” on page 449. This section explains how the

RADIUS protocol is used to authenticate dial-up users to Remote Access Servers

(RASs).

“HTTPS/SSL Server Health Checks” on page 451. This section explains how the

switch queries the health of the SSL servers by sending an SSL client “Hello” packet

and then verifies the contents of the server’s “Hello” response.

“WAP Gateway Health Checks” on page 452. This section discusses how the applica-

tion switch provides connectionless and connection-oriented WSP health check for

WAP gateways.

“LDAP Health Checks” on page 458. This section describes how to configure theswitch 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” on page 460. This section describes how to perform health checks

on Intrusion Detection Servers (IDS) that do not have full TCP/IP stack support.

“Failure Types” on page 461. This section explains the service failed and server failed

states.




315394-J, January 2005Chapter 15: Health Checking 421

Real Server Health Checks

Alteon 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 Alteon 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, bydefault, declares the service unavailable. You can modify both the health check interval and

the number of retries.

NOTE – Health checks are performed sequentially when used in conjunction with a virtual

server configured with multiple services and groups. As a result, the actual health-check inter-

val could vary significantly 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, orARP. You may use the LDAP health check method to health check LDAP servers.

>> # /cfg/slb/real < real server number> (Select the real server)

>> Real server# inter 4 (Check real server every 4 seconds)

>> Real server# retry 6 (If 6 consecutive health checks fail,

declare real server down)





Advanced Group Health Check

Alteon OS allows you to configure an expression to fine tune the selected health check for a

real server group. For example, you have configured a real server group with four real servers.

Two of the real servers are handling the contents of the Web site and the other two real servers

are handling audio files. If the two content servers fail due to traffic 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 configured 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 (Select the real server 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 (Assign the real server group 1)

>> Virtual Server 1 Service# apply (Apply the changes)

>> Virtual Server 1 Service# save (Save the changes)





(1&2)|(2&3)|(1&3)

Real servers 1, 2, and 3 are configured in group 2 and assigned to virtual service x in vir-

tual 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.

Disabling the Fast Link Health Check

By default, the Alteon Application Switch sets the real server as operationally down as soon as

the physical connection to it is down—without waiting for the health check to fail. This behav-

ior may not be advantageous in certain configurations in which a link may go down and then

be quickly restored—such as in VPN load balancing. By disabling this “fast health check”

behavior, the real server will be marked as “down” only after the configured 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/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 (Assign the real server group 2)

>> Virtual Server 1 Service# apply (Apply the changes)

>> Virtual Server 1 Service# save (Save the changes)

>> # /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 vir-

tual server IP address. In this configuration, the server will be configured with a real server IP

address and virtual server IP address. The virtual server IP address is configured to be the same

address as the user’s virtual server IP address. When DSR health checks are selected, the spec-

ified health check is sent originating from one of the switch’s configured IP interfaces, and is

destined to the virtual server IP address with the MAC address that was acquired from the real

server IP address’s Address Resolution Protocol (ARP) entry.

Alteon OS allows you to perform health checks for DSR configurations. For more information,

see “Direct Server Return” on page 228. The switch is able to verify that the server correctly

responds to requests made to the virtual server IP address as required in DSR configurations.

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 configured

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 configured with DSR.

Configuring the Switch for DSR Health Checks

1. Select the health check menu for a real server group.

2. Enable DSR VIP health checks for a real server group.

For more information on DSR, see “Direct Server Return” on page 228.


>> # /cfg/slb/group 1 (Select the Real Server Group 1 menu)

>> Real server group 1# viphlth enable|disable

>> DSR VIP Health Check# apply





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 first 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 indi-cates the IDS is alive.

To perform this health check, a link option has been added to the real server group health com-

mand. 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.

Configuring Link Health Checks

Configure the switch to verify if the IDS server is alive by performing the following tasks:

1. Select the health check menu for real server group 1.

2. Set the health check type to link for real server group 1.


>> # /cfg/slb/group 1

>> # Real server group 1# healthCurrent health check type: tcpEnter health check type: link

>> # Real server group 1# apply>> # Real server group 1# save





TCP Health Checks

TCP health checks are useful in verifying user-specific 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-config-

urable 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 (finished) packet.

NOTE – TCP health check is a default health check after you have configured the switch for a

particular service.

ICMP Health Checks

Configure 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

configured.

1. Select the health check menu for group 1.

2. Set the health check type to ICMP for group 1.



>> # Real server group 1# health icmp

>> # Real server group 1# apply





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.

Configuring Script-Based Health Checks

You can configure 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 benefits of using script-based health checks are listed below:

Ability to send multiple commands

Check for any return ASCII string or Binary pattern

Test availability of different applications

Test availability of multiple domains or Web sites

Alteon OS supports the following capacity for a single switch:

6K bytes per script

32 scripts per switch

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 specific 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. Thestring or pattern configured 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 com-

mands, 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 onceentered, can be assigned as the health-check method using SNMP or the Browser-Based Inter-

face (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:

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)

send request 1 (ascii string)

expect response 1

send request 2

expect response 2

send request 3

expect response 3close (used in TCP-based health checks only)

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 configured to look for an HTTP 200 (ok) response, this typicallyappears starting from the 7th byte in the packet, so an offset value of 7 can be specified.

open "80,tcp"bsend "<binary content for request 1>"nsend "<continuing binary content for request 1>"bexpect "<binary content for response 1>"nexpect "<binary content>"offset "<byte count from the start of the IP header> "

depth "10" wait "100"close (used in TCP-based health checks only)





Notes on UDP-Based Health Checks

UDP-based health check scripts can use either ASCII strings or 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 first 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 fol-

lowing line: Host: www.hostname.com

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 finished 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 \\).


S i ti C d




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, OPEN9201. 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 con-

nection. 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 com-

mand 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 inlength 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 specified 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 specified 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 specified, Depth is specified from

the beginning of the packet. If an OFFSET value is specified, 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


h k f il Th WAIT d h ld ft EXPECT d i th i t




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 receivedfrom 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 defined by the RFC, as applicable. Thishelps ensure that if the server software changes, the servers won't start failing unexpect-

edly.

Avoid tasks that may take a long time to perform or the health check will fail. For exam-

ple, avoid tasks that exceed the interval for load balancing.


Script Configuration Examples




Script Configuration Examples

Script Example 1: A Basic ASCII TCP-Based Health Check

Configure 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.

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.

NOTE – When you are using the command line interface to enter thesend

string as an argu-

ment 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 Alteon OS releases, each remote Global Server Load Balancing site’s 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 switch’s virtual servers that are configured 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.

>> /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


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”


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:

Script-based health checking is intelligent in that it will only send the appropriate requests to

the relevant servers. In the example above, the first 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.

Configure the remote real server IP address (the virtual server IP address of the remote site) to

accept “any” URL requests. The purpose of the first GET is to check if Real Server 1 or Real

Server 2 is up—that 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 first GET health check.

>> /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"


close

open 80

send "GET /script.cgi HTTP/1.1\\r\\nHOST: www.myurl.com \\r\\n\\r\\n"


close


If all the real server IP addresses are down, Real Server 7 (the virtual server IP address of the




a e ea se ve add esses a e dow , ea Se ve 7 ( e v ua se ve add ess o e

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 Redi-

rect 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 dif-

ferences from a TCP-based health check script. Due to the stateless nature of the UDP proto-

col, 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.

NOTE – A maximum of 255 bytes of input are allowed on the switch command line. If yoursend 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.

>> /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"


Script Example 4: A TCP-Based Health Check using Binary Content




p p g y

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.

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:

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:

>> /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

>> # /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

>> # /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-Specific Health Checks




Application Specific Health Checks

Application-specific health checks include the following applications:

“HTTP Health Checks” on page 438

“UDP-Based DNS Health Checks” on page 440

“FTP Server Health Checks” on page 444

“POP3 Server Health Checks” on page 445

“SMTP Server Health Checks” on page 445

“IMAP Server Health Checks” on page 447

“NNTP Server Health Checks” on page 448

“RADIUS Server Health Checks” on page 449

“HTTPS/SSL Server Health Checks” on page 451

“WAP Gateway Health Checks” on page 452

“Configuring WSP Health Checks” on page 454

“Configuring WTP Health Checks” on page 455

“Configuring WTLS Health Checks” on page 457

“LDAP Health Checks” on page 458


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:

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 = everestdname = alteonwebsystems.com

content=index.html

Health check is performed using:

GET /index.html HTTP/1.1Host: everest.alteonwebsystems.com

NOTE – If the content is not specified, the health check will revert back to TCP on the port that is being

load balanced.

Example 2:

hname = (none)

dname = raleighduram.cityguru.com content = /page/gen/?_template=alteon


GET /page/gen/?_template=alteon HTTP/1.1Host: raleighduram.cityguru.com

Example 3:

hname = (none)

dname = jansuscontent = index.html

Item Option Configured Under Max. Length

Virtual server hostname hname /cfg/slb/virt/service 9 characters

Domain name dname /cfg/slb/virt 35 characters

Server group health check field content /cfg/slb/group 34 characters






GET /index.html HTTP/1.1Host: jansus

Example 4:

hname = (none)

dname = (none)

content = index.html


GET /index.html HTTP/1.0 (since no HTTP HOST: header is required)

Example 5:

hname = (none)

dname = (none)

content = //everest/index.html


GET /index.html HTTP/1.1

Host: everest

Configuring the Switch for HTTP Health Checks

Perform the following on the switch to configure the switch for HTTP health checks:

1. Select the real server group.

2. Set the health check type to FTP for the real server group.

3. Configure the health check content.


>> # /cfg/slb/group 1 (Select a real server group)

>> # /cfg/slb/group 1/health http

>> # /cfg/slb/group 1/content <filename>



UDP-Based DNS Health Checks




Alteon OS 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 que-

ries to another real server group.

The health check may be performed by sending a UDP-based query (for example, for

www.nortelnetworks.com), and watching for the server’s reply. The domain name to be que-

ried may be modified by specifying the content command if you need to change the

domain name.

Configuring the Switch for UDP-based Health Checks

Configure the switch to verify if the DNS server is alive.


2. Set the health check type to UDP for the real server group.

3. Set the content to domain name.


NOTE – If no host name is configured, the health check is performed by sending a UDP-basedquery from a dummy host and watching for the server’s 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.


>> # Real server group 1# health udpdns

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



TFTP Health Check




Alteon OS supports the Trivial File Transfer Protocol (TFTP) health check which utilizes the

TFTP protocol to request a file 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 serversuccessfully responds to the RRQ. The health check fails if the switch receives an error packet

from the real server.

To configure TFTP health check, do the following:


2. Set the health check type to TFTP for the real server group.

3. Specify the file name that the switch requests from the real servers.

Make sure the file is less than 512 bytes, so you don’t incur additional traffic between theserver and the switch. Depending on the implementation of the TFTP daemon on the real serv-

ers being health-checked, you may have to specify the full pathname of the file

(/tftpboot/< filename>) on some systems and on others a filename is sufficient. By

default, the switch checks the /tftpboot folder.

If full pathname is specified, add quotation marks for example, “/tftpboot/test”.



>> # Real server group 1# health tftp

>> # Real server group 1# content test



SNMP Health Check




Alteon OS 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 variablewithin the MIB. For each SNMP health check, you configure the Object Identifier (OID) and

community string to be queried. These values are obtained by using a MIB Browser and a MIB

compiler to find the OID of the desired variable.

If the OID and community string are assigned per real server (/cfg/slb/real/ids), then it

will override the group configuration. The SNMP health check per real server is used to health

check IDS servers only. Alteon OS also allows you to configure 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 configure SNMP health check for a real server group, do the following:

1. Select the SNMP health check menu and enter an index number.

You can configure up to five SNMP health checks and assign it to a group or per real server.

2. Specify the object identifier (OID).

The OID is obtained from the MIB file of the switch. For example, you may enter the OID forchecking the status of a physical port on the switch port that is connected to the group of IDS

servers.

3. Set the community string on the switch which notifies the SNMP agent on the real server

to accept the SNMP packet from the switch.

This community string must match the community string specified on the real server.

4. Configure an integer value for the switch to accept the health check.

>> # /cfg/slb/advhc/snmphc 1 (Specify an index number)

>> SNMP Health Check 1# oid 1.3.6.1.2.1.2.2.1.8.257

>> SNMP Health Check 1# comm real1


If the value returned by the real server for the MIB variable does not match the expected value

configured in the rcvcnt field, then the server is marked down; the server is marked back up




g , ; p

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 isreturned from the real server is considered as health check failed.

5. Enable the real server weights to dynamically change based on the SNMP health check

response.

6. Enable the invert field if you want the switch to invert the health check.

By enabling the invert field, it is possible to reverse your configuration 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.

7. 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.

>> SNMP Health Check 1# rcvcnt 0

>> SNMP Health Check 1# weight ena (Update weights for the real servers)

>> SNMP Health Check 1# invert ena

>> # /cfg/slb/group 10 (Select the real server group)

>> Real Server Group 10# health snmp1


FTP Server Health Checks




The Internet File Transfer Protocol (FTP) provides facilities for transferring files to and from

remote computer systems. Usually the user transferring a file needs authority to login and

access files 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 con-

trol 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 files, the data

transfer mechanism is also used for transferring directory listings from server to client.

NOTE – To configure the switch for FTP health checks, the FTP server must accept anony-

mous user login.

Configuring the Switch for FTP Health Checks

Create any file name from an FTP server under FTP server directory, for example, .txt,.exe, .bin.

To configure the switch for FTP health checks:


2. Set the health check type to FTP for the real server group.




>> # /cfg/slb/group 1/health ftp

>> # /cfg/slb/group 1/content <filename>



POP3 Server Health Checks

Th P Offi P l V i 3 (POP3) i i d d i k i d i




The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynami-

cally 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.

Configuring the Switch for POP3 Health Checks

To support health checking on the UNIX POP3 server, the network administrator must config-

ure a username:password value in the switch, using the content option on the SLB real

server group menu (/cfg/slb/group)

To configure the switch for POP3 health checks:


2. Set the health check type to POP3 for the real server group..



SMTP Server Health Checks

Simple Mail Transfer Protocol is a protocol to transfer e-mail messages between servers reli-

ably and efficiently. 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.


>> # /cfg/slb/group 1/health pop3

>> # /cfg/slb/group 1/content <username>:<password>



Configuring the Switch for SMTP Health Checks

To support SMTP health checking the network administrator must configure a username:pass-




To support SMTP health checking, the network administrator must configure a username:pass-

word value in the switch, using the content option on the SLB real server group menu

(/cfg/slb/group).

To configure the switch for SMTP health checks:

1. Select the health check menu for the real server group.

2. Set the health check type to SMTP for the real server group..




>> # /cfg/slb/group 1/health smtp

>> # /cfg/slb/group 1/content <username>



IMAP Server Health Checks

Internet Message Access Protocol (IMAP) is a mail server protocol used between a client sys




Internet Message Access Protocol (IMAP) is a mail server protocol used between a client sys-

tem 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.

Configuring the Switch for IMAP Health Check

To support IMAP health checking, the network administrator must configure a username:pass-

word value in the switch, using the content option on the SLB Real Server Group Menu

(/cfg/slb/group).

To configure the switch for IMAP health checks:


2. Set the health check type to IMAP for the real server group..


The content option specifies 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 spec-

ify the client(s) or port(s) the user is allowed to access.



>> # /cfg/slb/group 1/health imap

>> # /cfg/slb/group 1/content <username>:<password>



NNTP Server Health Checks

Net News Transfer Protocol (NNTP) is a TCP/IP protocol based upon text strings sent bidirec-




Net News Transfer Protocol (NNTP) is a TCP/IP protocol based upon text strings sent bidirec

tionally 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 specifies a protocol for the distribu-tion, inquiry, retrieval, and posting of news articles using a reliable stream-based transmission

of 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 specified by RFC1036.

Configuring the Switch for NNTP Health Checks

To configure the switch for NNTP health checks:


2. Set the health check type to NNTP for the real server group.


Create nntp directory from MS Windows Option Pack4.



>> # /cfg/slb/group 1/health nntp

>> # /cfg/slb/group 1/content <nntp newsgroup name>



RADIUS Server Health Checks

Alteon OS allows you to use the Remote Authentication Dial-In User Service (RADIUS) pro-




teo OS a ows you to use t e e ote ut e t cat o a Use Se v ce ( US) p o

tocol 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 configuringRADIUS health checks, make sure of the following:

Configure 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 Alteon 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.

Configure the real server port (rport) on the switch

The RADIUS health check is performed using the real server port (rport). Make sure

that the rport is the same port the server is listening on for RADIUS authentication

(1812) or RADIUS accounting (1813). To configure the rport, use the /cfg/slb/

virt <#>/service menu.

Configuring RADIUS Authentication Health Checks

Follow this procedure to health check RADIUS authentication service.


2. Set the health check type for the real server group.


The content option specifies 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 spec-

ify the client(s) or port(s) the user is allowed to access.


>> Real server group 1# health radius-auth

>> Real server group 1# content <username>:<password>


4. Configure the RADIUS code value.

The secret value is a field 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 verification. This value must be identical to the value specified onthe RADIUS server.


Configuring 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.


2. Set the health check type for the real server group.

NOTE – Alteon OS allows you to couple the Radius Accounting Health check with the WAPhealth 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.

>> # /cfg/slb/advhc/secret <RADIUS-coded value>

>> # Real server group 1# apply

>> # Real server group 1# save


>> Real server group 1# health radius-acc


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 server’s “Hello” response. SSL health check is per-formed using the real server port configured, that is, the rport.

The SSL enhanced health check behavior is summarized below:

The switch sends a SSL “Hello” packet to the SSL server.

If it is up and running, the SSL server responds with the “Server Hello” message.

The switch verifies fields in the response and marks the service “Up” if the fields are OK.

During the handshake, the user and server exchange security certificates, negotiate an encryp-

tion and compression method, and establish a session ID for each session.


WAP Gateway Health Checks

Wireless Application Protocol or WAP is a specification 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 gate-ways on the land-based part of the network.

Wireless Session Protocol (WSP) is used within the WAP suite to manage sessions between

wireless devices and WAP content servers or WAP gateways. Alteon OS provides a content-

based health check mechanism where customized WSP packets are sent to the WAP gateways,

and the switch verifies the expected response, in a manner similar to scriptable health checks.

WSP content health checks can be configured in two modes: connectionless and connection-

oriented. Connectionless WSP runs on UDP/IP protocol, ports 9200/9202. Connection-ori-

ented traffic runs on ports 9201 and 9203. Alteon Application Switches can be used to load

balance the gateways in both modes of operation.

Alteon OS allows you to configure three WAP gateway health check types for all four WAP

services (default ports 9200, 9201, 9202, and 9203) deployed on WAP gateway/servers.

NOTE – In Alteon OS 22.0, 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.

Table 15-1 WAP Gateway Health Checks

Health Check

Type

Type of Traffic

Health Check Mode

WAP Service To configure, see

WSP connectionless

WSP

9200 page 454

WTPa

a. Wireless Transaction Protocol

connection-oriented

WTP + WSP

9201 page 455

WTLS b

b. Wireless Transport Layer Security

encrypted connectionless

WTLS + WSP

9202 page 457

WTLS encrypted connection-oriented

WTLS + WTP + WSP

9203 page 457


What is WTLS?

Wireless Transport Layer Security or WTLS is the security layer of the WAP, providing pri-

vacy data integrity and authentication for WAP services WTLS designed specifically for the




vacy, data integrity and authentication for WAP services. WTLS, designed specifically for the

wireless environment, is needed because the client and the server must be authenticated inorder 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 secu-

rity.

How WAP Health Check Works

The content of the WSP/UDP packet that is sent to the gateway is configured 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 specified 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 configure 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

Alteon OS allows you to couple the WAP health checks with the Radius Accounting healthcheck. 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.


Configuring WSP Health Checks

Follow this procedure to configure the health check for connectionless and unencrypted WAP

traffic




traffic.

1. Select the WAP Health Check Menu.

2. Enter the WSP port.

By default, the health check is sent to the UDP port 9200.


4. Use the sndcnt command to enter the content to be sent to the WSP gateway.

5. Enter the content that the switch expects to receive from the WSP gateway.

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.

>> # /cfg/slb/advhc/waphc

>> WAP Health Check# wspport 9200

>> WAP Health Check# wspcnt

>> WSP Health Check Content# sndcntCurrent Send content:Enter new Send content: 01 42 15 68 74 74 70 3a 2f 77 77 77 2e 6e 6f6b 61 6d 00 .

>> WSP Health Check Content# rcvcnt

Current Receive content:Enter new Receive content: 01 04 60 0e 03 94


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




p g p ,

area is the WSP response content.

7. Because WAP gateways are UDP-based and operate on a UDP port, configure UDP ser-

vice in the virtual server menu.

8. Enable WSP health checks for group 1.


Configuring WTP Health Checks

Follow this procedure to configure the health check for connection-oriented, unencrypted

WAP traffic.


2. Enter the WTP port.

By default, the health check is sent to the UDP port 9201.

3. Select the WTP Health Check Menu.

>> WSP Health Check Content# offset 0

>> # /cfg/slb/virt 1>> Virtual Server 1# service (Configure virtual service 1)

Enter virtual port: 9200 (On the default WSP port)

>> Virtual Server 1 9200 Service# group 1 (Set the real server group number)

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

>> Virtual Server 1 9200 Service# apply (Apply the configuration)


>> Real server group 1# health wsp (Set the health check type)

>> Real server group 1# apply


>> WAP Health Check# wtpport 9201

>> WAP Health Check# wtpcnt


4. Create a WSP session by sending the connect message.

Use the connect command to enter the content for the first switch-generated WSP session

packet. This command allows you to customize the headers in the connect message.





This send content can be used to get a dummy Web page from the server.

6. Enter the content that the switch expects to receive from the WSP gateway.

7. 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.

8. Because WAP gateways are UDP-based and operate on a UDP port, configure UDP ser-

vice in the virtual server menu.

9. Enable WSP health checks for group 1.

>> WTP+WSP Health Check Content# connectCurrent Connect content:Enter new Connect content: 01 10 00 00

>> WTP+WSP Health Check Content# sndcntCurrent Send content:Enter new Send content: 01 42 15 68 74 74 70 3a 2f 77 77 77 2e 6e 6f6b 61 6d 00 .

>> WTP+WSP Health Check Content# rcvcnt

Current Receive content:Enter new Receive content: 01 04 60 0e 03 94

>> WTP+WSP Health Check Content# offset 0

>> # /cfg/slb/virt 1>> Virtual Server 1# service (Configure virtual service 1)

Enter virtual port: 9201 (On the default WTP port)>> Virtual Server 1 9200 Service# group 1 (Set the real server group number)

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

>> Virtual Server 1 9200 Service# apply (Apply the configuration)


>> Real server group 1# health wtp (Set the health check type)







Configuring WTLS Health Checks

Wireless Transport Layer Security (WTLS) is used to health check encrypted WAP traffic.

The encrypted WAP traffic can be connectionless (WTLS+WSP) or connection-oriented

(WTLS+WTP+WSP). The connectionless encrypted WTLS traffic uses default port 9202 and

the connection-oriented encrypted WTLS traffic 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 configurable and is generated by the switch auto-

matically.

1. Select the group with the WAP gateway.



4. Select a port number on which your gateway is listening to WTLS traffic.

By default, the health check is sent to the UDP port 9202 for connectionless traffic (/cfg/

slb/adv/waphc/wtlswsp) and to port 9203 for connection-oriented traffic (/cfg/

slb/adv/waphc/wtlsprt).


>> Main# /cfg/slb/group 1 (Select the Real Server Group 1 menu)

>> Real server group 1# health wtls


>> WAP Health Check# wtlsprt 9203

>> WAP Health Check# apply


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 first 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 asup. 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 connec-tion will also be torn down if it crosses the timeout limit, irrespective of the server’s condition.

Configuring the Switch for LDAP Health Checks

Configure the switch to verify if the LDAP server is alive.


2. Add the desired real servers to the group.

3. Set the backup server.

4. Set the health check type to LDAP for the real server group.


>> Real server group 1# add 2>> Real server group 1# add 3

>> Real server group 1# backup r1 (Set real server 1 as backup)

>> # Real server group 1# health ldap


5. Configure the LDAP health check to verify the domain name in the content field. For

example, to verify the domain name ldap.example.com , enter the following with the

customer name=Admin and password=test:




6. (Optional) Name the real server group.


Determining the Version of LDAP

1. Select the Advanced Menu.

2. Set the version of LDAP. The default version is 2.


>> # content "cn=Admin,dc=ldap,dc=example,dc=com:test"

>> Real server group 1# name LDAP


>> # Real server group 1# /cfg/slb/advhc

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


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 itscache 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:

1. Accessing the ARP table.

2. 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.

3. If the entry is present, then check the timestamp to find 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.

4. Send another ARP request and repeat the above process until the timestamp shows the

last used time smaller than the ARP health check interval.

Configuring the Switch for ARP Health Checks

1. Select the SLB group from the health check menu.

2. Select the type of health check to use.

3. Enable ARP health checks for group 1.


>> /cfg/slb/group 1

>> Real server group 1# health arp

>> Real server group 1# arp



Failure Types




Service FailureIf a certain number of connection requests for a particular service fail, the Alteon 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

traffic associated with existing sessions continues to be sent to the server. Connection requests

to, and traffic associated with, other load-balanced services continue to be processed by the

server.

Example: A real server is configured 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.

When a service on a server is in the service failed state, the Alteon Application Switch sendsLayer 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 requestswithin the specified 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 traffic 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 inthe server failed state.

The server is brought back into service as soon as the first service is proven to be healthy.

Additional services are brought online as they are subsequently proven to be healthy.




315394-J, January 2005463

CHAPTER 16

High Availability

Alteon Application Switches support high-availability network topologies through an

enhanced implementation of the Virtual Router Redundancy Protocol (VRRP).


“VRRP Overview” on page 464. This section discusses VRRP operation and Alteon OS

redundancy configurations.

“Alteon OS Extensions to VRRP” on page 468. This section describes VRRP enhance-

ments implemented in Alteon OS.

“Failover Methods and Configurations” on page 479. This section discusses a few of the

more useful and easily deployed redundant configurations.

“Active-Standby VSR Configuration in a Non-Shared Environment” on page 481

“Active-Active VIR and VSR Configuration” on page 484

“Active-Active Server Load Balancing Configuration” on page 486

“Hot-Standby Configuration” on page 496

“Service-Based Virtual Router Groups” on page 504

“Virtual Router Deployment Considerations” on page 509. This section describes issues to

consider when deploying virtual routers.

“Stateful Failover of Persistent Sessions” on page 513. This section describes how to

enable stateful failover by mirroring Layer 7 and Layer 4 persistent transactional states on

the peer switch.


VRRP Overview

In a high-availability network topology, no device can create a single point-of-failure for the



315394-J, January 2005464 Chapter 16: High Availability

network or force a single point-of-failure to any other part of the network. This means thatyour 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 configurations 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 configured 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 backupvirtual routers will take control of the virtual router IP address and actively process traffic

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 host’s gateway information does

not change, no matter what path is used. A VRRP-based redundancy schema reduces adminis-

trative overhead because hosts need not be configured with multiple default gateways.

Standard VRRP Components

Each physical router running VRRP is known as a VRRP router .

Virtual Router

Two or more VRRP routers can be configured to form a virtual router (RFC 2338). EachVRRP router may participate in one or more virtual routers.Each virtual router consists of a

user-configured virtual router identifier (VRID) and an IP address.

Virtual Router MAC Address

The VRID is used to build the virtual router MAC Address. The five highest-order octets of the

virtual router MAC Address are the standard MAC prefix (00-00-5E-00-01) defined 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 configured as the IP address

owner. The owner is the virtual router (Alteon Application Switch) whose virtual interface

router’s IP address is equal to the real interface address. This router responds to packets



315394-J, January 2005Chapter 16: High Availability 465

addressed to the virtual interface router’s 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 configured with the virtual interface router's IP address.

There is no requirement for any VRRP router to be the IP address owner. Most VRRP installa-

tions 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” on page 466 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 router's 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 router’s VLAN with an active link, the interface for the VLAN

fails, thus placing the virtual router into the INIT state.


The INIT state identifies that the virtual router is waiting for a startup event. If it receives a

startup event, it will either transition to master if its priority is 255, (the IP address owner) or

transition to the backup state if it is not the IP address owner.

H VRRP P i it D id Whi h S it h i th M t




How VRRP Priority Decides Which Switch is the MasterEach VRRP router that is not an owner is configured with a priority between 1–254. According

to the VRRP standard, an owner has a priority of 255. A bidding process determines which

VRRP router is or becomes the master—the 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 back-ups 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 configured not to do so. In pre-

emption, 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 reasons—the 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 hasfailed, there will then be two masters within the virtual router. To prevent this from happening,

configure redundant links to be used between the switches that form a virtual router.

Determining How to Configure Priority

Think of a virtual router’s priority as a starting value that increases or decreases depending on

the parameters that are tracked. For example, if you configure the virtual router to track link

state of the physical ports, one port losing link would cause the virtual router’s priority to

decrease 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 switch’s priority to

108. As 108 is still higher than backup’s priority 100, the master switch would not fail over

due to the loss of one ports’ link.





Alteon OS Extensions to VRRP

This section describes the following VRRP enhancements that are implemented in Alteon OS:

“Virtual Interface Routers” on page 468

“Vi t l S R t ” 468




“Virtual Server Routers” on page 468

“Sharing Interfaces for Active-Active Failover” on page 470

“Switch-Based VRRP Groups” on page 474


“Tracking Service-Based Virtual Router Groups” on page 477

“Tracking VRRP Router Parameters” on page 475

“VRRP Holdoff Timer” on page 478

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. Ifthe IP interface of a VIR is down, then the VIR will be in the INIT state.

Virtual Server Routers

Support for 1024 VSRs

Alteon OS supports up to 1024 virtual server routers, which extend the benefits of VRRP to

virtual server IP addresses that are used to perform server load balancing.

In Alteon OS 22.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 field. When sending advertise-

ments 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 defined packet type (type=1).

What is a VSR?

Virtual server routers operate for virtual server IP (vip) addresses in much the same manner as

Virtual Interface Routers operate for IP interfaces. A master is negotiated via a bidding pro-

cess, during which information about each VRRP router’s priority is exchanged. Only the mas-

ter 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 indepen-

dently of one another; that is, their priority assignments, advertisements, and master negotia-

tions are separate For example when you configure a VRRP router’s priority in a virtual




tions are separate. For example, when you configure a VRRP router’s priority in a virtual

server router, you are not affecting that VRRP router’s 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 Alteon Application Switches in Figure 16-1 have been configured as VRRP routers.

Together, they form a virtual interface router (VIR).

VRRP Router

VRID = 1

Router #1 = Master ActiveVR IP dd 205 178 13 226




Figure 16-1 Virtual Interface Router

Application Switch 1 in Figure 16-1 has its real interface configured with the IP address of the

virtual interface router, making it the IP address owner. As IP address owner, it receives a pri-

ority of 255, and is the virtual router master.

Application Switch 2 is a virtual router backup. Its real interface is configured 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

Internet

Router

RouterVRRP Router

VRID = 1Router #2 = Backup StandbyVR IP address = 205.178.13.226

IP interface = 205.178.13.225MAC address = 00.00.5E.00.01.01Priority = 100

Router #1 Master ActiveVR IP address = 205.178.13.226IP interface = 205.178.13.226MAC address = 00.00.5E.00.01.01Priority = 255

VirtualInterface

Router

Host #1Default Gateway205.178.13.226

Alteon Application

Switch 1

Alteon Application

Switch 2


Alteon OS supports sharing of interfaces at both Layer 3 and Layer 4, as shown in Figure 16-2.

Router

Master-Active VR 1

Backup-Active VR 2

Master-Active VR 3




Figure 16-2 Active-Active Failover with Shared Interfaces

With sharing enabled, an IP interface or a VIP address can be active simultaneously on multi-

ple switches, enabling active-active operation as shown in Figure 16-2, and Table 16-1 below.

Table 16-1 Active-Active Failover with Shared Interfaces

Virtual Router 1 Virtual Router 2 Virtual Router 3

ApplicationSwitch 1

Master-ActiveVRID 2

VIP: 205.178.13.226

Virtual Rtr. MAC address:

00-00-5E-00-01-02

Backup-ActiveVRID 4

VIP: 205.178.13.240


00-00-5E-00-01-04

Master-ActiveVRID 6

VIP: 205.178.13.110


00-00-5E-00-01-06

Application

Switch 2

Backup-Active VR 1

VRID 2

VIP: 205.178.13.226

Virtual Rtr. MAC address: 00-00-5E-00-01-02

Master-Active VR 2

VRID 4

VIP: 205.178.13.240


Backup-Active VR 3

VRID 6

VIP: 205.178.13.110


Internet

Router

Backup-Active VR 1

Master-Active VR 2

Backup-Active VR 3

Alteon Application

Switch 2

Alteon Application

Switch 1


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 Span-

ning Tree configuration.

NOTE – Sharing cannot be used in configurations where incoming packets have more than one




g g g pentry point into the virtual router—for 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 vir-

tual server IP address, it does determine which switch sends advertisements and responds to

ARP requests sent to the virtual router’s IP address.

Alteon OS strongly recommends that sharing, rather than active-standby configurations, be

used whenever possible. Sharing offers both better performance and fewer service interrup-

tions in the face of fault conditions than active-standby configurations.

See “Active-Active Redundancy” on page 484 for a configuration 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 efficient tracking and failover based on each group’s

tracking parameters while leaving other groups unaffected. For example, an administrator

wishes to provide high availability for Customer A and Customer B’s servers and services

across the same two switches, without one affecting the other:

Customer A’s traffic load-balances across real servers in real server group 1. Customer B’s traffic load balances across real servers in real server group 2.

Each switch is configured 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 equiv-

alent vrgroup 1 on the other switch while not affecting the VRRP state of vrgroup 2.

Switch 1

VIP 1

Real server group 1

vrgroup 1 for customer A




Figure 16-3 Service Based Virtual Router Groups

Characteristics of Service-Based Virtual Router Groups (vrgroups)

Switch-based VRRP group must be disabled (/cfg/l3/vrrp/group dis)

Up to 16 vrgroups can be configured 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 configured as a virtual interface router or a virtual service router.

Virtual routers that become members of a vrgroup, assume the priority tracking parame-

ters configured 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

configuring tracking on the service-based virtual router group.

Commands

To access the vrgroup menu, enter the following command:

/cfg/l3/vrrp/vrgroup <vrgroup # 1-16>

Internet

Router

Router

Switch 2

VIP 2

Real server group 2

vrgroup 2 for customer B

vr1 (vrgroup 1: Master) vr2

vr3 (vrgroup 2: Backup) vr4

vr1 (vrgroup 1: Backup) vr2

vr3 (vrgroup 2: Master) vr4


To add virtual routers to a service-based virtual router group:

/cfg/l3/vrrp/vrgroup 1/ (Select vrgroup 1)

>> VRRP Virtual Router Vrgroup 1# add 1 (Add virtual router 1 to vrgroup 1)


/cfg/l3/vrrp/vrgroup 2/ (Select vrgroup 2)>> VRRP Virtual Router Vrgroup 2# add 3 (Add virtual router 3 to vrgroup 2)




See “Tracking Service-Based Virtual Router Groups” on page 477 for a configuration

example.

Switch-Based VRRP GroupsA 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

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

group’s 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 traffic addressed to that virtual

server IP address. Filtering is also still functional. Only traffic addressed to virtual server

routers is not processed.

Each VRRP advertisement can include up to 1024 addresses. All virtual routers are adver-

tised within the same packet, conserving processing and buffering resources.

NOTE – The switch-based virtual router group cannot be used for active-active configurations

or any other configuration that requires shared interfaces.

Command




The switch-based VRRP group is configured by the following command:

NOTE – For more information on using switch-based VRRP groups with hot-standby, see494

/cfg/l3/vrrp/group ena




page 494.

Tracking VRRP Router Parameters

Alteon OS supports a tracking function that dynamically modifies 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 configurations. It does not have

any effect on active-active sharing configurations.


Alteon OS can track the attributes listed in Table 16-2:

Table 16-2 VRRP Tracking Parameters

Parameter and Commands Description

Number of virtual routers in master mode on the

it h

Useful for ensuring that traffic for any particular client/server pair is

h dl d b th it h i i ti d l d b l i




switch.

To enable tracking on vrs:

/cfg/l3/vrrp/vr <#>/track/vrs/enaTo change the virtual router increment:

/cfg/l3/vrrp/track/vrs <[0-254]>

handled by the same switch, increasing routing and load-balancing

efficiency. This parameter influences the VRRP router's priority in

both virtual interface routers and virtual server routers.

Note: The vrs parameter is not available for tracking for a service

based virtual router group (vrgroup).

Number of IP interfaces active on the switch.

To enable tracking on IP interfaces:/cfg/l3/vrrp/vr /track/ifs <#>/enaTo change the interfaces tracking increment:

/cfg/l3/vrrp/track/ifs <[0-254]>

Helps elect the virtual routers with the most available routes as the

master. (An IP interface is considered active when there is at leastone active port on the same VLAN.) This parameter influences the

VRRP router’s priority in both virtual interface routers and virtual

server routers.

Number of active ports on the same VLAN.

To enable tracking on ports on the same VLAN:

/cfg/l3/vrrp/vr /track/port <#>/enaTo change the ports tracking increment:

/cfg/l3/vrrp/track/ports <[0-254]>

Helps elect the virtual routers with the most available ports as the

master. This parameter influences the VRRP router’s priority in both

virtual interface routers and virtual server routers.

Number of physical switch ports that have active

Layer 4 processing on the switch

To enable tracking on Layer 4 ports:

/cfg/l3/vrrp/vr/track/l4pts/enaTo change the Layer 4 ports tracking increment:

/cfg/l3/vrrp/track/l4pts <[0-254]>

Helps elect the main Layer 4 switch as the master. This parameter

influences the VRRP router’s priority in both virtual interface routers

and virtual server routers.

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

Helps elect the switch with the largest server pool as the master,

increasing Layer 4 efficiency. This parameter influences the VRRP

router’s priority in virtual server routers only.

In networks where the Hot Standby Router Protocol

(HSRP) is used for establishing router failover, the

number of Layer 4 client-only ports that receiveHSRP advertisements.

/cfg/l3/vrrp/track/hsrp

Helps elect the switch closest to the master HSRP router as the mas-

ter, optimizing routing efficiency. This parameter influences the

VRRP router’s priority in both virtual interface routers and virtualserver routers.

Tracking HSRP on VLAN

/cfg/l3/vrrp/track/hsrvHot 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-configurable weight. As the count associated

with each tracked item increases (or decreases), so does the VRRP router's 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” on page 502 for an example on how to configure the switch for

tracking VRRP priority




tracking VRRP priority.

Tracking Service-Based Virtual Router Groups

Alteon OS also supports a tracking function that dynamically modifies 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 group’s tracking configuration overrides an individualVRRP router’s tracking.

Alteon OS 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 specific cus-

tomer.

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 configured for each vrgroup, with the same resources tracked on individual

virtual routers (Table 16-2 on page 476). 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 cus-

tomer’s vrgroup will failover to the backup switch. Other vrgroups configured for other

customers do not failover. For example, if a vrgroup is configured to track on ports, a port

failure will decrease 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” on page 504 for an example on how to configurethe switch for tracking VRRP priority.


VRRP Holdoff Timer

When an application switch becomes the VRRP master at power up or after a failover opera-

tion, it may begin to forward data traffic before the connected gateways or real servers are

operational. The application switch may create empty session entries for the coming data pack-

ets and the traffic cannot be forwarded to any gateway or real server.




Alteon OS 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 specified number of seconds before forwarding

traffic to the default gateway and real servers. The VRRP holdoff timer is set with the follow-

ing command:

>> Main# /cfg/l3/vrrp/holdoff <0-255 seconds>


Failover Methods and Configurations

Alteon Application Switches offer flexibility in implementing redundant configurations. This

section discusses a few of the more useful and easily deployed configurations:

“Active-Standby Redundancy” on page 480




“Active-Standby VSR Configuration in a Non-Shared Environment” on page 481

“Active-Active Redundancy” on page 484

“Active-Active VIR and VSR Configuration” on page 484

“Active-Active Server Load Balancing Configuration” on page 486

“Hot-Standby Redundancy” on page 494 “Hot-Standby Configuration” on page 496

“Tracking Virtual Routers” on page 502


Alteon OS high availability configurations are based on VRRP. The Alteon OS implementa-

tion of VRRP includes proprietary extensions to accommodate Layer 4 though Layer 7 appli-

cation switching features.

The Alteon OS implementation of VRRP supports three modes of high availability:

Active-Standby

Active-Active

Hot-Standby

The first mode, active-standby, is based on standard VRRP, as defined in RFC 2338. The sec-

ond and third modes, active-active and hot-standby, are based on proprietary Alteon OS exten-sions to VRRP. Each mode is described in detail in the following sections.


Active-Standby Redundancy

In an active-standby configuration, shown in Figure 16-5, two application switches are used.

Both switches support active traffic but are configured so that they do not simultaneously sup-

port the same service. Each switch is active for its own set of services, such as IP routing inter-

faces 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 ser-




the other switch. If either switch fails, the remaining switch takes over processing for all ser

vices. The backup switch may forward Layer 2 and Layer 3 traffic, as appropriate.

NOTE – In an active-standby configuration, the same service cannot be active simultaneously

on both switches.

Figure 16-4 Active-Standby VRRP Routers

Internet

Router

RouterVRID = 1Router #2 = Backup Standby

VRID = 1Router #1 = Master Active



VRID = 2Router #2 = Master Active

VRID = 2Router #1 = Backup Standby

Alteon Application

Switch 1 Alteon Application

Switch 2


In the example shown in Figure 16-4 on page 480, 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 traffic at the same time but not for the same interface.

Table 16-3 Active-Standby Configuration




Active-Standby VSR Configuration in a Non-Shared Environment

Figure 16-5 shows an example configuration where two Alteon Application Switches are used

as VRRP routers in an active-standby configuration, implementing a virtual server router. In

this configuration, when both switches are healthy, only the master responds to packets sent to

the virtual server IP address.

y g

VRID = 1 VRID = 2

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 #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

Application

Switch 2

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

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


NOTE – Active-standby redundancy should be used in configurations that cannot support shar-

ing of interfaces at Layer 3 and Layer 4. This includes configurations where incoming packets

will be seen by more than one switch, such as instances where a hub is used to connect the

switches.

Server 1RIP 1: 10 10 10 101




Figure 16-5 Non-Shared Active-Standby High-Availability Configuration

Although this example shows only two switches, there is no limit on the number of switchesthat can be used in a redundant configuration. It is possible to implement an active-standby

configuration across all the VRRP-capable switches in a LAN.

Each VRRP-capable switch in an active-standby configuration is autonomous. Switches in a

virtual router need not be identically configured.

To implement the active-standby example, perform the following switch configuration:

1. Configure 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 configured, none of them should use the virtual server IP address described in Step 3.

Internet

Router

Router

Backup-StandbyVRID 2VIP: 205.178.13.226MAC address 00-00-5E-00-01-02

Server 4RIP 1: 10.10.10.104RIP 2: 10.10.11.104

Master-ActiveVRID 2VIP: 205.178.13.226MAC address 00-00-5E-00-01-02

Server 3RIP 1: 10.10.10.103RIP 2: 10.10.11.103

Server 2RIP 1: 10.10.10.102RIP 2: 10.10.11.102

RIP 1: 10.10.10.101RIP 2: 10.10.11.101

Alteon Application

Switch 1

Alteon Application

Switch 2


2. Define all filters required for your network configuration.

Filters may be configured on one switch and synchronized with settings on the other switch

(see Step 5 below).

3. Configure all required SLB parameters on application switch 1.For the purposes of this example, assume that application switch 1 in Figure 16-5 is configured

i hi R i d L 4 i l d VIP 205 178 13 226 d l




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. Configure the VRRP parameters on application switch 1.

This configuration includes VRID = 2, VIP = 205.178.13.226 and the priority. Enable trackingon the virtual router, and set the parameters appropriately (refer to “Tracking Virtual Routers”

on page 502). Make sure to disable sharing .

5. Synchronize the SLB and VRRP configurations by synchronizing the configuration from

application switch 1 to application switch 2.

Use the /oper/slb/sync command (see “Configuring VRRP Peers for Synchronization” on

page 511).

6. Change the real servers in the application switch 2 configuration 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 2’s priority (see “Tracking Virtual Routers” on page 502).

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 algo-

rithm. If tracking is enabled and is configured to take into account the number of healthy realservers for the Virtual Router's VIP address, application switch 1’s priority will be reduced. If it

is reduced to a value lower than application switch 2’s priority, then application switch 2 will

assume the role of master. In this case, all active connections serviced by application switch 1’s

virtual server IP address are severed.

If the link between application switch 1 and its Internet router fails, the protocol used to dis-

tribute traffic between the routers, for example, Open Shortest Path First (OSPF), will reroute

traffic to the other router. application switch 2 (backup) will act as a Layer 2/3 switch and for-

ward all traffic destined to the virtual server IP address to application switch 1.

If the entire application switch 1 (master) fails, the protocol used to distribute traffic between

the routers, such as OSPF, will reroute traffic 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 master’s responsibility of responding to ARP requests and issuing

advertisements.


Active-Active Redundancy

Alteon OS has extended VRRP to include virtual servers, allowing full active/active redun-

dancy between its Layer 4 switches. In an active-active configuration, shown in Figure 16-6,

both switches can process traffic 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 Configuration

In Figure 16-6, two Alteon Application Switches are used as VRRP routers in an active-active

configuration implementing a virtual server router. As noted earlier, this is the preferred redun-

dant configuration.

Figure 16-6 Active-Active High-Availability Configuration

Although this example shows only two switches, there is no limit on the number of switches

used in a high availability configuration. It is possible to implement an active-active configura-tion and perform load sharing between all of the VRRP-capable switches in a LAN.

In this configuration, 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 configuration.

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.

Internet

Router

Router

Backup-ActiveVRID 2VIP: 205.178.13.226MAC address 00-00-5E-00-01-02

Server 4RIP 1: 10.10.10.104

Master-ActiveVRID 2VIP: 205.178.13.226MAC address 00-00-5E-00-01-02

Server 3RIP 1: 10.10.10.103

Server 2RIP 1: 10.10.10.102

Server 1RIP 1: 10.10.10.101

Alteon Application

Switch 1

Alteon Application

Switch 2


NOTE – Each VRRP-capable switch is autonomous. There is no requirement that the switches

in a virtual router be identically configured. Different switch models with different numbers of

ports and different enabled services may be used in a virtual router.

To implement this example, configure the switches as follows:






This configuration includes any required VLANs, IP interfaces, default gateways, and so on. If

IP interfaces are configured, none of them should use the VIP address described in Step 3.


Filters may be configured on one switch and synchronized with the settings on the other switch(see Step 6, below).

3. Configure all required SLB parameters on one of the switches.

For the purposes of this example, assume that application switch 1 (see Figure 16-6 on page

484) is configured in this step. Configure a VIP = 205.178.13.226 and one real server group

with two real servers:

RIP = 10.10.10.103 should be configured as a backup server to RIP = 10.10.10.101.RIP = 10.10.10.104 should be configured as a backup server to RIP = 10.10.10.102.

NOTE – In this configuration, each server’s backup is attached to the other switch. This

ensures that operation will continue if all of the servers attached to a switch fail.

4. Configure the VRRP parameters on the switch.

Configure VRID = 2, VIP address = 205.178.13.226, and priority. Be sure to enable sharing.

5. Disable synchronization of VRRP priority to the 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 configurations by pushing the configuration from appli-

cation 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 2’s configu-

ration.

RIP = 10.10.10.101 should be configured as a backup server to RIP = 10.10.10.103.

RIP = 10.10.10.102 should be configured as a backup server to RIP = 10.10.10.104.


In this configuration, 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 traffic between the routers

(for example, OSPF) will reroute traffic to the other router. Since all traffic now enters the vir-

tual 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 master's responsibility of responding to ARP




p p y p g

requests and issuing advertisements.

Be cautious before setting the maximum connections ( maxconn) metric in this configuration.

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 connectionlimits defined for it on both switches.

Active-Active Server Load Balancing Configuration

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 bal-anced 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 benefits of active/

active failover. Set up one switch, dump out the configuration script (also called a text dump),

edit it, and dump the edited configuration into the peer switch.

NOTE – Configuring the switch for active-active failover should take no longer than 15 min-

utes to complete. You can use either the Alteon OS Browser-Based Interface (BBI) or theCommand Line Interface (CLI) for configuration.

Task 1: Background Configuration


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 appropri-ate 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 Alteon Application Switches, you may configure more than one subnet per

VLAN.


To configure the IP interfaces for this example, enter the following commands from the CLI:

Repeat the commands for each interface listed below:

>> Main# /cfg/l3/if 1 (Select IP interface 1)

>> IP Interface 1 # addr 10.10.10.10 (Assign IP address for the interface)

>> IP Interface 1 # vlan 2 (Assign VLAN for the interface)





Repeat the commands for each interface listed below:

IF 2—20.10.10.10

IF 3—30.10.10.10

IF 4—40.10.10.10

IF 5—200.1.1.10

2. Define the VLANs.

In this configuration, set up two VLANs: One for the outside world (the ports connected to the

upstream switches, toward the routers) and one for the inside (the ports connected to the down-

stream switches, toward the servers).

Repeat this command for the second VLAN.

VLAN 3 - IF 5—physical ports connected to upstream switches.

VLAN 2 - IFs 1,2,3,4—physical ports connected to downstream switches.

3. Disable Spanning Tree.

>> Main# /cfg/l2/vlan <VLAN number > (Select VLAN 3)

>> vlan 3 # add < port number > (Add a port to the VLAN membership)

>> vlan 3 # ena (Enable VLAN 3)

>> Main# /cfg/l2/stg 1 (Select the STP Group number)

>> Main# /cfg/l2/stg 1/off (Disable STP)

>> Main# /cfg/l2/stg 1/apply (Make your changes active)


4. Enable IP forwarding.

IP forwarding is enabled by default. Make sure IP 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 serverIP addresses and real server IP addresses are on different subnets, so enable this feature using

the following command:




Task 2: SLB Configuration

1. Define the Real Servers.

The real server IP addresses are defined and put into four groups, depending on the service

they are running. Notice that RIPs 7 and 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:

Repeat this sequence of commands for the following real servers:

RIP 2—10.10.10.6/24

RIP 3—20.10.10.5/24

RIP 4—20.10.10.6/24

RIP 5—30.10.10.5/24

RIP 6—30.10.10.6/24

RIP 7—200.1.1.5/24

RIP 8—200.1.1.6/24

>> Main# /cfg/l3/frwd/on (Enable IP forwarding)

>> Main# /cfg/slb/real 1 (Server A is real server 1)

>> Real server 1 # rip 10.10.10.5 (Assign Server A IP address)

>> Real server 1 # ena (Enable real server 1)


2. Define the real server groups, adding the appropriate real servers.

This combines the three real servers into one service group:

R t thi f d f th f ll i l

>> Real server 8 # /cfg/slb/group 1 (Select real server group 1)






Repeat this sequence of commands for the following real server groups:

Group 2—Add RIP 3 and 4



3. Define the virtual servers.

After defining 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 num-

ber.

Repeat this sequence of commands for the following virtual servers:

VIP 2—200.200.200.101 will load balance HTTPS (Port 443) to Group 2 VIP 3—200.200.200.102 will load balance POP/SMTP (Ports 110/25) to Group 3

VIP 4—200.200.200.104 will load balance FTP (Ports 20/21) to Group 4

4. Define the client and server port states.

Defining a client port state tells that port to watch for any frames destined for the VIP and to

load balance them if they are destined for a load-balanced service. Defining a server port state

tells the port to the do the remapping (NAT) of the real server IP address back to the virtualserver 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 serv-

ers) will need to be in the server port state.

>> Real server group 4 # /cfg/slb/virt 1 (Select virtual server 1)>> Virtual server 1 # vip 200.200.200.100 (Assign a virtual server IP address)

>> Virtual Server 1 # service 80 (Assign HTTP service port 80)

>> Virtual server 1 http Service # group 1 (Associate virtual port to real group)



Configure the ports, using the following sequence of commands:

Task 3: Virtual Router Redundancy Configuration


>> SLB port A1 # client ena (Enable client processing on port 1)

>> SLB port A1 # /cfg/slb/port 2 (Select physical switch port 2)

>> SLB port A2 # server ena (Enable server processing on port 2)




y g

1. Configure 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 configuration, which is disabled.

Configure a virtual router using the following sequence of commands:

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



2. Configure 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).

Configure 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




>> Virtual server 4 # /cfg/l3/vrrp/vr 2 (Select virtual router 2)

>> Virtual router 2 vrid 2 (Set virtual router ID)

>> Virtual router 2 addr 200.200.200.100 (Assign virtual router IP address)

>> Virtual router 2 if 5 (Assign virtual router interface)

>> Virtual router 2 ena (Enable virtual router 2)


3. 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 (Select virtual router 1)




Apply this sequence of commands to the following virtual routers, assigning each a priority of

101:

VR 2—Priority 101

VR 3—Priority 101

VR 4—Priority 101

4. Configure priority tracking parameters for each virtual router.

For this example, the best parameter(s) on which to track is Layer 4 ports (l4pts).

Use the following command:

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 follow-

ing virtual routers:

VR 2 - Track l4ptsVR 6 - Track l4pts



Switch 1 configuration is complete.

Task 4: Configuring Switch 2

Use the following procedure to dump the configuration script (text dump) out of Switch 1:

Using the Browser Based Interface (BBI)

(a) You need a serial cable that is a DB-9 Male to DB-9 Female, straight-through (not a

null modem) cable.

(b) Connect the cable from a COM port on your computer to the console port on switch 1.

>> Virtual router 1 prio 101 (Set virtual router priority)

>> Virtual server 4# /cfg/l3/vrrp/vr 1/track l4pts


(c) 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.

Using HyperTerminal

(a) Only the Baud Rate and Flow Control options need to be changed from the default set-tings.

(b) Once you connect to the switch, start logging your session in HyperTerminal (transfer/




(b) Once you connect to the switch, start logging your session in HyperTerminal (transfer/

capture text).

(c) Save the file as “Customer Name” Switch 1, then type the following command in the

switch command line interface:

A script will be dumped out.

(d) Stop logging your session (transfer/capture text/stop).

Modify the script as follows:

1. Open the text file that you just 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 con-

fuse Application Switch 2 when you dump in the file.

Change the last octet in all the IP interfaces from .10 to .11. Find this in line: /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, otherwise, you will have duplicate IP addresses in the network.

/cfg/dump


2. Change the virtual router priorities.

Virtual routers 1–4 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 find this in line /cfg/l3/vrrp/vr 1/

vrid 1/if 1/prio 101.

3. Scroll to the bottom of the text file and delete anything past “Script End.”

4. Save the changes to the text file as “Customer Name” Switch 2.




Move your serial cable to the console port on the second switch. Any configuration on it needs

to be deleted by resetting it to factory settings, using the following command:

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 configuration process. When it does, respond: “No.”

5. In HyperTerminal, go to transfer/send text file and send the Switch 2 text file. The configu-

ration will dump into the switch. Simply type apply, then save. When you can type charac-

ters in the terminal session again, reboot the switch (/boot/reset).

>> Main# /boot/conf factory/reset


Hot-Standby Redundancy

In a hot-standby configuration, 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 configured

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 configuration, two or more switches provide redundancy for each other. One

switch is elected master and actively processes Layer 4 traffic. The other switches (the backups)




y p y ( p )

assume the master role should the master fail. The backups may forward Layer 2 and Layer 3 traf-

fic 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”

on page 474.

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:

Layer 4 Port States

When a switch changes from master to backup, it does not process any traffic destined to thevirtual server routers configured on that switch. However, Layer 4 processing is still enabled.

A switch that has become the backup can still process traffic addressed to its virtual server IP

address. Filtering is also still functional.

Each VRRP advertisement can include up to 1024 addresses, and 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:

/cfg/l3/vrrp/group ena


Links that attach to the standby switch must be configured as hot standby using:

NOTE – All ports with hot standby enabled must be connected to another device.

Links that are used by VRRP to deliver updates are configured as intersw, or

Inter switch links (not to be confused with Cisco’s ISL)

/cfg/slb/port x/hotstan




Inter-switch links (not to be confused with Cisco s ISL).

The command to configure one or more ports as interswitch links is:

NOTE – A port cannot be configured to support both hot-standby and interswitch link.

The hot-standby switch listens to the master’s 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 traffic.

When the hotstan option (/cfg/slb/port x/hotstan) is enabled and all hot-standby

ports have link, the virtual router group’s priority is automatically incremented by set in 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 algo-

rithm, 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 traffic to the master switch.

/cfg/slb/port <port number>/intersw


The inter-switch port state is only a place holder. Its presence forces the user to configure 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 Configuration

A hot-standby configuration 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




p y pp y y g g

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.

Figure 16-7 shows a classic network topology, designed with redundancy in mind. This topol-

ogy 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.

Figure 16-7 Hot-Standby Configuration

2526

2526

Internet

Router

Router

Server 4

RIP 1: 10.10.10.104

Server 3RIP 1: 10.10.10.103

Server 2RIP 1: 10.10.10.102

Server 1RIP 1: 10.10.10.101

Alteon Application

Switch 2 Backup-Standby

VLAN 192:

Client Traffic

Alteon ApplicationSwitch 1 - Active-Hot

VLAN 172

Interswitch link

3

3


The key to hot-standby is that the interswitch link (the link between switches), does not partic-

ipate in STP, so there are no loops in the topology (see Figure 16-7). STP is disabled only on

the hot-standby ports, not globally. 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 an Alteon Application Switch

2424, you may adapt this example according the ports available on your particular Alteon

Application Switch model.




Task 1: Configure Layer 2 and Layer 3 Parameters on Switch 1

This example assumes you have already configured SLB parameters.

1. On Switch 1, configure the external ports into their respective VLANs as shown in Figure

16-7 on page 496.

2. Trunk the ports you configured for the client VLAN.

3. Turn off Spanning Tree.

/cfg/l2/vlan 1>> VLAN 1# ena>> VLAN 1# name servers (Name VLAN 1 for server traffic)

>> Port EXT4# /cfg/l2/vlan 192 (VLAN 192 is for client traffic)

>> VLAN 192# ena (Enable the VLAN)>> VLAN 192# name clients ( Name VLAN 192 for client traffic)

>> VLAN 192# def 25 26 (Add the ports 25, 26 to client VLAN)

>> VLAN 192# /cfg/l2/vlan 172 (VLAN 172 is for the Interswitch Link)

>> VLAN 172# ena (Enable the VLAN)

>> VLAN 172# name ISL (Name VLAN 172 for ISL)

>> VLAN 172# def 3 (Add port 3 to ISL VLAN)

/cfg/l2/trunk 1 (Select Trunk Group 1)

>> Trunk group 1# ena (Enable the Trunk Group)

>> Trunk group 1# failovr dis (Disable failover on the trunk)

>> Trunk group 1# add 25 26 (Add the external ports to the trunk)

/cfg/l2/stg 1/off (Disable STG group)

>> Spanning Tree Group 1# apply (Make your changes active)

>> Spanning Tree Group 1# save (Save for restore after reboot)


4. Configure the IP addresses for each VLAN.

/cfg/l3/if 1 (IP Interface 1: Servers)

>> IP Interface 1# ena (Enable this interface)

>> IP Interface 1# addr 10.0.1.251>> IP Interface 1# mask 255.255.255.0>> IP Interface 1# broad 10.0.1.255>> IP Interface 1# /cfg/l3/if 2 (IP Interface 2: Client traffic)

>> IP Interface 2# ena>> IP Interface 2# addr 192.168.1.251




Task 2:Configure Virtual Router Redundancy

1. Configure virtual routers for the server, client, and Interswitch Link traffic.

2. From the VRRP menu, enable VRRP group mode and hot-standby on all connected

ports except the interswitch link.

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

/cfg/l3/vrrp/vr 1 (Virtual router for server)

>> VRRP Virtual Router 1# ena

>> VRRP Virtual Router 1# vrid 1>> VRRP Virtual Router 1# if 1>> VRRP Virtual Router 1# addr 10.0.1.250/cfg/l3/vrrp/vr 2 (Virtual router for client)

>> VRRP Virtual Router 2# ena>> VRRP Virtual Router 2# vrid 2>> VRRP Virtual Router 2# if 2>> VRRP Virtual Router 2# addr 192.168.1.250/cfg/l3/vrrp/vr 3 (Virtual router for Interswitch Link)

>> VRRP Virtual Router 3# ena>> VRRP Virtual Router 3# vrid 3>> VRRP Virtual Router 3# if 3>> VRRP Virtual Router 3# addr 172.16.2.250

/cfg/l3/vrrp/on (Enable VRRP)>> Virtual Router Redundancy Protocol# hotstan ena(Enable hot-standby)

>> Virtual Router Redundancy Protocol# group ena (Enable VR group)

>> VRRP Virtual Router Group# apply (Make your changes active)

>> VRRP Virtual Router Group# save (Save for restore after reboot)


3. 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.

/cfg/l3/vrrp

>> VRRP Virtual Router Group# vrid 1>> VRRP Virtual Router Group# prio 101 (Set priority at 101 for Master switch)

>> VRRP Virtual Router Group# track/ports ena




4. Setup the peer switch to receive synchronization.

Make sure to disable synchronization of VRRP priorities; the peer switch will assume its own

priority based on the VRRP election process and should not acquire the VRRP priority from

the Master switch’s configuration. If you will be configuring real servers for VRRP hot-

standby, make sure to enable synchronization of real server configuration as well.

5. From the SLB menu, enable a hot-standby link on the Layer 4 ports; then enable inter-

switch link on the crosslink.

6. Apply and save changes to the configuration.

/cfg/slb/sync/prios d (Do not synchronize VRRP priorities

to the peer switch)

>> Peer Switch 1# /cfg/slb/synch/reals ena (Synchronize real server config to

the peer switch)

>> Config Synchronization# peer 1/ena (Enable the synch. peer switch)

>> Peer Switch 1# addr 172.16.2.252 (Set IP address of switch 1)

/cfg/slb/port INT2>> SLB port INT2# hotstan ena

>> SLB port INT2# /cfg/slb/port 3>> SLB port 3# intersw ena

>> SLB port 3# apply>> SLB port 3# save


Task 3: Prepare a Configuration Script for Switch 2

Use the following procedure to dump the configuration script (text dump) from Switch 1. This

configuration will be modified and loaded onto Switch 2.

1. Dump the switch configuration using the following command:


/cfg/dump





2. Copy and paste the entire contents of the script to a text file.

The first and last lines of the file should show the following:

3. Edit the text file 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.

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).

script start "Alteon Application Switch 2424" 4 /**** DO NOT EDITTHIS 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#

(Example from configuration script:)

/c/l3/if 1addr 10.0.1.252

(Example from configuration script:)/c/slb/sync/peer 1enaaddr 172.16.2.251


Change the virtual router priority from 100 to 101—this will indicate that switch 2 is the

backup for now.

4. Save the changes to the text file as <Customer-Name>_backup_config and load it onto a

TFTP server.

/c/l3/vrrp/group:prio 101




5. Begin a Telnet session for the second switch. Delete any existing configuration on it by

resetting it to factory settings, using the following command:

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 configuration process. When it does, respond: “No.”

6. From the CLI, download the configuration script into the switch from the TFTP server

using the following command:

Task 4: Synchronize Layer 4 Parameters form Switch 1 to Switch 2

1. On Switch 1, synchronize the VRRP, SLB, real server, and filter settings to the other

switch (same ports).

Switches peering with each other should have an equal number of ports.

2. On switch 2, apply and save the configuration changes.

/boot/conf factory/reset

/cfg/gtcfg <tftp-server-addr> <cfg-filename>

>> 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.252Confirm synchronizing the configuration to 172.16.2.252 [y/n]: y


Tracking Virtual Routers

Tracking configuration largely depends on user preferences and network environment. Con-

sider the configuration shown in Figure 16-5 “Non-Shared Active-Standby High-Availability

Configuration” on page 482. 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 bring-

ing 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 appli-

cation 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 configuring the switch for tracking as follows:

1. Set the priority for application switch 1 to the default value of 100.

2. Set the priority for application switch 2 to 96.

3. On both switches, enable tracking based on the number of virtual routers in master mode

on the switch and set the value = 5.

4. On both switches, enable tracking based on the number of healthy real servers behindthe 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 (Figure 16-5 on page 482) 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 1’s priority will be

reduced by 6 to 123. Since 123 is greater than 120 (application switch 2's priority), application

switch 1 will remain the master.

If a second server attached to application switch 1 fails, then application switch 1’s priority

will be reduced by 6 more to 117. Since 117 is less than 120 (application switch 2’s priority),

then application switch 2 will become the Master. At this point, application switch 1’s priority


will fall by 5 more and application switch 2’s will rise by 5 because the switches are tracking

how many masters they are running. So, application switch 1’s priority will settle out at 112

and application switch 2’s priority at 125.

When both servers are restored to application switch 1, that switch’s priority will rise by 12 (2

healthy real servers * 6 per healthy server) to 124. Since 124 is less than 125, applicationswitch 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 it’s now the master) while application switch 2’s priority will drop by 5 more to

114.

You can see from this example that the user’s goals were met by the configured tracking parameters.

NOTE – There is no shortcut to setting tracking parameters. The goals must first be set and the

outcomes of various configurations and scenarios analyzed to find settings that meet the goals.


Service-Based Virtual Router Groups

Service-based virtual router groups can be used for failover in either an active-active or active-

standby configuration.

In Figure 16-8, two customers are sharing the same VRRP switches configured in Active-

Standby configuration for VIP 1 and 2. Virtual routers 1, 2, 3, and 4 are defined on both

switches as follows:

Virtual routers 1 and 3 are virtual interface routers—they use the IP interface addresses.

Vi t l t 2 d 4 i t l i t th th i t l IP dd




Virtual routers 2 and 4 are virtual service routers—they 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.

Figure 16-8 Service-Based Virtual Router Groups—Active-Standby Configura-

tion

Configuration 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 VR’s

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.

Internet

Master for VIP 1(VIR1, VIR 2, VSR1)Backup for VIP 2

(VIR3, VIR 4, VSR2)

Active

Master for VIP 2(VIR3, VIR 4, VSR2)Backup for VIP 1(VIR1, VIR 2, VSR1)

Requests

to VIP 1

Requeststo VIP 1

VIP 1

VIP 2

VRGroup 1 (VR1, VR2)

VRGroup 2 (VR3, VR4)

Active


The separate real server groups provide segregation of services for each customer., so neither

customer’s traffic interferes with the others. To implement the active-standby example with

tracking of service-based virtual router groups, perform the following switch configuration


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 configure the IP interfaces for this example, enter

the following commands from the CLI:

>> Main# /cfg/l3/if 1 (Select IP interface 1)




Repeat the commands for the following interfaces:

IF 2: 205.178.13.2

IF 3: 200.200.200.3

IF 4: 205.178.13.4


Filters may be configured on one switch and synchronized with settings on the other switch.

g ( f )

>> IP Interface 1 # addr 200.200.200.1 (Assign IP address for the interface)



3. Configure all required SLB parameters on application switch 1.

Required Layer 4 parameters include 2 virtual server IP addresses, two groups and four real

servers.

>> Main# /cfg/slb/real 1/ (Configure real servers)

>> Real server 1# rip 10.10.10.101>> Real server 1# /cfg/slb/real 2/rip 10.10.10.102>> Real server 2# /cfg/slb/real 3/rip 10.10.10.103>> Real server 3# /cfg/slb/real 4/rip 10.10.10.104


l 1# dd 1 (Add l 1 1)






/cfg/slb/virt 1/vip 205.178.13.226 (Configure virtual server IP 1)

>> Virtual server 1# ena (Enable the virtual server)>> Virtual server 1# service http (Select the HTTP service port menu)


/cfg/slb/group 2



/cfg/slb/virt 1/vip 205.178.13.300

>> Virtual server 1# ena (Enable the virtual server)>> Virtual server 1# service http (Select the HTTP service menu)



4. Configure virtual interface routers 1 and 3, make sure to disable sharing.

These virtual routers are assigned the same IP address as the IP interfaces configured 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 configuration, which is disabled. For an active-standby config-

uration, sharing is disabled.

Main # /cfg/l3/vrrp/vr 1 (Select virtual router 1)

>> VRRP Virtual Router 1# vrid 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)




5. Configure 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 con-

figuration, sharing is disabled.

>> VRRP Virtual Router 1# share dis (Disable sharing of interfaces)

>> VRRP Virtual Router 1# ena (Enable virtual router 1)




















6. Add virtual routers 1 and 2 to the vrgroup 1.

7. Add virtual routers 3 and 4 to switch-based vrgroup 2.

>> Main# /cfg/l3/vrrp/vrgroup 1>> VRRP Virtual Router Vrgroup 1# add 1 (Add virtual router 1: the VIR)

>> VRRP Virtual Router Vrgroup 1# add 2 (Add virtual router 2: the VSR)

>> VRRP Virtual Router Vrgroup 1# ena

>> VRRP Virtual Router Vrgroup 1# track (Select the Priority Tracking Menu)>> VRRP Vrgroup 1 Priority Tracking# ports ena (Track on physical ports)




8. 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 configured in Step 6 and Step 7.

9. Synchronize the SLB and VRRP configurations from application switch 1 to application

switch 2.

Use the /oper/slb/sync command (see “Configuring VRRP Peers for Synchronization” on

page 511).

>> Main# >> Main# /cfg/l3/vrrp/vrgroup 2>> VRRP Virtual Router Vrgroup 2# add 3 (Add virtual router 1)

>> VRRP Virtual Router Vrgroup 2# add 4 (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)

Main # /cfg/slb/synch prios disable


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” on page 509

“Eliminating Loops with STP and VLANs” on page 509

“Assigning VRRP Virtual Router ID” on page 511

“Configuring VRRP Peers for Synchronization” on page 511




“Synchronizing Active/Active Failover” on page 512

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 vir-

tual routers in a LAN. Mixed configurations may result in unexpected operational characteris-

tics, and are not recommended.

Eliminating Loops with STP and VLANsVRRP active/active failover is significantly different from the hot-standby failover method

supported in previous releases. As shown in Figure 16-9, active-active configurations can

introduce loops into complex LAN topologies.

Figure 16-9 Loops in Active-Active Configuration

Internet

Router

RouterAlteon Application Switch


Server

Server

Bridging Loop


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 Figure 16-10. In this

example, a number of loops are wired into the topology. STP resolves loops by blocking ports

where looping is detected.Routers

Alteon ApplicationSwitches

Layer 2Switches Servers

Internet




Figure 16-10 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 traffic into non-looping broadcast domains. An example is shown in Figure 16-11:

Figure 16-11 Using VLANs to Create Non-Looping Topologies

This topology allows STP to be disabled. On the Alteon Application Switches, IP routing

allows traffic to cross VLAN boundaries. The servers use the Alteon Application Switches as

default gateways. For port failure, traffic is rerouted to the alternate path within one health

check interval (configurable between 1 and 60 seconds, with a default of 2 seconds).

is for switch-to-switch

and external routinggroups the first sub-switch with the AlteonWeb Switches

groups the secondsub- switch with theAlteon Web switches

VLAN 1

VLAN 2

VLAN 3

RoutersAlteon Application

SwitchesLayer 2

Switches Servers

Internet


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 configuring virtual routers at any point after

upgrade, virtual router ID numbers (/cfg/l3/vrrp/vr # /vrid) must be assigned. The vir-

tual router ID may be configured as any number between 1 and 255.

Configuring VRRP Peers for Synchronization

The final piece in configuring a high-availability solution includes the addition of synchroniza-

tion options to simplify the manual configuration Configuration options have been added to




tion options to simplify the manual configuration. Configuration options have been added to

refine what is synchronized, to whom, and to disable synchronizing certain configurations.

These options include proxy IP addresses, Layer 4 port configuration, filter configuration, andvirtual router priorities.

Also, a peer menu (cfg/slb/sync/peer) has been added to allow the user to configure 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

configured. As a result, configurations cannot be synchronized automatically.

For user convenience, it is possible to synchronize a configuration 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 configura-

tions, filter configurations, and VRRP parameters can be synchronized using the /oper/slb/

synch command.

NOTE – Before you synchronize the configuration between two switches, a peer must be con-

figured on each switch. Switches being synchronized must use the same administrator pass-

word.

Configure the two switches as peers to each other. From Switch 1, configure Switch 2 as a peer

and specify its IP address as follows:

>> Main # /cfg/slb/sync (Select the synchronization menu)

>> Config Synchronization # peer 1 (Select a peer)

>> Peer Switch 1 # addr < IP address> (Assign switch 2 IP address)

>> Peer Switch 1 # enable (Enable peer switch)


Similarly, from Switch 2, configure Switch 1 as a peer and specify its IP address as follows:

Port specific parameters, such as what filters 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 com-

mand is used, it is highly recommended that the hardware configurations and network connec-

tions of all switches in the virtual router be identical; that is, each switch should be the same

>> Main # /cfg/slb/sync (Select the synchronization menu)


>> Peer Switch 2 # addr < IP address> (Assign switch 1 IP address)





; ,

model, have the same line cards in the same slots (if modular) and have the same ports con-

nected to the same external network devices. Otherwise, unexpected results may occur when

the /oper/slb/synch command attempts to configure a non-existent port or applies an inap-

propriate configuration to a port.

Synchronizing Active/Active Failover

With VRRP and active/active failover, the primary and secondary switches do not require

identical configurations and port topology. Each switch can be configured individually with

different port topology, SLB, and filters. If you would rather force two active/active switchesto use identical settings, you can synchronize their configuration using the following com-

mand:.

The sync command copies the following settings to the switch at the specified IP interface

address:

VRRP settings (including priority)

SLB settings (including port settings)

Filter settings (including filter port settings)

Proxy IP settings

If you perform the sync command, you should check the configuration 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 synchro-

nized to) to a port other than port 80 before VRRP synchronization begins.

>> Main# /oper/slb/sync


Stateful Failover of Persistent Sessions

Alteon OS provides stateful failover of persistent session state. See Chapter 17, “Persistence”

for more information about the types of persistence supported.

Client IP

SSL session state

HTTP cookie state

Layer 4 persistent

FTP session state




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 configurations. 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 client’s 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 Figure 16-12. 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 eventsoccurs:

1. The backup switch becomes active.

2. The incoming request is redirected to the backup switch.




3. When the user clicks Submit again, the request is forwarded to the correct server.

Even though the master switch has failed, the stateful failover feature prevents the client fromhaving to re-establish a secure session. The server that stores the secure session now returns a

response to the client via the backup switch.

Figure 16-12 Stateful Failover Example when the Master Switch Fails

Stateful Failover Configuration Example

After the VRRP setup, perform the following additional steps to enable stateful failover on the

switches.

On the Master Switch

Router

Alteon Application SwitchMaster switch failed

10.1.1.1

Layer 2Switch

Servers

Alteon Application SwitchBackup switch Active

10.1.1.2

Internet

Traffic is redirectedto backup switch

Clients


1. Enable stateful failover.

2. Set the update interval.

3. Configure the backup switch as a peer and specify its IP address.

>> # /cfg/slb/sync/state ena

>> # /cfg/slb/sync/update 10 (The default is 30)

>> # /cfg/slb/sync





On the Backup Switch

1. Turn on stateful failover.

2. Set the update interval.

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. Configure the master switch as a peer and specify its IP address.


>> Peer Switch 1 # addr 10.1.1.2 (Assign backup switch IP address)


>> # /cfg/slb/sync/state ena

>> # /cfg/slb/sync/update 10 (The default is 30)

>> # /cfg/slb/sync


>> Peer Switch 2 # addr 10.1.1.1 (Assign master switch IP address)



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 com-

mand. The column on the far right displays the switch status.

If the switch is a master:

>> # /info/l3/vrrp (View VRRP Information)

VRRP information: 1: vrid 1, 172.21.16.187, if 4, renter, prio 109, master,server

3: vrid 3 192 168 1 30 if 2 renter prio 109 master




If the switch is a backup:

3: vrid 3, 192.168.1.30, if 2, renter, prio 109, master 5: vrid 5, 172.21.16.10, if 4, renter, prio 109, master

>> # /info/l3/vrrp (View VRRP Information)

VRRP information: 1: vrid 1, 172.21.16.187, if 1, renter, prio 104, backup,server 3: vrid 3, 192.168.1.30, if 3, renter, prio 104, backup

5: vrid 5, 172.21.16.10, if 1, renter, prio 104, backup

CHAPTER 17Persistence

The Alteon OS persistence feature ensures that all connections from a specific client session



315394-J, January 2005517

The Alteon OS persistence feature ensures that all connections from a specific client session

reach the same real server, even when Server Load Balancing (SLB) is used.


“Overview of Persistence” on page 518. This section gives an overview of persistence and

the different types of persistence methods implemented in Alteon OS.

“Cookie-Based Persistence” on page 522. The use of cookie persistence provides a mech-

anism 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” on page 520. This section explains

how both HTTP and HTTPS traffic map to the same server based on client IP.

“Server-Side Multi-Response Cookie Search” on page 534. This section explains how to

configure the switch to look through multiple HTTP responses from the server to achieve

cookie-based persistence.

“SSL Session ID-Based Persistence” on page 535. This section explains how an applica-

tion server and client communicate over an encrypted HTTP session.


Overview of Persistence

In a typical SLB environment, traffic comes from various client networks across the Internet to

the virtual server IP address on the Alteon Application Switch. The switch then load balances

this traffic 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 traffic is not load balanced mid-session to a different real server, forcing the user to



315394-J, January 2005518 Chapter 17: Persistence

, g

restart the entire transaction.

Persistence-based SLB enables the network administrator to configure the network to redirect

requests from a client to the same real server that initially handled the request. Persistence is an

important consideration for administrators of e-commerce Web sites, where a server may have

data associated with a specific user that is not dynamically shared with other servers at the site.

In Alteon OS, 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 identifier. There are two major conditions which cause problems when ses-

sion persistence is based on a packet’s IP source address:

Many clients sharing the same source IP address (proxied clients): Proxied clients

appear to the switch as a single source IP address and do not take advantage of SLB on the

switch. When many individual clients behind a firewall use the same proxied source IP

address, requests are directed to the same server, without the benefit of load balancing the

traffic across multiple servers. Persistence is supported without the capability of effec-

tively distributing traffic load.

Also, persistence is broken if you have multiple proxy servers behind the application

switch performing SLB. The application switch changes the client’s 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 specific server, the source IP address itself is ran-

domly 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 opera-

tion, 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 traffic

back to the same physical server to maintain session persistence.

Using SSL Session ID



315394-J, January 2005Chapter 17: Persistence 519

Using SSL Session ID

The SSL session ID is effective only when the server is running SSL transactions. Because ofthe heavy processing load required to maintain SSL connections most network configurations

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

Alteon OS 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 differ-

ent services (for HTTP and HTTPS traffic only) from the same client to map to the same

server, as long as the same group is configured for both services. In Alteon OS 22.0, when the

metric configured 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.

Configuring Client IP Address-Based Persistence

To configure client IP Address-based persistence for a real server, perform the following steps:

1. Configure real servers and services for basic SLB, as indicated below:

Define each real server and assign an IP address to each real server in the server pool.


Define 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 client processing on the port connected to the client.


page 181

2. If a proxy IP address is not configured on the client port, enable DAM for real servers.



3. Select Client IP-based persistence as the persistent binding option for the virtual port.

If multiple real server ports are configured for this service, you may choose whether to main-

tain persistence to the rport on the real server.

4. Enable client processing on the client port.

>> # /cfg/slb/virt 1/service <virtual port > pbind clientIP

Current persistent binding mode: disabledEnter clientip|cookie|sslid|disable persistence mode: clientIPUse Rport? (y/n) [y] y

>> # /cfg/slb/port < port number >/client ena





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 requireauthentication, 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

h i t d it t t I l li ti th ki b d d




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 identification number. Thecookie may contain the user’s preferences for a site that allows their pages to be customized.

Figure 17-1 Cookie-Based Persistence: How It Works

1. User registers to

buy an item

2. Switch completes 3-way

handshake with client.

Forwards HTTP request to

cookie server

4. Switch records or rewrites

cookie information based on

configuration

3. Web server designated to

serve cookies records informati

and sends the client a cookie

5. Cookie stored on client machine

6. Client decides to buy an item.

The cookie information is sent

as past of the HTTP request

7. Based on cookie information, the

switch redirects to the same server

or hashes on cookie value

Internet



The following topics discussing cookie-based persistence are detailed in this section:

“Permanent and Temporary Cookies” on page 523

“Cookie Formats” on page 523

“Cookie Properties” on page 524

“Client Browsers that Do Not Accept Cookies” on page 524

“Cookie Modes of Operation” on page 525

“Configuring Cookie-Based Persistence” on page 528

Permanent and Temporary Cookies




Permanent and Temporary Cookies

Cookies can either be permanent or temporary. A permanent cookie is stored on the client's

browser, as part of the response from a Web site’s 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 Ses-

sion-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.

Cookie Formats

A cookie can be defined in the HTTP header (the recommended method) or placed in the URL

for hashing. The cookie is defined as a “Name=Value” pair and can appear along with other

parameters and cookies. For example, the cookie “SessionID=1234” can be represented in

one of the following ways:

In the HTTP Header Cookie: SesssionID=1234

Cookie: ASP_SESSIONID=POIUHKJHLKHD

Cookie: name=john_smith

The second cookie represents an Active Server Page (ASP) session ID. The third cookie

represents an application-specific cookie that records the name of the client.

Within the URL

http://www.mysite.com/reservations/SessionID=1234


Cookie Properties

Cookies are configured on the application switch by defining the following properties:

Cookie names of up to 20 bytes

The offset of the cookie value within the cookie stringFor 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 defines the number of bytes to extract for the cookie value within a longer cookie




string.

Whether to find 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” on page 526), 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 configured to accept cookies. However, if a client

browser is not configured to accept cookies, you must use hash or pbind clientip (forclient 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 firewall will appear to be coming from the same source IP address. Therefore, the

requests will be directed to a single server, resulting in traffic being concentrated on a single

real server instead of load balanced across the available real servers.


Cookie Modes of Operation

Alteon OS 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:

Table 17-1 Comparison Among the Three Cookie Modes

Cookie Mode Configuration Required Cookie Location Uses Switch

Session Entry

Insert Cookie Switch only HTTP Header No

Passive Cookie Server and Switch HTTP Header or URL Yes




Insert Cookie Mode

In the insert cookie mode, the application switch generates the cookie value on behalf of the

server. Because no cookies are configured at the server, the need to install cookie server soft-

ware on each real server is eliminated.

An inserted cookie has a value of 20 bytes, containing an 8 byte VIP value, an 8 byte RIPvalue, 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 appli-

cation switch inserts a cookie and forwards the new request with the cookie to the client.

Figure 17-2 Insert Cookie Mode

Rewrite Cookie Server and Switch HTTP Header No

Internet

1. Configure switch to insert cookie values

Web ServerFarm

Client Alteon Application

SwitchProxy Firewall

2. Client visits the Web site via HTTP request3. Alteon Application Switch

selects server via SLB

4. Server responds

without any cookie5. Alteon Application switch inserts a cookie and

forwards the request to the client.


Passive Cookie Mode

In Passive Cookie mode, when the client first makes a request, the switch selects the server

based on the configured 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 figure shows passive cookie mode operation:

Figure 17-3 Passive Cookie Mode

Subsequent requests from Client 1 with the same cookie value will be sent to the same real

server (RIP 1 in this example).

Internet

1. Configure server to send cookies

2. Configure switch to record cookie values

Web ServerFarm



3. Client visits the web site.4. Switch selects

cookie server.

5. Server returns

cookie value.

6. Alteon Application Switch registers cookie value

and forwards it to the client for use in subsequent

requests.


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 configured to return a special persistence cookie which the switch is con-

figured to recognize. The switch then intercepts this persistence cookie and rewrites the valueto include server-specific 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 Bal-

ancing (GSLB).




NOTE – Rewrite cookie mode only works for cookies defined in the HTTP header, not cookies

defined in the URL.

Example: The following figure shows rewrite cookie mode operation:

Figure 17-4 Rewrite Cookie Mode

NOTE – When the application switch rewrites the value of the cookie, the rewritten value rep-

resents the responding server; that is, the value can be used for hashing into a real server ID orit can be the real server IP address. The rewritten cookie value is encoded.

Internet

1. Configure switch to rewrite cookie values

Web Server

Farm



5. Alteon Application Switch rewrites the cookie to

contain a server ID for hashing on subsequent

requests

4. Server HTTP response

includes empty cookie

3. Alteon Application Switch

selects server via SLB2. Client visits the Web site via HTTP request


Configuring Cookie-Based Persistence

1. Before you can configure cookie-based persistence, you need to configure the switch for

basic SLB. This includes the following tasks:



Configure each real server with its IP address, name, weight, and so forth.



For information see “Server Load Balancing” on page 181.

2 Either enable Direct Access Mode (DAM) or disable DAM and specify proxy IP




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.

Disable DAM and specify proxy IP address(es) on the client port(s).

NOTE – If Virtual Matrix Architecture (VMA) is enabled on the switch, you must configure 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/adv/direct ena (Enable Direct Access Mode on switch)

>> # /cfg/slb/adv/direct disable (Disable DAM on the switch)

>> # /cfg/slb/port 1 (Select network port 1)

>> # pip 200.200.200.68 (Set proxy IP address for port 1)

>> # /cfg/slb/port 1 (Select switch port 1)

>> # server dis (Disable server processing on port 1)


4. Select the appropriate load-balancing metric for the real server group.

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 con-

junction with a cookie assignment server.

While you may experience traffic concentration using the hash metric with a cookie

assignment server, using a hash metric without a cookie assignment server will cause

traffic concentration on your real servers.

>> # /cfg/slb/group 2/metric hash (Select hash as server group metric)




5. Enable cookie-based persistence on the virtual server service.

In this example, cookie-based persistence is enabled for service 80 (HTTP).

Once you specify cookie as the mode of persistence, you will be prompted for the following

parameters:

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.

Setting Expiration Timer for Insert Cookie

If you configure for insert cookie persistence mode, then you will be prompted for cookie expi-

ration timer. The expiration timer specifies a date string that defines the valid life time of that

cookie. The expiration timer for insert cookie can be of the following types:

>> # /cfg/slb/virt 1/service 80/pbindCurrent persistent binding mode: disabledEnter clientip|cookie|sslid|disable persistence mode: cookie

Enter insert|passive|rewrite cookie persistence mode [i/p/r]: pEnter cookie name: CookieSession1Enter starting point of cookie value [1-64]: 1Enter number of bytes to extract [0-64]: 8Look for cookie in URI [e|d]: d


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,

Relative timer

Enter cookie expiration: 12/31/04@11:59Current persistent binding for http: disabledNew persistent binding for http: cookieNew cookie persistence mode: insertInserted cookie expires on Mon 12/31/04 at 11:59




This timer defines the elapsed time from when the cookie was created. The syntax for the rela-

tive timer is days[:hours[:minutes]]. For example,

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 specified, the cookie will expire when the user's

session ends.

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: www.nortelnetworks.com

Cookie: UID=87654321

Look for the cookie in the HTTP header

Enter cookie expiration: 32:25:61Current persistent binding for http: disabledNew persistent binding for http: cookieNew cookie persistence mode: insertInserted cookie expires after 33 days 2 hours 1 minutes

>> # /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

The last “Look for cookie in URI?” parameter is set to enable. Therefore the application

switch will use UID=12345678 as the cookie.

>> # /cfg/slb/virt 1/service 80/pbind cookie passive UID 1 8 ena





Example 2: Parsing the Cookie

This example shows three configurations 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 defined as follows:

Cookie: sid=0123456789abcdef; name1=value1;...

Select the entire value 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 first byte in the

value and using the full 16 bytes.

>> # /cfg/slb/virt 1/service 80/pbind cookie passive sid 1 16 dis




Select a specific 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:

With this configuration, the switch will look for a cookie name that starts with ASPSES-

SIONID. ASPSESSIONID123, ASPSESSIONID456, and ASPSESSIONID789 will

all be seen by the switch as the same cookie name. If more than one cookie matches, only

the first one will be used.

Example 3: Using Passive Cookie Mode

If you are using passive cookie mode, the application switch examines the server’s 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 traf-

fic from a particular client with cookie sid=12345678 will be directed to Server 1.

The following command is used on the application switch:

Example 4: Using Rewrite Cookie Mode


>> # /cfg/slb/virt 1/service 80/pbind cookie passive ASPSESSIONID* 1 16 dis



Rewrite server cookie with the encrypted real server IP address:

In cookie rewrite mode, if the cookie length parameter is configured to be eight bytes, the

switch will rewrite the placeholder cookie value with the encrypted real server IP address.

If the server is configured to include a placeholder cookie, such as follows:

Set-Cookie: sid=alteonpersistence;

then the application switch will rewrite the first eight bytes of the cookie to include the

server’s encrypted IP address:

Set-Cookie: sid=cdb20f04rsistence;

>> # /cfg/slb/virt 1/service 80/pbind cookie rewrite sid 1 8 dis




All subsequent traffic from a specific client with this cookie will be directed to the samereal server.

Rewrite server cookie with the encrypted real server IP address and virtual server IP

address:

If the cookie length is configured to be 16 bytes, the switch will rewrite the cookie value

with the encrypted real server IP address and virtual server IP address.

If the server is configured to include a placeholder cookie, as follows:

Set-Cookie: sid=alteonwebcookies;

then the application switch will rewrite the first 16 bytes of the cookie to include the

encrypted real server IP address and virtual server IP address:

Set-Cookie: sid=cdb20f04cdb20f0a;

All subsequent traffic from a specific client to the particular virtual server IP address with

this cookie will be directed to the same real server.

>> # /cfg/slb/virt 1/service 80/pbind cookie rewrite sid 1 16 dis


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 Alteon switch looks through the first HTTP response from the server. While

this approach works for most servers, some customers with complex server configurations

might send the persistence cookie a few responses later. In order to achieve cookie-based per-

sistence in such cases, Alteon OS allows the network administrator to configure the switch to

search through multiple HTTP responses from the server.

In Alteon OS, 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.




Configuring Server-Side Multi-Response Cookie Search

Configure the server-side multi-response cookie search by using the following command:

>> # /cfg/slb/virt <virtual server>/service <virtual port number>/rcountCurrent Cookie search response count:Enter new Cookie search response count [1-16]:


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 connec-

tions 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 mecha-

i h th li t IP dd h t d ll i t th l




nism, 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 hand-

shake. 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 break-

ing the SSL ID persistence. To resolve this issue, use persistency with metric hash or pbindclientip.

NOTE – The destination port number to monitor for SSL traffic is user-configurable.

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 met-

ric 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 configured server time-

out (a default of 10 minutes) for the selected real server has expired.


Figure 17-5 illustrates persistence based on SSL session ID as follows:

1. An SSL Hello handshake occurs between Client 1 and Server 1 via the application switch.

2. An SSL session ID is assigned to Client 1 by Server 1.

3. The application switch records the SSL session ID.

4. The application switch selects a real server based on the existing SLB settings.

As a result, subsequent connections from Client 1 with the same SSL session ID are directed to

Server 1.

Web ServerFarm




Figure 17-5 SSL Session ID-Based Persistence

5. Client 2 appears to the switch to have the same source IP address as Client 1 because they

share the same proxy firewall.

However, the application switch does not automatically direct Client 2 traffic to Server 1 based

on the source IP address. Instead an SSL session ID for the new traffic is assigned. Based on

SLB settings, the connection from Client 2 is spliced to Server 3.

As a result, subsequent connections from Client 2 with the same SSL session ID are directed to

Server 3.

InternetClient 1

Client 2

FirewallAlteon Application

Switch


Configuring SSL Session ID-Based Persistence

To configure session ID-based persistence for a real server, perform the following steps:

1. Configure real servers and services for basic SLB, as indicated below:

Define each real server and assign an IP address to each real server in the server pool.


Define a virtual server on the virtual port for HTTPS (for example, port 443) and assign a

real server group to service it.


Enable client processing on the port connected to the client.

For information on how to configure your network for SLB see “Server Load Balancing” on




For information on how to configure your network for SLB, see Server Load Balancing on

page 181.

2. If a proxy IP address is not configured on the client port, enable DAM for real servers.

3. Select session ID-based persistence as the persistent binding option for the virtual port.

4. Enable client processing on the client port.


>> # /cfg/slb/virt <virtual server number>/service <virtual port > pbind sslid

>> # /cfg/slb/port < port number >/client ena





CHAPTER 18Advanced Denial of ServiceProtection

This chapter describes the Advanced Denial of Service protection features in Alteon OS that

can be used to prevent a wide range of network attacks The features described in this chapter



315394-J, January 2005539

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 pur-

chased 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” on page 540 describes the rationale for providing Advanced Denial of Ser-

vice protection and how the features can assist traditional firewalls in preventing mali-

cious network attacks.

“IP Address Access Control Lists” on page 542. Describes how to setup blocking of large

ranges of IP addresses.

“Protection Against Common Denial of Service Attacks” on page 544: This section

explains how to prevent common denial of service (DOS) attacks from entering switch

ports that are connected to unsafe networks.

“Protocol-Based Rate Limiting” on page 548: This section explains how to monitor and

limit incoming UDP, ICMP or TCP traffic within a configurable time window.

“Protection Against UDP Blast Attacks” on page 555. This section describes how to mon-

itor and limit traffic on UDP ports to a maximum number of connections per second.

“TCP or UDP Pattern Matching” on page 556. 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 filter to deny traffic containing those patterns.


Background

The Advanced Denial of Service Protection feature set extends the functionality of the Alteon

Application Switch to act as an application-intelligent firewall. An administrator can use the

features described in this chapter to configure the Alteon Application Switch to perform deep

inspection and blocking of malicious content. For example, many newer viruses, worms, mali-

cious code, buggy applications, and cyber-attacks have targeted application and protocol

weaknesses by tunneling through the firewall over HTTP port 80, or by encapsulating attacks

into SSL tunnels. Such packets can pass undetected through standard network firewalls, which

are configured only to open or close access to HTTP port 80. Many of the attacks (such as

nullscan, xmascan, scan SYNFIN) are created with purposely malformed packets that include

illegal fields in the IP headers.



315394-J, January 2005540 Chapter 18: Advanced Denial of Service Protection

Security Inspection Workflow

A typical workflow of the application switch to handle security inspection is described below.

1. The Alteon Application Switch is configured with a predefined set of rules. To increase the

performance of the inspection, complex pattern inspection rules can be defined with an offset

value so that the inspection engine can go directly to the location to be inspected. A virus pat-

tern often is a combination of multiple patterns within the IP payload. The application switch

can be configured to inspect multiple patterns and locate them at different offsets within the

payload.

2. Packets enter the Alteon Application Switch.

3. The Alteon 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 ses-

sion 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 Alteon Application Switch can use its inspection engine to provide rate limiting capabilityto complex protocols such as those used in the Peer to Peer programs that use dynamic ports to

establish communication between clients. Standard firewalls are unable to detect these pro-

grams, 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” on page

556.


The Alteon Application Switch can also rate limit the amount of the total traffic generated by

these programs. This is especially useful in Cable ISP and universities where Peer to Peer pro-

grams can reach as much as 70% of the total traffic. For more information, see “Protocol-

Based Rate Limiting” on page 548.



315394-J, January 2005Chapter 18: Advanced Denial of Service Protection 541


IP Address Access Control Lists

Alteon OS can be configured with IP access control lists (ACLs) composed of ranges of client

IP addresses that are to be denied access to the switch. When traffic ingresses the switch, the

client source IP address is checked against this pool of addresses. If a match is found, then the

client traffic is blocked.

ACLs vs. Filters

Access control lists (ACLs) are used to control which IP addresses are allowed access to a net-

work. Unlike a filter, the ACL feature in Alteon OS can only perform a deny action. The deci-

sion about whether to deny traffic 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 con-

figure a pool of up to 5000 blockable IP addresses.




g p p

While filters 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 traffic

before determining whether to allow, deny, or redirect traffic.

How it works

The IP ACL feature uses a hash table to effectively block a configured 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 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.


Configuring Blocking with IP Access Control Lists

1. Add IP addresses that you wish to block.

The following example will block addresses 192.168.40.0-255.

2. Repeat step 1 to configure any other IP addresses that should be dropped.

3. Enable IP ACL processing on the ingress port.

>> /cfg/security/ipacl (Select the IP ACL menu)

>> IP ACL# add 192.168.40.0 (Enter a network address)

Enter subnet mask: 255.255.255.0 (Enter the appropriate mask)

>> Main# /cfg/security/port <x>/ipacl ena (Enable IP ACL)

Current IP ACL processing: disabledNew IP ACL processing: enabled





Viewing IP ACL statistics

You can view the accumulated blocked packets for each IP address /mask pair by entering thefollowing command:

New IP ACL processing: enabled

>> /stats/security/ipacl/dump (Dump IP ACL statistics)

Address Blocked Packets--------------- ---------------192.168.40.1 3049

192.168.40.12 9702192.168.40.65 563


Protection Against Common Denial of

Service Attacks

Alteon OS can protect switch ports against a variety of Denial of Service (DOS) attacks includ-

ing Port Smurf, LandAttack, Fraggle, Blat, Nullscan, Xmascan, PortZero, and Scan SynFin.Enable DOS protection on any ports connected to unsafe networks.

Configuring 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 sup-

ported types of DOS attack.

1 A l DOS t ti th t




1. Apply DOS protection on the ports.

2. Repeat Step 1 to apply DOS protection to any other ports.


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 specific port.

When an attack is detected, the switch will generate a message such as:

>> Main# /cfg/security/port 1/dos ena (Enable DOS protection on this port)

Current DOS attack detection: disabledNew DOS attack detection: enabled

Jun 18 22:33:32 ALERT security: DoS Attack:Fragglesip:192.115.106.200 dip:192.115.106.255 ingress port:1


The following command shows DOS statistics on all ports where DOS protection is enabled:

Viewing DOS statistics per port

>> /stats/security/dos/dump------------------------------------------------------------------Port 1:Smurf: 0 LandAttack: 0 Fraggle: 107Nullscan: 0 Xmascan: 0 ScanSynFin: 0PortZero: 0 Blat: 0------------------------------------------------------------------Port 2:Smurf: 0 LandAttack: 0 Fraggle: 0Nullscan: 0 Xmascan: 0 ScanSynFin: 0PortZero: 0 Blat: 0




The following command displays DOS protection statistics only on the specified port:

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.

Once DOS protection is enabled on the appropriate ports on the Alteon Application Switch, the

switch performs the following checks on incoming 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 filter,

and drop any matching packet.

Affected protocol: ICMP

LandAttack:

>> /stats/security/dos/port 1Port 1:Smurf: 0 LandAttack: 0 Fraggle: 107Nullscan: 0 Xmascan: 0 ScanSynFin: 0PortZero: 0 Blat: 0

>> /stats/security/dos help


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.

Affected protocols: TCP/UDP/ICMP

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: Configure “UDP and ICMP Rate Limiting” on page 549.

Affected protocol: UDP




p

NULLscan:

Description: TCP sequence number is zero and all control bits are zeroes.

Switch action: Check for every packet before filter or client processing, and drop any

matching packet.

Affected protocols: TCP

Xmascan:

Description: Sequence number is zero and the FIN, URG, and PSH bits are set.

Switch action: Check every packet before filter or client processing, and drop any match-

ing packet.

Affected protocol: TCP

Scan SYNFIN:

Description: SYN and FIN bits set in the packet.

Switch action: Check every packet before filter or client processing and drop any match-

ing packet.

Affected protocol: TCP


PortZero

Description: The attacker sends TCP or UDP packets whose destination port (dport)

is zero.

Switch action: Check every TCP or UDP packet with dport=0 and drop any matching

packets.

Affected protocols: TCP and UDP

Blat

Description: Packets with source IP (sip) not equal to destination IP (dip), but source port

(sport) equals destination port (dport).

Switch action: The switch checks for , anddrops any matching packets.

sourceIP dest inat ionIP spor t dport =




Affected protocols: TCP, UDP, and ICMP.

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: Configure “A Rate Limiting Filter to Thwart Ping Flooding” on page 554 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 overflows in the server’s input buffer, and can cause

a system to crash, hang, or reboot.

User action: Configure “Matching and Denying Large Packets—ICMP Ping of Death

Example” on page 562.


Protocol-Based Rate Limiting

Alteon OS allows you to detect and block certain kinds of protocol-based attacks. These

attacks can flood servers with enough traffic to severely affect their performance or bring them

down altogether. Protocol-based rate limiting is implemented via filters. Alteon OS currently

supports rate limiting on TCP, UDP and ICMP protocols. Each filter is configured with one ofthe 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” on page

549 for more information.

UDP and ICMP Rate limiting: counts all received packets from a client and compares




against the configured maximum threshold. When the maximum configured threshold has

been reached before the time window expires, the switch will drop until the configured

hold-down period expires. See “UDP and ICMP Rate Limiting” on page 549 for more

information.

Time Windows and Rate LimitsA time window is a configured period of time (in seconds) during which packets are allowed to

be received. A rate limit is defined 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 configured time window.


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 configured 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 specified number of minutes, after which new TCP connectionrequests or packets from the client are allowed once again to pass through.

NOTE – The time window and hold duration can be configured individually on a per-filter

basis.

UDP and ICMP Rate LimitingAlteon OS filters can be config red to perform rate limiting on UDP and ICMP traffic




Alteon OS filters can be configured to perform rate limiting on UDP and ICMP traffic.

Because UDP and ICMP are stateless protocols, the maximum threshold (the maxcon com-

mand) should be interpreted as the maximum number of packets received from a particular cli-

ent IP address.

When the maximum threshold has been reached before the time window has expired, all pack-

ets of the configured protocol will be dropped until the configured hold down (holddur) period has expired.

TCP Rate Limiting

The switch monitors new TCP connections by looking for incoming SYN packets that match a

specified TCP rate filter. The first SYN packet to match the filter creates a TCP Rate session in

the session table. Subsequent SYN packets from the same client that match the same filterincrement 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 filter are allowed. Once the hold down

period ends, the next SYN packet is allowed, and a new TCP Rate session is created.

Figure 18-1 on page 550 shows four clients configured 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 connec-

tions per second.

When the rate of new TCP connections from clients 1, 2, 3, and 4 reach the configured thresh-

old, any new connection request from the client is blocked for a pre-determined amount of

time. If the client’s IP address and the configured filter do not match, then the default filter is

applied.


In Figure 18-1, the default filter 2048 configured for Any is applied for all other connection

requests.

Internet

Real serversClients

1

2

3

4Filter 10: 10 conn/sec

Filter 20: 20 conn/secFilter 30: 30 conn/sec

Filt 2048 All A

Client 1 limit: 10 conn/sec

Client 2 limit: 20 conn/secClient 3 limit: 30 conn/sec

Client 4 limit: 10 conn/sec

AlteonApplication

Switch




Figure 18-1 Configuring Clients with Different Rates

Configuring Protocol-Based Rate Limiting Filters

Rate limiting filters are supported on TCP, UDP or ICMP protocols only. Protocol-based rate

limiting can be configured for all filter types (allow, deny, redir, SIP , and DIP) and parame-

ters. Specify the source IP address and mask options in the filter configuration menu to moni-

tor 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 configuration. To

specify a rate limiting filter for TCP, UDP, or ICMP, simply set the protocol on the filter itself,then go into the Filtering Advanced menu to set the rate limiting parameters.

Filter 2048: Allow Any


A Basic Rate Limiting Filter

The following example shows how to configure rate limiting for Filter 10 in Figure 18-1.

1. Set the protocol used for the rate limiting filter.

Only UDP, ICMP, and TCP protocols are supported for rate limiting.

2. Enable rate limiting for the filter.

3. Configure maximum number of connections.

>> Main# /cfg/slb/filt 10 (Select the filter 10 menu)

>> Filter 10 # proto <any|<number>|<name>> (Specify TCP, UDP or ICMP protocol)

>> # /cfg/slb/filt 10/adv/security/ratelim/ena(Enable rate limiting)

>> 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.

NOTE – From Step 3 and Step 4 the rate limit defined as the maximum number of connections

over a specified time window is 30 TCP connections for every 3 seconds (or 10 TCP connec-

tions per second).

5. Set the holddur parameter in minutes.

If a client exceeds the rate limit, then the client is not allowed to make any new TCP connec-

tions or UDP/ICMP packets for 4 minutes. The following two configuration examples illus-

trate how to use protocol-based rate limiting to limit user access based on source IP address

and virtual IP address.

6. Repeat steps 1-5 to configure the other filters shown in Figure 18-1 on page 550.


>> Rate Limiting Advanced# maxconn 3 (Specify in units of 10)

>> Rate Limiting Advanced# timewin 3 (Denotes a 3-second time window)

>> Rate Limiting Advanced# holddur 4 (Set the hold duration)


A Rate Limiting Filter Based on Source IP Address

This example shows how to define a filter 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.

1. Configure the filter as follows.

>> # /cfg/slb/filt 100/ena (Enable the filter)>> Filter 100 # sip 30.30.30.0 (Specify the source IP address)

>> Filter 100 # smask 255.255.255.0 (Specify the source IP address mask)


>> Filter 100 # adv/security/ratelim (Select the Rate Limiting Adv. menu)

>> Rate Limiting # ena (Enable rate limiting on TCP)

>> Rate Limiting # maxconn 15 (Specify the maximum connections

in multiples of 10)

>> Rate Limiting # timewin 1 (Set the time window in seconds)

>> Rate Limiting # holddur 10 (Set the hold duration in minutes)




Time window = 1 second

Hold duration = 10 minutes

Max rate = maxconn/timewin = 150 connections/1 second = 150 connections/second


Any client with source IP address equal to 30.30.30.x is allowed to make 150 new TCP con-

nections (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 con-

nections to the same destination for 10 minutes.


A Rate Limiting Filter Based on Virtual Server IP Address

This example defines a filter that limits clients to 100 TCP connections per second or 100 UDP

or ICMP sessions per second to a specific destination (VIP 10.10.10.100). Once a client

exceeds that limit, the client is not allowed to initiate new TCP connection requests or send

UDP or ICMP traffic to that destination for 40 minutes. Figure 18-2 shows how to use this fea-

ture to limit client access to a specific destination.

Internet

Real serversClients

1

2

3

Client 1, 2, 3, and 4 are limited

to 100 conn/sec to virtual IP addressS1

Alteon Application

Switch




Figure 18-2 Limiting User Access to Server

1. Configure the following on the switch:

time window = 2 seconds

hold down time = 40 minutes max rate = maxconn/time window = 100 connections/second

200 connections/2 seconds = 100 connections/second

This configuration limits all clients to 100 new TCP (or UDP/ICMP packets) per second to the

server. If a client exceeds this rate, then the client is not allowed transmit sessions or connec-

tions to the virtual server for 40 minutes.

>> # /cfg/slb/filt 100/ena (Enable the filter)

>> Filter 100 # dip 10.10.10.100>> Filter 100 # dmask 255.255.255.255


>> Filter 100 # adv/security (Select the Security menu)

>> Security# ratelim ena (Enable rate limiting)

>> Security# maxconn 20 (Specify the maximum connections in

multiples of 10)

>> Security# timewin 2 (Set the time window for the session)

>> Security# holddur 40 (Set the hold duration for the session)

4

Filter 100: 100 conn/sec

VIP: 10.10.10.100

S2


2. Add the filter to the ingress port on the switch.


A Rate Limiting Filter to Thwart Ping Flooding

This example shows how to define a filter that limits the amount of ICMP pings to any destina-

tion behind the application switch. A ping flood attempts to overwhelm servers with ping

packets, thus removing it from service while it attempts to reply to every ping.

1. Configure the following filter on the switch.

>> Rate Limiting # /cfg/slb/port 2/filt ena/add 100

>> # /cfg/slb/filt 30/ena>> Filter 30 # proto icmp (Specify ICMP protocol)

>> Filter 30 # action allow (Allow ICMP traffic)





2. Add the filter to the ingress port on the switch.



>> Security# ratelim ena (Enable rate limiting)

>> Security# maxcon 10 (Specify the maximum connections in

multiples of 10)

>> Rate Limiting # /cfg/slb/port 2 (Select the appropriate ingress port)


Current port 2 filtering: disabledNew port 2 filtering: enabled>> SLB port 2# add 30 (Add the rate limit filter to the port)

Filter 30 added to port 2.


Protection Against UDP Blast Attacks

Malicious attacks over UDP protocol ports are becoming a common way to bring down real

servers. Alteon OS can be configured to restrict the amount of traffic allowed on any UDP

port, thus ensuring that backend servers are not flooded 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 traffic is shut down on those

ports.

Configuring UDP Blast Protection

1. Configure the UDP port numbers or ranges of UDP ports that you want to protect

against UDP attacks.

For example, configure UDP ports 1001-2000 @ 1000pps, UDP ports 2001-4000 @2000pps,




p , g p @ pp , p @ pp ,

and UDP ports 4001-6000 @5000pps.

Alteon OS 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 net-

works


>> /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-2000Enter max packet rate per second (1 to 20000000): 1000

>> UDP Blast Protection# addEnter UDP port number (1 to 65535) or range (first-last): 2001-4000Enter max packet rate per second (1 to 20000000): 2000

>> UDP Blast Protection# addEnter UDP port number (1 to 65535) or range (first-last): 4001-6000

Enter max packet rate per second (1 to 20000000): 5000

/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 configured with one

or more filters that scan the first IP packet, and drop if it finds one or all of the configured pat-

terns. If no match is found, the packets will be allowed through.

Pattern matching is constructed much in the same way as any other filter configured to exam-

ine Layer 7 content, such as “Deny Filter Based on Layer 7 Content Lookup” on page 363.

NOTE – The ability to match and perform filter action on a pattern or group of patterns is avail-

able 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 configured to examine an IP packet from either the beginning, from a specific

offset value (starting point) within the IP packet, and/or from a specified depth (number of

characters) into the IP packet. It then performs a matching operation.

Figure 18-3 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 patterndata, see “Regular Expression Matching” on page 722.

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 com-

pare operation is performed. If no offset value is configured, the offset value is assumed to be

zero (0) and the packet is examined from the first byte of the IP packet.

For example, if an offset of 12 is specified, 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.

IP Header

Version Length Service Type Total Length

Identification Flags Fragment Offset

Time to Live Protocol Header Checksum

Source IP AddressIP payload

Each row is 4 bytes long.

Pattern matching examines

from the beginning of the IP

payload portion of the packet.




Figure 18-3 IP Packet Format

Depth

Depth is the number of bytes in the IP packet that should be examined from either the begin-ning of the packet or from the offset value. For example, if an offset of 12 and a depth of 8 is

specified, the search begin at the 13th byte in the IP packet, and will match 8 bytes. As we can

see from Figure 18-3, an offset of 12 and depth of 8 encompasses the Source IP Address and

Destination IP Address fields in the IP payload.

If no depth is specified, then the exact pattern will be matched from the offset value, to the end

of the pattern.

Source IP Address

Destination IP Address

IP Options (optional) Padding

Data

IP payload


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 find values lt (less than), gt (greater than) or eq (equals) to thespecified binary value. If no operation is specified, 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:

Matching Groups of Patterns

>> /cfg/slb/layer7/slb/addstr




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 filter, the switch will match any of the strings or patterns within that group

before denying and dropping the packet. Up to five patterns can be combined into a single pat-

tern group. Configure the binary or ascii pattern strings, group them into a pattern group, name

the pattern group, and then apply the group to a filter.

The filtering commands allow the administrator to define groups of patterns and place them

into groups. By applying the patterns and groups to a deny filter, the packet content can be

detected and thus denied access to the network.

NOTE – The pattern group matching feature is available only if you have purchased andenabled the Advanced Denial of Service Protection software key.


Matching and Denying a UDP Pattern Group

1. Configure 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/addstrEnter 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]: patternEnter match pattern type [ascii|binary]: ascii (Select ascii matching)

Enter ASCII string: /default.htm (Match this ascii string)

E t ff t i b t f t t f IP f (0 1500) 44 (S h f 45th b t )







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 SLB String

1 ida

2 %c1%9c

3 %c0%af

4 playdog.com



8 BINMATCH=014F, offset=2, depth=0, op=eq, cont 256

9 STRMATCH=/default.htm offset=44, depth=30, op=eq, cont 256




If the incoming client requests enter the switch on port 3, then add this filter to port 3.


Matching All Patterns in a Group

The switch is capable of matching on all patterns in a pattern group before the filter denies a

packet. Use the matchall command to instruct the filter to match all patterns in the group

before performing the deny action.

NOTE – The matchall command is configurable only for binary or ascii patterns added to pat-

tern groups (pgroup). It does not apply to l7lkup filter strings configured with the /cfg/slb/layer7/slb/addstr command.


>> SLB Port 3# filt ena (Enable filtering on the client port)

>> SLB Port 3# add 90 (Add Filter #90 to the client port)




1. Use the base configuration in “Matching and Denying a UDP Pattern Group” on page

559.

2. In the Filter menu, enable the matching of all criteria.

Now, both patterns configured in the above example must be matched before a packet is

denied and dropped:


>> /cfg/slb/filt 90/adv/security/matchall ena(Enable matching all criteria)

Current Match-all Criteria: disabledNew Match-all Criteria: enabled




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 overflows in the server’s input buffer, and can cause a system to crash, hang, or

reboot.

Large ICMP packets, such as in an ICMP ping of death attack, can be blocked using a deny fil-

ter combined with binary patterns used to filter non-zero IP offsets or More-Fragment bits sent

in the IP flags.

An IP packet is determined to be an IP fragment if:

(a) the 13-bit fragment offset field in the IP header is non-zero, or

(b) the More Fragments bit in the 3-bit flags field in the IP header is set.

The flags field begins at the 7th byte of the IP packet, and the fragment offset is right after this

field. The two fields 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 configuration is similar to the examples in “Matching and Denying a UDP Pat-

tern Group” on page 559 and “Matching All Patterns in a Group” on page 561.

1. Create an SLB string pattern that filters non-zero IP offsets. Enter the value in Hexadec-

imal notation.

2. Create another SLB string pattern that filters More Fragments.

>> /cfg/slb/layer7/slb/addstrEnter type of string [l7lkup|pattern]: pattern (Add the pattern)


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)

>> Server Loadbalance Resource# addEnter type of string [l7lkup|pattern]: pattern (Add the pattern)


Enter HEX string: 4000 (More-Fragments bit set)Enter offset in bytes from start of IP frame (0-1500): 6 (Search from 7th byte)

Enter depth in bytes to search from offset (0-1500): 0 (Through end of pattern)

Enter operation (eq|gt|lt): lt (For values less than 4000)


3. Apply the new configuration.

4. Identify the IDs of the defined patterns.



>> Server Loadbalance Resource# apply


ID SLB String

1 ida

2 %c1%9c3 %c0%af

4 playdog.com

6 HTTPHDR:Host:www playdog com




5. In the security menu, configure a pattern group and name it something relevant and easy

to remember.

6. Add the defined patterns to the pattern group.

7. Configure a filter and its appropriate protocol in which the patterns are found; in this

case, icmp protocol should be specified.





10 BINMATCH=0000, offset=6, depth=0, op=gt, cont 256

11 BINMATCH=4000, offset=6, depth=0, op=lt, cont 256

>> /cfg/security/pgroup 2/name

Current pattern group name:Enter new pattern group name: pingofdeath (Enter name for pattern group 2)

>> Pattern Match Group 2# add 10>> Pattern Match Group 2# add 11

>> /cfg/slb/filt 190 (Go to the Filter 90 menu)

>> Filter 190 # proto icmp


8. Set the filter action to deny.

9. Set the ICMP message type.Ping of Death uses the ICMP message type echoreq.

10. Apply the pattern group you configured in Step 5 and Step 6 to the filter.


Current action: nonePending new action: deny

>> Filter 190 # adv/icmp>> Filter 190 Advanced# icmpCurrent ICMP message type: anyEnter ICMP message type or any: echoreq (Set ICMP message type)

>> Filter 190 # security/addgrp 2 (Add pattern group 2 to the filter)

Group ID 2 added.




11. Enable pattern matching on the filter.

12. Enable matchall criteria so that the filter matches on all patterns in the pattern group.

13. Apply the filter to the client port.

This example assumes a client connection on port 22.


>> /cfg/slb/filt 190/adv/security/pmatch enable

Current Pattern Match: disabledNew Pattern Match: enabled

>> Security# matchall enaCurrent Match-all Criteria: disabledNew Match-all Criteria: enabled


>> SLB Port 22# filt ena (Enable filtering on the client port)

>> SLB Port 22# add 190 (Add Filter #190 to the client port)

CHAPTER 19

Firewall Load Balancing

Firewall Load Balancing (FWLB) with Alteon Application Switches allows multiple active

firewalls to operate in parallel. Parallel operation allows users to maximize firewall productiv-

ity, scale firewall performance without forklift upgrades, and eliminate the firewall as a single

point-of-failure.

This chapter presents the following topics:

“Firewall Overview” on page 566



315394-J, January 2005565

Firewall Overview on page 566

An overview of firewalls and the various FWLB solutions supported by Alteon Applica-

tion switches.

“Basic FWLB” on page 568Explanation and example configuration for FWLB in simple networks, using two parallel

firewalls and two application switches. The basic FWLB method combines redirection fil-

ters and static routing for FWLB.

“Four-Subnet FWLB” on page 580

Explanation and example configuration for FWLB in a large-scale, high-availability net-

work with redundant firewalls and application switches. This method combines redirec-

tion filters, static routing, and Virtual Router Redundancy Protocol (VRRP).

“Advanced FWLB Concepts” on page 601

“Free-Metric FWLB” on page 601. Using other load balancing metrics (besides

hash) by enabling the Return to Sender (RTS) option.

“Adding a Demilitarized Zone (DMZ)” on page 605. Adding a DMZ for servers that

attach to the Alteon Application Switch between the Internet and the firewalls. “Firewall Health Checks” on page 607. Methods for fine-tuning the health checks

performed for FWLB.


Firewall Overview

Firewall devices have become indispensable for protecting network resources from unautho-

rized access. Prior to FWLB, however, firewalls could become critical bottlenecks or single

points-of-failure for your network.

As an example, consider the following network:

"Dirty" Public Network

Internet

DMZ

Firewall

Private

Network

"Clean" Private Network



315394-J, January 2005566 Chapter 19: Firewall Load Balancing

Figure 19-1 Typical Firewall Configuration Before FWLB

One network interface card on the firewall 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 firewall. Another net-

work interface card on the firewall 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 firewall.

In this simple example, all traffic passing between the dirty, clean, and DMZ networks must

traverse the firewall, which examines each individual packet. The firewall is configured with a

detailed set of rules that determine which types of traffic are allowed and which types are

denied. Heavy traffic can turn the firewall into a serious bottleneck. The firewall is also a sin-gle 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 firewall or between the Internet and

the firewall. Typically, a DMZ contains its own servers that provide dirty-side clients with

access to services, making it unnecessary for dirty-side traffic to use clean-side resources.

FWLB with Alteon Application Switches provides a variety of options that enhance firewall performance and resolve typical firewall problems.


Alteon Application Switches support the following methods of FWLB:

Basic FWLB for simple networks

This method uses a combination of static routes and redirection filters and is usually

employed in smaller networks.

An Alteon Application Switch filter on the dirty-side splits incoming traffic into streams

headed for different firewalls. To ensure persistence of session traffic through the same

firewall, distribution is based on a mathematical hash of the IP source and destination

addresses.

For more information about basic FWLB, see “Basic FWLB” on page 568.

Four-Subnet FWLB for larger networks

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 Redun-

dancy Protocol (VRRP) to the configuration.

Just as with the basic method, four-subnet FWLB uses the hash metric to distribute fire-

ll t ffi d i t i i t



315394-J, January 2005Chapter 19: Firewall Load Balancing 567

wall traffic and maintain persistence.

For more information, see “Four-Subnet FWLB” on page 580.

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 filters to allow

multiple active firewalls to operate in parallel.

Figure 19-2 shows a basic FWLB topology:

Figure 19-2 Basic FWLB Topology

"Dirty" Side of Network

Firewalls

"Clean" Side of Network

InternetInternal

Network






The firewalls being load balanced are in the middle of the network, separating the dirty side

from the clean side. This configuration requires a minimum of two application switches: one

on the dirty side of the firewalls and one on the clean side.

A redirection filter on the dirty-side application switch splits incoming client traffic into multi-

ple streams. Each stream is routed through a different firewall. The same process is used for

outbound server responses; a redirection filter on the clean-side application switch splits the

traffic, and static routes forward each stream through a different firewall and then back to the

client.

Although other metrics can be used in some configurations (see “Free-Metric FWLB” on page

601), the distribution of traffic 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 firewall (a feature known as persistence) and that the traffic

will be equally distributed. The persistence is required for the firewall as it maintains state and

processes traffic in both directions for a connection.

Although basic firewall load-balancing techniques can support more firewalls as well as multi-

ple switches on the clean and dirty sides for redundancy, the configuration complexityincreases dramatically. The four-subnet FWLB solution is usually preferred in larger scale,

high-availability topologies (see page 580).


Basic FWLB Implementation

In this example, traffic is load balanced among the available firewalls.

Figure 19-3 Basic FWLB Process

"Dirty" Side "Clean" Side

Internet

Firewalls

Servers

Alteon Application

SwitchClient3

4

5

87

6

1 2

9

10

1. Client sends a request2. Redir filter selects upper or lower path3. Static route directs request through the selected firewall

4. Firewall forwards valid traffic5. SLB selects an available server6. Server responds

7. Redir filter selects reverse path 8. Static route directs response back

through the same firewall 9. Firewall forwards valid traffic10. Client receives response

Alteon Application

Switch




1. 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.

2. A redirection filter balances incoming requests among different IP addresses.

When the client request arrives at the dirty-side application switch, a filter redirects it to a real

server group that consists of a number of different IP addresses. This redirection filter splits the

traffic 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.

3. Requests are routed to the firewalls.

On the dirty-side switch, one static route is needed for each traffic stream. For instance, the first

static route will lead to an IP interface on the clean-side application switch using the first fire-

wall as the next hop. A second static route will lead to a second clean-side IP interface using the

second firewall as the next hop, and so on. By combining the redirection filter and static routes,

traffic is load balanced among all active firewalls.

All traffic between specific IP source/destination address pairs flows through the same fire-

wall, ensuring that sessions established by the firewalls persist for their duration.

NOTE – More than one stream can be routed though a particular firewall. You can weight the

load to favor one firewall by increasing the number of static routes that traverse it.


4. The firewalls decide if they should allow the packets and, if so, forwards them to a virtual

server on the clean-side application switch.

Client requests are forwarded or discarded according to rules configured for each firewall.

NOTE – Rule sets must be consistent across all firewalls.

5. The clean-side application switch performs normal SLB functions.

Packets forwarded from the firewalls are sent to the original destination address, that is, the vir-

tual server on the clean-side application switch. There, they are load balanced to the real servers

using standard SLB configuration.

6. The real server responds to the client request.

7. Redirection filters on the clean-side application switch balance responses among differ-ent IP addresses.

Redirection filters 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 traffic 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 traffic is routed to the firewalls.

Static routes are configured on the clean-side switch. One static route is needed for each stream

that was configured on the dirty-side application switch. For instance, the first static route

would be configured to lead to the first dirty-side IP interface using the first firewall as the next

hop. The second static route would lead to the second dirty-side IP interface using the second

firewall as the next hop, and so on.

Since application switches intelligently maintain state information, all traffic between specificIP source/destination addresses flows through the same firewall, maintaining session persis-

tence.

NOTE – If Network Address Translation (NAT) software is used on the firewalls, FWLB ses-

sion persistence requires the RTS option to be enabled on the application switch (see “Free-

Metric FWLB” on page 601).


9. The firewall decides if it should allow the packet and, if so, forwards it to the dirty-side

application switch.

Each firewall forwards or discards the server responses according to the rules that are

configured for it. Forwarded packets are sent to the dirty-side application switch and out to

the Internet.

10. The client receives the server response.

Configuring Basic FWLB

The steps for configuring 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 firewalls) as shown in Figure 19-4.


Firewall 1

ServersAlteon Application

Switch 1


IF1: 20.1.1.1Virtual Server:

Dirty Side:10.1.1.10

Clean Side:10.1.3.10




Figure 19-4 Basic FWLB Example Network

Configure the Dirty-Side Alteon Application Switch

1. Configure VLANs.

NOTE – Alternately, if using hubs between the switches and firewalls and you do not wish to

configure VLANs, you must enable Spanning Tree Protocol to prevent broadcast loops.

InternetFirewall 2

Switch 1IF1: 192.16.12.1

Virtual Server:20.1.1.10

20.1.1.2

20.1.1.3Dirty Side:10.1.2.10

IF2: 10.1.1.1IF3: 10.1.2.1

IF2: 10.1.3.1IF3: 10.1.4.1Clean Side:

10.1.4.10

12

3

2

3

4

5


2. Define 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 firewall path being load balanced. Each must be on a different subnet.

3. Configure the clean-side IP interface as if they were real servers on the dirty side.


>> IP Interface 1# addr 192.16.12.1 (Set address for switch management)

>> IP Interface 1# mask 255.255.255.0 (Set subnet mask for interface 1)>> IP Interface 1# ena (Enable IP interface 1)


>> IP Interface 2# addr 10.1.1.1 (Set the IP address for interface 2)

>> IP Interface 2# mask 255.255.255.0 (Set subnet mask for interface 2)



>> IP Interface 3# addr 10.1.2.1 (Set the IP address for interface 3)

>> IP Interface 3# mask 255.255.255.0 (Set subnet mask for interface 3)>> IP Interface 3# ena (Enable IP interface 3)




Later in this procedure, you’ll configure one clean-side IP interface on a different subnet for

each firewall 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 firewall. For

example, if real server 1 is the dirty-side IP interface for Firewall 1, then configure real server

1 on the clean side with the dirty-side IP interface. Configuring the same real server number on

both sides of the firewall ensures that the traffic travels through the same firewall.

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 servergroup, then real server 1 IP interface on the dirty side should be connected to Firewall 1.

Selecting the same real server ensures that the traffic travels through the same firewall.

NOTE – Each of the four interfaces used for FWLB (two on each application switch) in this

example must be configured for a different IP subnet.

>> IP Interface 3# /cfg/slb/real 1 (Select real server 1)

>> Real server 1# rip 10.1.3.1 (Assign clean-side IF 2 address)



>> Real server 2# rip 10.1.4.1 (Assign clean-side IF 3 address)



4. Place the IP interface real servers into a real server group.

5. Set the health check type for the real server group to ICMP.

6. Set the load-balancing metric for the real server group to hash.

Using the hash metric, all traffic between specific IP source/destination address pairs flows

through the same firewall. This ensures that sessions established by the firewalls are main-

tained for their duration.

N Oth l d b l i t i h l d bi i i




>> Real server group 1# health icmp (Select ICMP as health check type)

>> Real server group 1# metric hash (Select SLB hash metric for group 1)




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” on page 601.

7. Enable SLB on the switch.

8. Create a filter to allow local subnet traffic on the dirty side of the firewalls to reach the

firewall interfaces.

>> Real server group 1# /cfg/slb/on

>> Layer 4# /cfg/slb/filt 10 (Select filter 10)


>> Filter 10# dip 192.16.12.0 (Specify destination IP address)

>> Filter 10# dmask 255.255.255.0 (Specify destination mask)

>> Filter 10# action allow (Allow frames with this DIP address)

>> Filter 10# ena (Enable filter)


9. Create the FWLB redirection filter.

This filter will redirect inbound traffic, load balancing it among the defined real servers in the

group. In this network, the real servers represent IP interfaces on the clean-side application

switch.

10. Enable firewall load balancing.

11. Add filters to the ingress port.

>> Filter 10# /cfg/slb/filt 15 (Select filter 15)

>> Filter 15# sip any (From any source IP address)>> Filter 15# dip any (To any destination IP address)

>> Filter 15# proto any (For any protocol)

>> Filter 15# action redir (Perform redirection)

>> Filter 15# group 1 (To real server group 1)


>> Filter 15# adv/fwlb ena




12. Define static routes to the clean-side IP interfaces, using the firewalls as gateways.

One static route is required for each firewall 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 first firewall (10.1.1.10) as

its gateway, and one that leads to clean-side IF 3 (10.1.4.1) through the second firewall

(10.1.2.10) as its gateway.


>> Filter 15# /cfg/slb/port 1 (Select the ingress port)

>> SLB Port 1# add 10 (Add the filter to the ingress port)

>> SLB Port 1# add 15 (Add the filter to the ingress port)>> SLB Port 1# filt ena (Enable filtering on the port)

>> SLB Port 5# /cfg/l3/route>> 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

>> # apply>> # save




3. Place the real servers into a real server group.

4. Set the health check type for the real server group to ICMP.

5. Set the load-balancing metric for the real server group to hash.

NOTE – The clean-side application switch must use the same metric as defined on the dirty

side.

6. Enable server load balancing on the switch.


>> Real server group 1# add 1 (Select real server 1 to group 1)


>> Real server group 1# health icmp (Select ICMP as health check type)







7. Configure ports 2 and 3, which are connected to the clean-side of the firewalls, for client

processing.

8. Configure the virtual server that will load balance the real servers.

9. Configure the real servers to which traffic will be load-balanced.

These are the real servers on the network.

>> Real server group 1# /cfg/slb/port 2/client ena(Enable client processing

on port 2)

>> SLB port 2# /cfg/slb/port 3/client ena (Enable client processing on port 3)

>> SLB port 3# apply (Apply the configuration)

>> SLB port 3# save (Save the configuration)

>> SLB port 3# /cfg/slb/virt 100 (Configure virtual server 100)

>> Virtual Server 100# vip 20.1.1.10 (Assign virtual server 100 IP address)


>> Real server group 1# /cfg/slb/real/2 (Select real server 2)

>> Real server 2 # rip 20.1.1.2 (Assign real server 2 IP address)




10. Place the real servers into a real server group.

11. Configure ports 4 and 5, which are connected to the real servers, for server processing.

12. Enable server load balancing on the switch.

>> Real server 2 # ena (Enable real server 2)

>> Real server 2 # /cfg/slb/real 3 (Select real server 3)

>> Real server 3 # rip 20.1.1.3 (Assign real server 3 IP address)




>> Real server group 200# /cfg/slb/port 4/server ena>> SLB port 4# /cfg/slb/port 5/server ena



13. Create a filter to prevent server-to-server traffic from being redirected.

14. Create the redirection filter.

This filter will redirect outbound traffic, load balancing it among the defined real servers in the

group. In this case, the real servers represent IP interfaces on the dirty-side switch.

>> Layer 4# /cfg/slb/filt 10 (Select filter 10)


>> Filter 10# dip 20.1.1.0 (To base IP address for IF 5)

>> Filter 10# dmask 255.255.255.0 (For the range of addresses)


>> Filter 10# action allow (Allow traffic)


>> Filter 10# /cfg/slb/filt 15 (Select filter 15)>> Filter 15# sip any (From any source IP address)



>> Filter 15# action redir (Perform redirection)





15. Add the filters to the ingress ports for the outbound packets.

Redirection filters 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 net-

work. In this case, two real servers are attached to the clean-side application switch on port 4

and port 5.



>> Filter 15# /cfg/slb/port 4 (Select ingress port 4)

>> SLB Port 4# add 10 (Add the filter to the ingress port)>> SLB Port 4# add 15 (Add the filter to the ingress port)

>> SLB Port 4# filt ena (Enable filtering on the port)

>> SLB Port 4# /cfg/slb/port 5 (Select ingress port 5)



>> SLB Port 5# filt ena (Enable filtering on the port)


16. Define static routes to the dirty-side IP interfaces, using the firewalls as gateways.

One static route is required for each firewall 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 first firewall (10.1.3.10) as

its gateway, and one that leads to dirty-side IF 3 (10.1.2.1) through the second firewall

(10.1.4.10) as its gateway.

NOTE – Configuring static routes for FWLB does not require IP forwarding to be turned on.


>> SLB Port 5# /cfg/l3/route>> 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

>> # apply>> # save





Four-Subnet FWLB

The four-subnet FWLB method is often deployed in large networks that require high-availabil-

ity solutions. This method uses filtering, static routing, and Virtual Router Redundancy Proto-

col (VRRP) to provide parallel firewall operation between redundant application switches.

Figure 19-5 shows one possible network topology using the four-subnet method:

Subnet 1 Subnet 2 Subnet 3 Subnet 4

Dirty Side Clean Side

Internet

RoutersSi l Si l

PrimaryPrimary




Figure 19-5 Four-Subnet FWLB Topology

This network is classified 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. How-

ever, 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

Alteon Application Switches and simple switches are also possible. While such topologies

may resolve networking issues in special circumstances, they can make configuration 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 Alteon OS FWLB white papers, but are not within the scope of this manual.

RoutersSimple

SwitchesSimple

SwitchesFirewalls

SecondaryAlteon Application

Switch


Switch Servers


As shown in Figure 19-5, 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 firewall interfaces.

Subnet 3 includes the clean-side firewall 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 traffic arrives through both routers. Since VRRP is enabled, one of

the dirty-side application switches acts as primary and receives all traffic. The dirty-side pri-

mary application switch performs FWLB in a fashion similar to basic FWLB: a redirection fil-ter splits traffic into multiple streams which are routed through the available firewalls to the

primary clean-side application switch.

Just as with the basic method, four-subnet FWLB uses the hash metric to distribute firewall

traffic and maintain persistence, though other load-balancing metrics can be used by configur-




ing an additional Return to Sender (RTS) option (see “Free-Metric FWLB” on page 601).


Four-Subnet FWLB Implementation

In this example, traffic between the redundant Alteon Application Switches is load balanced

among the available firewalls.

Subnet 1 Subnet 2 Subnet 3 Subnet 4


Internet

RoutersSimple

SwitchesSimple

SwitchesFirewalls


Switch

Primary Primary


Switch Servers

1

2

3

1. VRRP forces incoming traffic to converge on primary dirty-side application switch2. Firewall load balancing occurs between primary application switches3. Primary clean-side application switch performs standard SLB




Figure 19-6 Four-Subnet FWLB Process

1. Incoming traffic converges on the primary dirty-side application switch.

External traffic arrives through redundant routers. A set of interconnected switches ensures

that both routers have a path to each dirty-side application switch.

VRRP is configured on each dirty-side application switch so that one acts as the primary rout-

ing switch. If the primary fails, the secondary takes over.

2. FWLB is performed between primary application switches.

Just as with basic FWLB, filters on the ingress ports of the dirty-side application switch redi-

rect traffic to a real server group composed of multiple IP addresses. This configuration splits

incoming traffic into multiple streams. Each stream is then routed toward the primary clean-

side application switch through a different firewall.

Although other load balancing metrics can be used in some configurations (see “Free-Metric

FWLB” on page 601), the distribution of traffic within each stream is normally based on amathematical hash of the IP source and destination addresses. Hashing ensures that each

request and its related responses will use the same firewall (a feature known as persistence),

and that the streams will be statistically equal in traffic load.


3. The primary clean-side application switch forwards the traffic to its destination.

Once traffic arrives at the primary clean-side application switch, it is forwarded to its destina-

tion. 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 filter on the clean-side application

switch splits the traffic, and static routes forward each response stream back through the samefirewall that forwarded the original request.

Configuring Four-Subnet FWLB

An example network for four-subnet FWLB is illustrated in Figure 19-7. While other complex

topologies are possible, this example assumes a high-availability network using block (rather

than diagonal) interconnections between switches.

Subnet 1 (VLAN 1):195.1.1.0/24

Subnet 2 (VLAN 2):10.10.2.0/24

Subnet 3 (VLAN 3):10.10.3.0/24

Subnet 4 (VLAN 4):10.10.4.0/24


Firewall #1Dirty: 10.10.2.3

Alteon ApplicationSwitch #3

IF1: 10.10.4.10/24IF2: 10.10.3.1/24IF3 10 10 3 2/32


IF1: 195.1.1.10/24IF2: 10 10 2 1/24




Figure 19-7 Four-Subnet FWLB Example Network

NOTE – The port designations of both dirty-side application switches are identical, as are the port designations of both clean-side application switches. This simplifies configuration by

allowing you to synchronize each primary application switch’s configuration with the second-

ary.

Internet

25 26

Router195.1.1.1

Router195.1.1.2

Dirty: 10.10.2.3Clean: 10.10.3.3

Firewall #2Dirty: 10.10.2.4Clean: 10.10.3.4

10.10.4.20

10.10.4.21

10.10.4.22

IF3: 10.10.3.2/32 VIP: 10.10.4.100 (VSR)


IF1: 10.10.4.11/24IF2: 10.10.3.11/24IF3: 10.10.3.12/32

VIP: 10.10.4.100 (VSR)

IF2: 10.10.2.1/24IF3: 10.10.2.2/32


IF1: 195.1.1.11/24IF2: 10.10.2.11/24IF3: 10.10.2.12/32

VIR195.1.1.9

VIR10.10.2.9

VIR10.10.3.9

VIR10.10.4.9

25

2525

26

2626

28

28

28

28

PrimaryPrimary

Secondary Secondary


Four-subnet FWLB configuration is summarized as follows:

Configure routers and firewalls and test them for proper operation.

Configure VLANs, IP interfaces, and static routes on all application switches and test

them.

Configure secondary application switches with VRRP support settings.

Configure FWLB groups and redirection filters on the primary dirty-side applicationswitch.

Configure and synchronize VRRP on the primary dirty-side application switch.

Configure FWLB and SLB groups, and add FWLB redirection filters on the primary

clean-side application switch.

Configure VRRP on the primary clean-side application switch and synchronize the sec-

ondary.

These steps are explained in detail in the following sections.

Configure the Routers

The routers must be configured 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)


Configure the Firewalls

Before you configure the Alteon Application Switches, the firewalls must be properly config-

ured. For incoming traffic, each firewall must be configured with a static route to the clean-

side virtual server, using the VIR in its clean-side subnet as the next hop. For outbound traffic,

each firewall must use the VIR in its dirty-side subnet as the default gateway.

In this example, the firewalls are configured with the following IP addresses:

Table 2 Four-Subnet Firewall IP Address Configuration

Item Address

Firewall 1

Dirty-side IP interface

Clean-side IP interface

Default GatewayRoute Added

10.10.2.3

10.10.3.3

10.10.2.9 (Subnet 2 VIR)10.10.4.100 (virtual server) via 10.10.3.9 (Subnet 3 VIR)

Firewall 2

Dirty-side IP interface

Clean-side IP interface

Default Gateway

Route Added

10.10.2.4

10.10.3.4

10.10.2.9 (dirty-side VIR)

10 10 4 100 (virtual server) via 10 10 3 9 (Subnet 3 VIR)




The firewalls must also be configured with rules that determine which types of traffic will be

forwarded through the firewall and which will be dropped. All firewalls participating in FWLB

must be configured with the same set of rules.

NOTE – It is important to test the behavior of the firewalls prior to adding FWLB.

Route Added 10.10.4.100 (virtual server) via 10.10.3.9 (Subnet 3 VIR)


Configure Connectivity for the Primary Dirty-Side Switch

1. Configure 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 firewall connection, and port 28, for the interswitch connection.

NOTE – Port 25 is part of VLAN 1 by default and does not require manual configuration.

2. Configure IP interfaces on the primary dirty-side application switch.

Three IP interfaces (IF’s) are used. IF 1 is on placed on Subnet 1. IF 2 will be used for routing

traffic through the top firewall. IF 3 will be used for routing traffic through the lower firewall.

To avoid confusion, IF 2 and IF 3 will be used in the same way on all application switches.

>> # /cfg/l2/vlan 2>> # add 26 (Port 26 connects to the firewall)

>> # add 28 (Port 28 is the inter-switch

connection)

>> # ena

# / f /l3/if 1




NOTE – By configuring the IP interface mask prior to the IP address, the broadcast address is

automatically calculated. Also, only the first IP interface in a given subnet is given the full sub-

net 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/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

>> # /cfg/l2/stg #/off


4. Configure 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 firewall, and IF 3 is being used on all application switches whenever routing through

the lower firewall.

The static route add command uses the following format:

add <destination address> <dest. mask> <gateway address> <source interface>

This example requires the following static route configuration:

>> # /cfg/l3/frwd/route>> # add 10.10.3.1 255.255.255.255 10.10.2.3 2

# dd 10 10 3 2 255 255 255 255 10 10 2 4 3




NOTE – When defining static routes for FWLB, it is important to specify the source IP inter-

face numbers.

5. When dynamic routing protocols are not used, configure a gateway to the external rout-

ers.

6. Make your changes take effect.

>> # 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

>> # /cfg/l3/gw 1/addr 195.1.1.1>> # /cfg/l3/gw 2/addr 195.1.1.2

>> # apply

>> # save>> # /boot/reset


Configure Connectivity for the Secondary Dirty-Side Switch

Except for the IP interfaces, this configuration is identical to the primary dirty-side application

switch.

1. Configure VLANs on the secondary dirty-side application switch.

2. Configure IP interfaces on the secondary dirty-side application switch.

>> # /cfg/l2/vlan 2>> # add 26>> # add 28>> # ena

>> # /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




3. Turn STP off for the secondary dirty-side application switch.

4. Configure static routes on the secondary dirty-side application switch.

5. When dynamic routing protocols are not used, configure a gateway to the external rout-

ers on the secondary dirty-side switch.

>> # /cfg/l3/if 3

>> # mask 255.255.255.255>> # addr 10.10.2.12>> # vlan 2>> # ena


>> # /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

>> # /cfg/l3/gw 1/addr 195.1.1.1>> # /cfg/l3/gw 2/addr 195.1.1.2



Configure Connectivity for the Primary Clean-Side Switch

1. Configure VLANs on the primary clean-side application switch.

Two VLANs are required. VLAN 3 includes the firewall port and interswitch connection port.

VLAN 4 includes the port that attaches to the real servers.

2. Configure IP interfaces on the primary clean-side application switch.

>> # apply>> # save>> # /boot/reset

>> # /cfg/l2/vlan 3>> # add 25>> # add 28>> # ena>> # /cfg/l2/vlan 4>> # add 26>> # ena




3. Turn STP off for the primary clean-side application switch.

Spanning Tree Protocol is disabled because VLANs prevent broadcast loops.

4. Configure static routes on the primary clean-side application switch.

>> # /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

>> # /cfg/l2/stg/off


Four static routes are needed:

To primary dirty-side IF 2 via Firewall 1 using clean-side IF 2

To primary dirty-side IF 3 via Firewall 2 using clean-side IF 3

To secondary dirty-side IF 2 via Firewall 1 using clean-side IF 2

To secondary dirty-side IF 3 via Firewall 2 using clean-side IF 3

The static route add command uses the following format:

add <destination address> <dest. mask> <gateway address> <source interface>

This example requires the following static route configuration:


>> # /cfg/l3/frwd/route>> # add 10.10.2.1 255.255.255.255 10.10.3.3 2>> # add 10.10.2.2 255.255.255.255 10.10.3.4 3

>> # add 10.10.2.11 255.255.255.255 10.10.3.3 2>> # add 10.10.2.12 255.255.255.255 10.10.3.4 3

>> # apply>> # save




Configure Connectivity for the Secondary Clean-Side Switch

1. Configure VLANs on the secondary clean-side application switch.

>> # /boot/reset

>> # /cfg/l2/vlan 3>> # add 25>> # add 28

>> # ena>> # /cfg/l2/vlan 4>> # add 26>> # ena


2. Configure IP interfaces on the secondary clean-side application switch.

3. Turn STP off for the secondary clean-side application switch.

Spanning Tree Protocol is disabled because VLANs prevent broadcast loops.

>> # /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





p g p p

4. Configure static routes on the secondary clean-side application switch.


>> # /cfg/l3/frwd/route>> # add 10.10.2.1 255.255.255.255 10.10.3.3 2>> # add 10.10.2.2 255.255.255.255 10.10.3.4 3>> # add 10.10.2.11 255.255.255.255 10.10.3.3 2>> # add 10.10.2.12 255.255.255.255 10.10.3.4 3



Verify Proper Connectivity

To verify proper configuration up to this point, use the ping option to test network connectiv-

ity. At each Alteon 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:

Configure VRRP Support on the Secondary Dirty-Side Switch

The secondary dirty-side application switch must be configured with the primary as its peer.

Once this is done, the secondary application switch will get the remainder of its configuration

from the primary when synchronized in a later step.

>> # ping 10.10.2.1Response; 10.10.2.1: #1 OK, RTT 1 msec.>> # ping 10.10.2.2Response; 10.10.2.2: #1 OK, RTT 1 msec.>> # ping 10.10.2.11Response; 10.10.2.11: #1 OK, RTT 1 msec.>> # ping 10.10.2.12

Response; 10.10.2.12: #1 OK, RTT 1 msec.




In this example, the secondary application switch is configured to use primary dirty-side inter-

face 1 as its peer.

>> # /cfg/l3/vrrp/on>> # /cfg/slb>> # on>> # sync/peer 1>> # addr 195.1.1.10>> # ena

>> # apply>> # save


Configure VRRP Support on the Secondary Clean-Side Switch

In this example, the secondary application switch uses primary clean-side interface 1 as its

peer.

Complete the Configuration of the Primary Dirty-Side Switch

1. 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 filter. Each IP address that is

assigned to the group represents a path through a different firewall. In this case, since two fire-

walls 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 firewall, and IF 3 on all application switches whenever routing through the

>> # /cfg/l3/vrrp/on>> # /cfg/slb>> # on

>> # sync/peer 1>> # addr 10.10.4.10>> # ena>> # apply>> # save



315394-J, January 2005 Chapter 19: Firewall Load Balancing 593

g p pp g g

lower firewall. Therefore, the first address will represent the primary clean-side IF 2, and thesecond represents the primary clean-side IF 3.

Using the hash metric, all traffic between specific IP source/destination address pairs flows

through the same firewall, ensuring that sessions established by the firewalls are maintainedfor their duration (persistence).

>> # /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


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” on page 601.

2. Create the FWLB filters.

Three filters are required on the port attaching to the routers:

Filter 10 prevents local traffic from being redirected.

Filter 20 prevents VRRP traffic (and other multicast traffic on the reserved 224.0.0.0/24

network) from being redirected.

Filter 2048 redirects the remaining traffic to the firewall group.

>> # /cfg/slb/filt 10

>> # dip 195.1.1.0>> # dmask 255.255.255.0>> # ena>> # /cfg/slb/filt 20>> # dip 224.0.0.0>> # dmask 255.255.255.0>> # ena>> # /cfg/slb/filt 2048

# ti di




>> # action redir

>> # group 1>> # ena>> # /cfg/slb/port 1>> # filt ena>> # add 10>> # add 20>> # add 2048


3. Configure VRRP on the primary dirty-side application switch.

VRRP in this example requires two virtual routers–one for the subnet attached to the routers,

and one for the subnet attached to the firewalls.

>> # /cfg/l3/vrrp>> # on>> # vr 1

>> # vrid 1 (Configure virtual router 1)>> # addr 195.1.1.9 (For the subnet attached to the routers)

>> # if 1>> # prio 101>> # share dis>> # ena>> # track>> # ifs ena

>> # ports ena>> # /cfg/l3/vrrp/vr 2>> # vrid 2 (Configure virtual router 2)

>> # addr 10.10.2.9 (For the subnet attached to the firewall)

>> # if 2>> # prio 101>> # share dis>> # ena>> # track




4. Configure the VRRP peer on the primary dirty-side application switch.


6. Synchronize primary and secondary dirty-side application switches for the VRRP config-

uration.

# t ac

>> # ifs ena>> # ports ena

>> # /cfg/slb/sync>> # prios d>> # peer 1

>> # ena>> # addr 195.1.1.11

>> # apply>> # save

>> # /oper/slb/sync


Complete the Configuration of the Primary Clean-Side Switch

1. 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 filter. Each IP address

assigned to the group represents a return path through a different firewall. In this case, since

two firewalls are used, two addresses are added to the group. The two addresses are the inter-

faces of the dirty-side application switch, and are configured as if they are real servers.

NOTE – IF 2 is used on all application switches whenever routing through the top firewall, and

IF 3 is used on all application switches whenever routing through the lower firewall.

>> # /cfg/slb>> # on

>> # real 1>> # rip 10.10.2.1 (IF2 of the primary dirty-side application switch)

>> # ena>> # /cfg/slb/real 2>> # rip 10.10.2.2 (IF2 of the primary dirty-side application switch)

>> # ena>> # /cfg/slb/group 1>> # add 1>> # add 2




NOTE – The clean-side application switch must use the same metric as defined on the dirty

side. For information on using metrics other than hash, see “Free-Metric FWLB” on page

601.

>> # add 2

>> # metric hash


2. Create an SLB real server group on the primary clean-side application switch, to which

traffic 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 configured as follows:

>> # /cfg/slb (Select the SLB menu)

>> # real 20 (Select real server 20)

>> # rip 10.10.4.20 (Set IP address of real server 20)

>> # ena (Enable)

>> # /cfg/slb/real 21 (Select real server 21)


>> # ena (Enable)

>> # /cfg/slb/real 22 (Select real server 22)


>> # ena (Enable)>> # /cfg/slb/group 2 (Select real server group 2)

>> # add 20 (Add the real servers to the group)

>> # add 21>> # add 22>> # metric leastconns (Select least connections as the load

balancing metric)

>> # /cfg/slb/virt 1 (Select the virtual server 1 menu)

>> # vip 10.10.4.100 (Set the virtual server IP address)




NOTE – The virtual server IP address configured in this step will also be configured as a Vir-

tual Server Router (VSR) when VRRP is configured in a later step.

>> # vip 10.10.4.100 (Set the virtual server IP address)

>> # service http (Select HTTP for load balancing)

>> # group 2 (Add real server group 2)

>> # ena (Enable the virtual server)

>> # /cfg/slb/port 26/server ena (Enable server processing on the port

connected to the real servers)

>> # /cfg/slb/port 25/client ena (Enable client processing on the port

connected to the firewall)

>> # /cfg/slb/port 28/client ena (Enable client processing on the inter-

switch connection)


3. Create the FWLB filters on the primary clean-side application switch.

Three filters are required on the port attaching to the real servers:

Filter 10 prevents local traffic from being redirected.

Filter 20 prevents VRRP traffic from being redirected.

Filter 2048 redirects the remaining traffic to the firewall group.

>> # /cfg/slb/filt 10>> # dip 10.10.4.0>> # dmask 255.255.255.0>> # ena>> # /cfg/slb/filt 20>> # dip 224.0.0.0>> # dmask 255.255.255.0>> # ena

>> # /cfg/slb/filt 2048>> # action redir>> # group 1>> # ena>> # /cfg/slb/port 4>> # filt ena>> # add 10>> # add 20>> # add 2048




# add 2048


4. Configure VRRP on the primary clean-side application switch.

VRRP in this example requires two virtual routers to be configured–one for the subnet attached

to the real servers, and one for the subnet attached to the firewalls.

>> # /cfg/l3/vrrp>> # on>> # vr 1

>> # vrid 3>> # addr 10.10.4.9>> # if 1>> # prio 100>> # share dis>> # ena>> # track>> # ifs ena>> # ports ena>> # /cfg/l3/vrrp/vr 2>> # vrid 4>> # addr 10.10.3.9>> # if 2>> # prio 101>> # share dis>> # ena>> # track




A third virtual router is required for the virtual server used for optional SLB.

5. Configure the peer on the primary clean-side application switch.

>> # ifs ena>> # ports ena

>> # /cfg/l3/vrrp/vr 3>> # vrid 5>> # addr 10.10.4.100

>> # prio 102>> # share dis>> # ena>> # track>> # ifs ena>> # ports ena

>> # /cfg/slb/sync>> # prios d>> # peer 1>> # ena>> # addr 10.10.4.11



7. Synchronize primary and secondary dirty-side application switches for the VRRP config-

uration.

>> # apply>> # save

>> # /oper/slb/sync





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 versatil-ity. 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.


Internet

Firewall 1

Firewall 2

ServersAlteon Application

Switch 1IF1: 192.16.12.1


IF1: 20.1.1.1Virtual Server:

20.1.1.10

20.1.1.2

Dirty Side:10.1.1.10

Clean Side:10.1.3.10

12

3

2

3

4

5




Figure 19-8 Basic FWLB Example Network

To use free-metric FWLB in this network, the following configuration changes are necessary.

1. On the clean-side application switch, enable RTS on the ports attached to the firewalls(ports 2 and 3).

Enable filter 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

20.1.1.3Dirty Side:10.1.2.10

IF2: 10.1.1.1IF3: 10.1.2.1

IF2: 10.1.3.1IF3: 10.1.4.1Clean Side:

10.1.4.10


2. On the clean-side application switch, remove the redirection filter from the ports

attached to the real servers (ports 4 and 5), but make sure filter processing is enabled.

The redirection filter is removed so that the return packet traverses through the same firewall.

If the firewalls synchronize their states, then it is not required to remove the redirection filter.

Filter processing is enabled to make use of the RTS-created sessions.

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.

Any of the following load-balancing metrics can be used: hash, leastconns, roun-

drobin, minmiss, response, and bandwidth. See “Metrics for Real Server Groups”

on page 195 for details on using each metric.

N S i ll h i ( h i h ) b fi d

>> # /cfg/slb/port 4/rem 2048>> # filt ena>> # /cfg/slb/port 5/rem 2048>> # filt ena

>> # /cfg/slb/group 1>> # metric <metric type>




NOTE – Some metrics allow other options (such as weights) to be configured.


Free-Metric with Four-Subnet FWLB

For this example, review the four-subnet example network.

Figure 19 9 Four Subnet FWLB Example Network

Subnet 1 (VLAN 1):195.1.1.0/24

Subnet 2 (VLAN 2):10.10.2.0/24

Subnet 3 (VLAN 3):10.10.3.0/24

Subnet 4 (VLAN 4):10.10.4.0/24


Internet

25 26

Router195.1.1.1

Router195.1.1.2



10.10.4.20

10.10.4.21

10.10.4.22


IF1: 10.10.4.10/24IF2: 10.10.3.1/24IF3: 10.10.3.2/32

VIP: 10.10.4.100 (VSR)


IF1: 10.10.4.11/24IF2: 10.10.3.11/24IF3: 10.10.3.12/32

VIP: 10.10.4.100 (VSR)


IF1: 195.1.1.10/24IF2: 10.10.2.1/24IF3: 10.10.2.2/32


IF1: 195.1.1.11/24IF2: 10.10.2.11/24IF3: 10.10.2.12/32

VIR195.1.1.9

VIR10.10.2.9

VIR10.10.3.9

VIR10.10.4.9

25

2525

26

2626

28

28

28

28

PrimaryPrimary

Secondary Secondary




603

Figure 19-9 Four-Subnet FWLB Example Network

To use free-metric FWLB in this network, the following configuration changes are necessary.

1. On the clean-side application switches, enable RTS on the ports attached to the firewalls

(port 3) and on the interswitch port (port 9).

Enable filter 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


2. On the clean-side application switches, remove the redirection filter from the ports

attached to the real servers (ports 4), but make sure filter processing is enabled.

To view the original redirection filters that were configured for the four-subnet example, see

Step 3. on page 598.

On both clean-side switches:

3. On the dirty-side application switches, set the FWLB metric.

On both dirty-side application switches:

Any of the following load-balancing metrics can be used: hash, leastconns, roun-

drobin, minmiss, response, and bandwidth. See “Metrics for Real Server Groups”

on page 195 for details on using each metric.

NOTE – Some metrics allow other options (such as weights) to be configured.

>> # /cfg/slb/port 4/rem 2048>> # filt ena


>> # metric <metric type>



315394-J, January 2005604

Chapter 19: Firewall Load Balancing


Adding a Demilitarized Zone (DMZ)

Implementing a DMZ in conjunction with firewall load balancing enables the Alteon Applica-

tion Switch to do the traffic filtering, off-loading this task from the firewall. A DMZ is created

by configuring FWLB with another real server group and a redirection filter towards the DMZ

subnets.

The DMZ servers can be connected to the application switch on the dirty side of the firewall. Atypical firewall load balancing configuration with a DMZ is shown in Figure 19-10.

Fi 19 10 T i l Fi ll L d B l i T l ith DMZ

Firewalls

DMZ

Alteon Application

Switches

InternetPrivate

Network

Note: There can beone or two DMZs.

Alteon Application

Switches




605

Figure 19-10 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 configured with filters 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 filters, and another that restricts

access to the clean network through the use of stateful inspection performed by the firewalls.


You could add the filters required for the DMZ (to each application switch) as follows:

1. On the dirty-side application switch, create the filter to allow HTTP traffic to reach the

DMZ Web servers.

In this example, the DMZ Web servers use IP addresses 205.178.29.0/24.

2. Create another filter to deny all other traffic to the DMZ Web servers.


>> Filter 80# sip any (From any source IP address)>> Filter 80# dip 205.178.29.0 (To the DMZ base destination)

>> Filter 80# dmask 255.255.255.0 (For the range of DMZ addresses)




>> Filter 80# action allow (Allow the traffic)


>> Filter 80# /cfg/slb/filt 89 (Select filter 89)


>> Filter 89# dip 205.178.29.0 (To the DMZ base destination)

>> Filter 89# dmask 255.255.255.0 (For the range of DMZ addresses)

>> Filter 89# proto any (For TCP protocol traffic)

>> Filter 89# action deny (Allow the traffic)



315394-J, January 2005606


NOTE – The deny filter has a higher filter number than the allow filter. This is necessary so

that the allow filter has the higher order of precedence.

3. Add the filters to the traffic ingress ports.


>> Filter 89# action deny (Allow the traffic)


>> Filter 89# /cfg/slb/port 1 (Select the ingress port)

>> SLB Port 1# add 80 (Add the allow filter)

>> SLB Port 1# add 89 (Add the deny filter)



Firewall Health Checks

Basic FWLB health checking is automatic. No special configuration is necessary unless you

wish to tune the health checking parameters. See Chapter 15, “Health Checking” for details.

Firewall Service Monitoring

To maintain high availability, application switches monitor firewall health status and send packets only to healthy firewalls. There are two methods of firewall service monitoring: ICMP

and HTTP. Each application switch monitors the health of the firewalls on a regular basis by

pinging the IP interfaces configured on its partner application switch on the other side of the

firewall.

If an application switch IP interface fails to respond to a user-specified number of pings, it

(and, by implication, the associated firewall), is placed in a Server Failed state. At this time,

the partner application switch stops routing traffic to that IP interface and, instead, distributes itacross the remaining healthy application switch IP interfaces and firewalls.

When an application switch IP interface is in the Server Failed state, its partner application

switch continues to send pings to it at user-configurable intervals. After a specified number of

successful pings, the IP interface (and its associated firewall) is brought back into service.

For example, to configure the switch to allow one-second intervals between health checks or

pings, two failed health checks to remove the firewall, and four successful health checks toh fi ll h l h f ll i d




607

p g , ,restore the firewall to the real server group, use the following command:

Physical Link Monitoring

Alteon Application switches also monitor physical link status of switch ports connected to fire-

walls. If the physical link to a firewall goes down, that firewall is placed immediately in theServer Failed state. When an Alteon Application Switch detects that a failed physical link to a

firewall has been restored, it brings the firewall back into service.

>> /cfg/slb/real <real server number>/inter 1/retry 2/restr 4


Using HTTP Health Checks

For those firewalls that do not permit ICMP pings to pass through, application switches can be

configured to perform HTTP health checks, as described below.

1. Set the health check type to HTTP instead of ICMP.

2. Enable HTTP access to the switch.

3. Configure a “dummy” redirect filter as the last filter (after the redirect all filter) to force

the HTTP health checks to activate, as shown below:

NOTE Make s re that the n mber of each real filter is lo er than the n mber of the “d mm ”

>> # /cfg/slb/group 1/health http (Select HTTP health checks)

>> # /cfg/sys/access/http ena (Enable HTTP)



>> Filter 2048# action redir (Redirect the traffic)

>> Filter 2048# group 1 (Set real server group for redirection)

>> Filter 2048# rport http (Set real server port for redirection)




315394-J, January 2005608


NOTE – Make sure that the number of each real filter is lower than the number of the “dummy”

redirect filter.

4. Apply filter to the port directed to the firewall.

In addition to HTTP, Alteon OS allows you to configure up to 5 different TCP services to lis-

ten for health checks. For example, you can configure FTP and SMTP ports to perform health

checks. Refer to Table 10-3 on page 192 for a list of other well-known application ports.

>> # /cfg/slb/port #/add 2048 (Add the dummy filter)

CHAPTER 20

Virtual Private Network LoadBalancing

The VPN (Virtual Private Network) load balancing feature in Alteon OS 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 traffic returns back to the same VPN serverfrom which the session started.


“Overview” on page 610

This section describes a VPN network and how VPN load balancing works on an Alteon

Application Switch.

“VPN Load Balancing Configuration” on page 612



315394-J, January 2005 609

VPN Load-Balancing Configuration on page 612

This section provides step-by-step instructions to configure 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 traffic from many sources to travel via separate

tunnels across the infrastructure. It also enables traffic from many sources to be differentiated,so that it can be directed to specific destinations and receive specific levels of service.

VPNs provide security features of a firewall, network address translation, data encryption, and

authentication and authorization. Since most of the data sent between VPN initiators and ter-

minators is encrypted, network devices cannot use information inside the packet to make intel-

ligent routing decisions.

How VPN Load Balancing Works

VPN load balancing requires that all ingress traffic passing through a particular VPN must

traverse the same VPN as it egresses back to the client. Traffic ingressing from the Internet is

usually addressed to the VPNs, with the real destination encrypted inside the datagram. Traffic

egressing the VPNs into the intranet contains the real destination in the clear.

In many VPN/firewall configurations it may not be possible to use the hash algorithm on thesource and destination address, because the address may be encrypted inside the datagram.



315394-J, January 2005610

Chapter 20: Virtual Private Network Load Balancing

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 Alteon Application Switch records state on frames enter-

ing the switch to and from the VPNs. This session table ensures that the same VPN server han-

dles all the traffic 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 gate-

ways is not supported.

Basic frame flow, from the dirty side of the network to the clean side, is shown in Figure 20-1.

An external client is accessing an internal server. The VPN devices do not perform Network

Address Translation (NAT).


Clean SideDirty Side

Client

Alteon Application

Switch 1VPN Device 1

Internet

SMAC DMAC SIP DIP

VPN Device 2

Alteon Application

Switch 2

SMAC DMAC SIP DIP

Client Router D1 E10 PAYLOAD

MAC MAC

1

2

3 4

SMAC DMAC SIP DIP5SMAC DMAC SIP DIP

Client Router D2 D3 D1 E10

MAC MAC

Encrypted

SMAC DMAC SIP DIP

SW1 VPN1 D2 D3 D1 E10

MAC MAC

Encrypted

Router

VPN1 SW2 D1 E10

MAC MAC

SW2 Real server D1 E10

MAC MAC

Real server

D1 = Client IP address

D2 = IP address used by the VPN client softwareD3 = Cluster IP address of the VPN devices



315394-J, January 2005Chapter 20: Virtual Private Network Load Balancing 611

Figure 20-1 Basic Network Frame Flow and Operation

The basic steps that occur at the switches when a request arrives from the Internet are

described below:

1. The client prepares to send traffic to the destination real server (with IP address E10).

2. The VPN client software encrypts the packet and sends it to the cluster IP address (D3) of

the VPN devices.

3. Alteon 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. The VPN device 1 strips the IP header and decrypts the encrypted IP header.

5. Alteon Application Switch 2 forwards the packet to the real server.

E10 = IP address of the Real server


If an entry is found, the frame is forwarded normally. If an entry is not found, the switch deter-

mines 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 traffic is redirected to the same VPN device.

VPN Load-Balancing Configuration

Before you start configuring the switch for VPN load balancing, do the following:

Configure the switch with firewall load balancing. For more information, see “Firewall


Enable the Return to Sender (RTS) feature on the ports attached to the VPN devices, using

the following command:

The following example illustrates VPN load balancing with two VPN devices and four Alteon

Application Switches in a four subnet scenario.

>> # /cfg/slb/port <port number>/rts ena

VPN Device 1Client:192 168 10 100 / /

Mgmt. Server:30 0 0 100

Alteon ApplicationSwitch DA

Alteon ApplicationSwitch CA




315394-J, January 2005612 Chapter 20: Virtual Private Network Load Balancing

Figure 20-2 VPN Load-Balancing Configuration Example

1 25

26

1 25 25

25

1

1

26

26

26

192.168.10.100Default Gateway:192.168.10.50

IF 1 = 192.168.10.10/24IF 2 = 10.0.0.10/24IF 3 = 10.0.0.11/32

IF 1 = 30.0.0.10/24IF 2 = 20.0.0.10/24IF 3 = 20.0.0.11/32

IF 1 = 30.0.0.11/24IF 2 = 20.0.0.20/24IF 3 = 20.0.0.21 /32

IF 1 = 192.168.10.11/24IF 2 = 10.0.0.20/24IF 3 = 10.0.0.21/32

VPN Device 2

IF 1 = 10.0.0.101IF 2 = 20.0.0.101

IF 1 = 10.0.0.102IF 2 = 20.0.0.102

30.0.0.100

VIR

192.168.10.50

VIR

10.0.0.1

VIR20.0.0.1

VIR30.0.0.50

Alteon ApplicationSwitch DB

Alteon ApplicationSwitch CB

L2 SwitchL2 Switch

Internal network: 30.0.0.0./2Default Gateway: 30.0.0.50

Static Routes

(Both Dirty Web Switches):20.0.0.10 via 10.0.0.101IF 220.0.0.11 via 10.0.0.102 IF 320.0.0.20 via 10.0.0.101 IF 220.0.0.21 via 10.0.0.102 IF 3

Static Routes:

(Both Clean Web Switches)20.0.0.10 via 10.0.0.101IF 220.0.0.11 via 10.0.0.102 IF 320.0.0.20 via 10.0.0.101 IF 220.0.0.21 via 10.0.0.102 IF 3

VPN Static Routes

(Both VPN Devices)Default via 10.0.0.130.0.0.0/24 via 20.0.0.1

Cables:

Straight-through

Crossover


Build the topology illustrated in Figure 20-2 on page 612, and configure the switches as shown

in the following sections.

Configure the First Clean-Side Application Switch-CA

1. Turn off BOOTP.

2. Define and enable VLAN 2 for ports 25, and 26.

3. Turn off Spanning Tree Protocol (STP).

4. Define the clean-side IP interfaces.

Create one clean-side IP interface on a different subnet for each VPN device being load bal-

anced.

>> # /cfg/sys/bootp dis

>> # /cfg/l2/vlan 2/ena/def 25 26


>> # /cfg/l3/if 1/ena (Select IP interface 1 and enable)


>> IP Interface 1# addr 30.0.0.10 (Set IP address for interface 1)





>> IP Interface 1# vlan 1 (For VLAN 1)

>> IP Interface 1# /cfg/l3/if 2/ena (Select IP interface 2 and enable)




>> IP Interface 2# /cfg/l3/if 3/ena (Select IP interface 3 and enable)





5. Configure routes for each of the IP interfaces you configured 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 (Static route destination IP address)

>> IP Static Route# 255.255.255.255 (Destination subnet mask)

>> IP Static Route# 20.0.0.101 (Enter gateway IP address)>> IP Static Route# 2 (For interface 2)

>> IP Static Route# add 10.0.0.11 (Enter destination IP address)


>> IP Static Route# 20.0.0.102 (Enter gateway IP address)

>> IP Static Route# 3 (For interface 3)

>> IP Static Route# add 10.0.0.20 (Enter destination IP address)



>> IP Static Route# 2 (For interface 2)>> IP Static Route# add 10.0.0.21 (Static route destination IP address)



>> IP Static Route# 3 (For interface 3)





6. Configure VRRP for virtual routers 1 and 2.

>> # /cfg/l3/vrrp/on (Enable VRRP)

>> Virtual Router Redundancy Protocol# vr 1 (Select virtual router 1 menu)

>> VRRP Virtual Router 1# ena (Enable the virtual router)

>> VRRP Virtual Router 1# vrid 1 (Assign virtual router ID 1)

>> VRRP Virtual Router 1# if 1 (To interface number 1)

>> VRRP Virtual Router 1# prio 101 (Set the renter priority)

>> VRRP Virtual Router 1# addr 30.0.0.50 (Set IP address of virtual router)>> VRRP Virtual Router 1# share dis (Disable sharing)

>> VRRP Virtual Router 1# track (Select virtual router tracking menu)

>> VRRP VR 1 Priority Tracking# vrs ena (Enable tracking of virtual routers)

>> VRRP VR 1 Priority Tracking# apply (Apply the configuration)

>> VRRP VR 1 Priority Tracking# save (Save the configuration)

>> VRRP VR 1 Priority Tracking# /cfg/l3/vrrp/vr 2(Select virtual router 2

menu)

>> VRRP Virtual Router 2# ena (Enable the virtual router)

>> VRRP Virtual Router 2# vrid 2 (Assign virtual router ID 2)>> VRRP Virtual Router 2# if 2 (To interface number 2)

>> VRRP Virtual Router 2# prio 101 (Set the renter priority)

>> VRRP Virtual Router 2# addr 20.0.0.1 (Set IP address of virtual router)

>> VRRP Virtual Router 2# share dis (Disable sharing)

>> VRRP Virtual Router 2# track (Select Virtual Router Tracking Menu)

>> VRRP VR 2 Priority Tracking# ports ena (Track VLAN switch ports)

>> VRRP VR 2 Priority Tracking# apply (Apply the configuration)

>> VRRP VR 2 Priority Tracking# save (Save the configuration)




7. Enable Server Load Balancing (SLB) on the first clean switch.

8. Configure real servers for health checking VPN devices.

>> # /cfg/slb/on

>> # /cfg/slb/real 1/ena (Enable slb for real server 1)>> Real server 1 # rip 10.0.0.10 (Assign IP address for real server 1)

>> Real server 1 # /cfg/slb/real 2/ena (Enable SLB for real server 2)

>> Real server 2 # rip 10.0.0.11 (Assign IP address for real server 2)






9. Configure real server group 1, and add real servers 1, 2, 3, and 4 to the group.

10. Enable RTS on the necessary ports.

11. Enable filter processing on the server ports so that the responses from the real server is

looked up in the VPN session table.

12. When dynamic routing protocols are not used, configure a gateway to the external

router.

13. Apply and save the configuration, and reboot the switch.

>> # /cfg/slb/group 1 (Configure real server group 1)


>> Real server group 1# add 1 (Add real servers 1-4 to group 1)

>> Real server group 1# add 2/add 3/add 4

>> # /cfg/slb/port 26/rts ena (Enable Return to Sender on port 26)

>> # /cfg/slb/port 25/rts ena (Enable Return to Sender on port 25)

>> # /cfg/slb/port 1/filt ena

>> # /cfg/l3/gw 1/addr 192.168.10.50

>> # apply#




Configure the Second Clean-Side Application Switch-CB

1. Turn off bootp.

2. Define and enable VLAN 2 for ports 25 and 26.

3. Turn off Spanning Tree Protocol.

4. Define the clean-side IP interfaces.

>> # save>> # /boot/reset





Create one clean-side IP interface on a different subnet for each VPN device being load bal-

anced.

5. Configure routes for each of the IP interfaces you configured in Step 4, using the VPNdevices as gateways.

One static route is required for each VPN device being load balanced.

6. Configure Virtual Router Redundancy Protocol (VRRP) for virtual routers 1 and 2.

>> # /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

>> # /cfg/l3/route>> # add 10.0.0.10 255.255.255.255 20.0.0.101 2>> # add 10.0.0.11 255.255.255.255 20.0.0.102 3>> # add 10.0.0.20 255.255.255.255 20.0.0.101 2

>> # add 10.0.0.21 255.255.255.255 20.0.0.102 3

>> # /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




7. Enable SLB.


#>> 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

>> VRRP Virtual Router 2 Priority Tracking# /cfg/slb/on

>> Layer 4# /cfg/slb/real 1/ena/rip 10.0.0.10>> Real server 1# /cfg/slb/real 2/ena/rip 10.0.0.11>> Real server 2# /cfg/slb/real 3/ena/rip 10.0.0.20>> Real server 3# /cfg/slb/real 4/ena/rip 10.0.0.21


9. Enable the real server group.

10. Enable RTS on the necessary ports.

11. Enable filter processing on the server ports so that the response from the real server will

be looked up in VPN session table.


Configure the First Dirty-Side Application Switch-DA1. Turn off BOOTP.

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

>> Real server group 1# /cfg/slb/port 26/rts ena>> SLB port 26# /cfg/slb/port 25/rts ena

>> SLB port 25# /cfg/slb/port 1/filt ena

>> SLB port 25# apply>> SLB port 25# save>> SLB port 25# /boot/reset



315394-J, January 2005

618 Chapter 20: Virtual Private Network Load Balancing


3. Turn off STP.

4. Configure IP interfaces 1, 2, and 3.






5. Define static routes for each of the IP interfaces you configured 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 255.255.255.255 10.0.0.101 2>> # add 20.0.0.11 255.255.255.255 10.0.0.102 3

>> # add 20.0.0.20 255.255.255.255 10.0.0.101 2>> # add 20.0.0.21 255.255.255.255 10.0.0.102 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



315394-J, January 2005

Chapter 20: Virtual Private Network Load Balancing 619

7. Enable SLB.

8. Configure real servers for health-checking VPN devices.

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

>> VRRP Virtual Router 1 Priority Tracking# /cfg/slb/on

>> Layer 4# real 1/ena/rip 20.0.0.10>> Real server 1# /cfg/slb/real 2/ena/rip 20.0.0.11>> Real server 2# /cfg/slb/real 3/ena/rip 20.0.0.20>> Real server 3# /cfg/slb/real 4/ena/rip 20.0.0.21


9. Enable the real server group.

10. Configure the filters to allow local subnet traffic on the dirty side of the VPN device to

reach the VPN device interfaces.

11. Create the redirection filter and enable firewall load balancing.

This filter will redirect inbound traffic, redirecting it among the defined real servers in the 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

>> # /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

>> # /cfg/slb/filt 2048>> # ena>> # sip any>> # dip any



315394-J, January 2005


12. Create a filter to allow the management firewall (Policy Server) to reach the VPN firewall.


>> # dip any>> # action redir>> # /cfg/slb/filt 2048/adv>> # fwlb ena

>> # /cfg/slb/filt 120 ena>> # sip 192.168.10.120>> # smask 255.255.255.255>> # dip 10.0.0.0>> # dmask 255.255.255.0

>> # /cfg/slb/port 1>> # filt ena>> # add 100/add 110/add 2048



Configure the Second Dirty-Side Application Switch-DB

1. Turn off BOOTP.


3. Turn off STP.

4. Configure IP interfaces 1, 2, and 3.








315394-J, January 2005


5. Configure routes for each of the IP interfaces you configured in Step 4.

>> # /cfg/l3/route>> # add 20.0.0.10 255.255.255.255 10.0.0.101 2>> # add 20.0.0.11 255.255.255.255 10.0.0.102 3

>> # add 20.0.0.20 255.255.255.255 10.0.0.101 2>> # add 20.0.0.21 255.255.255.255 10.0.0.102 3



7. Enable SLB.


>> # /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

>> # /cfg/slb/on



315394-J, January 2005


9. Enable the real server group, and place real servers 1-4 into the real server group.

>> # /cfg/slb/real 1/ena/rip 20.0.0.10>> # /cfg/slb/real 2/ena/rip 20.0.0.11>> # /cfg/slb/real 3/ena/rip 20.0.0.20>> # /cfg/slb/real 4/ena/rip 20.0.0.21

>> # /cfg/slb/group 1>> # metric hash>> # add 1/add 2/add 3/add 4


10. Configure the filters to allow local subnet traffic on the dirty side of the VPN device to

reach the VPN device interfaces.

11. Create the redirection filter and enable firewall load balancing.

This filter will redirect inbound traffic, among the defined real servers in the group.


>> # /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

>> # /cfg/slb/filt 2048>> # ena>> # sip any>> # dip any>> # proto any>> # action redir>> # /cfg/slb/filt 2048/adv>> # fwlb ena

>> # /cfg/slb/port 1



315394-J, January 2005


13. Apply and save the configuration and reboot the switch.

g p>> # filt ena>> # add 100/add 110/add 2048



Test Configurations 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 Figure 20-3).

Figure 20-3 Checkpoint Rules for Both VPN Devices as Seen in the Policy Editor

1. Disconnect the cables (cause failures) to change the available servers that 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 traffic. In the tool bar above, click on Window, then

Log Viewer

>> # /info/slb/dump (Verify which servers are up)



315394-J, January 2005


Log Viewer.

NOTE – To help simplify the logs, the health checks are not logged.


Test the VPN

1. Launch the SecuRemote client on the dirty side of the network.

2. Add a new site.

3. Enter the policy server IP address: 192.168.10.120. You have the option of adding a

nickname.

4. Launch a browser (such as Netscape or Internet Explorer) and go to http://30.0.0.100

5. You will be prompted for authentication.



315394-J, January 2005


5. You will be prompted for authentication.

Enter vpnuser for user name and alteon for the password.


6. A message is displayed verifying that you were authenticated.

7. Browse to the Web site.

If there are other services running on other servers in the internal network, you should be able

to reach those services. All traffic 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 traffic.

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), configure 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 differ-

ently, but each VPN 1 Gateway will be treated as one client each (that is, one Client IP



315394-J, January 2005


address). VPN Device 1 and VPN Device 2 belong to one cluster IP.

CHAPTER 21

Global Server Load Balancing

This chapter provides information for configuring Global Server Load Balancing (GSLB)

across multiple geographic sites. The following topics are covered:

“Enabling GSLB on the Switch” on page 628

“GSLB Overview” on page 630

“GSLB Enhancements” on page 633

“Configuring Basic GSLB” on page 637

“Configuring a Standalone GSLB Domain” on page 652

“Configuring GSLB with Rules” on page 656

“Configuring GSLB Network Preference” on page 660

“Configuring GSLB with Proxy IP for Non-HTTP Redirects” on page 663

“U i B d G t P t l f GSLB” 667



315394-J, January 2005

627

“Using Border Gateway Protocol for GSLB” on page 667

“Verifying GSLB Operation” on page 668


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 certificate.

Once you have obtained the proper password key to enable GSLB, follow these instructions:

1. Connect to the switch command line interface via Telnet or the console port, and login as

the administrator, following the directions in the Alteon OS Command Reference.

2. 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 switch’s non-volatile RAM

(NVRAM), and will then enable the feature.

DSSP version 1 vs. version 2

Distributed Site Selection Protocol (DSSP) is a proprietary protocol that resides above TCP. It

enables sending and receiving remote site updates. By default, DSSP version 1 is enabled on

the Alteon Application Switch. DSSP version 1 was used for Alteon OS version prior to 22.0.DSSP version 1 supports server response time and sessions available in the remote site

updates.



315394-J, January 2005

628 Chapter 21: Global Server Load Balancing

DSSP version 2 is new in Alteon OS 22.0, and 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” on page 633.)

When upgrading to Alteon OS 22.0, your GSLB configurations will by default support onlyDSSP version 1. DSSP v1 remains in release 22.0 mainly to support interconnection with

switches running older versions of Alteon OS, during a migration to Alteon OS 22.0.

If you are using an Alteon Application Switch for the first time starting with Alteon OS 22.0,

then you should start any GSLB by first setting DSSP to version 2.

The command to change to DSSP version 2 is /cfg/slb/gslb/version 2.


Migrating Old GSLB Configurations intoAlteon OS 22.0

In Alteon OS 22.0, many new GSLB commands and menus have been added that differ from

older Alteon OS versions. If your application switch is already configured for GSLB using an

Alteon OS version older than 22.0, your configuration will be maintained upon upgrading to

22.0. Simply upgrade to Alteon OS 22.0 by downloading the new image, and then reboot the

switch.

GSLB License Key

If GSLB is not already enabled on your application switch, you will need to obtain a GSLB

key specifically for Alteon OS 22.0.

If you already own a GSLB license key from an earlier version of Alteon OS, you may use

your existing key if you perform a direct upgrade from 21.0.x to Alteon OS 22.0.

If you upgrade to Alteon OS 22.0 then revert to a pre-Alteon OS 22.0 release, then apply a

pre-Alteon OS 22.0 license key, the key will not work if you were to then upgrade to Alteon

OS 22.0.



315394-J, January 2005

Chapter 21: Global Server Load Balancing 629


GSLB Overview

GSLB allows balancing server traffic load across multiple physical sites. The Alteon GSLB

implementation takes into account an individual site’s health, response time, and geographic

location to smoothly integrate the resources of the dispersed server sites for complete global

performance.

Benefits

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.

The best performing sites receive a majority of traffic 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 site’s 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.



315394-J, January 2005


GSLB is easy to deploy, manage, and scale. Switch configuration 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 traffic 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 Figure 21-1, 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 Alteon Application Switch configured for GSLB, with domain name set to

“www.gslb.example.com.” These switches are also configured as the Authoritative Name

Servers for “www.example.com.”On the company master DNS server, the configuration is to

delegate “www.example.com” to “www.gslb.example.com.”

Internet

Example Site 1:San Jose Example Site 2: Denver

Client Site

DNS

DNSDNS

AlteonApplicationSwitch

AlteonApplicationSwitch

Best Service!

4

3

2

15

DNSRequest HTTP

Request



315394-J, January 2005


Figure 21-1 DNS Resolution with Global Server Load Balancing

The DNS resolution for GSLB is described in detail in the following procedure:

1. The client Web browser requests the “www.example.com” IP address from the local

DNS.

2. The client’s DNS asks its upstream DNS, which in turn asks the next, and so on, until theaddress 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.

Switches regularly exchange performance information

WebServers

WebServers

DNS responselists best site'sIP address first


3. The Example Inc.’s San Jose DNS tells the local DNS to query the Alteon ApplicationSwitch with GSLB software as the authoritative name server for “www.example.com.”

4. 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 client’s name resolution

request. Since each switch regularly checks and communicates health and performance infor-

mation with its peers, either switch can determine which site(s) are best able to serve the cli-ent’s 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.

In this case, the San Jose switch knows that Example Inc. Denver currently provides better ser-

vice, and lists Example Inc. Denver’s virtual server IP address first when responding to the

DNS request.

5. The client connects to Example Inc. Denver for the best service.

The client’s Web browser will use the IP address 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 configuration.

If the site serving the client HTTP content suddenly experiences a failure (no healthy real serv-

ers) or becomes overloaded with traffic (all real servers reach their maximum connection

limit), the switch issues an HTTP Redirect and transparently causes the client to connect toanother peer site.

The end result is that the client gets quick, reliable service with no latency and no special cli-

ent-side configuration



315394-J, January 2005


ent-side configuration.


GSLB Enhancements

GSLB has been enhanced with the following new features in Alteon OS 22.0.

Distributed Site Selection Protocol version 2 —DSSP version 2 can be configured to

send updates over TCP ports besides port 80, and can handle additional parameter

exchanges as described in “DSSP version 1 vs. version 2” on page 628. DSSP is a propri-

etary protocol residing above TCP.

Network Preference Table —supports multiple servers as opposed to two servers in

Alteon OS versions prior to 22.0. The network preference table can be used for HTTP

redirect GSLB, but cannot be used in pre 22.0.

Rule and metric preference per virtual server/domain —each virtual server/domain can

use different rules, listing different metric preferences, supporting load balancing vs mul-

tiple site high availability.

New static and load site selection metrics for rule-based processing —several new met-

rics have been added for rule-based processing, as described in “GSLB Metrics” on page

633.

Prioritization and weighting of GSLB metrics— selection of GSLB metrics can be pri-

oritized by configuring a GSLB rule, as described in “Configuring GSLB with Rules” on

page 656.

GSLB Metrics

This section describes all GSLB metrics The (Ne ) items are ne l introd ced as of Alteon



315394-J, January 2005


This section describes all GSLB metrics. The (New) items are newly introduced as of Alteon

OS 22.0. All metrics can be prioritized for selection order, and can be weighted on per site

basis.

For details on the configuration parameters of GSLB metrics, see the /cfg/slb/gslb/rule menu and the command descriptions in the Alteon OS 22.0 Command Reference.

Session utilization capacity threshold (New)—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 avail-

able, 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 (new)—This metric causes the GSLB-enabled applica-tion 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

Pacific Rim

Sub-Sahara

Japan

Network preference (client proximity)—This metric selects the server based on the pre-

ferred network of the source IP address. This metric does not require remote site updates.

Weighted least connections (new)—This metric selects the server based on which server



315394-J, January 2005


Weighted least connections (new) 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 (new)—This metric selects the server based on round robin of the

servers.

Weighted random (new)—This metric selects the server based on uniform random distribution of the servers.


Availability (new)—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.

Quality of service (new)—This metric selects the server based on combination of the low-

est 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 (new) —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 configured for

the domain irrespective of the state of the server. When the server selected is not available,

minmisses selects the next available server.

Hashing (new)—This metric selects the same server based on the hash of source IPaddress 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. This metric was introduced in

Alteon OS 21.0.5.



315394-J, January 2005



Metric preferencesThis metric allows the GSLB selection to use multiple metrics from a metric preference list.

The GSLB selection starts with the first metric in the list. The GSLB selection goes to the next

metric when no server is selected, 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 configured 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



315394-J, January 2005


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 first rule that matches for the

domain and starts with the first metric in the metric preference list of the rule. For more infor-

mation, see “Configuring GSLB with Rules” on page 656.


Configuring Basic GSLB

Configuring GSLB is simply an extension of the configuration procedure for SLB. The process

is summarized as follows:

Use the administrator login to connect to the switch you want to configure.

Activate the GSLB software key. See the Alteon OS Command Reference for details.

Configure the switch at each site with basic attributes.

Configure the switch IP interface.

Configure the default gateways.

Configure the switch at each site to act as the DNS server for each service that is hosted on

its virtual servers. Also, configure the master DNS server to recognize the switch as the

authoritative DNS server for the hosted services.

Configure the switch at each site for local SLB.

Define each local real server.

Group local real servers into real server groups.

Define the local virtual server with its IP address, services, and real server groups.

Define the switch port states.

Enable SLB.

Finally, configure each switch so that it recognizes its remote peers.



315394-J, January 2005


Configure a remote real server entry on each switch for each remote service. This is

the virtual server IP address that is configured on the remote peer.

Add the remote real server entry to an appropriate real server group. Enable GSLB.


Basic GSLB RequirementsThe following is required prior to configuration:

You must be connected to the switch Command Line Interface (CLI) as the administrator.

The optional GSLB software key must be activated

Server Load Balancing must be enabled.

Example GSLB Topology

Consider the following example network:

Figure 21-2 GSLB Topology Example 1

San Jose–Site 1 Denver–Site 2200.200.200.X Network 174.14.70.X Network

Web Servers:200.2.2.10200.2.2.20VLAN 201

Web Servers:174.40.7.11174.40.7.21VLAN 202

10

20 21

11

IP Interface 101200.200.200.1

VIP: 200.200.200.100VLAN 101

IP Interface 201200.2.2.201VLAN 201

IP Interface 102:174.14.70.2

VIP: 174.14.70.200VLAN 102


Internet

Alteon 2424 GSLB 1 Alteon 2424 GSLB 2

DNS Server

Default GW200.200.200.101

Default GW

174.14.70.101

DNS Server



315394-J, January 2005


In the following examples, many of the options are left to their default values. See “Additional

Server Load Balancing Options” on page 191 for more options.

NOTE – For details about any of the processes or menu commands described in this example,

see the Alteon OS Command Reference.


Task 1: Configure the Basics at the San Jose Site

1. (Optional) On the San Jose switch, configure management access, and management gate-

way address on the application switch, then enable the management port.

2. 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 Alteon OS

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 Alteon OS Command Refer-

ence), configure it to use a different port.

For example, enter the following command to change the BBI port to 8080:

3. Configure a VLAN for the Internet traffic.

>> # /cfg/sys/mmgmt/addr 50.133.88.31 (Mgmt. port IP address)

>> Management Port# mask 255.255.255.0 (Mgmt. port mask)

>> Management Port# gw 50.133.88.1 (Mgmt. port gateway addr.)

>> Management Port# ena (Enable the Mgmt port)

>> # /cfg/sys/ wport 8080 (Set service port 8080 for BBI)

>> # /cfg/l2/vlan 101/name internet (VLAN 101 for Internet)

>> VLAN 101# add 2/ena (Add port 2 to VLAN 101)

Port 2 is an UNTAGGED port and its current PVID is 1.Confirm changing PVID from 1 to 101 [y/n]: yCurrent ports for VLAN 101: emptyPending new ports for VLAN 101: 2



315394-J, January 2005


g pCurrent status: disabledNew status: enabled


4. Configure another VLAN for local server traffic, and add server ports to this VLAN.

5. Define an IP interface to the local real servers.

6. Define an IP interface to the Internet.

The switch IP interface responds when asked to resolve client DNS requests.

>> # /cfg/l2/vlan 201/name servers (VLAN 201 for local servers) >> VLAN 201# add 4/ena (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]: yCurrent ports for VLAN 201: emptyPending new ports for VLAN 201: 10Current 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]: yCurrent ports for VLAN 201: emptyPending new ports for VLAN 201: 3 4



>> IP Interface 201# mask 255.255.255.0 (Assign network mask)

>> IP Interface 201# vlan 201 (Assign interface to VLAN 201)




f 101# k 255 255 255 0 (A i k k)



315394-J, January 2005


7. Define the default gateway.

The router at the edge of the site acts as the default gateway to the Internet. The default gate-

way address should be on the same subnet as the IP interface 101, which points to the Internet.

To configure the default gateway for this example, enter these commands from the CLI:




>> IP Interface 101# /cfg/l3/gw 1 (Select default gateway 1)

>> Default gateway 1# addr 200.200.200.101 (Assign IP address for the gateway)

>> Default gateway 1# ena (Enable default gateway 1)



9. Configure 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 eachdistributed service. In this example, the San Jose DNS server is configured 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.”

Task 2: Configure the San Jose Switch for Standard SLB

1. 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 vio-

late the topology rules outlined in “Network Topology Requirements” on page 186.

For this example, the host real servers have IP addresses on the same IP subnet:

>> # apply>> # save

Table 21-1 GSLB Example: San Jose Real Server IP AddressesReal Server IP address

Server 10 200.2.2.10

Server 20 200.2.2.20



315394-J, January 2005


2. Define each local real server.

For each local real server, you must assign a real server number, specify its actual IP address,

and enable the real server. For example:

3. On the San Jose switch, define a real server group.

Server 20 200.2.2.20

>> Default gateway 1# /cfg/slb/real 10 (Configure Real Server 10)

>> Real server 10# rip 200.2.2.10 (Assign IP address to server 10)


>> Real server 10# /cfg/slb/real 20 (Configure Real Server 20)

>> Real server 20# rip 200.2.2.20 (Assign IP address to server 20)>> Real server 20# ena (Enable real server 20)


Combine the real servers into one service group and set the necessary health checking parame-ters. In this example, HTTP health checking is used to ensure that Web content is being served.

If the index.html file is not accessible on a real server during health checks, the real server

will be marked as down.

4. On the San Jose switch, define a virtual server.

All client requests will be addressed to a virtual server IP address defined on the switch. Cli-

ents acquire the virtual server IP address through normal DNS resolution. HTTP uses well-

known TCP port 80. In this example, HTTP is configured as the only service running on this

virtual server IP address and, is associated with the real server group. For example:

NOTE – This configuration is not limited to HTTP services. For a list of other well-known

TCP/IP services and ports, see Table 10-3 on page 192.




>> Real server group 1# health http (Use HTTP for health checks)>> Real server group 1# content index.html (Set URL content for health checks)

>> Real server group 1# /cfg/slb/virt 1 (Select virtual server 1)

>> Virtual server 1# vip 200.200.200.100 (Assign a virtual server IP address)

>> Virtual Server 1# service 80


>> Virtual server 1 http Service# /cfg/slb/virt 1 ena(Enable virtual

server)



315394-J, January 2005642 Chapter 21: Global Server Load Balancing

5. On the San Jose switch, define the type of Layer 4 traffic processing each port must sup-

port.


Table 21-2 GSLB Example: San Jose Alteon Switch Port Usage

Port Host Layer 4 Processing

4 Server 10 Server

3 Server 20 Server

2 Default Gateway Router. This connects the switch to the Internet

where all client requests originate.

Client



6. On the San Jose switch, enable SLB.

Task 3: Configure the San Jose Site for GSLB

1. On the San Jose switch, turn on GSLB.

2. Enable DSSP version 2 to send out remote site updates.

Unless you are in the middle of network migration from an Alteon OS version prior to 22.0

you should always enable DSSP version 2.

3. On the San Jose switch, define each remote site.

When you start configuring at the San Jose site, San Jose is local and Denver is remote. Add







>> SLB port 6# /cfg/slb/on

>> Virtual server 1# /cfg/slb/gslb/on

>> # /cfg/slb/gslb/version 2 (Enable DSSP version 2 updates)



315394-J, January 2005Chapter 21: Global Server Load Balancing 643

and enable the remote switch’s 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 com-

mands are used:

Each additional remote site would be configured 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.

>> # /cfg/slb/gslb/site 2 (Select remote site 2)

>> Remote site 2# name site_2 (Name remote site 2)

>> Remote site 2# prima 174.14.70.2 (Define remote interface)

>> Remote site 2# ena (Enable remote site 1)


Configure the local San Jose site to recognize the services offered at the remote Denver site.To do this, configure 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 configured with the remote virtual server IP address, i.e. Switch

2’s 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 traffic. 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:

NOTE – Take care to note where each configured value originates, or this step can result in

improper configuration.

5. On the San Jose switch, define the domain name and host name for each service hosted

>> # /cfg/slb/real 2 (Create an entry for real server 2)

>> Real server 2# rip 174.14.70.200 (Set remote virtual server IP address)

>> Real server 3# remote enable (Define the real server as remote)

>> Real server 3# inter 30 (Set a higher health check interval)

>> Real server 3# ena (Enable the real server entry)

>> Real server 3# /cfg/slb/group 1 (Select appropriate real server group)

>> Real server group 1# add 2 (Add real server 2 to the group 1)




5. On the San Jose switch, define 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 hostname for the only service (HTTP) is “www.” These values are configured as follows:

To define other services (such as FTP), make additional hostname entries.


>> Virtual server 1# dname gslb.example.com (Define domain name)

>> Virtual server 1# service 80/hname www (Define HTTP host name)



Examine the resulting information. If any settings are incorrect, make and apply any appropri-

ate changes, and then check again.


>> Global SLB# apply (Make your changes active)

>> Global SLB# cur (View current GSLB settings)

>> Global SLB# /cfg/slb/cur (View current SLB settings)






Task 4: Configure the Basics at the Denver SiteFollowing the same procedure described for San Jose (see “Example GSLB Topology” on

page 638), configure the Denver site as follows:

1. (Optional) On the Denver switch, configure management access, and management gate-

way address on the application switch.

2. 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 Alteon OS

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 Alteon OS Command Refer-

ence), configure it to use a different port.

For example, enter the following command to change the BBI port to 8080:





>> Management Port# ena (Enable the Mgmt. port)

>> # /cfg/sys/ wport 8080 (Set service port 8080 for BBI)


>> VLAN 102# add 2/ena (Add port 2 to VLAN 102 and enable)

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




Current ports for VLAN 102: emptyPending new ports for VLAN 102: 2

Current status: disabledNew status: enabled


4. Configure a VLAN for local server traffic, and add server ports to this VLAN.

5. Define an IP interface to the local real servers.


>> # /cfg/l2/vlan 202/name servers (VLAN 202 for local servers) >> VLAN 202# add 11/ena (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]: yCurrent ports for VLAN 202: emptyPending new ports for VLAN 202: 11Current status: disabled

New status: enabled>> VLAN 202# add 12/ena (Add port 12 to VLAN 201)

Port 11 is an UNTAGGED port and its current PVID is 1.Confirm changing PVID from 1 to 202 [y/n]: yCurrent ports for VLAN 202: emptyPending new ports for VLAN 202: 11 12
















9. Configure the local DNS server to recognize the local GSLB switch as the authoritative

name server for the hosted services.




>> # apply>> # save


Determine the domain name that will be distributed to both sites and the host name for eachdistributed service. In this example, the Denver DNS server is configured to recognize

174.14.70.2 (the IP interface of the Denver GSLB switch, configured with the domain name

“www.gslb.example.com”) as the authoritative name server for “www.example.com.”

Task 5: Configure the Denver Switch for Standard SLB

1. Assign an IP address to each of the real servers in the local Denver server pool.

2. On the Denver switch, define each local real server.

3. On the Denver switch, define a real server group.

Table 21-3 Denver Real Server IP Addresses

Real Server IP address

Server 11 174.14.7.11

Server 21 174.14.7.21

>> Default gateway 1# /cfg/slb/real 11 (Server C is real server 1)

>> Real server 11# rip 174.14.7.11 (Assign IP address for Server 11)


>> Real server 11# /cfg/slb/real 21 (Server D is real server 21)

>> Real server 21# rip 174.14.7.21 (Assign IP address for Server 21)




# (Add l 21 1)




4. On the Denver switch, define a virtual server.


>> Real server group 1# health http (Use HTTP for health checks)

>> Real server group 1# content index.html (Set URL content for health checks)


>> Virtual server 1# vip 174.14.70.200 (Assign IP address)

>> Virtual server 1# service http (Select the HTTP service menu)

>> Virtual server 1 http service# group 1 (Associate virtual port to real group)

>> Virtual server 1 http service# /cfg/slb/virt 1/ena(Enable the virtual server)


5. On the Denver switch, define the type of Layer 4 processing each port must support.



6. On the Denver switch, enable SLB.

Table 21-4 Web Host Example: Port Usage

Port Host Layer 4 Processing

11 Server 11 Server

12 Server 12 Server

2 Default Gateway Router. This connects the switch to the Internet

where all client requests originate.

Client

>> # /cfg/slb/port 11 (Select physical switch port 11)

>> SLB port 11# server ena (Enable server processing on port 11)>> SLB port 11# /cfg/slb/port 12 (Select physical switch port 12)




>> # /cfg/slb/on





Task 6: Configure the Denver Site for GSLBFollowing the same procedure described for San Jose (see “Task 3: Configure the San Jose Site

for GSLB” on page 643), configure the Denver site as follows:

1. On the Denver switch, turn on GSLB.

2. 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.

3. On the Denver switch, define each remote site.

When you start configuring at the Denver site, Denver is local and San Jose is remote. Add and

enable the remote switch’s 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:

Each additional remote site would be configured 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 configured to recognize the services offered at the remote

>> Virtual server 1# /cfg/slb/gslb/on

>> # /cfg/slb/gslb/version 2 (Enable DSSP version 2 updates)

>> # /cfg/slb/gslb/site 1 (Select remote site 1)

>> Remote site 1# prima 200.200.200.1 (Define remote IP interface address)

>> Remote site 1# ena (Enable remote site 1)




p, g g

San Jose site. As before, configure one real server entry on the Denver switch for each virtual

server located at each remote site. Since there is only one remote site (San Jose) with only onevirtual server, only one more local real server entry is needed at the Denver site.

The new real server entry is configured 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 inter-

face 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 traffic. The more remote sites you have, the

larger the time interval should be.


For example:

NOTE – Take care to note where each configured value originates or this step can result in


5. On the Denver switch, define 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 configured as follows:


>> Remote site 1# /cfg/slb/real 1 (Create an entry for real server 1)

>> Real server 1# rip 200.200.200.100 (Set remote virtual server IP address)


>> Real server 1# inter 30 (Set a high health check interval)


>> Real server 1# /cfg/slb/group 1 (Select appropriate. real server

group)>> Real server group 1# add 1 (Add real server 1 to group 1)


>> Virtual server 1# dname gslb.example.com (Define domain name)

>> Virtual server 1# service 80 (Select HTTP for virtual server)

>> Virtual server 1 http# hname www (Define HTTP hostname)

>> Global SLB# apply (Make your changes active)






Examine the resulting information. If any settings are incorrect, make and apply any appropri-

ate changes, and then check again.





Configuring a Standalone GSLB Domain

An Alteon 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 configured with an Alteon Application Switch running

GSLB, an Alteon Application Switch running only SLB, or even a site that uses another ven-dor’s load balancers.

An Alteon Application Switch running GSLB can operate in standalone mode as long as it uses

site selection metrics that do not require remote site updates.

GSLB Topology with a Standalone GSLB Site

San Jose– SLB Site 1 Denver– SLB Site 2200.200.200.X Network 174.14.70.X Network

Web Servers:200.2.2.10200.2.2.20VLAN 201

Web Servers:174.40.7.11174.40.7.21VLAN 202

10

20 21

11

IP Interface 101200.200.200.1

VIP: 200.200.200.100VLAN 101


IP Interface 102:174.14.70.2

VIP: 174.14.70.200VLAN 102


Alteon 2424 SLB 1 Alteon 2424 SLB 2

Internet

DNS Server

Default GW200.200.200.101

Default GW174.14.70.101

DNS Server




Figure 21-3 GSLB Topology Example 2—with Standalone GSLB

Tokyo– GSLB

43.10.10.X Network

IP Interface43.10.10.3

VLAN 103

Standalone

Alteon 2424 GSLBDefault GW43.10.10.103

DNS Server


Task 1: Configure the Basics at the Tokyo SiteFollowing a similar procedure as described in “Configuring Basic GSLB” on page

637, configure a third site—Tokyo—in Standalone mode.

Remember that in Standalone mode, the Alteon Application Switch does not require

SLB configuration of local real servers.

1. (Optional) On the Tokyo switch, configure management access and

management gateway address.






>> Management Port# ena (Enable the Mgmt Port)


>> VLAN 103# add 3 (Add port 3 to VLAN 103)

Port 3 is an UNTAGGED port and its current PVID is 1.Confirm changing PVID from 1 to 103 [y/n]: yCurrent ports for VLAN 103: emptyPending new ports for VLAN 103: 3Current status: disabledNew status: enabled









( g )






>> # apply>> # save


6. Configure the local DNS server to recognize the local GSLB switch as the authoritativename 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 configured to recognize

43.10.10.3 (the IP interface of the Tokyo GSLB switch) as the authoritative name server for

“www.gslb.example.com.”

Task 2: Configure the Tokyo Site for GSLBFollowing the similar procedure described for San Jose (see “Task 3: Configure the San Jose

Site for GSLB” on page 643), configure the Tokyo site as follows:

1. On the Tokyo switch, turn on SLB and GSLB.

2. On the Tokyo switch, assign each remote distributed service to a local virtual server.

In this step, the local site, Tokyo, is configured to recognize the services offered at the remote

San Jose and Denver sites. As before, configure one real server entry on the Tokyo switch for

each virtual server located at each remote site.

The new real server entry is configured 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 (Select the SLB Menu)

>> SLB# on (Activate SLB for the switch)

>> # /cfg/slb/gslb (Select the GSLB Menu)

>> Global SLB# on (Activate GSLB for the switch)

>> # /cfg/slb/real 1 (Create an entry for San Jose)





NOTE – Take care to note where each configured value originates, or this step can result in


( y)

>> Real server 1# name San_Jose (Set a name for the real server entry)

>> Real server 1# rip 200.200.200.100 (Set remote vip address of San Jose)>> Real server 1# remote enable (Define the real server as remote)

>> # /cfg/slb/real 2 (Create an entry for Denver)


>> Real server 2# name Denver (Set a name for the real server entry)

>> Real server 2# rip 74.14.70.200 (Set remote vip address for Denver)



3. Define a network that will match and accept all incoming traffic for the other sites.

4. Define a new rule that will make the new network active.


Examine the resulting information. If any settings are incorrect, make and apply

any appropriate changes, and then check again.


NOTE – Configuration for the Tokyo site is now complete.

>> # /cfg/gslb/net 1 (Create an entry for the new network)

>> Network 1# ena (Enable the new network)

>> Network 1# sip 0.0.0.0 (Define a source IP address match)

>> Network 1# mask 0.0.0.0 (Define a network mask match)

>> Network 1# addreal 1 (Add the San Jose site to the network)

>> Network 1# addreal 2 (Add the Denver site to the network)

>> # /cfg/slb/gslb/rule 1/ena (Enable the new rule)

>> Rule 1# dname gslb.example.com (Define a domain name)

>> Rule 1# metric 1/gmetric network (Define the metric this rule will use)

>> Rule 1# metric 1/addnet 1 ( Add network to the rule metric)

>> Virtual Server 2 http Service# apply (Make your changes active)








Configuring GSLB with Rules

GSLB rules can be configured 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 first rule that matches for the domain and starts with the first

metric in the metric preference list of the rule.

Up to 128 rules can be configured, with up to eight metrics per rule. The site selection metric

sequence in the default Rule 1 is as follows:

1. Network Preference

The first 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

configured, this metric is not used in the default rule. For more information on configuring pre-

ferred networks, see “Configuring GSLB Network Preference” on page 660.

2. None

The second metric in rule 1 is set to “None” in order to allow you to configure the local or

availability metric here. The local server or the server with the highest availability isselected 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-defined geo-

graphical region based on the client source IP is used to redirect the request to the client’s

region




region.

4. Least connections

5. Round robin

“Round robin” or random should be the last metric defined in a rule, because they always

return a value if there is at least one functional site.

6. None

7. None

8. None


The last metric in rule 1 should be configured as dnsalways so that the GSLB selectionselects at least the local virtual server when all servers are not available. In this case, metric 6

can be configured with DNS always.

Configuring Time-Based Rules

Task 1: Configure the first time-based rule

Using the base configuration “Configuring Basic GSLB” on page 637, you can define a new

time-based rule for certain networks, as follows:

1. Disable the default rule 1, in order to ensure that the time based rule is processed first.

2. Configure the networks to be added to the GSLB rule.

3. Configure a new rule.

4. Specify a start and end time for this rule to be applied.

>> # /cfg/slb/gslb/rule 1/dis (Disable rule 1)

>> # /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

>> # /cfg/slb/gslb/rule 2 (Select rule 2)

>> Rule 2# start 7 00/end 18 00/ena (From 7am until 6PM)

>> Rule 2# ena (Enable the rule)




5. Specify the GSLB metrics to be used to select a site if a server is not selected at first.

Since network metric is the first metric, make sure to add the configured networks to metric 1.

6. Specify the other preferred GSLB metrics.

>> # /cfg/slb/gslb/rule 2/metric 1/gmetric network>> # /cfg/slb/gslb/rule 2/metric 1/addnet 43/addnet 55/addnet 56

>> # /cfg/slb/gslb/rule 2/metric 2/gmetric geographical>> # /cfg/slb/gslb/rule 2/metric 3/gmetric roundrobin


Task 2: Configure the second time-based ruleUsing the steps in “Task 1: Configure the first time-based rule” on page 657, configure another

rule with the following parameters.

7. Add the rule to the configured virtual server. Using the basic GSLB example, add the fol-

lowing command to the virtual server configuration steps on page 644 on page 651.


>> # /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

>> # /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





Using the Availability Metric in a RuleThe availability metric selects the next server in a priority list when any capacity thresholds of

the previous servers has been reached.

1. Set the availability metric for metric 2 in rule 1.

2. Set the Availability values for the real/virt servers. For example:


>> # /cfg/slb/gslb/rule 1/metric 2/gmetric availability

>> Rule 1# /cfg/slb/virt 1/avail 11 (Set avail. weight for virt. server)

>> Rule 1# /cfg/slb/real 10/avail 22 (Set avail. weight for real server)

>> Rule 1# /cfg/slb/real 11/avail 33 (Set avail. weight for real server)

>> Rule 1 Metric 4# apply>> Rule 1 Metric 4# save





Configuring GSLB Network PreferenceAlteon OS software allows clients to select GSLB sites based on where the client is located. This

is implemented by configuring network preference. Network preference selects the server based

on the preferred network of the source IP address for a given domain. The preferred network con-

tains a subset of the servers for the domain.

The following example, illustrated in Figure 21-4 on page 661, shows how to create rules based on client network preference. Two client networks, A and B, are configured in the net-

work preference rule on the master switch at Site 4. Client A with a subnet address of

205.178.13.0 is configured with a network preference rule for preferred Sites 1 and 3. Client B,

with a subnet address of 204.165.0.0, is configured 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 configured to forward requests to the DNS server at Site

4. The Alteon Application Switch at Site 4 looks up its network preference and finds Client A

prefers to connect to Sites 1 or 3. Similarly, Client B’s requests are always forwarded to Sites 2

or 4.

Internet

Client Site B

DNS

Request

Client Site A

DNS

Request

205.178.13.0 204.165.0.0

IF: 1.1.1.1 / 24

VIP: 1.1.1.100

IF: 2.2.2.2 / 24 IF: 3.3.3.3 / 16

IF: 4.4.4.4 / 24

VIP: 4.4.4.100

WebServers

WebServers

DNS DNS

DNS DNS


Site 3Site 2

Site 4Site 1

WebServers

WebServers




Master switch returns

Client's request with theVIP of the preferred site

2. The master switch looks through itsnetwork preference rule, and responds tothe DNS request by providing the virtual

IP address of the preferred site.

3. The client sends out a new request and connects to the preferred site.

Prefers

Sites 1 and 3Prefers

Sites 2 and 4

1. Client sites A and B send requests to

their DNS servers which are forwarded to the master switch at Site 4.




Figure 21-4 Configuring Client Proximity Table

NOTE – Alteon OS allows you to configure up to 128 preferred client networks. Each network

can contain up to 1023 real servers.

VIP: 2.2.2.100 VIP: 3.3.3.100


Use the following commands to configure network preferences on the application switch at

Site 4:

Using this configuration, 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.

>> # /cfg/slb/gslb/net 1/ (Select Network 1)

>> Network 1# sip 205.178.13.0 (Assign source address for Client A )

>> Network 1# mask 255.255.255.0 (Assign the mask for Client A )

>> Network 1# addreal 1/addreal 3 (Add real servers 1 and 3)

>> # /cfg/slb/gslb/net 2/(Select Network 2)

>> Network 2# sip 204.165.0.0 (Assign source address for Client B )

>> Network 2# mask 255.255.0.0 (Assign the mask for Client B )

>> Network 2# addreal 2 (Add real server 2)

>> Network 2# addvir 4 (Select preferred Site 4)

>> # /cfg/slb/gslb/rule 1/metric 1 (Select metric 1-network preference)

>> Rule 1 Metric 2# addnet 1/addnet 2 (Add Network 1 and Network 2)





Configuring 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 redirectionfunction in these applications requires that a proxy IP address be configured on the client port.

The client port will initiate a redirect only if resources are unavailable at the first 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 Alteon

Application Switches.





Figure 21-5 illustrates the packet-flow of HTTP and non-HTTP redirects in a GSLB environ-

ment. Table 21-5 explains the packet -flow 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.

Table 21-5 HTTP Versus Non-HTTP Redirects

Site 2 Alteon Switch Site 1 Alteon Switch

HTTP application(built-in redirection)

1a Client HTTP request reaches Site 2.Resources are unavailable at Site 2.

Site 2 sends an HTTP redirect to Client with

Site 1’s virtual server IP address.

2a. Client resends request to Site 1.Resources are available at Site 1.

Non-HTTP application

(no redirection

1b. Client non-HTTP request reaches Site 2.

Resources are unavailable at Site 2.

Site 2 sends a request to Site 1 with Site 2’s

proxy IP address as the source IP address and

the virtual server IP address of Site 1 as the des-tination 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.

1aa2aa

Client Site

Client Request

Site 1

Alteon ApplicationAlt A li ti

Site 2

HTTP ApplicationsNon HTTP Applications

DNS




Figure 21-5 HTTP and Non-HTTP Redirects

1b

WebServersWeb

ServersDNS



Proxy IP address isconfigured on Clientport for non-HTTPapplications.

2b


How Proxy IP WorksFigure 21-6 shows examples of two GSLB sites deployed in San Jose and Denver. The appli-

cations 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.

Figure 21-6 POP3 Request Fulfilled via IP Proxy

The following procedure explains the three-way handshake between the two sites and the cli-ent for a non-HTTP application (POP3).

1. 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.

2. 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

Proxy Disabled ForLocal Real Servers

Proxy Enabled ForRemote Server

San Jose Site #1174.14.70.X Network

A

B C

D

Proxy Disabled ForLocal Real Servers

Proxy IP Address174.14.70.4

Proxy IP Address200.200.200.4

Internet

200.200.200.X Network

HTTP/POP3Local Servers

200.200.200.2200.200.200.3

Remote Server174.14.70.1

Alteon

Application

Switch

Virtual Server200.200.200.1

Denver: Site #2

HTTP/POP3Local Servers

174.14.70.2174.14.70.3

Remote Server200.200.200.1

Virtual Server174.14.70.1

Service requests are always served by

local real servers if available.

If local real servers cannot service the request,

the remote server is used via proxy.

Alteon

Application

Switch

Proxy Enabled ForRemote Server

6 4




address.

3. 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.

4. Internally at Site 1, the switch and the real servers exchange information. The TCP SYN

ACK from Site 1’s local real server is sent back to the IP address specified by the proxy IP

address.

5. The Site 1 switch sends the TCP SYN ACK frame to Site 2, with Site 1’s virtual server IPaddress as the source IP address, and Site 2’s proxy IP address as the destination IP

address.


6. The switch at Site 1 receives the frame and translates it, using Site 1’s virtual server IP

address as the source IP address and the client’s IP address as the destination IP address.

This cycle continues for the remaining frames to transmit all the client’s mail, until a FIN

frame is received.

Configuring Proxy IP Addresses

The switch at Site 1 in San Jose is configured with switch port 6 connecting to the default gate-way and real server 3 represents the remote server in Denver.

The following commands are used at Site 1 in San Jose to configure the proxy IP address for

the remote server in Denver:


If you want to configure proxy IP addresses on Site 2, the following commands are issued on

the Denver switch:

>> # /cfg/slb/pip (Select proxy IP address menu)


>> Proxy IP address# add 200.200.200.4 (Set unique proxy IP address)

>> # /cfg/slb/port 6/proxy enable (Enable proxy on the port)

>> Proxy IP address /cfg/slb/real 1/proxy dis(Disable local 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 (Apply configuration changes)

>> Real server 3# save (Save configuration changes)

>> # /cfg/slb/pip (Select proxy IP address menu)


>> Proxy IP address# add 174.14.70.4 (Set unique proxy IP address)






>> 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 (Apply configuration changes)

>> Real server 3# save (Save configuration changes)


Using Border Gateway Protocol for GSLBBorder Gateway Protocol (BGP)-based GSLB utilizes the Internet’s routing protocols to local-

ize content delivery to the most efficient and consistent site. This is done by using a shared IP

block that co-exists in each Internet Service Provider’s (ISP’s) network and is then advertised,

using BGP, throughout the Internet.

Because of the way IP routing works, BGP-based GSLB allows for 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 bydistributing the IP blocks that contain that content to several sites.

When using DNS to select the site, a single packet is used to make 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 efficient, 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 provid-ers 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 traffic 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 theGSLB configuration. If one site is saturated, then the switch will failover and deliver the IP

address of a more available site.

For more information on configuring your switch to support BGP routing, see “Border Gate-

way Protocol” on page 129.


Verifying GSLB Operation Use your browser to request the configured service ( www.gslb.example.com in the previ-

ous 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 configuration changes and then check the informationagain.

Examine the /stats/slb and /stats/slb/gslb statistics on each switch.




CHAPTER 22

Bandwidth Management

Bandwidth Management (BWM) enables Web site managers to allocate a portion of the avail-

able bandwidth for specific users or applications. It allows companies to guarantee that critical

business traffic, such as e-commerce transactions, receive higher priority versus non-critical

traffic. Traffic classification can be based on user or application information. BWM policies

can be configured to set lower and upper bounds on the bandwidth allocation.


“Enabling Bandwidth Management” on page 670

“Contracts” on page 671

“Policies” on page 677

“Rate Limiting” on page 679

“Traffic Shaping” on page 681

“Bandwidth Management Information” on page 682

“Packet Coloring (TOS bits) for Burst Limit” on page 684

“Configuring Bandwidth Management” on page 684

“Additional BWM Configuration Examples” on page 688



315394-J, January 2005669


Enabling Bandwidth ManagementTo 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 certificate.

There are two operational keys for BWM: a standard key and a demo key. The demo key auto-

matically 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:

1. Connect to the switch command line interface via Telnet or the console port, and login as

the administrator, following the directions in the Alteon OS Command Reference.

2. 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 switch’s MAC

address, the switch will accept the password, permanently record it in the switch’s non-volatile

RAM (NVRAM), and will then enable the feature.



315394-J, January 2005670 Chapter 22: Bandwidth Management


ContractsA contract is created to assign a certain amount of bandwidth. Up to 256 contracts can be con-

figured on a single Alteon Application Switch. The switch uses these contracts to limit individ-

ual traffic flows. Contracts can be assigned to different types of traffic. Traffic can be

classified based on layer 2, layer 4, or layer 7 traffic. Traffic classification can be based on the

following: port, VLAN, trunk, filters, virtual IP address, service on the virtual server, URL,

and so on.

Any item that is configured with a filter can be used for BWM. Bandwidth classification is per-

formed using the following menus:

/cfg/slb/filt is used to configure classifications based on the IP destination address,

IP source address, TCP port number, UDP, UDP port number, 802.1p priority value, or

any filter rule.

/cfg/slb/virt is used to configure classifications based on virtual servers. /cfg/port is used to configure classifications based on physical ports.

(In case of trunking, use /cfg/l2/trunk.)

/cfg/l2/vlan is used to configure classifications based on VLANs.

/cfg/slb/layer7/lb is used to configure classification based on URL paths.

To associate a particular classification with a contract, enter the contract index into the

“cont” menu option under the applicable configuration menus.



315394-J, January 2005Chapter 22: Bandwidth Management 671


When Virtual Matrix Architecture (VMA) is enabled, traffic classification is done on the

ingress port —that is, the port on which the frame is received (not the client port or the server

port ). If the traffic classification is done on layer 4 through layer 7 traffic (filter-based or SLB

traffic), then the classification occurs on the designated port .

Figure 22-1 Bandwidth Management: How It Works

Classification Rules

In a classification rule certain frames are grouped together. For frames qualifying for multiple

classifications, precedence of contracts is also specified per contract. If no precedence is spec-

ified, the default order is used (see “Classification Precedence” on page 673).

The following classifications are aimed at limiting the traffic outbound from the server farm

Internet

1. A client accesses a

site's VIP address

2. The VIP address has been

assigned a bandwidth contractand policy.

3. Frames are classified

on ingress port of switch

4. Bandwidth management contract is applied

on the egress port of switch. Can optionally

set TOS values to reflect usage rate

5. TOS value (optional) can be assigned to

affect the upstream router's bandwidth





The following classifications are aimed at limiting the traffic outbound from the server farm

for bandwidth measurement and control.

Physical Port - All frames are from a specified physical port.

VLAN - All frames are from a specified VLAN. If a VLAN translation occurs, the band-

width policy is based on the ingress VLAN.

IP Source Address - All frames have a specified IP source address or range of addresses

defined with a subnet mask.

IP Destination Address - All frames have a specified IP destination address or range of

addresses defined with a subnet mask.

Switch services on the virtual servers


The following are various Layer 4 groupings:

A single virtual server

A group of virtual servers

A service for a particular virtual server

Select a particular port number (service on the virtual server) within a particular vir-

tual server IP address.

The following are various Layer 7 groupings:

A single URL path

A group of URL paths

A single cookie

Classification Precedence

If a frame qualifies for different classifications, it is important to be able to specify the classifi-

cation with which it should be associated. There are two mechanisms to address classifica-tion—a 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 prece-

dence value, then the default ordering is applied as follows:

1. Incoming source port/default assignment

2. VLAN

3. Filter

4. Layer 4 services on the virtual server

5. Layer 7 applications (for example, URL, HTTP, headers, cookies, and so forth

If a frame falls into all of classifications #1–5, and if the precedence is same for all the applica-

ble contracts, then the Layer 7 applications contract classification (#5) will be assigned since it

comes last and has the highest presentness




comes last and has the highest presentness.


Application Bandwidth Control

Classification policies allow bandwidth limitations to be applied to particular applications; that

is, they allow applications to be identified and grouped. Classification can be based on any fil-

tering rule, including those listed below:

Layer 7 strings that identify which application the traffic belongs to

TCP Port Number - All frames with a specific TCP source or destination port number

UDP - All UDP frames

UDP Port Number - All frames with a specific UDP source or destination port number

Combinations

Combinations of classifications 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 filters in this manner.

“Grouped Bandwidth Contracts” on page 674 describes how the contracts can be grouped

together to aggregate BWM resources.

“IP User Level Contracts for Individual Sessions” on page 676 describes a user level contract.

Grouped Bandwidth Contracts

Alteon OS 22.0 introduces the concept of multi-tiered, or grouped bandwidth management

contracts. In earlier Alteon OS releases, a single level bandwidth management contract was

used to manage bandwidth on an Alteon Application Switch. BWM contract groups can now

be configured to aggregate contract resources and share unused bandwidth within the contract

group. A group level contract should contain two or more individual contracts as defined in

“Contracts” on page 671.

Based on how much traffic is sent in each contract in the group, the hard limits of the contracts




Based on how much traffic 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 configured 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 mem-

bers of the contract group by polling bandwidth statistics every second, and re-calculating the

bandwidth allocation.

Table 22-1 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 1–4 are part of a contract group, the Total hard limit allowed for the group in this

example is 100 Mbps.


The actual traffic 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 proportion-

ately between the two contracts that exceeded their hard limits—Contracts 1 and 4.

Contract 1 requests 15 Mbps, which is 5 Mbps over its hard limit. Because Contract 1

requested 5 of the 25 Mbps BW over the total BW Hard Limit for the contract group, it

will thus receive one-fifth of the available Extra Share, or 2 Mbps. The remaining 3 Mbps

that Contract 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-fifths of the Extra Share, or 12 Mbps. The remaining 12 Mbps requested

by Contract 4 is dropped.

Table 22-1 Bandwidth Reallocation in Grouped Contracts

Contract 1 Contract 2 Contract 3 Contract 4 Total

Hard Limit (Mbps) 10 20 30 40 100

Actual traffic 15 20 20 60 115

Unused BW NA NA 10 NA 10

BW over Hard 5 0 NA 20 25

Extra Share a

a. Denotes the BW over hard limit in Contract 1, divided by the Total BW over hard limit for the con-tract group multiplied by the total Extra Share bandwidth

0 NA b 10

Adjusted Hard Limit 12 20 20 48 100

(All units in Mbps)

x10 2= x10 8=




, ytract 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 con-

tract group, multiple by the total Extra Share bandwidth.


The soft and reserved (CIR) limits of each contract are not part of the grouped contract’s calcu-

lation, and remain set at their individual contract’s levels.

For a group contract configuration example, see “Configuring Grouped Contracts for Band-

width Sharing” on page 690.

IP User Level Contracts for Individual Sessions

Alteon OS 22.0 introduces user limits for bandwidth management. User limits are policies thatcan be applied to a contract that specify a rate limit for each user who is sending or receiving

traffic in that contract. Each user is identified by his/her IP address. The contract can be config-

ured 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 user’s IP

address, monitoring the amount of bandwidth used per second, and dropping any traffic that

exceeds the configured limit. In order to monitor a user’s bandwidth, the switch creates a user

entry that records the source or destination IP address, and the amount of bandwidth used. Thisuser entry is called an IP user entry, because the user is identified by his/her IP address.

The user limit feature is extremely useful for limiting bandwidth hogging by a few overactive

internet users with unimportant traffic (for example peer-to-peer movie sharing), which may

end up denying the other users with legitimate traffic from their fair share. Since the user limit-

ing is done on per-contract basis, different types of traffic can be classified into different con-

tracts and can have different user limits applied according to the class of traffic. Also, since

user limiting for a contract is optional, it can be configured for some contracts with class of

traffic where fair sharing of bandwidth is important, and not configured 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 configured in addition to the contract's hard limit. However, the contract’s




hard limit overrides the individual user entry's 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

traffic rate of 1 Mbps each (for total offered traffic rate for the contract 20 Mbps), the total traf-

fic 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 traffic dropped because the contract’s hard limit (10 Mbps) is less than the

total of the offered traffic 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 traffic rate of 5 Mbps each (total offered

traffic rate for the contract 10 Mbps). Even though the offered traffic rate for the whole con-

tract does not exceed the hard limit, Alteon OS will limit the traffic for both the IP users to

their user limits: 1 Mbps each.

The user limit configured for a contract will be the limit for one egress SP rather than the entire

switch. For example; on an Alteon Application Switch 2424, if a contract is configured for a

user limit of 64 kbps—and traffic for a user (IP address) is egressing port 1 (SP 1) and 20 (SP2) — that user (IP address) will be restricted to 64 kbps egressing on port 1 and 64 kbps egress-

ing out on port 20.

For an example, see “Configuring a IP User-Level Rate Limiting Contract” on page 694.

Policies

Bandwidth policies are bandwidth limitations defined 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 pro-

vider could charge a customer for bandwidth utilization. There are three rates that are config-

ured: a Committed Information Rate (CIR)/Reserved Limit, a Soft Limit, and a Hard Limit, asdescribed 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 classifications 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 band-

width policies can be defined. 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 configured to apply different time policies defined by ranges of hours

or days of the week. The time policy is based on the time set in the switch’s system clock

(/info/sys/general).

“Configuring Time and Day Policies” on page 708 describes how to configure and apply poli-

cies 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.

Even when BWM is not enforced, the Alteon Application Switch can still collect classification

information and report it, allowing an administrator to observe a network for a while before

deciding how to configure 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 LimitingA rate limiting contract is controlled by metering the traffic that egresses from the switch. If

the egress rate is below the configured rate limit (hard limit) for the port, the traffic is transmit-

ted immediately without any buffering. If the egress rate is above the configured rate limit the

traffic above the rate limit is dropped.

Figure 22-2 Bandwidth Rate Limits

For rate limiting contracts, the queue depth is ignored because traffic is not buffered.

Typically, bandwidth management occurs on the egress port of the switch—that 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).

Hard Limit

Soft Limit

Reserved Limit

User Limit





A bandwidth policy specifies four limits, listed and described in Table 22-2:

Table 22-2 Bandwidth Rate Limits

Rate Limit Description

Committed Information

Rate (CIR)

or Reserved Limit

This is a rate that a bandwidth classification is always guaranteed. In con-

figuring BWM contracts, ensure that the sum of all committed information

rates never exceeds the link speeds associated with ports on which the traf-

fic is transmitted. In a case where the total CIRs exceed the outbound port

bandwidth, the switch will perform a graceful degradation of all traffic onthe associated ports.

Soft Limit 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 band-

width 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.

Hard Limit 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 pol-

icy 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.

User Limit A user limit is a Hard Limit rate for individual users. It is defined as a pol-

icy 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




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 net-

work.

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.


Rate Limiting Timeslots

For rate limiting contracts, metering of individual traffic flows is accomplished using several

timeslots per second. The timeslot traffic limit is the traffic that is sent for a particular contract

for every timeslot corresponding to the contract’s rate limit or the hard limit is initially calcu-

lated.

For any contract there is one timeslot traffic limit for each egress port. The timeslot traffic limit

is calculated from the hard limit. The timeslot traffic limit is the amount of traffic that corre-

sponds to the hard limit per second divided by the number of timeslots per second.

Traffic is transmitted for every timeslot as long as the traffic is below the timeslot traffic limit

for the contract. Any traffic that exceeds the timeslot traffic is discarded.

Traffic Shaping

A traffic shaping contract establishes queues and schedules when frames are sent from each

queue. Traffic 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 con-

figured 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 traffic 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

traffic (such as audio) versus drop-sensitive traffic (such as FTP).

Data Pacing for Traffic Shaping Contracts




Data Pacing for Traffic Shaping Contracts

The mechanism used to keep the individual traffic flows under control in a traffic shaping con-

tract is called data pacing . It is based on the concept of a real-time clock and theoretical depar-

ture times (TDT). The actual calculation of the TDT is based initially on the configured soft

limit rate. The soft limit can be thought of as a target limit for the ISP’s customer. As long as

bandwidth is available and the classification queue is not being filled at a rate greater than the

soft limit, the TDT will be met for both incoming frames and outgoing frames and no borrow-


ing or bandwidth limitation will be necessary. If the classification 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.

Figure 22-3 shows a simple illustration of how data may be paced in a traffic shaping contract.

Six arriving frames are processed differently depending on rate of the queue. Queue 1 pro-

cesses each packet evenly. Queue 2 processes per 1500 bytes and inserts some delay as it pro-

cesses the first 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.

Figure 22-3 Real-time Clocks and Theoretical Departure Times

If the data is arriving more quickly than it can be transmitted at the soft limit and sufficient

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 trans-

mitted or the CIR is hit. If the CIR is overcommitted among all the contracts configured for the

switch, graceful degradation will reduce each CIR until the total bandwidth allocated fits

within the total bandwidth available.

Ingressing frames **** **

Egressing Frames

1. Per packet | | | | | |

2. Per 1500 bytes ||| |||

3. Per 3000 bytes |||| ||

Time

Key* Indicates a single fixed size 500 byte frame being received.| Indicates a single fixed size 500 byte frame being sent.




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 forsome classifications 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.

Configuring BWM History

History is maintained only for the contracts for which the history option is enabled (/cfg/bwm/cont x/hist).

Sending BWM History

Via E-Mail

The MP maintains some global statistics, such as total octets and a window of historical statis-tics. When the history buffer of 128K is ready to overflow, it can be optionally e-mailed to a

user for long-term storage.

To configure the switch to send the history buffer to the user, enter the following commands:

To obtain graphs, the data must be collected and processed by an external entity through

SNMP or through e-mailed logs.

If SMTP is enabled, then the info command (/info/bwm ) can display when the history sta-

tistics will be e-mailed to a user.

Statistics and Management Information Bases

/cfg/bwm/user <e-mail username, e.g. johnd> (Set the e-mail username)

/cfg/sys/smtp <SMTP host name or IP address> (At this SMTP mail server host)/oper/bwm/sndshist (E-mail BWM history now)




Stat st cs a d a age e t o at o ases

For existing BWM classes:

As mentioned above, the MP maintains per-contract rate usage statistics. These are obtain-

able via a private MIB.

When BWM services are not enabled:


Even when BWM is not enforced, the MP can still collect classification information and

report it, allowing an administrator to observe a network for a while before deciding howto configure 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 Configurations in VRRP

BWM configurations will optionally be synchronized to a backup switch during VRRP syn-

chronization. However, port contracts and VLAN contracts will not be synchronized. For moreinformation on VRRP and synchronized configurations, see “Configuring VRRP Peers for

Synchronization” on page 511.

Packet Coloring (TOS bits) for Burst Limit

Whenever the soft limit is exceeded, optional packet coloring can be done to allow down-stream 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-profile frames. Frames that are not out-of -pro-

file 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 traffic

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 spec-

ified should match the appropriate diff-serv specification but could be different, depend-

ing on the customer environment.

Configuring Bandwidth Management

The following procedure provides general instructions for configuring BWM on the switch




The following procedure provides general instructions for configuring BWM on the switch.

Specific configuration examples begin on page 688.

1. Configure the switch as you normally would for SLB. Configuration includes the follow-

ing tasks:








For more information about SLB configuration, see Chapter 10, “Server Load Balancing.”

2. Enable BWM on the switch.

NOTE – If you purchased the Bandwidth Management option, make sure you enable it by typ-

ing /oper/swkey and entering its software key. For more information, see “Enabling Band-

width Management” on page 670.

3. Select a bandwidth policy.

Each policy must have a unique number from 1 to 64.

4. 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” suffix to the number.

5. (Optional) Set the Type-Of-Service (TOS) byte value, between 0-255, for the policyunderlimit and overlimit.

>> # /cfg/bwm/on (Turn BWM on)

>> Bandwidth Management# pol 1 (Select bandwidth policy 1)

>> Policy 1# hard 6 (Set “never exceed” rate)

>> Policy 1# soft 5 (Set desired bandwidth rate)

>> Policy 1# resv 4 (Set committed information rate)




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 traffic for

a contract is under or over the soft limit, respectively. These values only have significance 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.

6. 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.

7. 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.

8. (Optional) Set a precedence value for the BWM contract.

Each contract can be given a precedence value from 1-255. The higher the number, the higher

the precedence. If a frame is applicable to different classifications, then the contract with

higher precedence will be assigned to the frame. If the precedence is the same for the applica-

ble 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

>> Policy 1# utos 204 (Set BWM policy underlimit)

>> Policy 1# otos 192 (Set BWM policy overlimit)

>> Policy 1# buffer 16320 (Set BWM policy buffer limit)

>> Policy 1# /cfg/bwm/cont 1 (Select BWM contract 1)

>> BWM Contract 1# name BigCorp (Assign contract name “BigCorp”)

>> BWM Contract 1# prec 1 (Sets contract precedence value to 1)




9. (Optional) Enable TOS overwriting for the BWM contract.

10. Set the bandwidth policy for this contract.

Each bandwidth management contract must be assigned a bandwidth policy.

>> BWM Contract 1# wtos ena (Enables TOS overwriting for

contract)

>> BWM Contract 1# pol 1 (Assign policy 1 to BWM contract 1)


11. (optional) Enable traffic shaping.

Rate limiting is enabled by default. Enabling traffic shaping automatically disables rate limit-

ing. See “Traffic Shaping” on page 681 for more information.

12. Enable the BWM contract.

13. Classify the frames for this contract and assign the BWM contract to the filter or virtual

IP address.

Each BWM contract must be assigned a classification rule. The classification can be based on

a filter or service(s) on the Virtual server. Filters are used to create classification policies based

on the IP source address, IP destination address, TCP port number, UDP, and UDP port num-

ber.

In this case, all frames that match filter 1 or virtual server 1 will be assigned contract 1.

14. On the switch, apply and verify the configuration.

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

15. On the switch, save your new configuration changes.

16 O th it h h k th BWM i f ti

>> BWM Contract 1# shaping e (Enables traffic shaping)

>> BWM Contract 1# ena (Enables this BWM contract)

>> BWM Contract 1# /cfg/slb/virt 1/cont 1 (Assign contract to virtual server)

>> Virtual Server 1# /cfg/slb/filt 1/adv/cont 1(Assign contract 1 to filter 1)

>> Filter 1 Advanced# apply (Make your changes active)

>> Filter 1 Advanced# /cfg/bwm/cur (View current settings)

>> Bandwidth Management# save (Save for restore after reboot)




16. On the switch, check the BWM information.

Check that all BWM contract parameters are set correctly. If necessary, make any appropriate

configuration changes and then check the information again.

>> Bandwidth Management# /info/bwm <contract number>(View BWM information)

>> Bandwidth Management# /stats/bwm <contract number>(View BWM statistics)


Additional BWM Configuration ExamplesExamples are provided for the following Bandwidth Management applications:

Configuring User/Application Fairness: page 688

Configuring Grouped Contracts for Bandwidth Sharing: page 690

Configuring a IP User-Level Rate Limiting Contract: page 694

Configuring BWM Preferential Services: page 695

Configuring Content Intelligent Bandwidth Management: page 698

Configuring Cookie-Based Bandwidth Management: page 703

Configuring Security Management: page 706

Configuring Time and Day Policies: page 708

Configuring Egress Bandwidth Tuning for Connections to Lower Speed Networks: page710

Configuring Intelligent Traffic Management: page 711

NOTE – Ensure BWM is enabled on the switch (/cfg/bwm/on).

Configuring 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 flash crowd

FTP locking out Telnet

Rate limits of particular applications

In the following example BWM is configured to prevent broadband customers from affecting




In the following example, BWM is configured 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 traffic.

Policy 1 is for dialup customers with lower bandwidth allocation needs

Policy 2 is for broadband customers with higher bandwidth allocation needs.

1. Select the first bandwidth policy for dialup customers.

Each policy must have a number from 1 to 512.



2. Set the hard, soft, and reserved rate limits for the bandwidth policy, in Mbps.

3. On the switch, select a BWM contract and name the contract.



Each BWM contract must be assigned a bandwidth policy.

5. Enable this BWM contract.

6. Select the second bandwidth policy for broadband customers.

7. Set the hard, soft, and reserved rate limits for this policy, in Mbps.

>> # /cfg/bwm/pol 1 (Select BWM policy 1)


>> Policy 1# soft 4 (Set desired bandwidth rate)>> Policy 1# resv 3 (Set committed information rate)


>> BWM Contract 1# name dial-up(Assign contract name “dial-up”)

>> BWM Contract 1# pol 1 (Assign policy 1 to BWM Contract 1)


>> BWM Contract 1# /cfg/bwm/pol 2 (Select bandwidth policy 2)





8. On the switch, select the second BWM contract and name the contract.

>> Policy 2# hard 30 (Set never exceed rate)




>> BWM Contract 2# name broadband (Assign contract name “broadband”)





11. Assign the BWM contracts to different switch ports.

Physical switch ports are used to classify which frames are managed by each contract—that is,

one BWM contract will be applied to all frames from a specific port. The second contract will

be applied to all frames from another specified port.








>> BWM Contract 2# /cfg/port 1/cont 1 (Assign contract 1 to port 1)

>> Port 1# /cfg/slb/port 2/cont 2 (Assign contract 2 to port 2)

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

>> Port 2# /cfg/bwm/cur (View current BWM settings)


>> Bandwidth Management# /info/bwm <contract number> (View BWM information)





Configuring Grouped Contracts for Bandwidth Sharing

In the following example, BWM is configured to allow sharing of BWM resources by config-

uring a group contract. While the group hard limit will be essentially the aggregate of the hard

limits defined for each contract in the group, any unused bandwidth may be shared amongst all

member contracts.


For example, a group level contract is defined with four individual contracts that have commit-

ted information rates (CIR) of 10, 20, 30, and 40 Mbps each. Together, the total CIR of themember contracts is 100 Mbps. Based on how much traffic is actually being sent by all the

contracts in the group, the hard limits of each contract are readjusted every few seconds, in

proportion to each contract’s 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 traffic above its configured 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 Table 22-1 “Bandwidth Reallocation in Grouped Contracts” on page 675.

NOTE – While traffic shaping contracts may be added to a group level contract, their soft and

reserved limits are not readjusted.

1. Ensure BWM is enabled on the switch.


ing tasks:







3. Select the first bandwidth policy and set the hard, soft, and reserved rate limits for the

bandwidth policy, in Mbps.

>> /cfg/bwm/on


>> Policy 1# hard 10M (Set “never exceed” rate)

i # (S d i d b d id h )




4. Configure BWM contract 1.


>> Policy 1# soft 5M (Set desired bandwidth rate)

>> Policy 1# resv 1M (Set committed information rate)



5. Assign the bandwidth policy 1 to contract 1.

6. Enable contract 1.

7. Select bandwidth policy 2.


9. On the switch, select BWM contract 2.

10. Assign bandwidth policy 2 to contract 2.


11. Enable contract 2.

>> BWM Contract 1# pol 1 (Assign policy 1 to BWM Contract 1)


>> BWM Contract 1# /cfg/bwm/pol 2 (Select bandwidth policy 2)



>> Policy 2# resv 10 Set committed information rate)








12. Using the same CLI commands as described above, configure policy 3 with hard, soft,

and reserved limits of 30, 25, and 20 Mbps respectively. Then create contract 3 and applypolicy 3 to this contract.

13. Configure policy 4 with hard, soft, and reserved limits of 40, 35, and 30 Mbps respec-

tively. Then create contract 4 and apply policy 4 to this contract.

14. Assign the BWM contracts to different switch ports.

Physical switch ports are used to classify which frames are managed by each contract—that is,

one BWM contract will be applied to all frames from a specific port. The second contract will

be applied to all frames from another specified port.

15. Configure BWM contract group 1 and add all four contracts to this group.



>> BWM Contract 4# /cfg/port 1/cont 1 (Assign contract 1 to port 1)

>> Port 1# /cfg/port 2/cont 2 (Assign contract 2 to port 2)



>> /cfg/bwm/group 1 (Select contract group 1)

>> BW Group 1# add 1 (Add contract 1 to group 1)

Contract 1 added to group 1.>> BW Group 1# add 2 (Add contract 2 to group 1)



Contract 4 added to group 1.

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

>> Port 2# /cfg/bwm/cur (View current BWM settings)





18. Check the BWM information.


>> Bandwidth Management# /info/bwm <contract number> (View BWM information)




Configuring a IP User-Level Rate Limiting Contract

The following example is for university that wants to restrict the amount of TCP traffic for

individual students and for the student body as a whole. Contract 1 is configured as follows:

Each student (IP address) is limited to 64 kbps.

All members of the student body is limited to maximum (hard limit) 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 student’s 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 traffic within the

configured user limit of 64 kbps.

The administrator would setup a configuration as follows:

1. Select the first bandwidth policy.


2. Configure the BWM policy with a Hard Limit of 10 Mbps and a “user limit” of 64 kbps.

Then apply that policy to Contract 1.

3. Configure a filter to match the source IP address range of the student body, and assign

BWM Contract 1 to that filter


>> Policy 1# hard 10m >> Policy 1# userlim 64k>> Policy 1# /cfg/bwm/cont 1 (Select contract 1)

>> BW Contract 1# policy 1(Apply policy 1 to this contract)




BWM Contract 1 to that filter.

/cfg/slb/filt 20/sip 150.150.0.0/smask 255.255.0.0/action allow (Allow

student traffic)

>> Filter 20 # adv (Select the filter 20 advanced menu)

>> Filter 20 Advanced# cont 1 (Apply BWM contract 1 to this filter)


4. Add the filter to an ingress port on the Alteon Application Switch.

5. In the BWM configuration, enable IP limiting.

6. Determine whether the user should be identified by his/her source IP or destination IP

address.

If the contract is used for traffic going out to the Internet, define it by the source IP

address: iptype sip.

If the contract is used to limit the amount of traffic downloaded from the user by a client

on the Internet, define it by the destination IP address: iptype dip.

7. Disable traffic shaping on this contract. Traffic shaping cannot be used in user-level rate

limiting contracts.


9. View the current per-user BWM sessions for the active contract.

Configuring BWM Preferential Services

BWM can be used to provide preferential treatment to certain traffic, based on source IP blocks, applications, URL paths, or cookies. You may find it useful to configure higher policy

rate limits for specific sites, for example, those used for e-commerce.

/cfg/slb/port 1/filt ena/add 20 (Add filter 20 to port 1)

/cfg/bwm/cont 1/iplimit e

>> BW Contract 1# iptype sip

>> /cfg/bwm/cont 1/shaping dis

/stats/bwm/port 1/cont 1




In the following example, there are two Web sites, “A.com” and “B.com.” BWM is configured

to give preference to traffic sent to Web site “B.com:”


ing tasks: Assign an IP address to each of the real servers in the server pool.







For more information about SLB configuration, refer to Chapter 10, “Server Load Balancing.”




3. Set the hard, soft, and reserved rate limits for the bandwidth policy in Mbps.

4. Select a BWM contract and name the contract.


5. Assign the bandwidth policy to this contract.




>> Policy 1# hard 10 (Set “never exceed” rate)>> Policy 1# soft 8 (Set desired bandwidth rate)


>> Policy 1# /cfg/bwm/cont 1 (Select BWM Contract 1)>> BWM Contract 1# name a.com (Assign contract name “a.com”)







( )

>> BWM Contract 1# /cfg/bwm/policy 2 (Select BWM policy 2)



9. Select the second BWM contract and name the contract.

10. Assign the bandwidth policy to this contract.



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 vir-

tual server. Repeat this procedure for a second virtual server.

NOTE – This classification applies to the services within the virtual server and not to the

virtual server itself.

The classification 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# name b.com (Assign contract name “b.com”)



>> BWM Contract 2# /cfg/slb/virt 1/service 80/cont 1(Assign contract to vir-

tual server 1)

>> Virtual Server 1# vip 100.2.16.2 (Set virtual server VIP address)




u S # p ( )

>> Virtual Server 1# ena (Enable this virtual server)

>> Virtual Server 1# /cfg/slb/virt 2/cont 2 (Assign contract to virtual server)

>> Virtual Server 2# vip 100.2.16.3 (Set virtual server IP address)

>> Virtual Server 2# ena (Enable this virtual server)





15. Check the bandwidth management information.



Configuring 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 configuration guidelines on con-

tent switching described in “Content Intelligent Server Load Balancing” on page 202 and Chapter 14, “Application Redirection.” You would also need to assign a contract to each

defined 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 Figure 22-4, if a Web site has 10Mbps of bandwidth, the site man-

ager 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

i bi t d t

>> Virtual Server 2# apply (Make your changes active)

>> Virtual Server 2# /cfg/bwm/cur (View current BWM settings)


>> Bandwidth Management# /info/bwm <contract number>(View BWM information)




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 Figure 22-4 on page 699, users will be able to allocate a certain percentage of

bandwidth for Web cache requests by using the URL parsing and bandwidth managementfeature.

Figure 22-4 URL-Based SLB with Bandwidth Management

The following example assumes you have configured URL-based SLB and the layer 7 strings

as described in “Content Intelligent Server Load Balancing” on page 202. For URL-based

server load balancing a user has to first define strings to monitor Each of these strings is

GET/www.foo.com/event/reg.bin

GET/www.foo.com/product/abc.html

GET/www.foo.com/images/abc.gif

3 Mbs of bandwidth

Policy 1, Contract 1


images

.gif

.jpg


.cgi

.bin

.exe

4 Mbs of bandwidth



.html

1 Mbs of bandwidth


2 Mbs of bandwidth


Alteon Application

Switch

A n

y o t h e r s

t r i n

g




server load balancing, a user has to first define strings to monitor. Each of these strings is

attached to real servers, and any URL with the string is load balanced across the assigned serv-

ers. The best way to achieve URL-based bandwidth management is to assign a contract to each

defined string. This allocates a percentage of bandwidth to the string or URL containing the

string.

1. Configure “Content Intelligent Server Load Balancing” on page 202.


2. Configure BWM policies with the desired bandwidth limits. In this example, four policies

are configured, as illustrated in Figure 22-4.

3. Configure BWM contracts and apply the appropriate policies to the contracts. In this

example, the policy numbers correspond to the contract numbers.

4. Identify the defined string IDs that were configured.

For easy configuration and identification, each defined 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

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

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


ID SLB String BWMContract

1 any 4

2 .gif 1

3 .jpg 1

4 .cgi 2

5 .bin 2

6 .exe 2

7 html 3




5. Assign BWM contracts to each string using the syntax shown:

7 .html 3

>> Main# /cfg/slb/layer7/slb/cont <String ID> <BWM Contract number>


6. Verify that the strings and contracts are assigned properly.:

7. Configure a real server to handle the URL request.


where SLB string ID is the identification number of the defined string as displayed when youenter the cur command.

Example: /cfg/slb/real 2/layer7/addlb 3

8. Either enable Direct Access Mode (DAM) on the switch or configure a proxy IP address

on the client port.

To turn on DAM:

To turn off DAM and configure a proxy IP address on the client port:


>> Server Load Balance Resource# curNumber of entries: 21: any, cont 42: .gif, cont 13: .jpg, cont 14: .cgi, cont 25: .bin, cont 26: .exe, cont 2

7: .html, cont 3

>> # /cfg/slb/real 2/layer7/addlb <SLB string ID>


>> # /cfg/slb/adv/direct dis>> # /cfg/slb/port 2/proxy ena (Enable use of proxy IP on this port)

>> # /cfg/slb/pip/type port>> # /cfg/slb/pip/add 12.12.12.12 (Add this proxy IP address to port 2)




NOTE – Port mapping for content intelligent server load balancing can be performed by

enabling DAM on the switch, or disabling DAM and configuring a proxy IP address on the cli-

ent port.

9. Turn on HTTP SLB processing on the virtual server.


Configure everything under the virtual server as in Configuration Example 1.

If the same string is used by more than one service, and you want to allocate a certain percent-

age of bandwidth to this URL string for this service on the virtual server, then define a rule

using the urlcont command.

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/virt 1/service 80/httpslb urlslb

>> # /cfg/slb/virt 1/service 80/urlcont <SLB string ID> <BW Contract num-

ber>

>> # /cfg/slb/on





Configuring Cookie-Based Bandwidth Management

Cookie-based BWM enables Web site managers to prevent network abuse by bandwidth-hog-

ging users. Using this feature, bandwidth can be allocated by type of user or other user-specific

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 first class, business class, and coach and

allocate a larger share of the bandwidth for preferred classes.

Figure 22-5 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, configure cookie-based

server load balancing, which is very similar to URL-based load balancing. Any cookie contain-

ing the specified 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.

InternetProxy Firewall

Client #1


Client #2

First

Business

For Virtual IP address: 172.17.1.1

First = 2 Mbs

Business = 1 Mbs




>> # /cfg/slb/virt 1/service 80>> Virtual Server 1 http Service# httpslb cookie enaEnter the starting point of the cookie value [1-64]: 1

Enter the number of bytes to be extract [1-64]: 8Look for cookie in URI [e|d]: d


1. Define one or more load-balancing strings.

Example:

2. Allocate bandwidth for each string.

To do this, assign a BWM contract to each defined string.

3. Configure a real server to handle the cookie.


where SLB string ID is the identification number of the defined string.

Example:

4. Either enable DAM on the switch or configure a proxy IP address on the client port.

To turn on DAM:

To turn off DAM and configure a Proxy IP address on the client port:

>> # /cfg/slb/layer7/slb/addstr <l7lkup|pattern> <SLB string>

>> # /cfg/slb/layer7/slb/addstr l7lkup "Business">> # add l7lkup "First">> # add l7lkup "Coach"

>> # /cfg/slb/layer7/slb/cont <SLB string ID> <BWM Contract number>

>> # /cfg/slb/real 2/layer7/addlb <SLB string ID>

>> # /cfg/slb/real 2/layer7/addlb 3


>> # /cfg/slb/adv/direct dis>> # /cfg/slb/pip>> Proxy IP address# type port (Use port based proxy IP)






>> Proxy IP Address# add 12.12.12.12>> # /cfg/slb/port 2>> SLB Port 2# proxy ena


NOTE – By enabling DAM on the switch or, alternatively, disabling DAM and configuring a

proxy on the client port, port mapping for URL-based load balancing can be performed.

5. Enable SLB.

Scenario 2: In this scenario, the Web site has multiple virtual server IP addresses, and the

same user classification or multiple sites use the same string name. In this scenario, there aretwo Virtual IP (VIP) addresses: 172.17.1.1 and 172.17.1.2. Both the virtual servers and sites

have first class and business class customers, with different bandwidth allocations, as shown in

Figure 22-6 on page 705.

Figure 22-6 Cookie-Based Preferential Services

The configuration to support this scenario is similar to scenario 1. Note the following:

>> # /cfg/slb/on

InternetProxy Firewall

Client 1

Alteon Application

Switch

Client 2

F i r s

t

B u s i n e

s s


First = 2 Mbs

Business = 1 Mbs

F i r s t B u s i n

e s s


First = 3 Mbs

Business = 2 Mbs




1. Configure the string and assign contracts for the strings and services.


2. 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 definea rule using the urlcont command:

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.

Configuring Security Management

BWM can be used to prevent Denial of Service (DoS) attacks that generate a flooding of “nec-

essary evil” packets. BWM can be used to limit the rate of TCP SYN, ping, and other disrup-

tive packets. BWM can also be used to alert the network manager when soft limits are

exceeded.

In the following example, a filter is configured to match ping packets, and BWM is configured

to prevent DoS attacks by limiting the bandwidth policy rate of those packets:

1. Configure the switch as usual for SLB (see “Server Load Balancing” on page 181):








2. Select a bandwidth policy.


>> # /cfg/slb/virt 1/service 80/ urlcont <URL path ID> <BW Contract number>





3. Set the hard, soft, and reserved rate limits for this policy in Kilobytes.


>> Policy 1# hard 250k (Set “never exceed” rate)

>> Policy 1# soft 250k (Set desired bandwidth rate)

>> Policy 1# resv 250k (Set committed information rate)


4. Set the buffer limit for the policy.

Set a parameter between 8192 and 128000 bytes. The buffer depth for a BWM contract should be set to a multiple of the packet size.

5. On the switch, select a BWM contract and name the contract.


6. Set the bandwidth policy for the contract.


7. Enable the BWM contract.

8. Create a filter that will be used to classify the frames for this contract and assign the

BWM contract to the filter.

The classification rule for this BWM contract is based on a filter configured to match ICMP

traffic. The contract will be applied to any frames that match this filter


>> Policy 1# buffer 8192 (Set policy buffer limit of 8192 bytes)

>> Bandwidth Management# /cfg/bwm/cont 1 (Select BWM contract 1)

>> BWM Contract 1# name icmp (Select contract name “icmp”)


>> BWM Contract 1# ena (Enable this BWM contract)

>> BW Contract 1# /cfg/slb/filt 1/proto icmp (Define protocol affected by filter)

>> Filter 1# adv/icmp any (Set the ICMP message type)

>> Filter 1 Advanced# cont 1 (Assign BWM contract 1 to this filter)

>> Filter 1 Advanced# /cfg/slb/filt 1/ena (Enable this filter)>> Filter 1# apply (Port and enable filtering)





>> Filter 1 Advanced# apply (Make your changes active)

>> Filter 1 Advanced# /cfg/bwm/cur (View current BWM settings)






Configuring Time and Day Policies

Bandwidth Management contracts can be configured to have different limits depending on the

time of day and day of the week. For example, in office 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 traffic, such as on evenings or weekends.

Up to two time policies can be applied to each contract. The default settings for each time pol-

icy 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 switch’s system clock, time policy 1 will take effect.

1. Configure three BWM policies for high, low and default bandwidth. These policies will

be applied to different time policies later in this procedure.


>> Bandwidth Management# /info/bwm <contract number > (View BWM information)

!CAUTION—When configuring time policies, the “to” hour cannot be earlier than the “from”

hour, as in a time policy set from 7pm to 7 am. Alteon OS does not calculate time policies that

cross the 24-hour day boundary.

>> /cfg/bwm/policy 1/hard 10M/soft 5M (For peak working hours)

>> /cfg/bwm/policy 2/hard 5M/soft 1M (For weekday evening hours)

>> /cfg/bwm/policy 3/hard 4M/soft 2M (For all other times)




2. Create a BWM contract that will contain the time policies.

>> /cfg/bwm/cont 1


3. Create the first time policy under contract 1, for peak working hours.

4. Create the second time policy under contract 1, for weekday evening hours.

5. Apply the default BWM policy 3 to this contract. This BW policy will be in effect at allother times beyond the specifications of the two time policies.

6. Assign the contract to an ingress port on the Application Switch.


>> # /cfg/bwm/cont 1/timepol 1

>> BW Contract 1 Time Policy 1# day weekdayCurrent Time Policy Day: everydayPending new Time Policy Day: weekday

>> BW Contract 1 Time Policy 1# from 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: disabledNew status: enabled

>> # /cfg/bwm/cont 1/timepol 2/day weekday/from 7pm/to 11pm/policy 2/ena

>> # /cfg/bwm/cont 1/policy 3/ena

>> Main# /cfg/port 1

>> Port 1# cont 1Current BW Contract: 256New pending BW Contract: 1





Configuring Egress Bandwidth Tuning for Connections

to Lower Speed NetworksIn situations where an Alteon Application Switch is connected to a router that feeds into lower

speed networks, the egress traffic from the Alteon Application Switch should be throttled

down to prevent the packets from being dropped from the router as it forwards traffic into the

slower network. For example, an Alteon 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.

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 traffic usually exceeds the configured BWM soft limit in

a BWM contract, the TCP window size may be overwritten to better accommodate the prevail-ing traffic rates. It would be beneficial if the TCP traffic 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 traffic 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/port 1 (Select the desired port)

>> Port 1# egbw 44M (Change egress BW to 44Mbps)

Current port egress bandwidth: 0K

New pending port egress bandwidth: 44M

>> # /cfg/bwm/cont 1/wtcpwin e (Enable overwriting of TCP window)





Configuring Intelligent Traffic Management

Intelligent Traffic Management (ITM) can be used to configure, monitor and limit IP and non-

IP traffic based on well-known application signatures. Content intelligent traffic management

includes classifying different types of traffic by denying, rate limiting, or shaping according to

your policies.

To setup Alteon Intelligent Traffic Management (ITM), it is recommended that you use the

Traffic Management Wizard in the Alteon EMS client software. For more information on

Intelligent Traffic management and how to classify traffic see the Alteon Intelligent TrafficManagement User’s Guide.

The ITM wizard enables you to configure complex filters for BWM contracts and policies

using a simple click of a mouse. This wizard also includes Nortel signature files to classify dif-

ferent types of traffic, for example, you can allow HTTP traffic, Deny peer-to-peer uploads,

Rate limit peer-to-peer downloads, User limit traffic, Allow Instant Messaging chat, Deny

Instant Messaging file transfers, Guarantee Voice over Internet Protocol (VoIP) traffic, etc.

Alteon ITM has the ability to combat high-profile network worms and viruses without stop- ping valid application traffic. Shape and prioritize critical business application traffic, so that it

is not impacted when a new worm attacks the network.

Initially you can setup the EMS wizard to monitor all available traffic on a switch for a few

days. Monitor the unclassified traffic to identify the popular applications on the network. Use

the Alteon Traffic Management Reporting tool to graph application traffic. Analyze the data in

your report and determine the traffic you want denied or rate limited on your network. Run the

Traffic Management wizard again to classify the traffic.

New in Alteon OS 22.0.2 is the ability to arbitrarily create a session entry that is opposite to the

direction that the traffic was originally classified. This feature, known as reverse session

update, avoids the need to inspect traffic in both directions. This feature can also supply a

“reverse contract” association so that returning traffic can be classified, through Bandwidth

Management, into a different contract than was configured on the ingress filter. For more

information about this feature, refer to the Alteon OS 22.0.2 Release Note (Part Number315397-J) and the Alteon Intelligent Traffic Management User’s Guide (Part Number 216392-

B).

For more information on how to run the wizard and classify traffic see Chapter 2, “Getting

Started” in the Alteon Intelligent Traffic Management User's Guide. Run the Reporting tool




Started in the Alteon Intelligent Traffic Management User s Guide. Run the Reporting tool

frequently to verify if the policies are being enforced.





APPENDIX A

Troubleshooting

This section discusses some tools to help you troubleshoot common problems on the Alteon

Application Switch:

“Port Mirroring” on page 714

“Filtering the Session Dump” on page 717



315394-J, January 2005713




To configure port mirroring for the example shown in Figure A-1 on page 714:

1. Specify the monitoring port.

2. Select the ports that you want to mirror.

3. Enable port mirroring.


5. View the current configuration.

>> # /cfg/pmirr/monport 19 (Select port 19 for monitoring)

>> 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)

>> # /cfg/pmirr/mirr ena (Enable port mirroring)

>> PortMirroring# apply (Apply the configuration)

>> PortMirroring# save (Save the configuration)

>> Port 19# cur (Display the current settings)

Monitoring port (Mirrored port,direction,vlans)19 (3,in,vlans: ) (11,out,vlans: )



315394-J, January 2005Appendix A: Troubleshooting 715


Mirroring VLANs on a Port

VLAN-based port mirroring allows the user to monitor traffic based on VLANs associated

with a port. If a mirrored port is configured as a member of more than one VLAN, you may

wish to monitor only traffic entering that port on a specific VLAN. You can add specific

VLAN(s) to be mirrored, even if there are multiple VLANs associated with that port. If you do

not specify a VLAN, all traffic 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 commandsdescribed in “Mirroring Individual Ports” on page 714, and specify which VLANs’ traffic that

you wish to mirror, using the following syntax:

To enable mirroring of ingress traffic for VLAN 3 on port 3, and egress traffic for VLAN 4 on

port 11 of Step 1 and Step 2 on page 715, change the commands to the following:.

To view the current configuration:

add <mirrored port (port to mirror from)> <direction> <vlan index or Carriage Return for all

vlans>

>> # /cfg/pmirr/monport 19 (Select port 19 for monitoring)

>> Port 19 # add 3 in 3 (Mirror only vlan 3 ingress traffic

on port 3)

>> Port 19 # add 11 out 4 ( Mirror only vlan 4 egress traffic on)

>> Port 19# cur (Display the current settings)

Monitoring port (Mirrored port,direction,vlans)19 (3,in,vlans: 3) (11,in,vlans: 4)



315394-J, January 2005716 Appendix A: Troubleshooting


Filtering the Session Dump

Typically, session dumps are long and unwieldy. Alteon OS however, provides a tool to filter

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 filter

Matching flag

Ingress port

Real IP address

SP

Only one attribute can be used at a time to filter the session dump. For example, to filter a ses-

sion dump based on client IP address 10.10.10.1, use the following command:

>> # /info/slb/sess/cip 10.10.10.1Printing Sessions for SP 11,01: 10.10.10.1 137, 205.178.13.100 137 ALLOW age 2 f:100 E

1,01: 10.10.10.1 2592, 172.21.31.100 http -> 14291 10.20.1.2 http age 01,01: 10.10.10.1 2593, 172.21.31.100 http -> 14292 10.20.1.3 http age 0

1,01: 10.10.10.1 2594, 172.21.31.100 http -> 14307 10.20.1.2 http age 0






>> Session Table Information#



315394-J, January 2005Appendix A: Troubleshooting 717

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.




315394-J, January 2005718 Appendix A: Troubleshooting

APPENDIX B

Layer 7 String Handling

This appendix describes how to create and manage the Layer 7 content used for configuring

content-intelligent load balancing and redirection features described elsewhere in this manual.


“Exclusionary String Matching for Real Servers” on page 720

“Regular Expression Matching” on page 722

“Content Precedence Lookup” on page 724

“String Case Insensitivity” on page 727

“Configurable HTTP Methods” on page 728

NOTE – For all content-intelligent switching features enable Direct Access Mode (DAM) or

configure proxy IP addresses. For more information, see “Direct Access Mode” on page 230.



315394-J, January 2005719


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. Thereis also a special string known as “any” that matches all content.

Alteon OS also supports exclusionary string matching. Using this option, you can define a

server to accept any requests regardless of the URL, except requests with a specific string.

NOTE – Once exclusionary string matching is enabled, clients cannot access the URL strings

that are added to that real server. This means you cannot configure a dedicated server to

receive a certain string and, at the same time, have it exclude other URL strings. The exclu-sionary feature is enabled per server, not per string.

For example, the following strings are assigned to a real server:

string 1 = cgistring 2 = NOT cgi/form_Astring 3 = NOT cgi/form_B

As a result, all cgi scripts are matched except form_A and form_B.

Configuring Exclusionary URL String MatchingThis configuration example shows you how to configure a server to handle any requests except

requests that contain the string “test” or requests that start with “/images” or “/product”.

To configure exclusionary URL string matching, perform the following procedure:

1. Before you can configure URL string matching, ensure that the switch has already been

configured for basic SLB:






315394-J, January 2005720 Appendix B: Layer 7 String Handling


Define virtual servers and services. Enable SLB.


For information on how to configure your network for server load balancing, see Chapter 10,

“Server Load Balancing.”

2. Add the load balancing strings (for example test, /images, and /product) to the

real server.



5. Assign the URL string ID to the real server.

6. Enable the exclusionary string matching option.

If you configured a string “any” and enabled the exclusion option, the server will not handleany requests. This has the same effect as disabling the server.

>> # /cfg/slb/layer7/slb/addstr “test”>> Server Loadbalance Resource# addstr “/images”>> Server Loadbalance Resource# addstr “/product”

>> Server Loadbalance Resource# cur

ID SLB String

1any

2 test

3 /images

4 /product

>> Real Server 1 Layer 7 commands# addlb 2>> Real Server 1 Layer 7 commands# addlb 3>> Real Server 1 Layer 7 commands# addlb 4

>> Real Server 1 Layer 7 commands# exclude enable



315394-J, January 2005Appendix B: Layer 7 String Handling 721


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 effec-

tive 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. configuring 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

Alteon OS:

Use the following rules to describe patterns for string matching:

Table 22-3 Standard Regular Expression Special Characters

Construction Description

* Matches any string of zero or more characters

. Matches any single character

+ Matches one or more occurrences of the pattern it follows

? Matches zero or one occurrences of its followed pattern

$ Matches the end of a line

\ Escape the following special character

[abc] Matches any of the single character inside the bracket

[^abc] Matches any single character except those inside the bracket

^ Matches the pattern exactly only if it appears at the beginning of a

line




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 “*” prefixed 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

Configuring Regular ExpressionsThe 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. Configure

regular expressions at the following CLI prompt:

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.

>> # /cfg/slb/layer7/slb/addstr





Content Precedence Lookup

The Layer 7 Precedence Lookup feature in Alteon OS allows you to give precedence to one

Layer 7 parameter over another and selectively decide which parameter should be analyzed

first.

The Content Precedence Lookup feature allows you to combine up to two Layer 7 load balanc-

ing 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 specified:

URL SLB

HTTP Host

Cookie

Browsers (User agent)

URL hash

Header hash

Using the above content types with the and and or operators, the application switch is config-

ured to refine 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

configured using the Content Precedence Lookup feature:

Virtual host and/or URL-based load balancing

Cookie persistence and URL-based load balancing

Cookie load balancing and/or URL-based load balancing

Cookie persistence and HTTP SLB together in the same service

Multiple HTTP SLB process type on the same service

NOTE – Cookie persistence can also be combined with the Layer 7 content types. For more

information on cookie persistence, see Chapter 17, “Persistence.”

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 configured, 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 configured on the switch




If the client request is sent without a cookie, but HTTP SLB is configured 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 configure proxy IP address if DAM is disabled. Enable delayed binding.

Using the or / and Operators

Figure 22-7 shows a network with real servers 1 and 3 configured for URL SLB and real serv-

ers 2 and 3 configured for HTTP Host SLB.

Figure 22-7 Content Precedence Lookup Protectors Example

If the Content Precedence Lookup feature is configured with the or and and operators, the

request from the client is as follows:

HTTP Host or URL SLB

The HTTP Host header takes precedence because it is specified first. If there is no Host

Header information and because or is the operator, the URL string is examined next.

If a request from a client contains no Host Header but has a 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 balancedamong Server 2 and Server 3. The URL string is ignored because the HTTP Host was

specified and matched first.

Alteon Application

Switch

Real Servers

URL: "/gold"

Host: "www.host.net"

URL: "/gold"

Host: "www.host.net"

Client

Internet

1

2

3





HTTP Host and URL SLB

The HTTP Host header takes precedence because it is specified first. Because and is theoperator, 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

Figure 22-8 shows an example of a company providing content for two large customers: Cus-

tomers 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 flexibility to allow different types of con-

tent to be placed on different servers. To make most efficient use of their server resources, they

separate their servers into two groups, using their fastest servers to process dynamic content

(such as .cgi files) and their slower servers to process all static content (such as .jpg files).

Figure 22-8 Content Precedence Lookup Multiple Strings Example


Real Servers

Client

Internet

1 2 3 4 5

Host: www.a.com

URL: *.jpg

Host: www.a.com

URL: *.jpg

Host: www.a.com

URL: *.cgi

Host: www.b.com

URL: *.jpg

Host: www.b.com

URL: *.cgi





To configure content precedence lookup for the example in Figure 22-8, the hosting company

groups all the real servers into one real server group even though different servers provide ser-

vices for different customers and different types of content. In this case, the servers are set upfor the following purpose:

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 configuration, you must assign multiple strings (a Host Header string and aURL string) for each real server.

String Case Insensitivity

By default, Alteon OS supports case sensitive matching when performing lookup of Layer 7

string content.

If the following strings were configured for a real server:

1. default.asp2. search.asp

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.

Table 22-4 Real Server Content

Server Customer Content

Server 1 Customer A Static .jpg files

Server 2 Customer A Static .jpg files

Server 3 Customer A Dynamic .cgi files

Server 4 Customer B Static .jpg files

Server 5 Customer B Dynamic .cgi files

>> # /cfg/slb/layer7/slb/case disable (Disable case-sensitive matching)





Configurable HTTP Methods

Various types of HTTP methods to be processed by the Alteon Application Switch’s Layer 7

engine are now configurable. To view the currently supported HTTP methods, enter the fol-

lowing:

To add an HTTP method type, select the method by its index number from the above list, andenter the following:

The list of supported HTTP methods will be updated regularly in Alteon OS as the HTTP pro-

tocol evolves.


HTTP method types:

1 GET 2 POST 3 HEAD 4 BCOPY5 BMOVE 6 BDELETE 7 BPROPPATCH 8 COPY9 CONNECT 10 DELETE 11 LINK 12 MKCOL13 MOVE 14 OPTIONS 15 POLL 16 PUT17 PROPFIND 18 PROPPATCH 19 SEARCH 20 SUBSCRIBE21 TRACE 22 UNLINK

>> # /cfg/slb/layer7/slb/addmeth 2 (Add HTTP POST method)




Glossary

DIP (Destination IP

Address)

The destination IP address of a frame.

Dport (Destination

Port)

The destination port (application socket: for example, http-80/https-443/DNS-53)

NAT (Network

Address Translation)

Any time an IP address is changed from one source IP or destination 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). Min-

imum 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 specification (for example, TCP, UDP, OSPF, ICMP, and so on.)

Real Server Group A group of real servers that are associated with a Virtual Server IP address, or a filter.

Redirection or

Filter-Based LoadBalancing

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” toa server group. “Transparently” means that requests are not specifically destined for a Vir-

tual Server IP address that the switch owns. Instead, a filter is configured in the switch.

This filter intercepts traffic based on certain IP header criteria and load balances it.

Filters can be configured to filter on the SIP/Range (via netmask), DIP/Range (via net-

mask), Protocol, SPort/Range or DPort/Range. The action on a filter 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

h f f h l Th f di i b d l d b l i i d i d



315394-J, January 2005729

that of one of the real servers. Therefore, redirection-based load balancing is designed to

load balance devices that normally operate transparently in your network—such as a fire-wall, spam filter, 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/HTTPS-443/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 configura-

tion.

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)

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 rout-

ers.

Virtual Router A shared address between two devices utilizing VRRP, as defined in RFC 2338. One vir-

tual router is associated with an IP interface. This is one of the IP interfaces that the switchis assigned. All IP interfaces on the Alteon Application Switches must be in a VLAN. If

there is more than one VLAN defined on the application switch, then the VRRP broad-

casts 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 withone of the real server IP addresses (RIP's), updates the relevant checksums, and forwards

the frame to the server for which it is now destined. This process of replacing the destina-

tion IP (VIP) with one of the real server addresses is called half NAT. If the frames were

not half NAT'ed to the address of one of the RIPs, a server would receive the frame that

was destined for it's 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).



315394-J, January 2005730 : Glossary


VRID (Virtual Router

Identifier)

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 defined 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.

VRRP (Virtual Router

Redundancy

Protocol)

A protocol that acts very similarly to Cisco's 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 broad-

casts. Should the master stop advertising, the backup will take over ownership of the

VRRP IP and MAC addresses as defined by the specification. The switch announces this

change in ownership to the devices around it by way of a Gratuitous ARP, and advertise-

ments. If the backup switch didn't 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 Alteon OS proprietary

extension to the VRRP specification. The switches must be able to share Virtual Server IP

addresses, as well as IP interfaces. If they didn’t, the two switches would fight for owner-

ship 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.



315394-J, January 2005: Glossary 731




315394-J, January 2005732 : Glossary

Index

Symbols

[ ]....................................................................... 28

Numerics

80 (port) ................................................... 639, 646802.1Q VLAN tagging................................... 76, 77

Aaccessing the switch

defining source IP addresses........................... 52RADIUS authentication................................. 53security........................................................ 49using EMS ................................................... 43using the Browser-based Interface................... 45using the CLI ............................................... 34

active cookie mode ............................................ 527active-active redundancy .................................... 484

configuration.............................................. 484Server Load Balancing ................................ 486synchronization .......................................... 512

active-standby redundancy ................................. 480configuration.............................................. 481

administrator account........................................... 56aggregating routes

............................................. 134example..................................................... 141allow (filtering) ................................. 184, 300, 332Alteon EMS........................................................ 35application health checking ................................ 438application ports ................................................ 192

application redirection................................334, 367client IP address authentication .....................381example with NAT ......................................373games and real-time applications...................381non cacheable sites ......................................381non-HTTP redirects for GSLB ......................663

proxies....................................370, 373 to 379rport ..................................................373, 380

See cache redirectiontopologies .................................................. 371Web-cache redirection example .........369 to 381

authenticating, in OSPF......................................157authoritative name servers ..................................631autonomous systems (AS) ..................................150

B

backup servers................................................... 201 bandwidth management

burst limit................................................... 684configuration, general .......................671 to 687configuration, preferential service .................695configuration, security .................................706configuration, user fairness...........................688content intelligent.............................698 to 702contracts ............................................ 674, 681

cookie-based .............................................. 703data pacing ................................................. 681egress bandwidth tuning...............................710grouped contracts ........................674, 676, 690operational keys ..........................................670overwriting TCP window .............................710

precedence ................................................. 673rate limiting................................................ 687



315394-J, January 2005733

rate limiting timeslots ..................................681statistics and history ....................................682time policy ................................................. 678


configuration example708 to 709traffic shaping .....................................681, 687

user limits....................................... 676 to 677configuration example694 to 695

VMA .........................................................672 bandwidth managment

policies.......................................................677 bandwidth metric ...............................................198 bandwidth policies

rates ...........................................................680BBI

See Browser-Based Interface.........................151 blat ...........................................................544, 547Border Gateway Protocol (BGP)..........................129

attributes ....................................................136failover configuration...................................138route aggregation.........................................134route maps ..................................................131selecting route paths.....................................137

use with GSLB............................................667Bridge Protocol Data Unit (BPDU)......................101

broadcast domains............................75, 77, 80, 121Browser-Based Interface.....151, 427, 512, 639, 646

C

cache redirection

browser-based.............................................392

delayed binding ...........................................375example......................................................371HTTP header-based .....................................391layer 7 traffic ..............................................382RTSP .................................................376, 398See application redirection

servers.................................... 369 to 371, 372URL hashing...............................................393URL-based .................................................383

CGI-bin scripts ..........................................187, 200Cisco EtherChannel..............................................94client traffic processing...............................187, 190command conventions ..........................................28Command Line Interface...............................34, 151

configuring

BGP failover .............................................. 138

cache redirection......................................... 371cookie-based persistence .............................. 528default filter ............................................... 336delayed binding .......................................... 236DNS load balancing .................................... 248dynamic NAT............................................. 353filter-based security ..................................... 346FTP Server Load Balancing ......... 240, 241, 246IDS load balancing...................................... 279

IP load balancing ........................................ 239IP routing................................................... 119LDAP load balancing .................................. 244multiple services ......................................... 194multi-response cookie search ........................ 534OSPF ........................................................ 164

port trunking ................................................ 93 proxy IP addresses ...................................... 223

RTSP cache redirection ............................... 377server load balancing................................... 188spanning tree groups.................................... 111stateful failover ........................................... 514static NAT ................................................. 352tunable hash for filter redirection................... 344VLAN-based filters..................................... 340WAP load balancing.................... 266, 268, 271

configuring WAN links

basic example............................................. 310summary.................................................... 308with SLB ................................................... 320

connection time-out ........................................... 200console port ........................................................ 34content intelligent

cache redirection......................................... 382server load balancing................................... 202

contracts, bandwidth management....................... 674cookie

active ........................................................ 527different types ............................................ 525expiration timer .......................................... 529header ....................................................... 523names........................................................ 524

passive mode.............................................. 526 permanent.................................................. 523



315394-J, January 2005734 : Index

rewrite ....................................................... 527temporary .................................................. 523values........................................................ 524

cookie-based persistence .................................... 522


D

data pacing ....................................................... 681datagram........................................................... 610default gateway ................................................. 118

configuration example ... 84, 120, 640, 647, 653VLAN-based................................................ 81

default password ................................................. 56default route

OSPF ........................................................ 155delayed binding...................................... 234 to 236

cache redirection......................................... 375denial of service protection...................... 544 to 564deny (filtering) .................................. 184, 300, 332detecting SYN attacks........................................ 236dip (destination IP address for filtering) ............... 337Direct Access Mode (DAM) ....................... 315, 325direct real server access...................................... 228Direct Server Return (DSR)................................ 228disabling real servers ......................................... 193

Distributed Site State Protocol (DSSP) ................ 630dmask

destination mask for filtering ........................ 337DNS load balancing........................................... 248Domain Name Server ................................. 318, 329Domain Name System (DNS)

filtering ............................................. 345, 348Global SLB (diagram) ................................. 631

load balancing, layer 4................................. 245load balancing, layer 7................................. 250round robin ........................................ 182, 299

dport (filtering option) ............................... 346, 374DSSP. See Distributed Site State Protocol.

duplex mode for jumbo frames ............................. 85dynamic NAT ................................................... 353

E

egress traffic ..................................................... 610Element Management System (EMS) .................... 43encrypt ............................................................. 610End user access control

configuring .................................................. 67EtherChannel ...................................................... 90

as used with port trunking .............................. 94

expiration timer, insert cookie .............................529external routing .........................................130, 150

F

failed server protection, SLB ......................182, 299failover

active-active ............................................... 470overview ....................................................479stateful.......................................................513

fault tolerance

port trunking................................................. 92Server Load Balancing.........................186, 299

filter redirection

tunable hash ............................................... 344filtering

configuration example .................................346default filter ........................................335, 346IP address ranges ........................................337layer 7 deny................................................ 363

NAT configuration example ..............351 to 353numbering.................................................. 336order of precedence .............................334, 335

proto (option) .....................................346, 374rate limiting................................................ 551security example .........................................345session dumps............................................. 717

filtering-based VLANs .......................................340

firewalls............................................................ 345fraggle ......................................................544, 546fragmenting jumbo frames ..........................116, 118frame processing.................................................. 85frame tagging. See VLANs tagging.

FTP

applications ................................................ 192 proxy IP.....................................................663Server Load Balancing.................................240

configuring240, 241, 246

G

gateway. See default gateway.

Gigabit adapters

jumbo frames................................................ 85



315394-J, January 2005: Index 735


Global SLB

configuration tutorial........638 to 651, ?? to 655

Distributed Site State Protocol.......................630DNS resolution (diagram).............................631domain name configuration...........................644health check interval ....................................644hostname configuration ................................644HTTP redirect .............................................632

port states ...................................................642real server groups ........................................641real servers .................................................641

remote site configuration ..............................643tests ...........................................................668using proxy IP.............................................663

group SLB, metrics ............................................195grouped contracts, bandwidth ..............674, 676, 690

example.......................................... 690 to 694

H

half-duplex for jumbo frames ................................85hash metric ........................................................196hashing

redirection filters .........................................344hashing on any HTTP header ...............................216health checks .............................................373, 447

configuration using scripts ............................433format ........................................................428

Global SLB interval .....................................644hostname for HTTP content .............. 438 to 439HTTPS/SSL................................................451IMAP server ...............................................447RADIUS server ............................... 449 to 450real server parameters...................................438real servers .................................................194script-based..................................... 427 to 436SNMP ........................................................442

verifying scripts...........................................436wireless session protocol .................. 452 to 457WTLS........................................................457

high-availability.................................................463Host routes

OSPF .........................................................160hostname, for HTTP health checks...............438, 644hot-standby redundancy ......................................494

configuration...............................................496

HP-OpenView..................................................... 35HTTP

application health checks ............................. 438redirects (Global SLB option)....................... 632

HTTP header

hashing...................................................... 216HTTP redirection

IP-based.......................................... 405 to 407MIME header-based......................... 410 to 411TCP service port-based ..................... 408 to 409URL-based................................................. 412

HTTP URL request............................................ 363HTTPS/SSL health checks ................................. 451

I

ICMP ............................................................... 333IDS load balancing ............................................ 279IEEE 802.1Q VLAN tagging ................................ 77IF. See IP interfaces.

IGMP ............................................................... 333IMAP server health checks ................................. 447imask ............................................................... 194inbound traffic................................................... 302incoming route maps.......................................... 132ingress traffic .................................................... 610insert cookie mode

expiration timer .......................................... 529

Intelligent Traffic Management........................... 711internal routing..........................................130, 150Internet Service Provider (ISP), SLB example ...... 185inter-switch port states, for hot-standby redundancy....

494Intrusion Detection System (IDS)........................ 274IP address

conservation............................................... 351filter ranges ................................................ 337

local route cache ranges ............................... 123 private ....................................................... 351 proxies ................... 186, 219, 370, 373 to 379real server groups................ 189, 388, 489, 641real servers......... 184, 188, 300, 311, 321, 641routing example ....................................83, 119SLB real servers ......................................... 189virtual servers .... 184, 186, 190, 300, 317, 327,

642



315394-J, January 2005736 : Index


IP interfaces

configuration example ......... 188, 640, 647, 653

example configuration ................... 83, 119, 122VLAN #1 (default)........................................ 77VLANs ....................................................... 77

IP packet format ................................................ 557IP proxies

for application redirection ............................ 379for Global Server Load Balancing ................. 663for Server Load Balancing ........................... 219See also proxies, proxy IP address (PIP).

IP routing ......................................................... 187cross-subnet example .................................. 116default gateway configuration................. 84, 120IP interface configuration............... 83, 119, 122IP subnets .................................................. 117network diagram......................................... 117subnet configuration example ....................... 119switch-based topology ................................. 118

IP subnets ......................................................... 118routing............................................... 117, 118VLANs ................................................. 75, 77

ISL Trunking ...................................................... 90ITM. See Intelligent Traffic Management

J

jumbo frames

fragmenting to normal size................... 116, 118frame size .................................................... 85Gigabit adapter ............................................. 85isolating with VLANs ................................... 85routing............................................... 116, 118supported duplex modes ................................ 85VLANs ....................................................... 85

L

landattack ................................................. 544, 545Layer 4

administrator account .................................... 56cache redirection......................................... 371server load balancing........................... 188, 306

Layer 7

cache redirection .........................................382

deny filter ................................................... 363 precedence lookup.......................................724regular expression matching .........................722server load balancing ...................................202string matching ...........................................720

Layer 7 lookup

with deny filter ...........................................363LDAP load balancing .........................................244least connections (SLB Real Server metric) ..........197

leastconn metric................................................. 197Link load balancing

using filters ................................................ 300link load balancing

basic example ............................................. 310 benefits ......................................................298configuration summary ................................308example with SLB.......................................320

inbound traffic ............................................ 302outbound traffic ..........................................301using virtual servers.....................................300WAN links ................................................. 297

lmask (local route cache parameter).....................123lnet (local route cache parameter)........................123load balancing

DNS..................................................245, 250FTP traffic.................................................. 240

IDS traffic .................................................. 274layer 7 traffic .............................................. 202RTSP......................................................... 253SIP traffic................................................... 293TCP-based DNS queries ..............................245TFTP traffic ............................................... 241types of ...........................................239 to 297UDP-based DNS queries ..............................245WAN traffic ............................................... 297WAP traffic................................................ 263

local route cache address range ...........................123local route cache parameters

lmask ......................................................... 123lnet............................................................ 123

log

filtering option ............................................ 332log (filtering option)...........................................345

l i l S IP b



315394-J, January 2005: Index 737

logical segment. See IP subnets.LSAs ................................................................149


M

MAC address .....................................................612Main Menu

Command-Line Interface (CLI) .......................34management port

setting up......................................................47management port, using ........................................46Management Processor (MP)

use in switch security .....................................52manual style conventions ......................................28

mapping ports ....................................................380mapping virtual ports to real ports........................225matchall ............................................................561matching TCP flags ............................................357maxcons limit ............................................200, 201maximum connections ................................200, 201metrics

real server groups ........................................195MIME header, in HTTP redirection ......... 410 to 411

minimum misses (SLB real server metric) ............195minmiss metric ..................................................195mirroring ports ...................................................714monitoring ports.................................................714monitoring real servers .......................................233multi-homing.....................................................667

WAN links .................................................297multi-links between switches

using port trunking.........................................89using VLANs................................................80multimedia servers .............................................253multiple services, configuring..............................194multiple spanning tree groups ..............................106

N

name servers, Global SLB configuration example .631

Network Address Translation (NAT) ...................373configuration example...................... 351 to 353filter action .................................................334filter example ..............................................354

proxy .........................................................354static example .............................................351

network management............................................35network performance

statistics, with use of proxy addresses.............219

NFS 185

non-HTTP redirects for GSLB ............................ 663nullscan .................................................... 544, 546

O

offset................................................................ 557optional software ............................................... 368OSPF

area types................................................... 146authentication ............................................. 157configuration examples..................... 165 to 180

default route ............................................... 155external routes ............................................ 163filtering criteria ........................................... 333host routes.................................................. 160link state database ....................................... 149neighbors ................................................... 149overview.................................................... 146redistributing routes............................. 131, 135route maps .........................................131, 133

route summarization.................................... 154router ID.................................................... 157virtual link ................................................. 156

outbound traffic................................................. 301outgoing route maps .......................................... 132overflow servers ................................................ 201

P

parallel links ....................................................... 80 password

administrator account .................................... 56default ......................................................... 56L4 administrator account................................ 56user account ................................................. 56

pattern group..................................................... 558 pattern matching

criteria ....................................................... 556depth ......................................................... 557groups ....................................................... 558matchall..................................................... 561offset......................................................... 557operation.................................................... 558TCP or UDP............................................... 556

persistence

Client IP-based ................................520 to 521

ki b d 522



315394-J, January 2005738 : Index

NFS server ........................................................185non cacheable sites in application redirection ........381none (port processing mode) example ..................190

cookie-based .............................................. 522multi-response cookie search ........................ 534SSL session ID-based ....................... 535 to 537


persistent

bindings..................................................... 187

port sessions............................................... 516 ping flood ................................................. 547, 554 ping of death.................................. 547, 562 to 564PIP. See proxies, proxy IP address.

POP3 ............................................................... 663 port 80...................................................... 639, 646 port mapping..................................................... 380 port mirroring ........................................... 714, 716 port processing mode

client ......................................................... 190none.......................................................... 190server ................................................ 187, 190

port smurf ......................................................... 544 port states ......................................................... 642 port trunking ....................................................... 90

configuration example ................................... 92description ................................................... 94EtherChannel ............................................... 90fault tolerance............................................... 92

ports

for services ................................................ 192monitoring ................................................. 714

physical. See switch ports.

SLB configuration example.......................... 190 portzero.................................................... 544, 547 precedence, in bandwidth classifications.............. 673

private IP address .............................................. 351 private network ................................................. 351 protocol types ................................................... 333 proxies ..................................... 186, 219, 370, 379

configuration example ................................. 354 NAT ......................................................... 353

proxy IP address (PIP) ............... 186, 219, 232, 379 proxy servers .................................................... 370PVID (port VLAN ID)......................................... 76

Q

QuickTime Streaming Server .............................. 254

R

RADIUS

authentication ............................................... 53health checks ...................................449 to 450

port 1812 and 1645..............192, 265, 266, 269 port 1813 ...................................192, 270, 273SSH/SCP ..................................................... 66

RADIUS snooping.....................................267, 270RADIUS static session entries.............................265RADIUS/WAP persistence .................................270

Rate limiting .....................................................680rate limiting............................................... 679, 687

filter ..........................................................551hold down periods .......................................549

protocol-based .................................548 to 554TCP........................................................... 549time window............................................... 548timeslots ....................................................681UDP and ICMP ..........................................549

real server groupsconfiguration example .................388, 489, 641

real servers........................................................186 backup/overflow servers ..............................201configuration example .................................641connection timeouts.....................................200disable/enable ............................................. 193health checks .............................................. 438maximum connections .................................200monitoring ................................................. 233SLB configuration example ..........................189weights ......................................................199

redirect (HTTP) ................................................. 632redirecting filters

tunable hash ............................................... 344redirecting non-HTTP applications ......................663redirection. See application redirection

redistributing routes ...........................131, 135, 141redundancy

active-active ............................................... 484active-standby............................................. 480hot-standby ................................................ 494

remote (Global SLB real server property).............644response metric.................................................. 198Return-to-Sender (RTS)

for link load balancing .........303, 315, 324, 326



315394-J, January 2005: Index 739


RIP (Routing Information Protocol)

advertisements ............................................128

distance vector protocol................................127hop count....................................................127metric.........................................................127routing table................................................128TCP/IP route information .......................26, 127UDP ..........................................................128version 1.....................................................127

roundrobin

SLB Real Server metric................................197

route aggregation .......................................134, 141route cache, sample ..............................................82route maps .........................................................131

configuring .................................................133incoming and outgoing .................................132

route paths in BGP .............................................137Router ID

OSPF .........................................................157routers.................................................84, 117, 120

border ........................................................150 peer ...........................................................150 port trunking .................................................90switch-based routing topology.......................118using redirection to reduce Internet congestion 367web-cache redirection example......................369

routes, advertising ..............................................150routing ..............................................................130

internal and external.....................................150Routing Information Protocol. See RIP

rport (filtering) ...........................................373, 380RSA keys ............................................................65

RTSP

cache redirection......................................... 376

server load balancing................................... 253

S

scalability, service .....................................182, 299scan synfin................................................ 544, 546SCP

client commands ..................................63 to 64configuring administrator password................. 62

enabling....................................................... 62services........................................................ 63

script-based health checks ....................... 427 to 436searching for cookie........................................... 534SecurID .............................................................. 66security

allowable SIP addresses ................................. 52denial of service protection................ 544 to 564filter-based................................................. 345

filtering.............................................. 332, 345firewalls..................................................... 345from viruses ............................................... 332IP access control lists........................ 542 to 543layer 7 deny filter ........................................ 363

port mirroring............................................. 714 private networks ......................................... 351RADIUS authentication ................................. 53

switch management....................................... 52VLANs........................................................ 75segmentation. See IP subnets.

segments. See IP subnets.

server (port processing mode) example ................ 190server failure ..................................................... 461



315394-J, January 2005740 : Index



across subnets............................................. 116

active-active redundancy ............................. 486 backup servers............................................ 201complex network topologies................. 218, 219configuration example ......................... 185, 219direct real server access ............................... 228distributed sites........................................... 630DNS.................................................. 245, 250failed server protection ........................ 182, 299fault tolerance..................................... 186, 299

FTP........................................................... 240health checks.............................................. 438IDS ................................................... 274, 293maximum connections................................. 200metrics ...................................................... 195overflow servers ......................................... 201overview.................................................... 183

persistent bindings ...................................... 187 port processing modes......................... 187, 190 proxies .............................................. 186, 219 proxy IP addresses ...................................... 232real server group ......................... 189, 388, 489real server IP address (RIP) .................. 184, 300real servers................................................. 186remote sites ................................................ 630RTSP ........................................................ 253topology considerations ............................... 186

virtual IP address (VIP) ............... 184, 186, 300virtual servers............................. 184, 190, 300WAN links................................................. 297WAP......................................................... 263weights...................................................... 199

server pool........................................................ 182server port processing ........................................ 187service failure ................................................... 461service ports...................................................... 192

session dumps ................................................... 717Session Initiation Protocol (SIP) ......................... 293shared services .......................................... 182, 299sharing ............................................................. 471SIP (source IP address for filtering)..................... 337smask

source mask for filtering .............................. 337SMTP .............................................................. 663

smurf 545

SNMP ........................................................35, 151Alteon EMS ................................................. 35

assign health check ......................................427HP-OpenView .............................................. 35SNMP content health check ..........................442

SNMP health check ...........................................442Spanning-Tree Protocol

eliminating bridge loops with VRRP .............510multiple instances........................................106replacing with hot-standby failover ................496VLANs........................................................ 80

spoofing, prevention of .........................................52sport (filtering option) ................................346, 374SSH

client commands ..................................63 to 64generating RSA keys .....................................65RSA host and server keys ...............................65

SSH/SCP

client commands ..................................63 to 64configuring................................................... 61encryption and authentication methods............. 65with Radius authentication .............................66with SecurID ................................................ 66

stateful failover .................................................. 513static NAT ........................................................351static session entries ...........................................265statistical load distribution ....................................90streaming media ................................................ 253

summarizing routes............................................ 154switch failover ................................................... 479switch management

security ........................................................ 52via IP interface.............................................. 77

switch ports VLANs membership ..........................76switch-centric virtual router group.......................494syslog

messages....................................................332

T

tagging. See VLANs tagging.

TCP..................................................333, 348, 349health checking using ..................................194

port 80 .......................................................233TCP flags..........................................................357TCP window size

overwriting 710



315394-J, January 2005: Index 741

smurf ............................................................... 545 overwriting................................................. 710TCP/UDP port numbers .....................................225TDT (Theoretical Departure Times) ....................681


Telnet ...............................................................345text conventions ...................................................28

Theoretical Departure Times (TDT) .....................681timeouts for real server connections .....................200TOS burst limit for bandwidth management..........684tracking

switch-based virtual router groups .................477virtual routers..............................................475

Traffic shaping...........................................680, 681traffic shaping............................................681, 687

bandwidth management................................681

transparent proxies ................. 219, 370, 373 to 379troubleshooting..................................................717tunable hashing ..................................................344tunneling ...........................................................610typographic conventions .......................................28

U

UDP .................................................333, 348, 349

jumbo frame traffic fragmentation .................118RIP ............................................................128server status using........................................194

UDP blast protection ..........................................555URL, in HTTP redirection...................................412user account.........................................................56user limits, bandwidth............................. 676 to 677Using proxy IP

GSLB ........................................................663

V

virtual clocks .....................................................681virtual interface router (VIR) ...............................464virtual IP address (VIP) ......................184, 186, 300virtual link, OSPF ..............................................156Virtual Local Area Networks. See VLANs.

Virtual Matrix Architecture (VMA) .....................218virtual port mapping to multiple real ports 225 to 228virtual router

ID numbering..............................................511virtual router group

switch-based ...............................................474Virtual Router Redundancy Protocol

tracking virtual routers .................................475virtual server router ............................................468

virtual servers ............................................184, 300

virus attacks, preventing..................................... 363VLAN-based ..................................................... 716

VLAN-based filtering ........................................ 340VLANs

broadcast domains..................... 75, 77, 80, 121default PVID ................................................ 76example showing multiple VLANs ................. 78filtering...................................................... 340gateway, default............................................ 81ID numbers .................................................. 76IP interface configuration............................. 122

IP interfaces ................................................. 77 jumbo frames ............................................... 85multiple links ............................................... 80multiple spanning trees ................................ 100multiple VLANs ..................................... 76, 77

parallel links example.................................... 80 port members ............................................... 76 port mirroring............................................. 716PVID........................................................... 76routing....................................................... 121security........................................................ 75Spanning-Tree Protocol ......................... 80, 100tagging ............................................... 76 to 79topologies .................................................... 77VLAN #1 (default).................. 76, 77, 189, 372VLAN-tagging adapter support for .................. 77

VPN................................................................. 609

VPN cluster ...................................................... 610VPN Load Balancing overview........................... 610VRRP (Virtual Router Redundancy Protocol)

active-active redundancy.............................. 484active-standby redundancy ........................... 480holdoff timer .............................................. 478hot-standby redundancy ............................... 494inter-switch port states ................................. 494master, backup and init ................................ 465

overview............................................ 464, 475owners and renters ...................................... 465

priority ...................................................... 466sharing ...................................................... 471switch-based virtual router group .................. 474synchronization .......................................... 512synchronizing configurations........................ 494tracking service-based virtual router groups.... 477

virtual interface router ................................. 464virtual router ID numbering 511



315394-J, January 2005742 : Index

,configuration example..................................190IP address ...........................190, 317, 327, 642

virtual router ID numbering.......................... 511virtual server router ..................................... 468vrid ........................................................... 464


W

WAN links

configuration summary................................ 308configuring basic example ........................... 310configuring with SLB .................................. 320inbound traffic............................................ 302load balancing ............................................ 300multi-homing ............................................. 297outbound traffic .......................................... 301

WAP

WTLS health check ..................................... 457WAP Gateway .................................................. 263WAP load balancing

RADIUS snooping.............................. 267, 270RADIUS/WAP persistence .......................... 270static session entries .................................... 265

Web cache redirection

See application redirection

Web hosting ......................................................185weights .............................................................199Wide Area Networking (WAN)

load balancing ............................................ 297Wireless Application Protocol.............................263World Wide Web, client security for browsing .....345WSP health checks .................................452 to 457WTLS health check ...........................................457

Xxmascan.................................................... 544, 546



315394-J, January 2005: Index 743




315394-J, January 2005744 : Index

alteon os 22.0.2 application guide

Documents