Alteon OS 22.0.2 Application Guide

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 2005
2 :
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 means
without prior written authorization of Nortel Networks, Inc. Documentation is provided as is without
warranty of any kind, either express or implied, including any kind of implied or express warranty of non-
infringement or the implied warranties of merchantability or 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 the
United States and certain other countries. Cisco
and EtherChannel
are registered trademarks of Cisco

Systems, Inc. in the United States and certain other countries. Check Point
and FireWall-1
are
trademarks or registered trademarks of Check Point Software Technologies Ltd. Any other trademarks
appearing in this manual are owned by their respective companies.
Originated in the U.S.A.
315394-J, January 2005
3
Contents
Preface 25
Who Should Use This Guide 25
What Youll 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 43
Using 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 53
RADIUS Authentication Features in Alteon OS 53
315394-J, January 2005
4 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 66
SSH/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 69
Defining a Users Access Level 69
Assigning One or More Real Servers to the End User 69
Validating a Users 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 End
User Account 71
Deny Routes 72
Configuring a Deny Route 72
Viewing a Deny Route 73
VLANs 75
VLAN ID Numbers 76
315394-J, January 2005
Contents 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 90
The 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 99
Overview 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 103
Multiple 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
315394-J, January 2005
6 Contents
Part 2: IP Routing 113
Basic IP Routing 115
IP 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 129
Internal 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
315394-J, January 2005
Contents 7
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 160
Redistributing 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 174
Verifying 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
315394-J, January 2005
8 Contents
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 218
Proxy 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 223
Mapping 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 230
Blocking 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
315394-J, January 2005
Contents 9
Detecting SYN Attacks 236
Load Balancing Special Services 239
IP Server Load Balancing 239
FTP 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 246
Configuring 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 254
Content-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 275
Setting 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
315394-J, January 2005
10 Contents
WAN Link Load Balancing 297
Multi-homing 297
Benefits of WAN Link Load Balancing 298
Identifying Your Network Needs 299
What 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 332
Filtering Criteria 333
Filtering Actions 334
Stacking Filters 334
Overlapping Filters 335
The Default Filter 335
Optimizing Filter Performance 336
IP Address Ranges 337
Filter 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 342
Classifying 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
315394-J, January 2005
Contents 11
FTP Client NAT 355
Matching TCP Flags 357
Matching ICMP Message Types 361
Deny Filter Based on Layer 7 Content Lookup 363
Denying 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 405
TCP 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 424
Link Health Checks 425
315394-J, January 2005
12 Contents
Configuring Link Health Checks 425
TCP Health Checks 426
ICMP Health Checks 426
Script-Based Health Checks 427
Configuring 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 445
IMAP 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 460
Failure Types 461
Service Failure 461
Server Failure 461
High Availability 463
VRRP Overview 464
Standard VRRP Components 464
Alteon 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
315394-J, January 2005
Contents 13
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 511
Configuring 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 534
SSL 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 540
Other 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
315394-J, January 2005
14 Contents
Viewing DOS statistics per port 545
Understanding the types of DOS attacks 545
Preventing other types of DOS attack 547
Protocol-Based Rate Limiting 548
Time 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 601
Free-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 610
VPN 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
315394-J, January 2005
Contents 15
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 629
GSLB 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 652
Configuring 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 666
Using Border Gateway Protocol for GSLB 667
Verifying GSLB Operation 668
Bandwidth Management 669
Enabling Bandwidth Management 670
Contracts 671
Classification Rules 672
Grouped 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
315394-J, January 2005
16 Contents
Rate Limiting Timeslots 681
Traffic Shaping 681
Data Pacing for Traffic Shaping Contracts 681
Bandwidth Management Information 682
Viewing 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
315394-J, January 2005
Contents 17
Requirements 725
Using the or / and Operators 725
Assigning Multiple Strings 726
String Case Insensitivity 727
Configurable HTTP Methods 728
315394-J, January 2005
18 Contents
315394-J, January 2005
19
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 80
Default 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 108
The 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 174
Traditional 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 214
Basic Virtual Port to Real Port Mapping Configuration 226
315394-J, January 2005
20 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 235
LDAP 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 320
Assigning 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 353
Active 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 376
URL-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 2005
Figures 21
Active-Active High-Availability Configuration 484
Hot-Standby Configuration 496
Service-Based Virtual Router GroupsActive-Standby Configuration 504
Loops in Active-Active Configuration 509
Cross-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 571
Four-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 611
VPN 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 2with Standalone GSLB 652
Configuring Client Proximity Table 661
HTTP and Non-HTTP Redirects 664
POP3 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 2005
22 Figures
Content Precedence Lookup Multiple Strings Example 726
315394-J, January 2005
23
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+ 59
Table 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 121
Table 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 298
Table 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 337
Table 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 476
Table 16-3 Active-Standby Configuration 481
315394-J, January 2005
24 : 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 648
Table 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 2005
25
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 Youll 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 2005
26 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 2005
Preface 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
switchmonitoring 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).
315394-J, January 2005
28 Preface
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 Users 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 2005
Preface 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
30 Preface
315394-J, January 2005
Part 1: Basic Switching
This 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 2005
32 : Basic Switching
315394-J, January 2005
33
CHAPTER 1
Accessing the Switch
The Alteon OS software provides means for accessing, configuring, and viewing information
and 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 2005
34 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]
315394-J, January 2005
Chapter 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 a
network 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
315394-J, January 2005
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
315394-J, January 2005
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
315394-J, January 2005
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 4
name "usr"
/cfg/sys/ssnmp/snmpv3/access 3
name "usrgrp"
rview "usr"
wview "usr"
nview "usr"
/cfg/sys/ssnmp/snmpv3/group 4
uname usr
gname usrgrp
/cfg/sys/ssnmp/snmpv3/view 6
name "usr"
tree "1.3.6.1.4.1.1872.2.5.1.2"
name "usr"
tree "1.3.6.1.4.1.1872.2.5.1.3"
name "usr"
tree "1.3.6.1.4.1.1872.2.5.2.2"
name "usr"
tree "1.3.6.1.4.1.1872.2.5.2.3"
name "usr"
tree "1.3.6.1.4.1.1872.2.5.3.2"
name "usr"
tree "1.3.6.1.4.1.1872.2.5.3.3"
name "usr"
tree "1.3.6.1.4.1.1872.2.5.4.2"
name "usr"
tree "1.3.6.1.4.1.1872.2.5.4.3"
name "usr"
tree "1.3.6.1.4.1.1872.2.5.5.2"
name "usr"
tree "1.3.6.1.4.1.1872.2.5.5.3"
name "usr"
tree "1.3.6.1.4.1.1872.2.5.6.2"
315394-J, January 2005
To configure an SNMP user equivalent to the CLI access level for oper, use the following
configuration:
name "slboper"
name "slbopergrp"
rview "slboper"
wview "slboper"
nview "slboper"
uname slboper
gname slbopergrp
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.1.2"
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.1.3"
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.2.2"
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.2.3"
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.3.2"
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.3.3"
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.4"
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.4.1"
type excluded
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.5.2"
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.5.3"
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.6.2"
315394-J, January 2005
Configuring SNMP Trap Hosts
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 10
name "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
315394-J, January 2005
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
name "v2trap"
name "v2trap"
model snmpv2
nview "iso"
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
315394-J, January 2005
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 authentication
only:
>> # /cfg/sys/ssnmp/snmpv3/access <x>/level
Enter new access level [noAuthNoPriv|authNoPriv|authPriv]: <access-level>
>> # /cfg/sys/ssnmp/snmpv3/tparam <snmpTargetParams number: (1-16)>
>> /cfg/sys/ssnmp/snmpv3/usm <usmUser number: (1-16)>
name "v3trap"
auth md5
authpw v3trap
name "v3trap"
level authNoPriv
nview "iso"
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
315394-J, January 2005
Using Alteon EMS
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 application
communicates 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.
315394-J, January 2005
Export data to a file such as an Excel spreadsheet
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.
315394-J, January 2005
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>
315394-J, January 2005
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
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 the
client, the BBI can be used as described in the BBI Quick Guide.
Using the Management Port
The management port is a Fast Ethernet port on the 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 InterfaceAlteon 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/generate
Country Name (2 letter code) [ ]: <country code>
State or Province Name (full name) []: <state>
Locality Name (eg, city) []: <city>
Organization Name (eg, company) []: <company>
Organizational Unit Name (eg, section) []: <org. unit>
Common Name (eg, YOUR name) []: <name>
Email (eg, email address) []: <email address>
Confirm generating certificate? [y/n]: y
Generating certificate. Please wait (approx 30 seconds)
restarting SSL agent
315394-J, January 2005
performing TFTP functions (ptimg, gtimg, ptcfg, gtcfg, ptdmp)
accessing the SMTP server
running ping, Telnet and traceroute commands
NOTE BOOTP is not supported over the management port.
For more information on using the commands to perform these functions, see the 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 Switch
over 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)
315394-J, January 2005
NOTE The default for TFTP can be overridden by using the data or mgmt option after a
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 2005
49
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. The
maximum rate (packets per second) can be configured differently for each of the supported
protocols.
315394-J, January 2005
50 Chapter 2: Securing the Switch
How Different Protocols Attack 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
processors CPU capacity:
Address Resolution Protocol (ARP) requests to the switch management interface IP
address.
ICMP pings to the switch management interface IP address.
TCP SYN packets sent the switch management interface IP addressincluding Telnet
sessions, HTTP requests via the Browser-Based Interface, and BGP peer connections to
the switch. TCP Rate Limiting 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 addressincluding 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/rlimit
Enter protocol [arp|icmp|tcp|udp]: arp
Current max rate: 0
Enter new max rate: 1000 (Set rate to 1000 packets per second)
315394-J, January 2005
Chapter 2: Securing the Switch 51
Viewing Dropped Packets
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/maint
Enter 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: 1482
tcpDiscards: 68 udpDiscards: 351
315394-J, January 2005
Setting Allowable Source IP Address
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 switchs 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 packet
addressed 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 is
not granted access. To make this source IP address valid, you would need to shift the host
to an IP address within the valid range 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.0
Enter Management Network Mask: 255.255.255.128
315394-J, January 2005
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 switchis a client to
the back-end database server. A remote user (the remote administrator) interacts only with the
RAS, not the back-end server and database.
RADIUS authentication consists of the following components:
A protocol with a frame format that utilizes UDP over IP (based on RFC 2138 and 2866)
A centralized server that stores all the user authorization information
A client, in this case, the switch
RADIUS Authentication Features 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.
315394-J, January 2005
How Radius Authentication Works
In Figure 2-1, the Alteon Application Switchacting as the RADIUS clientcommunicates
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 RADIUS
server are authenticated using a shared key that is not sent over the network. In addition, the
remote administrator passwords are sent encrypted between the RADIUS client (the switch)
and the back-end RADIUS server.
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 server
instructs the switch to
grant or deny admim access
Authentication
Servers
Alteon Application Switch
315394-J, January 2005
Configuring RADIUS Authentication on the Switch
1. Turn RADIUS authentication on, then configure the Primary and Secondary RADIUS
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: OFF
New status: ON
>> RADIUS Server# prisrv 10.10.1.1 (Enter primary server IP)
Current primary RADIUS server: 0.0.0.0
New pending primary RADIUS server: 10.10.1.1
>> RADIUS Server# secsrv 10.10.1.2 (Enter secondary server IP)
Current secondary RADIUS server: 0.0.0.0
New pending secondary RADIUS server: 10.10.1.2
>> RADIUS Server# secret
Enter new RADIUS secret: <1-32 character secret>
!
CAUTIONIf 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# port
Current RADIUS port: 1645
Enter new RADIUS port [1500-3000]: <port number>
>> RADIUS Server# retries
Current RADIUS server retries: 3
Enter new RADIUS server retries [1-3]: < server retries>
>> RADIUS Server# time
Current RADIUS server timeout: 3
Enter new RADIUS server timeout [1-10]: 10(Enter the timeout period in minutes)
315394-J, January 2005
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 managing
traffic 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
315394-J, January 2005
RADIUS Attributes for Alteon OS User Privileges
When the user logs in, the switch authenticates his/her level of access by sending the RADIUS
access request, that is, the client authentication request, to the RADIUS authentication server.
If the remote user is successfully authenticated by the authentication server, the switch 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 the
administrator. 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 250
admin Vendor-supplied 6 (pre-defined)
315394-J, January 2005
TACACS+ Authentication
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.
315394-J, January 2005
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 users 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
315394-J, January 2005
Configuring TACACS+ Authentication on the Switch
1. Turn TACACS+ authentication on, then configure the Primary and Secondary
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: OFF
New status: ON
>> TACACS+ Server# prisrv 10.10.1.1 (Enter primary server IP)
Current primary TACACS+ server: 0.0.0.0
New pending primary TACACS+ server: 10.10.1.1
>> TACACS+ Server# secsrv 10.10.1.2 (Enter secondary server IP)
Current secondary TACACS+ server: 0.0.0.0
New pending secondary TACACS+ server: 10.10.1.2
>> TACACS+ Server# secret
Enter new TACACS+ secret: <1-32 character secret>
!
CAUTIONIf 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# port
Current TACACS+ port: 49
Enter new TACACS+ port [1500-3000]: <port number>
>> TACACS+ Server# retries
Current TACACS+ server retries: 3
Enter new TACACS+ server retries [1-3]: < server retries>
>> TACACS+ Server# time
Current TACACS+ server timeout: 3
Enter new TACACS+ server timeout [1-10]: 10(Enter the timeout period in minutes)
315394-J, January 2005
Secure Shell and Secure Copy
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.52.x. The following SSH clients have been tested:
SSH 1.2.23 and SSH 1.2.27 for Linux (freeware)
SecureCRT 3.0.2 and SecureCRT 3.0.3 for Windows NT (Van Dyke Technologies, Inc.)
F-Secure SSH 1.1 for Windows (Data Fellows)
Putty SSH
Cygwin OpenSSH
Mac X OpenSSH
Solaris 8 OpenSSH
AxeSSH SSHPro
SSH Communications Vandyke SSH A
F-Secure
NOTE There can be a maximum number of four simultaneous Telnet/SSH/SCP connections
at one time. The /cfg/sys/radius/telnet command also applies to SSH/SCP connec-
tions.
Configuring SSH/SCP features on the switch
SSH/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.
315394-J, January 2005
Enabling or disabling SSH
Connect to the switch CLI and enter the following commands:
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: OFF
New 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 reboot
the box immediately.
RSA server key generation starts
............................................................
RSA server key generation completes (lasts 75503 ms)
RSA server key is being saved to Flash ROM, please don't reboot
the box immediately.
------------------------------------------------------------------
Apply complete; don't forget to "save" updated configuration.
>> # /cfg/sys/sshd/dis (Disable SSH/SCP apply and save)
315394-J, January 2005
To configure the password, enter the following command via the CLI. At factory default set-
tings, the current SCP administrator password is admin.
SCP Services
To perform SCP commands, you need the SCP admin password with administrator privileges
(this password must be different from the admin password).
The following SCP commands are supported in this service. These commands are entered
using the CLI on the client that is running the SCP application:
getcfg is used to download the switchs configuration to the remote host via SCP.
putcfg is used to upload the switchs 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:
>> /cfg/sys/sshd/scpadm
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>
315394-J, January 2005
Example:
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.
>> # ssh 205.178.15.157
>> # ssh -l <login-name> 205.178.15.157 (Login to the switch)
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
315394-J, January 2005
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
every connection
Key Exchange: RSA
Encryption: 3DES-CBC, DES
User Authentication: Local password authentication, RADIUS, SecurID (via
RADIUS, for SSH onlydoes not apply to SCP)
Generating RSA Host and Server Keys for SSH Access
To support the SSH server feature, two sets of RSA keys (host and server keys) are required.
The host key is 1024 bits and is used to identify the 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)>
315394-J, January 2005
The number of hours must range between 024. A value of 0 denotes that RSA server key
autogeneration is disabled. When greater than 0, the switch 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 Authentication
SSH/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.
315394-J, January 2005
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.
Use the command, /cfg/sys/sshd/scpadm to bypass the checking of SecurID.
An SCP-only administrators 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 administrators password must be different from the regular adminis-
trators password. If the two passwords are the same, the administrator using that password
will 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 real
server. 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.
315394-J, January 2005
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
315394-J, January 2005
Defining User Names and Passwords
Changing Passwords
Defining a Users 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 users 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 # name jane (Assign name jane to user ID 1)
Current user name:
New user name: jane
>> User ID 1 # passwd
Changing user password; validation required:
Enter current admin password: <current administrator password>
Enter new user password: <new user password>
Re-enter new user password: <new user password>
New user password accepted.
>> User ID 1 # cos <user|slboper|l4oper|oper|slbadmin|l4admin|admin>
>> User ID 1 # add
Enter real server number: (1-1023) 23
315394-J, January 2005
Validating a Users Configuration
Listing Current Users
The cur command displays defined user accounts and whether or not each user is currently
logged into the switch.
User ID 2 # cur
name jane , dis, cos user , password valid, offline
real servers:
23: 0.0.0.0, disabled, name , weight 1, timeout 20 mins, 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
315394-J, January 2005
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-
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 established
for 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
315394-J, January 2005
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
static 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 dont enter one here.)
!
CAUTIONDo not configure a deny route that covers the destination/mask pair of an existing
IP interfaces IP address/mask pair. For example, if you have an IP interface of 50.0.0.1/
255.0.0.0, and a deny route of 50.0.0.0/255.0.0, then traffic to the interface as well as the sub-
net will be deniedwhich is not the desired result.
315394-J, January 2005
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
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
315394-J, January 2005
315394-J, January 2005
75
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).
315394-J, January 2005
76 Chapter 3: VLANs
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.
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 ports PVID is configurable to any VLAN number between 1 and 4090.
Any untagged frames (those with no VLAN specified) are classified with the sending ports
PVID.
VLAN Tagging
Alteon 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.
315394-J, January 2005
Chapter 3: VLANs 77
VLANs and the IP Interfaces
Carefully consider how you create VLANs within the switch, so that communication with the
switch remains possible.
You can access the switch for remote 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 VLANs 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.
315394-J, January 2005
78 Chapter 3: VLANs
Example 1: Multiple VLANS with Tagging Adapters
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.
Server #1
VLAN #3
Server #2
Gigabit/Tagged
adapter
(All VLANs)
PC #1
VLAN #2
PC #2
VLAN #2
PC #3
VLAN #1
PC #4
VLAN #3
PC #5
Gigabit/Tagged
adapter
VLANs #1 & #2
Shared Media
315394-J, January 2005
Chapter 3: VLANs 79
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.
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.
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-tagging
Gigabit Ethernet adapter installed. It can minimize its broadcast
domain to Server #2 via VLAN 1, and to PC #1 and PC #2 via VLAN
2. The switch port to which it is connected is configured for both
VLAN 1 and VLAN 2 and has tagging enabled.
Component Description
315394-J, January 2005
80 Chapter 3: VLANs
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 Gigabit
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
315394-J, January 2005
Chapter 3: VLANs 81
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 Traffic
Deploy 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.20
Gateway 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 4
10.10.1.20
Alteon Application
Switch
26
7
25
8
27
315394-J, January 2005
82 Chapter 3: VLANs
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
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 is
routed via Gateway 5 instead of Gateway 6, because 192.168.20.200 in the route cache is
mapped to Gateway 5. If the requested route is not in the route cache, then the switch reads the
routing table. If the requested route is not in the routing table, then the switch looks at the 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
315394-J, January 2005
Chapter 3: VLANs 83
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# /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)
315394-J, January 2005
84 Chapter 3: VLANs
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.
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# addr 10.10.1.20 (Assign IP address for gateway 5)
>> Default gateway 5# /cfg/l3/gw 6 (Select default gateway 6)
>> /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
315394-J, January 2005
Chapter 3: VLANs 85
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
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 to
application 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.
315394-J, January 2005
86 Chapter 3: VLANs
Figure 3-4 Jumbo Frame VLANs
Configuring VLANs for Jumbo and Non-Jumbo Frames
To configure an Alteon 2424 for jumbo and non-jumbo frame traffic, configure two VLANs:
Jumbo Frame
VLAN
Normal Frame
VLAN
Normal Frame
VLAN
315394-J, January 2005
Chapter 3: VLANs 87
1. Add the switch uplink ports 25 and 26 to VLAN 2.
2. Enable jumbo frame processing on VLAN 2, then apply and save the changes.
>> Main# /cfg/l2/vlan 2
VLAN number 2 with name "VLAN 2" created.
------------------------------------------------------------
[VLAN 2 Menu]
name - Set VLAN name
stg - Assign VLAN to a Spanning Tree Group
cont - Set BW contract
add - Add port to VLAN
rem - Remove port from VLAN
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 25
Port 25 is an UNTAGGED port and its current PVID is 1.
Confirm changing PVID from 1 to 2 [y/n]: y
Current ports for VLAN 2: empty
Pending new ports for VLAN 2: 25
>> VLAN 2# add 26
Pending new ports for VLAN 2: 25 26
>> VLAN 2#
>> VLAN 2# jumbo enable
Current jumbo frame support: disabled
New jumbo frame support: enabled
>> apply
>> save
315394-J, January 2005
88 Chapter 3: VLANs
315394-J, January 2005
89
CHAPTER 4
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
315394-J, January 2005
90 Chapter 4: Port Trunking
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.
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 in
the distribution algorithm. Each packets particular combination of source and destination
MAC addresses results in selecting one line in the trunk group for data transmission. If there
are enough Layer 2 devices feeding the trunk lines, then 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
315394-J, January 2005
Chapter 4: Port Trunking 91
By adding Layer 3 IP address information to the distribution algorithm, a far wider variety of
address combinations is seen. Even with just a few routers feeding the trunk, the normal
source/destination IP address combinations (even within a single LAN) can be widely varied.
This results in a wider statistical load distribution and maximizes the use of the combined
bandwidth available to trunked ports.
The Trunk Hash Algorithm
In order to distribute the load across all active ports in a trunk group, the following algorithm is
used to determine which port within the trunk group to use for frame forwarding:
hash_idx = (A xor B)
port = (lower 6 bits of hash_idx) mod x
where x is the number of active ports within the trunk group. The parameters A and B are
given below for different types of forwarding and frames. These two parameters are 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.
315394-J, January 2005
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
switchs 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
315394-J, January 2005
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.
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.
!
CAUTIONTo prevent spanning tree instability, do not change the spanning tree parameters on
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)
315394-J, January 2005
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.
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.
>> /info/l2/trunk (View trunking information)
315394-J, January 2005
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 reassigned
dynamically to any of the remaining links of the LACP trunk group. Link aggregation is a
method of grouping physical link segments of the same media type and speed in full duplex,
and treating them as if they were part of a single, logical link segment. 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 112, 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 of
the 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)
315394-J, January 2005
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 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 ports association with the
LACP trunk group is lost.
When the system is initialized, all ports by default are in LACP off mode and are assigned
unique admin keys. To make a group of ports eligible for aggregation, you assign them all the
same admin key. You must set the ports LACP mode to active to activate LACP negotiation.
You can set other ports LACP mode to passive, to reduce the amount of LACPDU 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.
315394-J, January 2005
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.
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: off
New Port 1 LACP mode setting: active
>> # /cfg/l2/lacp/port 1/adminkey 100 (Set port 1 adminkey to 100)
Current LACP port adminkey: 1
New 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)
>> 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)
315394-J, January 2005
315394-J, January 2005
99
CHAPTER 5
Spanning Tree Protocol
When multiple paths exist on a network, Spanning Tree Protocol (STP) configures the network
so that a switch uses only the most efficient path.
Overview 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
315394-J, January 2005
100 Chapter 5: Spanning Tree Protocol
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.
The relationship between port, trunk groups, VLANs, and Spanning Trees is shown in
Table 5-1.
NOTE Due to Spanning Trees sequence of listening, learning, and forwarding or blocking,
lengthy delays may occur. For more information on using STP in cross-redundant topologies,
see Eliminating Loops with STP and VLANs 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
315394-J, January 2005
Chapter 5: Spanning Tree Protocol 101
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 network
through an exchange of BPDUs.
A BPDU is a 64-byte packet that is sent out at a configurable interval, which is typically set for
two seconds. The BPDU is used to establish a path, much like a hello packet in IP routing.
BPDUs contain information about the transmitting bridge and its ports, including bridge and
MAC addresses, bridge priority, port priority, and path cost. If the ports are tagged, each port
sends out a special BPDU containing the tagged information.
The generic action of a switch on receiving a BPDU is to compare the received BPDU to its
own BPDU that it 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-Mbps
link has a cost of 100, a 100-Mbps (Fast Ethernet) link carries a cost of 10, and a 1000-Mbps
(or Gigabit Ethernet) link has a cost of 1. The objective is to use the fastest links so that the
route with the lowest cost is chosen.
Bridge Priority
The bridge priority parameter controls which bridge on the network is the STP root bridge. To
make one switch the root bridge, 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.
315394-J, January 2005
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
encourage their use. The cost of a port also depends on whether the port operates at full-duplex
(lower cost) or half-duplex (higher cost). For example, if a 100-Mbps (Fast Ethernet) link has a
cost of 10 in half-duplex mode, it will have a cost of 5 in full-duplex mode. The objective is
to use the fastest links so that the route with the lowest cost is chosen. A value of 0 indicates
that the default cost will be computed for an auto-negotiated link speed.
Spanning Tree Compatibility between 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 a
BPDU. In the Nortel implementation, all of the ports in the trunk each transmit an identical
copy of the BPDU, and the tagged BPDUs are transmitted using a multicast MAC address as
tagged frames with a VLAN ID.
An 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 is
connected it to a Nortel product that uses tagging. Use the following commands to enable
Nortel tagged BPDU format:
Main # /cfg/l2/ntmstg ena (Enable Nortel tagged BPDU format)
Main # /boot/reset (Reset the switch to enable)
315394-J, January 2005
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 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.
315394-J, January 2005
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
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
315394-J, January 2005
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 sure
that 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.
!
CAUTIONAll 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.
315394-J, January 2005
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 instances
of 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
315394-J, January 2005
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
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, but
the 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
315394-J, January 2005
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.
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 2
Port 8
Port 1
STG 1
Port 8
STG 2
Port 8
STG 2
STG 1
Alteon Application
Switch D
Alteon Application
Switch C
315394-J, January 2005
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.
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-centricit is used to identify the VLANs participating in the Spanning Tree groups.
The Spanning Tree group ID is not transmitted in the BPDU. Each Spanning Tree decision is
based on the configuration of that 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
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
315394-J, January 2005
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.
315394-J, January 2005
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 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# /cfg/l2/vlan 3 (Select VLAN 3 menu)
315394-J, January 2005
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.
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 Routing
This 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 2005
114 : IP Routing
315394-J, January 2005
115
CHAPTER 6
Basic IP Routing
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
315394-J, January 2005
116 Chapter 6: Basic IP Routing
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-
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 are
increasingly 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.
315394-J, January 2005
Chapter 6: Basic IP Routing 117
For example, consider the following topology migration:
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.
Admin/Sales
Server
Subnet
Router
Switch
Staff/Eng2
Switch
Eng/Staff2/Sales
Switch
FDDI
Internet
Alteon Switch
Admin. Subnet
Server
Subnet
Hub
Staff Subnet
Hub
Eng. Subnet
Hub
Internet
FDDI
Router
315394-J, January 2005
Take a closer look at the Alteon Application Switch in the following configuration example:
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.
Second Floor
10/100 Client Subnet
131.15.15.2-254
First Floor
10/100 Client Subnet
100.20.10.2-254
1000 Mbps
100 Mbps
1000 Mbps
Secondary Default
Router: 205.21.17.2
Server Subnet:
206.30.15.2-254
Primary Default
Router: 205.21.17.1
IF#1 IF#4
IF#2 IF#3
IP Routing
100.20.10.1
205.21.17.3
131.15.15.1
206.30.15.1
315394-J, January 2005
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 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
315394-J, January 2005
IP interfaces are configured using the following commands at the CLI:
3. Set each server and workstations 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.
>> # /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)
>> 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)
315394-J, January 2005
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)
315394-J, January 2005
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# /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)
315394-J, January 2005
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.
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
315394-J, January 2005
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 manually
for each network device. DHCP allows a network administrator to distribute IP addresses from
a central point and automatically send a new IP address when a device is connected to a 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 on
the network and to centralize them. Without the DHCP relay agent, there must be at least one
DHCP server deployed at each subnet that has hosts needing to perform the DHCP request.
315394-J, January 2005
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
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 on
which VLAN to send the server response to the client.
315394-J, January 2005
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:
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
DHCP Relay Agent
DHCP Server
Boston Atlanta
20.1.1.1 10.1.1.2
315394-J, January 2005
127
CHAPTER 7
Routing Information Protocol
In a routed environment, routers communicate with one another to keep track of available
routes. Routers can learn about available routes dynamically using the Routing Information
Protocol (RIP). The Alteon OS software implements standard RIP for exchanging TCP/IP
route information with other routers.
Distance Vector Protocol
RIP is known as a distance vector protocol. The vector is the network number and next hop,
and the distance is the cost associated with the network number. RIP identifies network reach-
ability based on cost, and cost is defined as hop count. One hop is considered to be the distance
from one switch to the next which is typically 1. This cost or hop count is known as the metric.
When a switch receives a routing update that contains a new or changed destination network
entry, the switch adds 1 to the metric value indicated in the update and enters the network in
the routing table. The IP address of the sender is used as the next hop.
Stability
RIP 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.
315394-J, January 2005
128 Chapter 7: Routing Information Protocol
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
metric value) to a destination.
315394-J, January 2005
129
CHAPTER 8
Border 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
space they can access within their network and with routers on external networks. BGP allows
you to decide what is the best route for a packet to take from your network to a destination
on another network rather than simply setting a default route from your border router(s) to your
upstream provider(s). BGP is 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 Internets 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.
315394-J, January 2005
130 Chapter 8: Border Gateway Protocol
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
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
Application
Switches
315394-J, January 2005
Chapter 8: Border Gateway Protocol 131
Typically, an AS has one or more border routerspeer routers that exchange routes with other
ASsand an internal routing scheme that enables routers in that AS to reach every other router
and destination within that AS. When you advertise routes to border routers on other 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 to
carry that data to its destination.
Forming BGP Peer Routers
Two BGP routers become peers or neighbors once you establish a TCP connection between
them. For each new route, if a peer is interested in that route (for example, if a peer would like
to receive your static routes and the new route is static), an update message is sent to that peer
containing the new route. For each route removed from the route table, if the route has already
been sent to a peer, an update message containing the route to withdraw is sent to that peer.
For each Internet host, you must be able to send a packet to that host, and that host has to have a
path back to you. This means that whoever provides Internet connectivity to that host must have
a path to you. Ultimately, this means that they must hear a route which covers the section of the
IP space you are using; otherwise, you will not have connectivity to the host in question.
What is a Route Map?
A route map is used to control and modify routing information. Route maps 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)
315394-J, January 2005
Alteon OS allows you to configure 32 route maps. Each route map can have up to eight access
lists. Each access list consists of a network filter. A network filter defines an IP address and
subnet mask of the network that you want to include in the filter. Figure 8-2 illustrates the rela-
tionship between route maps, access lists and network filters.
Figure 8-2 Distributing Network Filters in Access Lists and Route Maps
Incoming and Outgoing Route Maps
You can have two types of route maps: incoming and outgoing. A BGP peer router can be con-
figured to support up to eight route maps in the incoming route map list and outgoing route
map list.
If a route map is not configured in the incoming route map list, the router imports all BGP
updates. If a route map is configured in the incoming route map list, the router ignores all
unmatched incoming updates.
Route maps in an outgoing route map list behave similar to route maps in an incoming route
map list. If a route map is not configured in the outgoing route map list, all routes are adver-
tised or permitted. If a route map is configured in the outgoing route map list, matched routes
are advertised and unmatched routes are ignored.
Access Lists
(alist)
Network Filter
(nwf)
Route Maps
(rmap)
1
Route Map 1
8
1
8
1
Route Map 2
8
9
16
1
Route Map 32
8
249
256
-----
-----
-----
-----
-----
-----
-----
---
---
---
---
---
---
---
---
---
315394-J, January 2005
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:
1. Define network filter.
Enter a filter number from 1 to 256. Specify the IP address and subnet mask of the network that
you 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/rmap <x>/pre (Specify a precedence)
>> # /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)
315394-J, January 2005
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.
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 Routes
Aggregation is the process of combining several different routes in such a way that a single
route can be advertised, which minimizes the size of the routing table. You can 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/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)
>> # /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)
315394-J, January 2005
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.
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
OriginateThe router sends a default route to peers even though it does not have any
default routes in its routing table.
>> # /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)
315394-J, January 2005
RedistributeDefault 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/lp
This command uses the route map local preference method, which affects both inbound
and outbound directions.
Metric (Multi-Exit Discriminator) Attribute
This attribute is a hint to external neighbors about the preferred path into an AS when there are
multiple entry points. A lower metric value is preferred over a higher metric value. The default
value of the metric attribute is 0.
Unlike local preference, the metric attribute is exchanged between ASs; however, a metric
attribute that comes into an AS does not leave the AS.
When an update enters the AS with a certain metric value, that value is used for decision mak-
ing within the AS. When BGP sends that update to another AS, the metric is reset to 0.
315394-J, January 2005
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.
315394-J, January 2005
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.
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.
ISP 2
Default gateway,
with routes having
shorter AS PATH
VIP: 200.200.200.200
IP: 200.200.200.1
IP:210.210.210.1
Alteon Application
switch
announces
routes with
metric of "3"
Peer 1 Router
(Primary)
IP: 200.200.200.2
AS 100
ISP 1
AS 200
Real server 2
IP: 200.200.200.11
Real server 1
IP: 200.200.200.10
AS 300
AS 300
Peer 2 Router
(Secondary)
IP: 210.210.210.2
Alteon metric = AS path
length (metric of '3' = local
AS repeated 3 times
315394-J, January 2005
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)
315394-J, January 2005
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.
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/on
>> # /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# 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)
315394-J, January 2005
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/8
traversing from
AS 135 to AS 200
AS 200
135.110.0.0/16
135.120.0.0/16
AS 135

Internal peer router 1
10.1.1.4
10.1.1.135
Alteon Application
switch
0.0.0.0/0
Default routes towards
internal peer router
External peer router 2
20.20.20.2
20.20.20.135
315394-J, January 2005
3. Configure internal peer router 1 and external peer router 2.
4. Configure redistribution for Peer 1.
5. Configure aggregation policy control.
Configure the routes that you want aggregated.
>> # /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)
>> # /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
315394-J, January 2005
Part 3: Application Switching
Fundamentals
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 2005
144 : Application Switching Fundamentals
315394-J, January 2005
145
CHAPTER 9
Open 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.
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
315394-J, January 2005
146 Chapter 9: Open Shortest Path First (OSPF)
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). The
LSDB for all routing devices within an area is identical but is not exchanged between different
areas. Only routing updates are exchanged between areas, thereby 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
Equal-cost multipath (ECMP) is a routing technique for routing packets along multiple paths
of equal cost. The routing table contains multiple next-hops for any given destination. The
router load balances packets along the multiple next-hops. 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 Areaan area that is connected to only one other area. External route information is
not distributed into stub areas.
Not-So-Stubby-Area (NSSA)similar to a stub area with additional capabilities. Routes
originating from within the NSSA can be propagated to adjacent transit and backbone
areas. External routes from outside the AS can be advertised within the NSSA but are not
distributed into other areas.
315394-J, January 2005
Chapter 9: Open Shortest Path First (OSPF) 147
Transit Areaan area that allows area summary information to be exchanged between
routing devices. The backbone (area 0), any area that contains a virtual link to connect two
areas, and any area that is not a stub area or an NSSA are considered transit areas.
Figure 9-1 OSPF Area Types
Backbone
Area 0
Stub Area
Not-So-Stubby Area
(NSSA)
Transit Area
No External Routes
from Backbone
Stub Area, NSSA,
or Transit Area
Connected to Backbone
via Virtual Link
(Also a Transit Area)
External LSA
Routes
Internal LSA
Routes
ABR
ABR
ABR
ASBR
Non-OSPF Area
RIP/BGP AS
Virtual
Link
ABR
ABR = Area Border Router
ASBR = Autonomous System
Boundary Router
315394-J, January 2005
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.
Figure 9-2 OSPF Domain and an Autonomous System
Backbone
Area 0
Area 3
Area 2
Area 1
Inter-Area Routes
(Summary Routes)
ABR
ABR
ABR
ASBR
Internal
Router
ASBR
External
Routes
BGP
RIP
OSPF Autonomous System
315394-J, January 2005
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 others hello packets and become neighbors. Neighbors continue to send
periodic hello packets to advertise their health to neighbors. In turn, they listen to hello packets
to determine the health of their neighbors and to establish contact with new neighbors.
The hello process is used for electing one of the neighbors as the areas Designated Router
(DR) and one as the areas Backup Designated Router (BDR). The DR is adjacent to all other
neighbors and acts as the central contact for database exchanges. Each neighbor sends its data-
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 devices LSDB, the routing device forwards the
changes to the adjacent neighbors (the DR and BDR) for distribution to the other neighbors.
OSPF routing updates occur only when changes occur, instead of periodically. For each new
route, if an adjacency is interested in that route (for example, if configured to receive static
routes and the new route is indeed static), an update message containing the new route is sent
to the adjacency. For each route removed from the route table, if the route has already been
sent to an adjacency, an update message containing the route to withdraw is sent.
315394-J, January 2005
The Shortest Path First Tree
The routing devices use a link-state algorithm (Dijkstras algorithm) to calculate the shortest
path to all known destinations, based on the cumulative cost required to reach the destination.
The cost of an individual interface in OSPF is an indication of the overhead required to send
packets across it. The cost is inversely proportional to the bandwidth of the interface. A lower
cost indicates a higher bandwidth.
Internal Versus External Routing
To ensure effective processing of network 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.
315394-J, January 2005
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
Authentication on page 157Host 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) intervalTime interval between successive calculations of the
shortest path tree using the Dijkstras algorithm.
Stub area metricA 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 routesDefault routes with weight metrics can be manually injected into transit
areas. This helps establish a preferred route when multiple routing devices exist between
two areas. It also helps route traffic to external networks.
315394-J, January 2005
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 informationan area index and an area
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 the
areaid portion of the command as explained in the following sections.
Assigning the Area Index
The aindex <area index> option is actually just an arbitrary index (0-2) used only by the
switch. This index does not necessarily represent the OSPF area number, though for 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)
Area index set to an arbitrary value
>> # /cfg/l3/ospf/aindex <area index>/areaid <n.n.n.n>
315394-J, January 2005
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 network 1.1.1.0 0.0.0.255 area 1
defines the area number simply as area 1. On the application switch, using the last
octet in the area ID, area 1 is equivalent to areaid 0.0.0.1.
Multi-octet (IP address)
Some OSPF vendors express the area ID number in multi-octet format. For example,
area 2.2.2.2 represents OSPF area 2 and 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)
315394-J, January 2005
Interface Cost
The OSPF link-state algorithm (Dijkstras algorithm) places each routing device at the root of
a tree and determines the cumulative cost required to reach each destination. Usually, the cost
is inversely proportional to the bandwidth of the interface. Low cost indicates high bandwidth.
You can manually enter the cost for the output route with the following command:
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
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 that
the 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>/cost <cost value (1-65535)>
>> # /cfg/l3/ospf/if <OSPF interface number>/prio <priority value (0-127)>
>> # /cfg/l3/ospf/range <range number>/addr <IP address>/mask
<mask>
315394-J, January 2005
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 switchs IP interface, and then into the connected transit area (usually the backbone).
Since this is automatic, no further configuration is required for such areas.
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
IF 1 IF 2
Backbone Stub Area Stub Area
Area 2 Area 1 Area 0
ABR
ABR
ASBR to
External Networks
IR
ABR
Metric:
10
Default
Route
Priority
Default
Route
Priority
Default
Route
IR Metric:
900
Metric:
201
Metric:
200
315394-J, January 2005
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:
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/default none
>> # /cfg/l3/ospf/aindex <area index>/type transit
>> # /cfg/l3/ospf/virt <link number>/aindex <area index>/nbr <router
ID>
315394-J, January 2005
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:
DynamicallyOSPF protocol configures the lowest IP interface IP address as the router
ID. This is the default.
StaticallyUse 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:
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
>> # /cfg/l3/rtrid <IP address>
>> # /info/l3/ospf/gen
IF 1
Area 1 Area 0
ABR
ABR
ASBR to
External Networks
Area 2
Virtual link
key=alteon
Simple authentication
key=test
IF 3
IF 4
IF 2
IF 5
Alteon Web
switch 1
Alteon Web
switch 2
Alteon Web
switch 3
Alteon Web
switch 5
Alteon
Web switch 4
315394-J, January 2005
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.
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.
>> # /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
>> # /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
315394-J, January 2005
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.
6. Assign MD5 key ID to OSPF virtual link on Alteon switches 2 and 4.
>> # /cfg/l3/ospf/if 1
>> OSPF Interface 1 # mdkey 1
>> # /cfg/l3/ospf/aindex 2/auth md5
>> # /cfg/l3/ospf/md5key 2/key alteon
>> # /cfg/l3/ospf/virt 1/mdkey 2
315394-J, January 2005
Host Routes for Load Balancing
Alteon OS implementation of OSPF includes host routes. Host routes are used for advertising
network device IP addresses to external networks, accomplishing the following goals:
Server Load Balancing (SLB) within OSPF
Host routes advertise virtual server IP addresses to external networks. This allows stan-
dard SLB between the Alteon Application Switch and the server pools in an OSPF envi-
ronment. For more information on SLB, see Chapter 10, Server Load Balancing and
your Alteon OS Command Reference.
ABR Load Sharing
As a second form of load balancing, host routes can be used for dividing OSPF traffic
among multiple ABRs. To accomplish this, each application switch provides identical ser-
vices but advertises a host route for a different virtual server IP address to the external net-
work. If each virtual server IP address serves a different and equal portion of the external
world, incoming traffic from the upstream router should be split evenly among ABRs.
ABR Failover
Complementing ABR load sharing, identical host routes can be configured on each ABR.
These host routes can be given different costs so that a different ABR is selected as the
preferred route for each virtual server and the others are available as backups for failover
purposes.
If redundant routes via multiple routing processes (such as OSPF, RIP, BGP, or static routes)
exist on your network, the application switch defaults to the OSPF-derived route.
For a configuration example, see Example 4: Host Routes on page 174.
Redistributing Routes into OSPF
Alteon OS software allows your switch to emulate an ASBR by redistributing information
from other routing protocols (static, RIP, iBGP, eBGP, and fixed routes) into OSPF. For infor-
mation on ASBR, see Types of OSPF Routing Devices on page 148. For example, you can
instruct OSPF to readvertise a RIP-derived route into OSPF as an AS-External LSA. Based on
this LSA, other routers in the OSPF routing domain will install an OSPF route.
Use the following command to redistribute a protocol into OSPF:
/cfg/l3/ospf/redist <protocol name>
where the protocol name is static, RIP, iBGP, eBGP, or fixed.
By default, these protocol routes are not redistributed into OSPF.
315394-J, January 2005
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:
where metric sets the OSPF cost for the route and metric type (either 1 or 2) determines
whether the routes cost includes or excludes external costs of the route. If you want to remove
a previous 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 <metric> <metric type>
/cfg/l3/ospf/redist <protocol name>/export none
Table 9-1 Route Maps
Task 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
315394-J, January 2005
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.
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>/ena
/cfg/l3/rmap <route map number>/metric <metric value>
/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>
315394-J, January 2005
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.
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)
/cfg/l3/rmap <route map number>/type [1|2]
/cfg/l3/rmap <l>/alist <access list number>/metric <metric value>
315394-J, January 2005
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.
315394-J, January 2005
Example 1: Simple OSPF Domain
In this example, two OSPF areas are definedone 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 areas IP interface, and then into the backbone.
Figure 9-5 A Simple OSPF Domain
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/24
and 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)
Area 0
(0.0.0.0)
IF 1
10.10.7.1
IF 2
10.10.12.1
Area 1
(0.0.0.1)
Backbone Stub Area
Network
10.10.7.0/24
Network
10.10.12.0/24
Alteon Application
switch
315394-J, January 2005
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.
6. Attach the network interface to the stub area.
7. Apply and save the configuration changes.
>> 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)
>> 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)
315394-J, January 2005
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
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 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)
Router ID:
10.10.10.1
Router ID:
10.10.14.1
Alteon
Application
switch #1
Alteon
Application
switch #2
Virtual Link 1
Area 0
(0.0.0.0)
IF 1
10.10.7.1
IF 2
10.10.12.1
Area 1
(0.0.0.1)
Backbone Transit Area
IF 1
10.10.12.2
IF 2
10.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
315394-J, January 2005
5. Define the transit area.
The area that contains the virtual link must be configured as a transit area.
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 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)
>> 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)
315394-J, January 2005
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.
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 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 # /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 # type transit (Define area as transit type)
315394-J, January 2005
8. Attach the network interface to the transit area.
9. Configure the virtual link.
The nbr router ID configured in this step must be the same as 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 1 # aindex 1 (Attach network to transit area index)
>> OSPF Interface 1 # 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.10.1 (Specify the router ID of the recipient)
>> OSPF Virtual Link 1 # enable (Enable the virtual link)
315394-J, January 2005
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.
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.
IF 1
10.10.7.1
IF 2
36.128.192.1
Area 1
(0.0.0.1)
36.128.192.x to
36.128.254.x
Area 0
(0.0.0.0)
Summary
Route
ABR
Stub Area Backbone
36.128.192.0/18
Network
10.10.7.0/24
Network
Alteon Application
switch
315394-J, January 2005
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 2 # /cfg/l3/ospf/on (Enable OSPF on the Alteon switch)
315394-J, January 2005
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)
315394-J, January 2005
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. Traffic
comes in for both virtual server IP addresses (10.10.10.1 and 10.10.10.2). The upstream router
sees that both addresses exist on both 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
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 Route
10.10.10.1
Preferred path
(lowest cost)
to Host Route
10.10.10.2
Virtual Servers/Host Routes:
10.10.10.1, Cost 1
10.10.10.2, Cost 100
Virtual Servers/Host Routes:
10.10.10.1, Cost 100
10.10.10.2, Cost 1
Area 1
Stub Area
Area 0
Backbone
Real Servers
with Identical
Content
315394-J, January 2005
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.
3. Configure client and server processing on specific ports.
4. Enable direct access mode.
>> Virtual server 1 # /cfg/l3/if 1 (Select menu for IP interface 1)
>> # /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)
>> 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)
315394-J, January 2005
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.
7. Enable OSPF on Alteon Application Switch 1.
>> 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 # 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) 1 # areaid 0.0.0.1 (Set the ID for stub area 1)
315394-J, January 2005
12. Configure host routes.
One host route is needed for each virtual server on Alteon Application Switch 1. Since virtual
server 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 # 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)
315394-J, January 2005
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.
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.
>> # /cfg/slb/real 1 (Select menu 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 # enable (Enable the group)
>> Real server group 1 # /cfg/slb/on (Turn SLB on)
>> Layer 4 # /cfg/slb/virt 1 (Select menu for virtual server 1)
>> Virtual server 1 # enable (Enable the 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 # 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)
315394-J, January 2005
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)
315394-J, January 2005
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.
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 Interface 2 # /cfg/l3/ospf/host 1 (Select menu for host route 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 # apply (Global command to apply all changes)
>> OSPF Host Entry 2 # save (Global command to save all changes)
315394-J, January 2005
181
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
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.
315394-J, January 2005
182 Chapter 10: Server Load Balancing
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 pools capabilities are saturated, new servers can be
added to the pool transparently.
Identifying Your Network Needs
SLB may be the right option for addressing these vital network concerns:
A single server no longer meets the demand for its particular application.
The connection from your LAN to your server overloads the servers capacity.
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 cant afford to continue using an inferior load-balancing technique, such as DNS
round robin or a software-only system.
315394-J, January 2005
Chapter 10: Server Load Balancing 183
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.
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).
Retail
Trading
Lending
Retail
Trading
Lending
Retail
Trading
Lending
Retail
Trading
Lending
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 Application
switch
315394-J, January 2005
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 of
services 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
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, 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, and
Host Headers) to make intelligent load balancing decisions.
URL-based load balancing, browser-smart load balancing, and cookie-based preferential
load balancing are a few examples of content-based load balancing.
315394-J, January 2005
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.
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
NFS Server
Web Clients
Internet
Web Host
Router
As clients increase, the server becomes overloaded
Web Server Farm
NFS Server
Alteon Application
Switch
A
B
C
Web Clients
Internet
Web Host
Routers
Layer 4 Switching &
Layer 2
Switching
Layer 2
Switching
315394-J, January 2005
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 the
real 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.
Clients
Switch
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 Application
Switch
Router
Router
315394-J, January 2005
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 the
switch 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 Application
Switch
Router
DNS
Server
Pool
Web
Server
Pool
Internet
C
S
Client Processing
Server Processing
S
C
Clients on the Internet
initiate HTTP sessions which
are load balanced to Web servers
Web servers initiate DNS requests
which are load balanced
to DNS servers
S
C
port 11
port 14
port 25
port 13
315394-J, January 2005
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
315394-J, January 2005
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, and
enable 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# /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)
315394-J, January 2005
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)
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 real
servers. 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
315394-J, January 2005
The ports are configured as follows:
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:
>> 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 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)
>> Layer 4# save (Save for restore after reboot)
>> Layer 4# /info/slb/dump (View SLB information)
315394-J, January 2005
Supported Services and Applications on page 192
Disabling and Enabling Real Servers on page 193
IP Address Ranges Using imask on page 194
Health Checks for Real Servers on page 194
Configuring Multiple Services on page 194
Metrics for Real Server Groups on page 195
Weights for Real Servers on page 199
Connection Time-outs for Real Servers on page 200
Maximum Connections for Real Servers on page 200
Backup/Overflow Servers on page 201
Supported Services and Applications
Each virtual server can be configured to support up to eight services, limited to a total of 1023
services per switch. Using the /cfg/slb/virt <virtual server number>/service option,
the following TCP/UDP applications can be specified:
NOTE The service number specified on the switch must match the service specified on the server.
NOTE Load balancing some applications (such as FTP and RTSP) require special configura-
tion. See Chapter 11 for more information.
Table 10-3 Well-Known Application Ports
Number TCP/UDP
Application
Number TCP/UDP
Application
Number TCP/UDP
Application
20
21
22
23
25
37
42
43
53
69
70
ftp-data
ftp
ssh
telnet
smtp
time
name
whois
domain
tftp
gopher
79
80
109
110
111
119
123
143
144
161
162
finger
http
pop2
pop3
sunrpc
nntp
ntp
imap
news
snmp
snmptrap
179
194
220
389
443
520
554
1645, 1812
1813
1985
bgp
irc
imap3
ldap
https
rip
rtsp
Radius
Radius Accounting
hsrp
315394-J, January 2005
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-
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/dis <real server number> n
>> # /oper/slb/dis <real server number> p
>> # /oper/slb/ena <real server number>
315394-J, January 2005
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
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 dependent
on each other. If a real server fails a health check for a service, then the status of the real server
for the second service appears as blocked.
>> # /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)
315394-J, January 2005
Independent Services. If you are configuring two independent services such as FTP and
SMTPwhere the real server failure on one service does not affect other services that the real
server supports, then 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 and
HTTPSwhere 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.
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 Alteon
OS 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)
315394-J, January 2005
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 applications
where 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.
315394-J, January 2005
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-
bution as you would with the standard hash metric.
Tunable Hash
By default, the hash metric has used the clients 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.
315394-J, January 2005
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-
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.
315394-J, January 2005
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 times
the 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
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.
>> Real server# weight 10 (10 times the number of connections)
>> # /cfg/slb/adv/snmphc < SNMP health script number>
>> SNMP Health Check 1# weight e (Enable weighting via SNMP
health check)
315394-J, January 2005
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
quicker, multiprocessor servers. The appropriate value also depends on the duration of each
session and how much CPU capacity is occupied by processing each session. Connections that
use a lot of Java or CGI scripts for forms or searches require more server resources and thus a
lower maxcon limit. You may wish to use a performance benchmark tool to determine how
many connections your real servers can handle.
When a server reaches its maxcon limit, the switch no longer sends new connections to the
server. When the server drops back below the maxcon limit, new sessions are again allowed.
Unlimited Connections to Real Servers
This feature allows an unlimited number of connections to be allocated to 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 switchs maximum of 2 Million connections.
>> Real server# tmout 4 (Specify an even numbered interval)
>> Real server# maxcon 1600 (Allow 1600 connections maximum)
315394-J, January 2005
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:
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:
>> # Main# /cfg/slb/real <x>/maxcon
Current max connections: 200000
Max connections 0 means unlimited connections
Enter new max connections [0-200000]: 0
Current max connections: 200000
Pending max connections: 0
>> # apply
>> # save
>> # /cfg/slb/real 4 (Select real server 4 as backup)
>> Real server 4# rip 200.200.200.5 (Assign backup IP address)
>> Real server 4# /cfg/slb/real 1 (Select real server 1)
>> Real server 1# backup 4 (Real server 4 is backup for 1)
>> Real server 2# 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 as
backup)
315394-J, January 2005
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.
315394-J, January 2005
Figure 10-6 URL-Based Server Load Balancing
Configuring URL-Based Server Load Balancing
To 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.
Alteon Application
Switch
String matching for:
images
/product
.gif
.jpg
/product
.cgi
.bin
.exe
/product
.html
In 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
3
4
5
6
2
315394-J, January 2005
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 cache
requests. Refer to the following examples given below:
Example 1: String with the Forward Slash (/)
A string that starts with a forward slash ( / ), such as /images, indicates that the server
will process requests that start out with the /images string only.
For example, with the /images string, the server will handle these requests:
/images/product/b.gif
/images/company/a.gif
/images/testing/c.jpg
The server will not handle these requests:
/company/images/b.gif
/product/images/c.gif
/testing/images/a.gif
Example 2: String without the Forward Slash (/)
A string that does not start out with a forward slash ( / ) indicates that the server will process
any requests that contain the defined string. For example, with the images string, the server
will process these requests:
>> # /cfg/slb/layer7/slb/addstr|remstr <l7lkup|pattern>
315394-J, January 2005
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, as
shown in the following example:
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
>> # /cfg/slb/layer7/slb/cur
ID SLB String
1 any
2 .gif
3 /sales
4 /xitami
5 /manual
6 .jpg
>> # /cfg/slb/real 2/layer7/addlb <ID>
315394-J, January 2005
/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
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:
>> # /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
>> 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
315394-J, January 2005
Sample Statistics:
Virtual Hosting
Alteon 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 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 instead
of a full URL.
An example of the request that the origin server would see as follows:
GET /products/2424/ HTTP/1.0
User-agent: Mozilla/3.0
Accept: text/html, image/gif, image/jpeg
The GET request does not include the host name. From the TCP/IP headers, the origin
server knows the requests host name, port number, and protocol.
With the extension to HTTP/1.1 to include the HTTP HOST: header, the above request to
retrieve the URL /www.nortelnetworks.com/ products/2424 would look like this:
ID SLB String Hits
1 any 73881
2 .gif 0
3 /sales 0
4 /xitami 162102
5 /manual 0
6 .jpg 0
315394-J, January 2005
Host: www.nortelnetworks.com
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 Overview
The 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.
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.
315394-J, January 2005
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 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.
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/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
>> # /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)
315394-J, January 2005
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
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.
315394-J, January 2005
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
page 181.
2. Turn on URL parsing for the virtual server.
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/virt 1
>> Virtual Server 1 # service 80
>> Virtual Server 1 http Service # httpslb cookie
Enter Cookie Name: sid
Enter the starting point of the Cookie value [1-64]: 1
Enter the number of bytes to extract [1-64]: 6
Look for Cookie in URI [e|d]: d
>> # /cfg/slb/layer7/slb/addstr "Gold"
>> # addstr "Silver"
>> # addstr "Bronze"
315394-J, January 2005
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 it
does not have an exact cookie match (matches with any configured at Real Server 4).
4. Configure the real server(s) to handle the appropriate load balance string(s).
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.
315394-J, January 2005
Browser-Smart Load Balancing
HTTP requests can be directed to different servers based on browser type by inspecting the
User-Agent header. For example,
To 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.
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/virt 1/service 80/httpslb browser
>> # /cfg/slb/layer7/slb/addstr "Mozilla"
>> Server Loadbalance Resource# addstr "Internet Explorer"
>> Server Loadbalance Resource# addstr "Netscape"
315394-J, January 2005
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 clients 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.
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
Virtual Server IP Address:
205.178.13.243
Non-Transparent
Cache Farm
$
$
$
315394-J, January 2005
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.
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.
>> Virtual Server 1 http Service # httpslb urlhash
Enter new hash length [1-255]: 25
>> # /cfg/slb/group 1/metric <hash|minmisses>
315394-J, January 2005
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.
>> Virtual Server 1 http Service # httpslb headerhash
Select Operation: none
Enter new HTTP header name: User-agent
>> # /cfg/slb/group 1/metric <hash|minmisses>
315394-J, January 2005
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
>> # /cfg/slb/virt 1/service 80/xforward ena
>> # apply
>> # save
315394-J, January 2005
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, thereby
improving 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).
315394-J, January 2005
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 switchs 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 clients source IP address with the switchs own proxy IP
address before sending the request to the real server. This creates the illusion that the switch
originated the request.
The real server uses the switchs proxy IP address as the destination address for any response.
SLB 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)
315394-J, January 2005
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-10
1-3 (Add proxy IP address to ports 1-3)
New pending: 1: 10.10.10.1 port 1-3
315394-J, January 2005
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.
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.
>> # /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.1
Enter VLAN <1 to 4090> or block <first-last>: e.g. 1 2 3-10
2 (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
or VLAN for a WCR filter)
315394-J, January 2005
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 clients 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
address configured on the Alteon Application Switch can be substituted as the proxy servers
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 embed
that address as their source IP address, thus conserving use of Public IP addresses.
>> # /cfg/slb/filt <filter #>/adv/proxyip
Current proxy IP address: any
Enter new proxy IP address or any: <proxy IP address>(Add a proxy IP to this filter)
>> Filter 2 Advanced# proxy ena (Enable use of proxy IP on this filter)
315394-J, January 2005
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:
The following commands are used to disable server processing on ports 1-3:
>> # /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
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)
315394-J, January 2005
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 you
must save them if you wish them to remain in effect after switch reboot. Also, the /info/slb
command is useful for checking the state of Server Load Balancing operations.
>> # /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.
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.
>> # /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
Consider the following network:
Figure 10-8 Basic Virtual Port to Real Port Mapping Configuration
In this example, four real servers are used to support a single service (HTTP). Clients access
this service through a virtual server with IP address 192.168.2.100 on virtual port 80. Since
each real server uses two ports (8001 and 8002) for HTTP services, the logical real servers are:
192.168.2.1/8001
192.168.2.1/8002
192.168.2.2/8001
192.168.2.2/8002
192.168.2.3/8001
192.168.2.3/8002
192.168.2.4/8001
192.168.2.4/8002
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 (rport 2)
192.168.2.1 (RIP 1)
192.168.2.2 (RIP 2)
192.168.2.3 (RIP 3)
192.168.2.4 (RIP 4)
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
Load Balancing Metric
For each service, a real server is selected using the configured load balancing metric (hash,
leastconns, minmisses, or roundrobin). To ensure even distribution, once an available
server is selected, the switch will use the roundrobin metric to choose a real port to receive
the incoming connection.
If the algorithm is leastconns, the switch sends the incoming connections to the logical real
server (real server IP address/port combination) with the least number of connections.
The /cfg/slb/virt command defines the real server TCP or UDP port assigned to a service.
By default, this is the same as the virtual port (service virtual port). If rport is configured to
be different from the virtual port defined in /cfg/slb/virt <virtual server number>/ser-
vice <virtual port>, the switch maps the virtual port to the real port.
NOTE To use the single virtual port to multiple rport feature, configure this real server port
option to be a value of 0. However, note that you cannot configure multiple services with mul-
tiple rports in the same server if the multiple rport feature is enabled.
Configuring Multiple Service Ports
Two commands, addport and remport, under the real server menu allow users to add or
remove multiple service ports associated with a particular server. (A service port is a TCP or
UDP port number.) For example: addport 8001 and remport 8001.
1. Configure the real servers.
2. Add all four servers to a group.
3. Configure a virtual server IP address.
>> # /cfg/slb/real 1/rip 192.168.2.1/ena
>> # /cfg/slb/group 1
>> Real server Group 1# add 1
>> # /cfg/slb/virt 1/vip 192.168.2.100/ena
315394-J, January 2005
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-
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.
>> # /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)
315394-J, January 2005
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
>> # /cfg/slb/virt <virtual server number>/service <service number>/nonat ena
Internet
2
Layer 2 Switch
Alteon Application
Switch
Server farm
Client
1
3
315394-J, January 2005
Direct Access Mode
Direct Access Mode (DAM) allows any client to communicate with any real servers 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 servers 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:
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.
>> Main# /cfg/slb/adv/direct e
Current Direct Access Mode: disabled
New Direct Access Mode: enabled
315394-J, January 2005
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 switchs 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
Assigning Multiple IP Addresses
One way to provide both SLB access and direct access to a real server is to assign multiple IP
addresses to the real server. For example, one IP address could be established exclusively for
SLB and another could be used for direct access needs.
Using Proxy IP Addresses
Proxy IP addresses are used primarily to eliminate SLB topology restrictions in complex 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 servers IP address. To directly access
a real server, the switch port connected to the real server must have server processing disabled.
However, if DAM is enabled (/cfg/slb/adv/direct ena), server processing must be
enabled on the server port regardless of the proxy setting and SLB is still accessed using the
virtual server IP address.
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 be
mishandled 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.
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.
315394-J, January 2005
In Figure 10-10, clients can access SLB services through well-known TCP port 80 at the vir-
tual servers 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 servers 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
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 cannot
access the virtual services being load balanced.
The mnet and mmask options are described below:
mnet: If defined, management traffic with this source IP address is 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.
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
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 servers SYN ACK with a data request (REQ) and, instead, sends another
SYN request, the server gets saturated with SYN requests. As a result, all of the servers
resources are consumed and it can no longer service legitimate client requests.
Figure 10-11 DoS SYN Attacks without Delayed Binding
Client
Server
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
Client
Server
DoS SYN Attack
Server 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
315394-J, January 2005
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.
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 server
until the proper handshakes are 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
Switch responds with special SYN ACK
Switch responds with another SYN ACK
Client sends new SYN requests No session entry is made until a valid
three-way handshake is complete.
Switch and server resources are
protected for legitimate requests
Server
315394-J, January 2005
Thus, with delayed binding, two independent TCP connections span a session: one from the
client 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
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.
>> # /cfg/slb/virt <virtual server number>/service <service type>/dbind
315394-J, January 2005
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
239
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
For additional information on SLB commands, see your Alteon OS Command Reference.
IP Server Load Balancing
IP server load balancing allows you to configure your Alteon Application Switch for server
load balancing based on clients IP address only. Typically, the client IP address is used with
the client port number to produce a session 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 >
315394-J, January 2005
240 Chapter 11: Load Balancing Special Services
IP server load balancing must be used if IP traffic is totally encrypted and you do not have
access to the content.
FTP Server Load Balancing
As defined in RFC 959, FTP uses two connectionsone for control information and another for
data. Each connection is unique. Unless the client requests a change, the server always uses TCP
port 21 (a well-known port) for control information, and TCP port 20 as the default data port.
FTP uses TCP for transport. After the initial three-way handshake, a connection is established.
When the client requests any data information from the server, it 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.
FTPP with port mapping is not supported.
Configuring FTP Server Load Balancing
1. 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
315394-J, January 2005
Chapter 11: Load Balancing Special Services 241
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 files
from/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 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.
>> Virtual Server 1 ftp Service# apply
>> # /cfg/slb/virt 1/service tftp
>> Virtual Server 1 ftp Service# ftpp ena
>> # /cfg/slb/virt 1/service 20/ftpp ena
315394-J, January 2005
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
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 server
and reinitiate another connection with the write server without the clients knowledge. Once
the connection is set up with write server, all the later requests 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.
>> Virtual Server 1 ftp Service# apply
315394-J, January 2005
Selectively Resetting a Real Server
If a long-lived LDAP connection exceeds the Alteon Application Switchs 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.
Figure 11-1 LDAP Load Balancing
Configuring LDAP SLB
1. Enable server load balancing.
>> # /cfg/slb/virt 1/service ldap/reset enable
>> # /cfg/slb/on
Alteon
Application
Switch
Group 1
LDAP
Internet
Real servers
20
21
22
Client
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
2. Configure the four real LDAP servers and their real IP addresses.
3. Configure group 1 for LDAP.
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/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)
server 21)
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)
>> # /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)
315394-J, January 2005
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 group
of real servers and UDP DNS queries to another group of real servers. The requests are then
load balanced among the real servers in that group.
>> 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
NOTE You can configure both UDP and TCP DNS queries for the same virtual server
IP address.
Preconfiguration Tasks
>> # /cfg/slb/on
Alteon
Application
Switch
Group 1
UDP
health udpdns
Internet
Group 2
TCP
health 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 2005
2. Configure the four real servers and their real IP addresses.
3. Configure group 1 for UDP and group 2 for TCP.
For more information on configuring health check, see UDP-Based DNS Health Checks on
page 440.
4. Define and enable the server ports and the client ports.
For more information, see Step 6 Define the port settings. on page 190. Some DNS servers
initiate upstream requests and must be configured both as server and client.
>> Real server 20 # /cfg/slb/real 21
metric for group 1)
>> Real server group 1 # health udpdns (Set the health check to UDP)
>> Real server group 1 # /cfg/slb/group 2
metric for group 2)
>> Real server group 2 # health dns (Set the health check to TCP)
315394-J, January 2005
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.
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 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
address)
>> Virtual Server 2# service dns (Specify the DNS service)
>> Virtual Server 2 DNS Service# group 2 (Select the real server group)
315394-J, January 2005
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 2005
Layer 7 DNS Load Balancing
The Internet name registry has become so large that a single server cannot keep track of all the
entries. This is resolved by splitting the registry and saving it on different servers.
If you have large DNS server farms, 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.
Figure 11-3 Load Balancing DNS Queries
Client
Alteon Application
Switch
DNS Server Farm
DNS Queries A - G
DNS Queries H - M
DNS Queries N - T
Server 1
Server 2
Server 3
DNS Queries U - Z
Server 4
315394-J, January 2005
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).
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
315394-J, January 2005
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
315394-J, January 2005
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 connection
to 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.
315394-J, January 2005
Supported RTSP Servers
In 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 QuickTime
servers and the other group of servers consist of RealNetworks servers. Each group has its own
virtual server IP address. For example, three Real Networks servers host media 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.
315394-J, January 2005
Retrieving files from the QuickTime server group
RTSP://www.NortelNews.com/*.mov is load balanced among the Quick Time media
servers using virtual IP address 40.40.40.100.
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
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
2
4
3
13
14
15
25
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 servers
virtual IP address 40.40.40.100
Real Networks servers
315394-J, January 2005
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 a
service 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)
>>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)
>>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)
315394-J, January 2005
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.
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.
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 15# apply
>> SLB port 15# save
315394-J, January 2005
Content-Intelligent RTSP Load Balancing
Alteon 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 from
other clients or from client 1 will hash to the same server 1. Similarly, another request for
http://nortelnews.com/marketingwebcast.rm may hash to media server 2, 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
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.
315394-J, January 2005
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
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.2
IP 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
2
3
4
5
8
6
9
25
1
2
3
4
5
6
7
8
315394-J, January 2005
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.
315394-J, January 2005
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.
Add URL strings.
Apply and save the configuration.
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
(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
315394-J, January 2005
Identify the defined string IDs.
For easy configuration and identification, each defined string has an ID attached, as shown
in the following example:
Number of entries: three
Add the defined string IDs to the real servers as shown in Figure 11-5.
Clients retrieving RTSP://nortelnews.com/saleswebcast.rm hash to the same media server1,
2, 3, or 4.
A client request of the form RTSP://120.10.10.20/../starwars1.mov is load bal-
anced between RTSP servers 5 and 6 using string matching. A client request of the form
RTSP://120.10.10.20/../starwars2.mov is load balanced between RTSP servers
7 and 8.
>> Server Loadbalance Resource# cur
ID SLB String
1 any, cont 1024
2 starwars1.mov, cont 1024
3 starwars2.mov, cont 1024
>> # /cfg/slb/real 5/layer7
>> Real server 5 Layer 7 Commands# addlb 2
>> Real server 5# /cfg/slb/real 6/layer7
>> Real server 8# apply
>> Real server 8# save
315394-J, January 2005
Wireless Application Protocol SLB
Wireless 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 systemswith the
goal of inter-operability. A WAP Gateway translates Wireless Markup Language (WML)
which is a WAP version of HTMLinto HTML/HTTP so that requests for information can be
serviced by traditional Web servers.
To load balance WAP 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.
315394-J, January 2005
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 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
Clients
Alteon Application
Switch
Virtual IP address: 10.10.10.10
Internet
RADIUS/WAP servers
Group 100
CDMA
GSM
Remote
Access
Server
3
4
1
2
3
Real 1: 1.1.1.100
Real 2: 2.2.2.100
Real 3: 3.3.100
1
2
315394-J, January 2005
WAP SLB with RADIUS Static Session Entries
RADIUS, 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 should
receive the client sessions. Typically, each WAP gateway is integrated with a RADIUS server
on the same host, and a RADIUS request packet is allowed to go to any of the RADIUS
servers. Upon receiving a request from a client, the RADIUS server instructs the switch to
create a static session entry in the switch via Transparent Proxy Control Protocol (TPCP).
TPCP is an 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.
315394-J, January 2005
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.
3. Configure IP addresses for the RADIUS/WAP Gateways.
>> # /cfg/slb/virt <number>/layr3 ena
>> # /cfg/slb/virt <number>/service <name|number>/udp ena
>> # /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)
315394-J, January 2005
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 session
entry 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 switchs session table so that it can perform the required persistency for load balancing. A
static session entry does not age out. Such an entry, added using RADIUS snooping, will only
be deleted using RADIUS snooping. The switch load balances both the RADIUS and WAP
gateway 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 users 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.
>> # cfg/slb/adv/tpcp ena
>> # cfg/slb/wap/tpcp ena
>> WAP Options# apply
>> WAP Options# save
315394-J, January 2005
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.
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:
315394-J, January 2005
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.
fied on the server.
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.
>> # /cfg/slb/virt <number>/layr3 ena
>> # /cfg/slb/on
>> # cfg/slb/adv/tpcp ena
>> # cfg/slb/wap/tpcp ena
315394-J, January 2005
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.
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.
>> # /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
315394-J, January 2005
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 92009203,
a new session is allocated and a server is bound to the WAP session.
The RADIUS session and the WAP session are now both bound to the same server because
both sessions are using the same source IP address.
Configuring WAP SLB using Radius/WAP Persistence
>> # /cfg/slb/on
315394-J, January 2005
4. Configure a virtual server.
>>Real Server Group 100# metric hash (Select hash as load balancing metric)
>> # cfg/slb/virt 1/vip 10.10.10.10
>>Virtual Server 1# ena (Enable virtual server 1)
315394-J, January 2005
5. Configure the services for virtual server 1.
fied on the server.
6. Configure the following filter on the switch to examine a RADIUS accounting packet. Set
the basic filter parameters.
7. Enable RADIUS/WAP persistence.
>>Virtual Server 1# service 1812
>>Virtual Server 1 radius-auth service# udp ena
>>Virtual Server 1 radius-auth service# /cfg/slb/virt 1/service 1813
>>Virtual Server 1 radius-acc service# udp ena
>>Virtual Server 1 9200 service# udp ena
>> Filter 1 # ena (Enable the filter)
>> Filter 1 # dip 10.10.10.10 (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 100 (Set the group for redirection)
>> Filter 1 # rport 1813 (Set server port for redirection)
>> Layer 7 Advanced# rdswap ena (Enable RADIUS/WAP persistence)
315394-J, January 2005
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
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.
>> # /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 4# save
315394-J, January 2005
How Intrusion Detection Server Load Balancing Works
Alteon 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.
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.
315394-J, January 2005
Setting Up IDS Servers
Table 11-1 shows how an Alteon Application Switch can be configured depending on the type
of IDS server.
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
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 the
destination 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 to
the correct IDS server.
The VLAN tag is used to identify the destination IDS
server. However, if the ingress packet is already
tagged, then you must use different VLANs for differ-
ent IDS servers.
With IP
addresses
ICMP or ARP IDS servers need not be
directly connected to the
application switch.The IDS
servers may be connected
via an Alteon Application
Switch or a Layer 2 switch.
The data packet is modified, so that it is addressed to
the IDS servers. Destination MAC address is changed
to Real server MAC address.
315394-J, January 2005
page 282, a single switch is performing both IDS load balancing and standard server load bal-
ancing. In example 2, two IDS groups are configuredIDS 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).
315394-J, January 2005
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.

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 performs
standard 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.
7
27
25
26
6
2 3
4
26
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 Application
Switch 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
315394-J, January 2005
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 163.
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.
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.
>> # /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)
>>Real Server Group 50# health link (Set the health check to link)
>>Real Server Group 50# ids ena (Enable IDS for the server group)
315394-J, January 2005
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)
>> # /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)
315394-J, January 2005
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
315394-J, January 2005
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-
uredIDS 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
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.
model.
7
8
25
2
3
4
6
6 Clients
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 52
Internet
315394-J, January 2005
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)
315394-J, January 2005
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)
>># /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)
315394-J, January 2005
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 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 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)
315394-J, January 2005
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
315394-J, January 2005
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. For
VLAN-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.
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.
Internet
1
VLAN 1003
VLAN 1004
VLAN 1001 VLAN 1002
Switch 2
Switch 1
Trunked ports 25, 26
tagged for VLANs
1000, 1001, 1002
1003, 1004
idslb filter
idslb filter on trunked ports 27, 28 28 27
26 25
2
4
4
Web servers
8
7
1
2
4
IDS group 1
IDS group 1
3
3
315394-J, January 2005
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. Because
the MAC addresses of the real servers are learned via the inter-switch link port, the request
packets from clients are forwarded to the inter-switch link port on the new master switch, and
are received by the new standby switch. Because the standby switch does not forward 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.
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 checkin 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.
3. Configure trunk groups.
4. Configure an IP interface for the SNMP health check to the other switch.
/cfg/port 25/tag ena/pvid 1000
/cfg/port 26/tag ena/pvid 1000
/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
315394-J, January 2005
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)
>> Layer 2# /cfg/l2/vlan 1001/ena/learn dis/add 25/add 26
315394-J, January 2005
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.
8. Define the group metric for the IDS server group.
>> # /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)
>> 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# oid 1.3.6.1.2.1.2.2.1.8.259 (Set OID to health check
port 3 on switch 2)
>> 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)
315394-J, January 2005
12. Enable IDS on the client and server ports.
This enables frames ingressing the traffic ports to be copied to the IDS servers.
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 27# /cfg/slb/advhc/snmphc 1/rcvcnt 1
315394-J, January 2005
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.
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.
>> 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)
315394-J, January 2005
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 Load
Balancing
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.
315394-J, January 2005
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 server
40.40.40.100.
Figure 11-10 SIP Load Balancing
1. At the Alteon Application Switch, before you start configuring SIP load balancing:
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
7
5
25
6
Clients
Alteon Application
Switch
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 3
IP 10.10.10.3
Virtual IP address:
40.40.40.100
315394-J, January 2005
3. Configure IP addresses for the SIP proxy servers.
4. Create a group to load balance the MCS servers.
5. Define the group metric for the server group.
Because SIP load balancing is done based on Call-ID, minmisses metric only is supported to
ensure persistency.
Configure SIP PING request health check which is specifically developed for SIP-enabled
servers.
7. Configure a virtual server for Layer 4 SIP load balancing.
8. Configure the SIP service 5060 for virtual server 1.
>> # /cfg/slb/on
>> # /cfg/slb/real 1/rip 10.10.10.1 (Define address for MCS 1)
>>Real Server Group 100# metric minmiss (Set the metric to minmisses)
>>Real Server Group 100# health sip (Set the health check to sip)
>> # /cfg/slb/virt 1 (Select virtual server 1)
>>Virtual Server 1# vip 40.40.40.100 (Set IP address for the virtual server)
>>Virtual Server 1# virt ena (Enable virtual server)
>> # /cfg/slb/virt 1/service 5060 (Add the SIP service for virt 1)
>>Virtual Server 1 sip Service# group 100 (Set the MCS server group)
315394-J, January 2005
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 7# save
315394-J, January 2005
297
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.
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.
315394-J, January 2005
298 Chapter 12: WAN Link Load Balancing
Multi-homing is becoming essential for reliable networks, providing customers with protection
against connectivity outages and unforeseen ISP failures. Multi-homing also presents other
clear opportunities for enterprises to intelligently manage how WAN links are used. With link
load balancing organizations have greater 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 2005
Chapter 12: WAN Link Load Balancing 299
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 pools capabilities are saturated, new WAN links
can be added to the pool transparently.
For ease of maintenance, WAN links can be added or removed dynamically, without 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 links capacity.
Your WAN links must remain available even in the event of a link failure.
Your WAN links are being used as a way to do business and for taking orders from 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.
You must be able to scale your applications to meet client and LAN request capacity.
You cant afford to continue using an inferior load-balancing technique, such as DNS
round robin or a software-only system.
315394-J, January 2005
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 trafficoutbound 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 the
link, the Alteon Application Switch chooses the most optimal link for that session.
315394-J, January 2005
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 users 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 with
a 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-
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.
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
315394-J, January 2005
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. The
selected 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 Application
Switch 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).
315394-J, January 2005
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 ISPs address range.
As shown in Figure 12-2, two virtual server IP addressesvirtual server IP address 1 and vir-
tual server IP address 2 are configured for nortelnetworks.com in each of the ISPs
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
315394-J, January 2005
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
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.
Inbound traffic
2
7
Client
5
Local DNS
server
3
1
www.nortelnetworks.com
Real 1 to ISP A
IP 50.1.1.1
Real 2 to ISP B
IP 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
315394-J, January 2005
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 exam-
ple, 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.
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.
Inbound traffic
2
7
Client
Local DNS
server
1
virtual IP address
30.30.30.2
11
Real 1 to ISP A
IP 50.1.1.1
Real 2 to ISP B
IP 80.1.1.1
1
2
RTS
vip 1: 50.1.1.100
RTS
vip 2: 80.1.1.100
Authoritative Name Server
Internet
SLB servers
5
6
315394-J, January 2005
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
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.
315394-J, January 2005
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.
315394-J, January 2005
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 defining
gateways per VLAN.
1. Configure the basic parameters.
This includes configuring VLAN, IP interfaces, and defining
gateways per VLAN.
2. Configure the load balancing parameters for the ISP WAN
links.
Configure the ISP routers as real servers
Add it to a group
Define the metric and health
Enable SLB
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 each
ISP.
For each ISP link, configure a virtual server IP address per
domain.
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.
315394-J, January 2005
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.
315394-J, January 2005
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 port
on the application switch.
Figure 12-4 Simple WAN Link Load Balancing
Inbound traffic
Outbound traffic
25
26
1
5
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.2
Client 1
Real server 3
1.1.1.2
3
IF 7: 80.1.1.2/24
VIP 2: 80.1.1.100
IF 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
315394-J, January 2005
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
315394-J, January 2005
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 receive
switching 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)
>> # /cfg/if 1 (Define interface 1 for Real server 3)
>> # /cfg/if 5 (Define interface 5 for internal client)
315394-J, January 2005
3. Configure VLANs.
The real server IP addresses (WAN links and real server 3) and the respective IP interfaces
must be on different VLANs. The pvid command sets the default VLAN number which 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.
3. Assign the response metric for the WAN link group.
>> # /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/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)
>>Real Server Group 100# metric response (Set the metric to response)
315394-J, January 2005
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)
315394-J, January 2005
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/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)
315394-J, January 2005
Step 4a (outbound traffic): Configure the client ports
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 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.
2. Enable server processing.
3. Enable filter on server port 1.
>> # /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)
>> # /cfg/slb/port 1/server ena (Enable server processing for port 1)
315394-J, January 2005
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 for
each 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.
Step 5b: Configure the virtual server IP address and the services for ISP 2
>>Virtual Server 1# vip 50.1.1.100 (Set IP address from the ISP 1 subnet)
>>Virtual Server 1# ena (Enable 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)
>>Virtual Server 1 ftp Service# ena (Enable the service)
>>Virtual Server 1 ftp Service# group 3 (Add real server group)
315394-J, January 2005
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 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)
315394-J, January 2005
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-
tersvirtual 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 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 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)
315394-J, January 2005
Example 2: WAN Link Load Balancing with Server Load
Balancing
In 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.
Figure 12-5 WAN Link Load Balancing with SLB
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
4
6
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 2: 1.1.1.200
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
26
25
Internet
315394-J, January 2005
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
ISP 2 30.1.1.1
315394-J, January 2005
The Alteon Application Switch must have an IP route to all of the real servers that receive
switching 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)
>> # /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)
315394-J, January 2005
On the Alteon Application Switch, configure the ISP routers as if they were real servers, with
SLB 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)
315394-J, January 2005
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
>> # /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)
315394-J, January 2005
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.
>> 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
315394-J, January 2005
Step 4b (inbound traffic): Configure the internal network
Configure the virtual server IP addresses on the Alteon Application Switch as real server IP
addresses. 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)
315394-J, January 2005
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 an
allow 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 for
each 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.
>> 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
315394-J, January 2005
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
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.
>>Virtual Server 1 HTTP Service#.. (Go to the virtual server menu)
>>Virtual Server 2 HTTP Service#.. (Go to the virtual server menu)
315394-J, January 2005
Step 6: Configure the Application Switch as a Domain Name Server
This involves configuring the domain record name and mapping the virtual server and real
server (ISP router) for each WAN link.
You must map the domain record, nortelnetworks.com to each ISP. Each ISP has two parame-
tersvirtual 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# domain abc.com (Define the Domain name)
>> 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
315394-J, January 2005
4. Configure an entry for each ISP and specify the virtual and real server (ISP router).
You must apply in order for these changes to take effect, and you must save changes if you
wish them to remain in effect after reboot.
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.
315394-J, January 2005
331
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.
Deny Filter Based on Layer 7 Content Lookup on page 363
Filtering on 802.1p Priority Bit in a VLAN Header on page 342
315394-J, January 2005
332 Chapter 13: Filtering
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 2005
Chapter 13: Filtering 333
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 2005
Filtering Actions
A filtering action (/cfg/slb/filt/action) instructs the filter what to do once the filtering
criteria are matched.
allowAllow the frame to pass (by default).
denyDiscard frames that fit this filters profile. This can be used for building basic
security profiles.
redirRedirect frames that fit this filters profile, such as for web cache redirection. In
addition, Layer 4 processing must be activated using the /cfg/slb/on command).
natPerform generic Network Address Translation (NAT). This can be used to map the
source or destination IP address and port information of a private network scheme to/from
the advertised network IP address and ports. This is used in conjunction with the nat
option (mentioned in this table) and can also be combined with proxies.
gotoAllows the user to specify a target 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 continue
from 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 filters 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 where
the Internet is divided according to destination IP address:
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.
Allow Deny Redirect
Filtering by Destination IP Address Ranges
Deny
0.0.0.0 255.255.255.255
Filter 1 Filter 3 Filter 4 Filter 2
315394-J, January 2005
Overlapping Filters
Filters are permitted to overlap, although special care should be taken to ensure the proper
order of precedence. When overlapping filters are present, the more specific filters (those that
target fewer addresses or ports) should be applied before the generalized filters.
Example:
Figure 13-2 Assigning Filters to Overlapping Ranges
In this example, Filter 2 must be processed prior to Filter 3. If Filter 3 was permitted to take
precedence, Filter 2 could never be triggered.
The Default Filter
Before filtering can be enabled on any given port, a default filter should be configured. This
filter handles any traffic not covered by any other filter. All the criteria in the default filter
must be set to the full range possible (any). For example:
Figure 13-3 Assigning a Default Filter
Allow
Redirect
Deny
0.0.0.0 255.255.255.255
Filter 1 Filter 3 Filter 2
Allow Redirect
Deny
0.0.0.0 255.255.255.255
Filter 1 Filter 2048 Filter 2
315394-J, January 2005
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, as
shown 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)
315394-J, January 2005
IP Address Ranges
You can specify a range of IP addresses for filtering both the source and/or destination IP
address 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 requests destination IP address should be redirected to
the cache servers attached to a particular switch, the destination IP address is masked (bit-wise
AND) with the dmask and then compared to the destination IP address.
As another example, the switch could be configured with two filters so that each would handle
traffic 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)
315394-J, January 2005
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 Filters
To 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, which
specifies 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
315394-J, January 2005
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 1
repeated 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# ena (Enable this filter)
315394-J, January 2005
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.
Alteon
Application
Switch
Internet
Unique Filters per
VLAN (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
315394-J, January 2005
Configuring VLAN-based Filtering
1. Configure filter 2 to allow local clients to browse the Web and then assign VLAN 20 to
the 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# sport telnet (From a Telnet port)
>> Filter 3# name allow clients to telnet (Provide a descriptive name for the
filter)
315394-J, January 2005
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 packets 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 Application
Switch 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)
315394-J, January 2005
Classifying and Prioritizing Packets Based on 802.1p
Priority Bits
Traffic 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)
315394-J, January 2005
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)
315394-J, January 2005
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
Router
Client Switch
315394-J, January 2005
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# name deny unwanted traffic(Provide a descriptive name for the
filter)
>> Filter 2048# adv/log enable (Log matching traffic to syslog)
315394-J, January 2005
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 servers 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# 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# sport smtp (From a SMTP port)
315394-J, January 2005
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# sport telnet (From a Telnet port)
315394-J, January 2005
For UDP:
Similarly, for TCP:
>> 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 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 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)
315394-J, January 2005
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 ports 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)
315394-J, January 2005
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 the
switch 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 servers internal private
network address. The filter for the server-side switch port reverses the process, translating the
servers private address information to a valid public address.
315394-J, January 2005
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 destination
to 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
315394-J, January 2005
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 NAT
Dynamic NAT is a many-to-one solution: multiple clients on the private subnet take advantage
of a single external IP address, thus conserving valid IP addresses. In this example, clients on
the internal private network require TCP/UDP access to the Internet:
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.
Router
Layer 2
switch
Internal Clients
10.10.10.x
(Private network)
Internet
Inbound proxy on
public address
Outbound filter:
NAT source info
to public address
Public IP Address:
205.178.17.12
1
315394-J, January 2005
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 filters 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)
315394-J, January 2005
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
Outbound filter:
NAT source info
to public address
1
Public IP Address:
205.178.17.12
(Pool of proxy IP
addresses instead
of a single proxy
IP address)
Alteon
Application
Switch
315394-J, January 2005
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 filters 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
315394-J, January 2005
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
from the Internet, except for HTTP.
Flag Description
URG Urgent
ACK Acknowledgement
PSH Push
RST Reset
SYN Synchronize
FIN Finish
SMTP
Mail Server
Router
Alteon Application
Switch
Web Servers:
203.122.186.*
Internet
Inside/
Trusted LAN
2
3
1
315394-J, January 2005
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)
315394-J, January 2005
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)
315394-J, January 2005
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)
315394-J, January 2005
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
5 redir ICMP redirect
8 echoreq ICMP echo request
9 rtradv ICMP router advertisement
10 rtrsol ICMP router solicitation
11 timex ICMP time exceeded
12 param ICMP parameter problem
13 timereq ICMP timestamp request
14 timerep ICMP timestamp reply
15 inforeq ICMP information request
16 inforep ICMP information reply
17 maskreq ICMP address mask request
18 maskrep ICMP address mask reply
>> # /cfg/slb/filt <filter number>/adv
>> Filter 1 Advanced# icmp <message type|number|any|list>
315394-J, January 2005
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.
315394-J, January 2005
Deny Filter Based on Layer 7 Content
Lookup
Alteon 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 the
offending 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
Alteon Application
Switch
Internet Real servers
Clients
ida
%c1%9c
%c0%af
www.playdog.com
HTTPHDR:Host:www.playdog.com
AAAAAA
HTTPHDR:SOAPAction:*
STOP
2. Switch filter processes
the string and denies entry
to the network.
1. Client sends
a request
containing a disallowed
string.
315394-J, January 2005
Denying HTTP URL Requests
1. Before creating a deny filter with Layer 7 lookup, ensure that the switch has already been
configured 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%9c
3 %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)
315394-J, January 2005
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# add
Enter type of string [l7lkup|pattern]: l7lkup
Configure HTTP header string? [y/n] y
Enter 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] y
Enter URL string: http://www.playdog.com
Enter HTTP header name: SoapAction=* (Define SOAPAction header)
Enter SLB header value string:
Configure URL string? [y/n] n
315394-J, January 2005
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)
315394-J, January 2005
367
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 2005
368 Chapter 14: Application Redirection
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 2005
Chapter 14: Application Redirection 369
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 clients 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 information
can be much faster than requesting the same information across the Internet.
Cache Redirection Environment
Consider a network where client HTTP requests begin to regularly overload the Internet router.
Figure 14-1 Traditional Network Without Cache Redirection
Clients
Internet
Router
Client Switch
Client Switch
Congestion
Targets Router
315394-J, January 2005
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.
A
B
C
Clients
Internet
Router
HTTP
Requests
HTTP requests
are redirected
Cache farm proxies
client requests
315394-J, January 2005
Cache Redirection Configuration Example
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 route
to the application switch that will perform the cache redirection. In addition, the path from the
application switch to the real servers must not contain a router. The router would stop HTTP
requests from reaching the cache servers and, instead, direct them back out to the Internet.
More complex network topologies can be used if 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 IP
subnet:
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
315394-J, January 2005
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)
315394-J, January 2005
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)
315394-J, January 2005
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# /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)
315394-J, January 2005
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 the
following 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
315394-J, January 2005
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 the
cache servers. If there is no cache server, the request is directed to the origin server. Internet
Service Providers use this feature to cache the multimedia data of a customer site locally. Since
the requests for this data are directed to the local cache, they are served faster.
This section explains Layer 4 support for RTSP Streaming Cache Redirection. For detailed
information on two prominent commercial RTSP serversReal Player and QuickTimesee
Real Time Streaming Protocol SLB 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
2
3
6
Clients
Router
IP 120.120.120.5
Media server farm
Internet
IP 1.1.1.1
IP 1.1.1.2
1
2
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
315394-J, January 2005
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
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.
>> 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 Group 1# add 1 (Add RTSP cache server 1 to group 1)
>>Real Server Group 1# metric leastconn (Set the metric to leastconn)
315394-J, January 2005
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# 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)
315394-J, January 2005
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# /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)
315394-J, January 2005
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
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 sites 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
Content Intelligent Cache Redirection
Alteon OS allows you to redirect cache requests based on different Layer 7 content such as HTTP
header information, such as Host: header or User-Agent for browser-smart load balancing.
The No Cache/Cache Control for cache redirection feature in 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
URL-Based Cache Redirection
URL parsing for cache redirection operates in a manner similar to URL-based server load bal-
ancingexcept 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 the
metric specified for the real server group (leastconns is the default).
Web Cache Redirector
N
o
n
-
H
T
T
P

G
E
T
G
E
T
/w
w
w
.h
o
s
tc
.c
o
m
/c
g
i-
b
in
/s
c
r
ip
t.b
in
GET/http://finance.yahoo.com/q?s=hwp%2C+ibm%d=v1
GET/product/Webswitch.html
GET/company/information.html
G
E
T
/c
o
m
p
a
n
y
/im
a
g
e
s
/s
w
itc
h
.g
if
Internet
Host A
Implicit load balancing
within the group
/product
information
Host B
Host C
images
$
$
$
315394-J, January 2005
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.
315394-J, January 2005
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:no
cache 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
315394-J, January 2005
4. Define the string(s) to be used for cache SLB. Refer to the parameters listed below:
addstr: Add a string or a path.
remstr: Remove string or a path.
A default string any indicates that the particular server can handle all URL or cache
requests. Refer to the following examples:
Example 1: String Starting with the 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:
The server will not handle these requests:
Example 2: String without the Forwardslash (/)
A string that does not start out with a forwardslash ( / ) 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:
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>
315394-J, January 2005
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
315394-J, January 2005
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)
315394-J, January 2005
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/redir
Total URL based Web cache redirection stats:
Total cache server hits: 73942
Total origin server hits: 2244
Total none-GETs hits: 53467
Total 'Cookie: ' hits: 729
Total no-cache hits: 43
315394-J, January 2005
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"
315394-J, January 2005
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 dont 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 is
already 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
315394-J, January 2005
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 Redirection
By default, hashing algorithms use the source IP address and/or destination IP address
(depending on the application area) to determine content location. For example, 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 client
requests 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
315394-J, January 2005
For example the switch could use the string nortelnetworks.com/products/2424/ for hashing
the following request:
GET http://products/2424/ HTTP/1.0
HOST:www.nortelnetworks.com
315394-J, January 2005
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
315394-J, January 2005
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 the
Host 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
Alteon Application
Switch
Cache server farm
http://www.nortelnetworks.com
Clients
2
3
1
1
2
3
Internet
315394-J, January 2005
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 the
HTTP header, the source IP address is used as the hash key and requests from clients 1, 2, and
3 are directed to three different cache servers as shown below.
315394-J, January 2005
RTSP Streaming Cache Redirection
RTSP load balancing with the URL hash metric can be used to load balance cache servers
that cache multimedia presentations. Since multimedia presentations consume a large amount
of Internet bandwidth, and their correct presentation depends upon the real time delivery of the
data over the Internet, several caching servers cache the multimedia data.
As a result, the data is available quickly from the cache, when required. The Layer 7 metric of
URL hashing directs all requests with the same URL to the same cache server, ensuring that no
data is duplicated across the cache servers. All the stream connections and the control 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 serversReal Player and
QuickTimesee 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
2
3
4
5
26
Clients
Router
IP 120.120.120.5
IP 10.10.10.1
IP 10.10.10.2
Alteon Application
Switch
IP 10.10.10.4
IP 10.10.10.3
RTSP servers
Internet
RTSP Cache server farm is configured
in forward transparency mode
1
2
3
4
condor.rm
cheetah.mov
Client 1 request
http://nortel.com/condor.rm
Client 2 request
http://alteon.com/cheetah.mov
tigon.rm
315394-J, January 2005
Follow this procedure to configure to load balance RTSP cache servers for the topology illus-
trated in Figure 14-6:
1. Before you start configuring the application switch do the following:
Connect each cache server to the application 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. Configure a redirection filter.
5. Enable Layer 7 lookup for the redirection filter 100.
>> # /cfg/slb/filter 100 (Select the menu for filter 100)
>> Filter 100# proto tcp (Enter TCP protocol)
>> Filter 100# dport rtsp (Enter service port for RTSP)
>> Filter 100# rport rtsp (Enter redirection port for RTSP)
>> Filter 100# group 1 (Select RTSP cache server group 1)
>> Filter 100# adv (Select advanced menu for filter 100)
>> Filter 100# Advanced# proxy disable (Disable proxy)
>> Filter 100 Advanced# layer7/l7lkup ena (Enable Layer 7 lookup)
315394-J, January 2005
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-cacheableRTSP 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# 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
315394-J, January 2005
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
315394-J, January 2005
HTTP Redirection
Filters can be used to redirect HTTP requests to different gateways or servers. The following
HTTP redirection types are supported:
IP redirectionThe application switch redirects client requests to different service 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 redirectionThe 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 different
service port (such as 9090). For details, see TCP Service Port Based HTTP Redirection
on page 408.
MIME type redirectionThe 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 redirectionThe 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.
315394-J, January 2005
Table 14-6 shows the ID numbers and SLB string content for the strings used in the following
examples. Not all strings are used in each example.
1. Configure the switch with the basic Server Load Balancing requirements as described in
HTTP Header-Based Cache Redirection on page 391.
2. Configure the filter strings.
Table 14-6 Example HTTP Redirection Strings
ID SLB String
1 any, cont 256
2 HTTPHDR=Host:wap.example.com
3 HTTPHDR=Host:wap.yahoo.com
4 HTTPHDR=Host:wap.google.com
5 HTTPHDR=Host:wap.p-example.com
6 HTTPHDR=Host:10.168.224.227=/top
7 jad, cont 256
8 jar, cont 256
9 HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor
10 HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL
11 HTTPHDR=Host:any
12 HTTPHDR=Host:any:90
13 HTTPHDR=Host:any:8080
14 HTTPHDR=X-Foo-ipaddress:10.168.100.*
15 HTTPHDR=Host:www.abc.com, cont 256
16 16: HTTPHDR=Host:any:443, cont 256
>> # /cfg/slb/layer7/slb/
>> Server Loadbalance Resource# addstr (Add the first SLB string)
Configure HTTP header string? (y/n) [n] y
Enter HTTP header name: Host
Enter SLB header value string: wap.example.com
Configure URL string? (y/n) [n] n
>> # /cfg/slb/layer7/slb/ (Select the Serverloadbalance Resource menu)
>> Server Loadbalance Resource# add (Add the second SLB string)
Enter HTTP header name: Host (Define HTTP header name Host)
Enter SLB header value string: wap.yahoo.com
315394-J, January 2005
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.
1: any, cont 256
2: HTTPHDR=Host:wap.example.com, cont 256
3: HTTPHDR=Host:wap.yahoo.com, cont 256
4: HTTPHDR=Host:wap.google.com, cont 256
5: HTTPHDR=Host:wap.p-example.com, cont 256
6: HTTPHDR=Host:10.168.224.227=/top, cont 256
7: jad, cont 256
8: jar, cont 256
9: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor, cont 256
10: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL, cont 256
11: HTTPHDR=Host:any, cont 256
12: HTTPHDR=Host:any:90, cont 256
14: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 256
15: HTTPHDR=Host:www.abc.com, 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: disabled
New port 1 filtering: enabled
315394-J, January 2005
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 clients 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.101
Home page: http://wap.example.com
WAP port 9001, CSD number as 18881234567
username: john
315394-J, January 2005
1. Identify the ID numbers of the defined strings. The strings in bold are used in this exam-
ple.
2. Configure filter 1.
1: any, cont 256
7: jad, cont 256
8: jar, cont 256
>> /cfg/slb/filt 1
>> Filter 1 # sip 10.168.43.0 (From this source IP address range)
Current source address: any
New pending source address: 10.168.43.0
>> Filter 1 # smask 255.255.255.0
Current source mask: 0.0.0.0
New pending source mask: 255.255.255.0
>> Filter 1 # proto tcp (For TCP protocol traffic)
Current protocol: any
Pending new protocol: tcp
>> Filter 1 # dport http (To destination port HTTP)
Current destination port or range: any
Pending new destination port or range: http
>> Filter 1 # action redir (Redirect the traffic)
Current action: allow
Pending new action: redir
>> Filter 1 # /cfg/slb/filt/adv/layer7 (Access advanced Layer 7 menu)
>> Layer 7 Advanced# addrd
Enter 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)
315394-J, January 2005
4. Configure Filter 3.
>> /cfg/slb/filt 2
>> Filter 2 # sip 10.46.6.0.0
New pending source address: 10.46.6.0.0
>> Filter 2 # smask 255.255.255.0
>> Filter 2 # proto tcp
>> Filter 2 # dport http
>> Filter 2 # action redir
>> Filter 2 # /cfg/slb/filt/adv/layer7
Enter 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.0
>> Filter 3 # smask 255.255.255.0
315394-J, January 2005
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.
1: any, cont 256
7: jad, cont 256
8: jar, cont 256
9: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor , cont 256
315394-J, January 2005
>> /cfg/slb/filt 4
>> Filter 4 # sip 10.46.6.231
>> Filter 4 # smask 255.255.255.255
>> /cfg/slb/filt 5
>> Filter 5 # sip 10.46.6.231
>> Filter 5 # smask 255.255.255.255
315394-J, January 2005
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 256
7: jad, cont 256
8: jar, cont 256
315394-J, January 2005
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 requests
HOST string and URL string.
>> /cfg/slb/filt 6
>> Filter 6 # sip 10.46.6.231
>> Filter 6 # smask 255.255.255.255
315394-J, January 2005
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.
1: any, cont 256
7: jad, cont 256
8: jar, cont 256
315394-J, January 2005
2. Configure filter 7 to redirect the URL as described above.
>> /cfg/slb/filt 7
>> Filter 7 # sip 10.46.6.231
>> Filter 7 # smask 255.255.255.255
315394-J, January 2005
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.
1: any, cont 256
7: jad, cont 256
8: jar, cont 256
315394-J, January 2005
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
>> Filter 8 # smask 255.255.255.255
315394-J, January 2005
example.
1: any, cont 256
2: HTTPHDR=Host:wap.foo.com, cont 256
5: HTTPHDR=Host:wap.p-foo.com, cont 256
7: jad, cont 256
8: jar, cont 256
10: HTTPHDR=Host:mobile.foo.com=/4g/w?url=$HOST_URL, cont 256
>> /cfg/slb/filt 9
>> Layer 7 Advanced# l7lkup en
Current layer 7 lookup: disabled
New layer 7 lookup: enabled
315394-J, January 2005
Part 4: Advanced Switching
Alteon 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 2005
418 : Advanced Switching
315394-J, January 2005
419
CHAPTER 15
Health Checking
Health checking allows you to verify content accessibility in large Web sites. As content grows
and information is distributed across different server farms, 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 switchs 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 applications
that 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 2005
420 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 servers 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 the
switch to perform Lightweight Directory Access Protocol (LDAP) health checks for
the switch to determine whether or not the LDAP server is running.
ARP Health Checks 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 2005
Chapter 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, by
default, 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, or
ARP. You may use the LDAP health check method to health check LDAP servers.
>> Real server# inter 4 (Check real server every 4 seconds)
>> Real server# retry 6 (If 6 consecutive health checks fail,
declare real server down)
315394-J, January 2005
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)
315394-J, January 2005
(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 downwithout 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 restoredsuch 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
315394-J, January 2005
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 users virtual server IP address. When DSR health checks are selected, the spec-
ified health check is sent originating from one of the switchs configured IP interfaces, and is
destined to the virtual server IP address with the MAC address that was acquired from the real
server IP addresss Address Resolution Protocol (ARP) entry.
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
315394-J, January 2005
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.
>> # Real server group 1# health
Current health check type: tcp
Enter health check type: link
>> # Real server group 1# apply
>> # Real server group 1# save
315394-J, January 2005
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
315394-J, January 2005
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. The
string or pattern configured with an expect (or in the case of binary, bexpect) command is
searched for in each response packet. If it is 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 once
entered, can be assigned as the health-check method using SNMP or the Browser-Based Inter-
face (BBI).
315394-J, January 2005
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 3
close (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
315394-J, January 2005
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 typically
appears 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"
315394-J, January 2005
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 \\).
315394-J, January 2005
Scripting Commands
Listed below are the currently available commands for building a script-based health check:
OPEN: specify which destination real server UDP port to be used; for example, OPEN
9201. After entering the destination port, you will be prompted to specify a protocol;
choose udp.
CLOSE (for TCP-based health checks only): This command is used to close a TCP 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 in
length to be generated.
EXPECT: specify the expected content in raw hexadecimal format.
BEXPECT (for binary content only): This command is used to specify the binary content
(in hex format) to be expected from the server response packet.
NEXPECT (for binary content only): Similar to NSEND, this command allows the user to
specify additional binary content to be appended to the original content 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
315394-J, January 2005
check fails. The WAIT command should come after an EXPECT command in the script,
or the OFFSET command if one exists after an EXPECT command. The wait window is in
units of milliseconds.
Wildcard character (*): can be used to trigger a match as long as a response is received
from the server. The wildcard character is allowed with the BEXPECT command, as in
BEXPECT *. Any NEXPECT, OFFSET, or DEPTH commands that follow a wildcard
character will be ignored.
Scripting Guidelines
Use generic result codes that are standard and defined by the RFC, as applicable. This
helps 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.
315394-J, January 2005
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 the send 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 sites virtual server
IP address was required to be a real server of the local switch. Each switch sends a health
check request to the other switchs virtual servers that are 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"
close
open 443
close
315394-J, January 2005
Site 1 with Virtual Server 1 and the following real servers:
Real Server 1 and Real Server 2: images
Real Server 3 and Real Server 4: html
Real Server 5 and Real Server 6: cgi and bin
Real Server 7 (which is Virtual Server 2): any
Site 2 with Virtual Server 2 and the following real servers:
Real Server 1 and Real Server 2: images
Real Server 3 and Real Server 4: html
Real Server 5 and Real Server 6: cgi and bin
Real Server 7 (which is Virtual Server 2): any
A sample script is shown below:
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 upthat is, to check if the remote site has at least one server for images content.
Either Real Server 1 or Real Server 2 will respond to the first GET health check.
>> /cfg/slb/group x/health script2/content none
open 80
send "GET /images/default.asp HTTP/1.1\\r\\nHOST: 192.192.1.2\\r\\n\\r\\n"
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
315394-J, January 2005
If all the real server IP addresses are down, Real Server 7 (the virtual server IP address of the
remote site) will respond with an HTTP Redirect (respond code 302) to the health check. Thus,
the health check will fail as the expected response code is 200, ensuring that the HTTP 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 your
send or expect content is lengthy, you may remove spaces in between the numbers to save
space on the command line. For example, type 000101 instead of 00 01 01. Or, continue the
content using the nsend and nexpect commands.
>> /cfg/slb/group <x>/health script3/content none
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"
315394-J, January 2005
Script Example 4: A TCP-Based Health Check using Binary Content
Health check scripts can also be sent over the TCP protocol using Binary content.
A sample of a TCP-based script that uses Binary content to send an HTTP GET request, and
expect an HTTP 200 response, is shown below.
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
315394-J, January 2005
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
315394-J, January 2005
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 = everest
dname = alteonwebsystems.com
content = index.html
Health check is performed using:
GET /index.html HTTP/1.1
Host: everest.alteonwebsystems.com
NOTE If the content is not 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.1
Host: raleighduram.cityguru.com
Example 3:
hname = (none)
dname = jansus
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
315394-J, January 2005
Host: jansus
Example 4:
hname = (none)
dname = (none)
GET /index.html HTTP/1.0 (since no HTTP HOST: header is required)
Example 5:
hname = (none)
dname = (none)
content = //everest/index.html
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>
315394-J, January 2005
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 servers 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-based
query from a dummy host and watching for the servers reply. The reply, even though negative
(for example, Server not found since the query is from a dummy host), serves the purpose of
a health check, nonetheless.
>> # Real server group 1# health udpdns
>> # Real server group 1# content <filename>|//<host><filename>|none
315394-J, January 2005
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 server
successfully 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 dont incur additional traffic between the
server 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
315394-J, January 2005
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 variable
within 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 for
checking 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
315394-J, January 2005
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 up if the switch receives a value 0; any other value that is
returned 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
315394-J, January 2005
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>
315394-J, January 2005
POP3 Server Health Checks
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>
315394-J, January 2005
Configuring the Switch for SMTP Health Checks
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>
315394-J, January 2005
IMAP Server Health Checks
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>
315394-J, January 2005
NNTP Server Health Checks
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>
315394-J, January 2005
RADIUS Server Health Checks
Alteon OS allows you to use the Remote Authentication Dial-In User Service (RADIUS) pro-
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 configuring
RADIUS 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>
315394-J, January 2005
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 on
the 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 WAP
health checks. If you enable the couple command (/cfg/slb/advhc/waphc/couple)
and one of the WAP health checks fail, then the Radius Accounting service is disabled.
>> # /cfg/slb/advhc/secret <RADIUS-coded value>
>> Real server group 1# health radius-acc
315394-J, January 2005
HTTPS/SSL Server Health Checks
The sslh health check option on the Real Server Group Menu (/cfg/slb/group <#>)
allows the switch to query the health of the SSL servers by sending an SSL client Hello
packet and then verify the contents of the servers Hello response. SSL health check is 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.
315394-J, January 2005
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
WTP
a
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
315394-J, January 2005
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
wireless environment, is needed because the client and the server must be authenticated in
order for wireless transactions to remain secure and because the connection needs to be
encrypted. For example, a user making a transaction with a bank over a wireless device needs
to know that the connection is secure and private and not subject to a security breach during
transfer. WTLS is needed because mobile networks do not provide complete end-to-end 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 health
check. If you enable the couple command (/cfg/slb/advhc/waphc/couple) and the
Radius Accounting health check fails, then all four of the WAP services are brought down.
Similarly, if one of the WAP health checks fail, then all the WAP services and the Radius
Accounting service fails.
315394-J, January 2005
Configuring WSP Health Checks
Follow this procedure to configure the health check for connectionless and unencrypted WAP
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# sndcnt
Current Send content:
Enter new Send content: 01 42 15 68 74 74 70 3a 2f 77 77 77 2e 6e 6f
6b 61 6d 00 .
>> WSP Health Check Content# rcvcnt
Current Receive content:
Enter new Receive content: 01 04 60 0e 03 94
315394-J, January 2005
6. Set the offset value.
The offset value is the number of bytes from the beginning of the UDP Data Area, at which the
comparison begins to match with the expected receive content. For 9200 service, the UDP data
area is the WSP response content.
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
>> 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
315394-J, January 2005
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# connect
Current Connect content:
Enter new Connect content: 01 10 00 00
>> WTP+WSP Health Check Content# sndcnt
Current Send content:
Enter new Send content: 01 42 15 68 74 74 70 3a 2f 77 77 77 2e 6e 6f
6b 61 6d 00 .
>> 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
>> 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)
315394-J, January 2005
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
315394-J, January 2005
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 as
up. Otherwise, the switch marks the server as down even if the switch did this because the
server did not respond within the timeout window.
Unbind request: If the server is alive, the switch sends a request to unbind the server.
This request does not require a response. It is necessary to send an unbind request as the
LDAP server may crash if too many protocol sessions are active.
If the server is up, the switch closes the TCP connection after sending the unbind request. If the
server is down, the connection is torn down after the bind response, if one arrives. The connec-
tion will also be torn down if it crosses the timeout limit, irrespective of the servers 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
315394-J, January 2005
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
315394-J, January 2005
ARP Health Checks
Address Resolution Protocol (ARP) is the TCP/IP protocol that resides within the Internet
layer. ARP resolves a physical address from an IP address. ARP queries machines on the local
network for their physical addresses. ARP also maintains IP to physical address pairs in its
cache memory. In any IP communication, the ARP cache is consulted to see if the IP address
of the computer or the router is present in the ARP cache. Then the corresponding physical
address is used to send a packet.
In the switch, this features allows the user to health check the Intrusion Detection Server (IDS)
by sending an ARP query. The health check consists of the following sequence of actions:
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
315394-J, January 2005
Failure Types
Service Failure
If 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 sends
Layer 4 connection requests for the failed service to the server. When the session switch has
successfully established a connection to the failed service, the service is restored to the load-
balancing algorithm.
Server Failure
If all load-balanced services supported on a server fail to respond to switch connection requests
within the 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 in
the 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 2005
315394-J, January 2005
463
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.
315394-J, January 2005
464 Chapter 16: High Availability
VRRP Overview
In a high-availability network topology, no device can create a single point-of-failure for the
network or force a single point-of-failure to any other part of the network. This means that
your network will remain in service despite the failure of any single device. To achieve this
usually requires redundancy for all vital network components.
VRRP enables redundant router 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 backup
virtual 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 hosts 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). Each
VRRP 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.
315394-J, January 2005
Chapter 16: High Availability 465
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
routers IP address is equal to the real interface address. This router responds to packets
addressed to the virtual interface routers IP address for ICMP pings, TCP connections, and
so on.
If the owner is not available, the backup becomes the master and takes over responsibility for
packet forwarding and responding to ARP requests. However, because this switch is not the
owner, it does not have a real interface 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 routers VLAN with an active link, the interface for the VLAN
fails, thus placing the virtual router into the INIT state.
315394-J, January 2005
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.
How VRRP Priority Decides Which Switch is the Master
Each VRRP router that is not an owner is configured with a priority between 1254. According
to the VRRP standard, an owner has a priority of 255. A bidding process determines which
VRRP router is or becomes the masterthe VRRP router with the highest priority. Owners
have a higher priority than the range permitted for non-owners. If there is an IP address owner,
it is always the master for the virtual interface router, as long as it is available.
The master periodically sends advertisements to an IP multicast address. As long as the 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 reasonsthe master can be
down, or all communications links between the master and the backup can be down. If the
master has failed, it is clearly desirable for the backup (or one of the backups, if there is more
than one) to become the master.
NOTE If the master is healthy but communication between the master and the backup has
failed, there will then be two masters within the virtual router. To prevent this from happening,
configure redundant links to be used between the switches that form a virtual router.
Determining How to Configure Priority
Think of a virtual routers priority as a starting value that increases or decreases depending on
the parameters that are tracked. For example, if you configure the virtual router to track link
state of the physical ports, one port losing link would cause the virtual routers priority to
decrease by 2 priority points. In order to ensure that this decrease in priority causes failover
from the current master to the backup virtual router, you should make sure to set the base
priority of the Master switch to be only 1 point higher than the backup; for example priority
101 for master, 100 for backup. If the master and backup switches were set to priorities 110
315394-J, January 2005
and 100 respectively, a single port failure would only decrease the master switchs priority to
108. As 108 is still higher than backups priority 100, the master switch would not fail over
due to the loss of one ports link.
315394-J, January 2005
Alteon OS Extensions to VRRP
This section describes the following VRRP enhancements that are implemented in Alteon OS:
Virtual Interface Routers on page 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. If
the IP interface of a VIR is down, then the VIR will be in the INIT state.
Virtual Server Routers
Support for 1024 VSRs
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 routers priority is exchanged. Only the mas-
ter can process packets that are destined for the virtual server IP address and respond to ARP
requests.
315394-J, January 2005
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 routers priority in a virtual
server router, you are not affecting that VRRP routers priority in any virtual interface router or
any other virtual server router of which it is a part. However, because of the requirement that
MAC addresses be unique on a LAN, VRIDs must be unique among all virtual routers,
whether virtual interface routers or virtual server routers.
315394-J, January 2005
The Alteon Application Switches in Figure 16-1 have been configured as VRRP routers.
Together, they form a virtual interface router (VIR).
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
Router
VRRP Router
VRRP Router
VRID = 1
Router #2 = Backup Standby
VR IP address = 205.178.13.226
IP interface = 205.178.13.225
MAC address = 00.00.5E.00.01.01
Priority = 100
VRID = 1
Router #1 = Master Active
VR IP address = 205.178.13.226
IP interface = 205.178.13.226
MAC address = 00.00.5E.00.01.01
Priority = 255
Virtual
Interface
Router
Host #1
Default Gateway
205.178.13.226
Alteon Application
Switch 1
Alteon Application
Switch 2
315394-J, January 2005
Alteon OS supports sharing of interfaces at both Layer 3 and Layer 4, as shown in Figure 16-2.
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
Application
Switch 1
Master-Active
VRID 2
VIP: 205.178.13.226
Virtual Rtr. MAC address:
00-00-5E-00-01-02
Backup-Active
VRID 4
VIP: 205.178.13.240
00-00-5E-00-01-04
Master-Active
VRID 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
00-00-5E-00-01-02
Master-Active VR 2
VRID 4
VIP: 205.178.13.240
00-00-5E-00-01-04
Backup-Active VR 3
VRID 6
VIP: 205.178.13.110
00-00-5E-00-01-06
Internet
Router
Router
Backup-Active VR 1
Master-Active VR 2
Backup-Active VR 3
Master-Active VR 1
Backup-Active VR 2
Master-Active VR 3
Alteon Application
Switch 2
Alteon Application
Switch 1
315394-J, January 2005
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
entry point into the virtual routerfor example, where a hub is used to connect the switches.
When sharing is enabled, the master election process still occurs. Although the process does
not affect which switch processes packets that must be routed or that are destined for the vir-
tual server IP address, it does determine which switch sends advertisements and responds to
ARP requests sent to the virtual routers 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 groups
tracking parameters while leaving other groups unaffected. For example, an administrator
wishes to provide high availability for Customer A and Customer Bs servers and services
across the same two switches, without one affecting the other:
Customer As traffic load-balances across real servers in real server group 1.
Customer Bs 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.
315394-J, January 2005
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.
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 1
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
VIP 1
Real server group 1
vrgroup 1 for customer A
315394-J, January 2005
To add virtual routers to a service-based virtual router group:
See Tracking Service-Based Virtual Router Groups on page 477 for a configuration
example.
Switch-Based VRRP Groups
A switch-based virtual router group aggregates all virtual routers on the switch as a single
entity for non-shared environments. All virtual routers will failover as a group, and cannot
failover individually. As members of a group, all virtual routers on the switch (and therefore
the switch itself), will be in either a master or backup state.
Characteristics of a Switch-Based VRRP Group
When enabled, all virtual routers behave as one entity, and all group settings override any
individual virtual router settings or service-based vrgroup settings.
All individual virtual routers, once the switch-based VRRP group is enabled, assume the
groups tracking and priority.
When one member of a switch-based VRRP group fails, the priority of the group
decreases, and the state of the entire switch changes from Master to Backup.
If a switch is in the backup state, Layer 4 processing is still enabled. If a virtual server is
not a virtual router, the backup switch can still process 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
/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)
315394-J, January 2005
The switch-based VRRP group is configured by the following command:
NOTE For more information on using switch-based VRRP groups with hot-standby, see
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.
/cfg/l3/vrrp/group ena
315394-J, January 2005
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
switch.
To enable tracking on vrs:
/cfg/l3/vrrp/vr <#>/track/vrs/ena
To change the virtual router increment:
/cfg/l3/vrrp/track/vrs <[0-254]>
Useful for ensuring that traffic for any particular client/server pair is
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 <#>/ena
To 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 least
one active port on the same VLAN.) This parameter influences the
VRRP routers priority in both virtual interface routers and virtual
server routers.
Number of active ports on the same VLAN.
To enable tracking on ports on the same VLAN:
/cfg/l3/vrrp/vr /track/port <#>/ena
To change the ports tracking increment:
/cfg/l3/vrrp/track/ports <[0-254]>
Helps elect the virtual routers with the most available ports as the
master. This parameter influences the VRRP routers priority in both
virtual interface routers and virtual server routers.
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/ena
To 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 routers 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
routers 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 receive
HSRP 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 routers priority in both virtual interface routers and virtual
server routers.
Tracking HSRP on VLAN
/cfg/l3/vrrp/track/hsrv
Hot Standby Router on VLAN (HSRV) is used in VLAN-tagged
environments. Enable this option to increment only that VRRP
instance that is on the same VLAN as the tagged HSRP master
flagged packet. This command is disabled by default.
315394-J, January 2005
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 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 groups tracking configuration overrides an individual
VRRP routers 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-
tomers 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 configure
the switch for tracking VRRP priority.
315394-J, January 2005
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>
315394-J, January 2005
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.
315394-J, January 2005
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-
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
Router
VRID = 1
VRID = 1
Host #1
Default Gateway
205.178.13.226
Host #2
Default Gateway
205.178.13.240
VRID = 2
VRID = 2
Alteon Application
Switch 1
Alteon Application
Switch 2
315394-J, January 2005
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.
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.
Table 16-3 Active-Standby Configuration
VRID = 1 VRID = 2
Application
Switch 1
VR IP address = 205.178.13.226
MAC address = 00.00.5E.00.01.01
Priority = 255
IP interface = 205.178.13.226
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
VR IP address = 205.178.13.226
MAC address = 00.00.5E.00.01.01
Priority = 100
IP interface = 205.178.13.225
VR IP address = 205.178.13.240
MAC address = 00.00.5E.00.01.02
Priority = 255
IP interface = 205.178.13.240
315394-J, January 2005
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.
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 switches
that 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-Standby
VRID 2
VIP: 205.178.13.226
MAC address 00-00-5E-00-01-02
Server 4
RIP 1: 10.10.10.104
RIP 2: 10.10.11.104
Master-Active
VRID 2
VIP: 205.178.13.226
MAC address 00-00-5E-00-01-02
Server 3
RIP 1: 10.10.10.103
RIP 2: 10.10.11.103
Server 2
RIP 1: 10.10.10.102
RIP 2: 10.10.11.102
Server 1
RIP 1: 10.10.10.101
RIP 2: 10.10.11.101
Alteon Application
Switch 1
Alteon Application
Switch 2
315394-J, January 2005
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
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 tracking
on 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 2s 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 real
servers for the Virtual Router's VIP address, application switch 1s priority will be reduced. If it
is reduced to a value lower than application switch 2s priority, then application switch 2 will
assume the role of master. In this case, all active connections serviced by application switch 1s
virtual server IP address are severed.
If the link between application switch 1 and its Internet router fails, the protocol used to 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 masters responsibility of responding to ARP requests and issuing
advertisements.
315394-J, January 2005
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-Active
VRID 2
VIP: 205.178.13.226
MAC address 00-00-5E-00-01-02
Server 4
RIP 1: 10.10.10.104
Master-Active
VRID 2
VIP: 205.178.13.226
MAC address 00-00-5E-00-01-02
Server 3
RIP 1: 10.10.10.103
Server 2
RIP 1: 10.10.10.102
Server 1
RIP 1: 10.10.10.101
Alteon Application
Switch 1
Alteon Application
Switch 2
315394-J, January 2005
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:
1. Configure the appropriate Layer 2 and Layer 3 parameters on both switches.
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.
NOTE In this configuration, each servers backup is attached to the other switch. This
ensures that operation will continue if all of the servers attached to a switch fail.
4. 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 2s configu-
ration.
315394-J, January 2005
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
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 connection
limits 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 the
Command 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.
315394-J, January 2005
To configure the IP interfaces for this example, enter the following commands from the CLI:
Repeat the commands for each interface listed below:
IF 220.10.10.10
IF 330.10.10.10
IF 440.10.10.10
IF 5200.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 5physical ports connected to upstream switches.
VLAN 2 - IFs 1,2,3,4physical ports connected to downstream switches.
3. Disable Spanning Tree.
>> 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)
>> 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)
315394-J, January 2005
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 server
IP 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 210.10.10.6/24
RIP 320.10.10.5/24
RIP 420.10.10.6/24
RIP 530.10.10.5/24
RIP 630.10.10.6/24
RIP 7200.1.1.5/24
RIP 8200.1.1.6/24
>> 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)
315394-J, January 2005
2. Define the real server groups, adding the appropriate real servers.
This combines the three real servers into one service group:
Repeat this sequence of commands for the following real server groups:
Group 2Add 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 2200.200.200.101 will load balance HTTPS (Port 443) to Group 2
VIP 3200.200.200.102 will load balance POP/SMTP (Ports 110/25) to Group 3
VIP 4200.200.200.104 will load balance FTP (Ports 20/21) to Group 4
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 virtual
server IP address. Note the following:
The ports connected to the upstream switches (the ones connected to the routers) will need
to be in the client port state.
The ports connected to the downstream switches (the ones providing fan out for the serv-
ers) will need to be in the server port state.
>> Real server 8 # /cfg/slb/group 1 (Select real server group 1)
>> 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)
315394-J, January 2005
Configure the ports, using the following sequence of commands:
Task 3: Virtual Router Redundancy Configuration
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
>> 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)
>> 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)
315394-J, January 2005
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:
Apply this sequence of commands to the following virtual routers, assigning each a priority of
101:
VR 2Priority 101
VR 3Priority 101
VR 4Priority 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 server 4 # /cfg/l3/vrrp/vr 1 (Select virtual router 1)
>> Virtual router 1 prio 101 (Set virtual router priority)
>> Virtual server 4# /cfg/l3/vrrp/vr 1/track l4pts
315394-J, January 2005
(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/
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
315394-J, January 2005
2. Change the virtual router priorities.
Virtual routers 14 need to have their priority set to 100 from 101, and virtual routers 5-7 need
to have their priorities set to 101 from 100. You can 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
315394-J, January 2005
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)
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 the
virtual 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
315394-J, January 2005
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 Ciscos 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 masters VRRP updates. After an interval period has
expired without receiving a update, the backup switch will take over. The forwarding states of
hot-standby ports are controlled much like the forwarding states of the old hot-standby
approach. Enabling hot-standby on a switch port allows the hot-standby algorithm to control
the forwarding state of the port. If a switch is master, the forwarding states of the hot-standby
ports are enabled. If a switch is backup, the hot-standby ports are blocked from forwarding or
receiving traffic.
When the hotstan option (/cfg/slb/port x/hotstan) is enabled and all hot-standby
ports have link, the virtual router groups priority is automatically incremented by 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 x/hotstan
/cfg/slb/port <port number>/intersw
315394-J, January 2005
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
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
25
26
25
26
Internet
Router
Router
Server 4
RIP 1: 10.10.10.104
Server 3
RIP 1: 10.10.10.103
Server 2
RIP 1: 10.10.10.102
Server 1
RIP 1: 10.10.10.101
Alteon Application
Switch 2 Backup-Standby
VLAN 192:
Client Traffic
Alteon Application
Switch 1 - Active-Hot
VLAN 172
Interswitch link
3
3
315394-J, January 2005
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)
315394-J, January 2005
4. Configure the IP addresses for each VLAN.
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.
/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# vlan 192
>> IP Interface 2# /cfg/l3/if 3 (IP Interface 3: Interswitch Link)
>> IP Interface 3# ena
>> 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)
/cfg/l3/vrrp/vr 3 (Virtual router for Interswitch Link)
/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)
315394-J, January 2005
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.
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 switchs 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/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
/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# save
315394-J, January 2005
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:
A script will be dumped out.
2. Copy and paste the entire contents of the script to a text file.
The first and last lines of the file should show the following:
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).
/cfg/dump
script start "Alteon Application Switch 2424" 4 /**** DO NOT EDIT
THIS LINE! (File must begin with this line)
/* Configuration dump taken 1:52:02 Fri Feb 6, 2004
/* Version 0.0.0, Base MAC address 00:0e:40:32:7c:00
:
:
script end /**** DO NOT EDIT THIS LINE!
>> Configuration#
(Example from configuration script:)
/c/l3/if 1
addr 10.0.1.252
(Example from configuration script:)
/c/slb/sync/peer 1
ena
addr 172.16.2.251
315394-J, January 2005
Change the virtual router priority from 100 to 101this 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.
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.
/c/l3/vrrp/group
:
prio 101
/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.252
Confirm synchronizing the configuration to 172.16.2.252 [y/n]:y
315394-J, January 2005
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 behind
the VIP address. The VIP address is the same as the IP address of the virtual server
router on the switch. Set the value = 6.
Initially, application switch 1 (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 1s 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 1s priority
will be reduced by 6 more to 117. Since 117 is less than 120 (application switch 2s priority),
then application switch 2 will become the Master. At this point, application switch 1s priority
315394-J, January 2005
will fall by 5 more and application switch 2s will rise by 5 because the switches are tracking
how many masters they are running. So, application switch 1s priority will settle out at 112
and application switch 2s priority at 125.
When both servers are restored to application switch 1, that switchs priority will rise by 12 (2
healthy real servers * 6 per healthy server) to 124. Since 124 is less than 125, application
switch 2 will remain the master.
If, at this point, a server fails on application switch 2, its priority will fall by 6 to 119. Since
119 is less than 124, application switch 1 will become the Master. Its priority will settle out at
129 (since its now the master) while application switch 2s priority will drop by 5 more to
114.
You can see from this example that the users goals were met by the 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.
315394-J, January 2005
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 routersthey use the IP interface addresses.
Virtual routers 2 and 4 are virtual service routersthey use the virtual server IP addresses.
Virtual router 1 on the master forwards the packets sent to the IP addresses associated with the
virtual router and answers ARP requests for these IP addresses. The virtual router backup
assumes forwarding responsibility for a virtual router should the current master fail.
Virtual routers 1 and 2 are members of vrgroup 1 and virtual routers 3 and 4 are members of
vrgroup 2.
Figure 16-8 Service-Based Virtual Router GroupsActive-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 VRs
in vrgroup 1 on Application Switch 2 change to the master state. Meanwhile, the VRs in
vrgroup 2 continue to operate via Application switch 1.
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
Requests
to VIP 1
VIP 1
VIP 2
VRGroup 1 (VR1, VR2)
VRGroup 2 (VR3, VR4)
Active
315394-J, January 2005
The separate real server groups provide segregation of services for each customer., so neither
customers 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:
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.
>> Main# /cfg/l3/if 1 (Select IP interface 1)
>> IP Interface 1 # addr 200.200.200.1 (Assign IP address for the interface)
315394-J, January 2005
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
/cfg/slb/virt 1/vip 205.178.13.226 (Configure virtual server IP 1)
>> Virtual server 1# service http (Select the HTTP service port menu)
/cfg/slb/group 2
/cfg/slb/virt 1/vip 205.178.13.300
315394-J, January 2005
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.
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.
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)
>> VRRP Virtual Router 1# share dis (Disable sharing of interfaces)
>> VRRP Virtual Router 1# ena (Enable virtual router 1)
315394-J, January 2005
6. Add virtual routers 1 and 2 to the vrgroup 1.
7. Add virtual routers 3 and 4 to switch-based vrgroup 2.
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# /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)
>> 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
315394-J, January 2005
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 VLANs
VRRP 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
Router
Server
Server
Bridging Loop
315394-J, January 2005
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.
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).
Routers
Alteon Application
Switches
Layer 2
Switches Servers
Internet
is for switch-to-switch
and external routing
groups the first sub-
switch with the Alteon
Web Switches
groups the second
sub- switch with the
Alteon Web switches
VLAN 1
VLAN 2
VLAN 3
Routers
Alteon Application
Switches
Layer 2
Switches
Servers
Internet
315394-J, January 2005
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
refine what is synchronized, to whom, and to disable synchronizing certain configurations.
These options include proxy IP addresses, Layer 4 port configuration, filter configuration, and
virtual router priorities.
Also, a peer menu (cfg/slb/sync/peer) has been added to 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)
315394-J, January 2005
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
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 switches
to 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 # /cfg/slb/sync (Select the synchronization menu)
>> Peer Switch 2 # addr <IP address> (Assign switch 1 IP address)
>> Main# /oper/slb/sync
315394-J, January 2005
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
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 clients request returns to the same server based on the
persistent session entries being shared by the master and the slave switch. The TCP session
information, however, is not shared.
315394-J, January 2005
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 events
occurs:
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 from
having to re-establish a secure session. The server that stores the secure session now returns a
response to the client via the backup switch.
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
Master switch failed
10.1.1.1
Layer 2
Switch
Servers
Backup switch Active
10.1.1.2
Internet
Traffic is redirected
to backup switch
Clients
315394-J, January 2005
1. Enable stateful failover.
2. Set the update interval.
3. Configure the backup switch as a peer and specify its IP address.
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.
>> # /cfg/slb/sync/state ena
>> # /cfg/slb/sync/update 10 (The default is 30)
>> # /cfg/slb/sync
>> 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)
315394-J, January 2005
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:
If the switch is a backup:
>> # /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
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
315394-J, January 2005
517
CHAPTER 17
Persistence
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.
315394-J, January 2005
518 Chapter 17: Persistence
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
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 packets IP source address:
Many clients sharing the same source IP address (proxied clients): Proxied clients
appear to the switch as a single source IP address and do not take advantage of SLB on the
switch. When many individual clients behind a 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 clients address to different
proxy addresses as attempts are made to load balance client requests.
Single client sharing a pool of source IP addresses: When individual clients share a
pool of source IP addresses, persistence for any given request cannot be assured. Although
each source IP address is directed to a 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.
315394-J, January 2005
Chapter 17: Persistence 519
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
The SSL session ID is effective only when the server is running SSL transactions. Because of
the heavy processing load required to maintain SSL connections most network 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.
315394-J, January 2005
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.
315394-J, January 2005
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: disabled
Enter clientip|cookie|sslid|disable persistence mode: clientIP
Use Rport? (y/n) [y]y
>> # /cfg/slb/port <port number>/client ena
315394-J, January 2005
Cookie-Based Persistence
Cookies are a mechanism for maintaining state between clients and servers. When the server
receives a client request, the server issues a cookie, or token, to the client, which the client then
sends to the server on all subsequent requests. Using cookies, the server does not require
authentication, the client IP address, or any other time-consuming mechanism to determine
that the user is the same user that sent the original request.
In the simplest case, the cookie may be just a customer ID assigned to the user. It may be a
token of trust, allowing the user to skip authentication while his or her cookie is valid. It may
also be a key that associates the user with additional state data that is kept on the server, such
as a shopping cart and its contents. In a more complex application, the cookie may be encoded
so that it actually contains more data than just a single key or an identification number. The
cookie may contain the users 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 informatio
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
Alteon Application
Switch
315394-J, January 2005
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
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 sites server. It will be sent by the browser when
the client makes subsequent requests to the same site, even after the browser has been shut
down. A temporary cookie is only valid for the current browser session. Similar to a SSL 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
315394-J, January 2005
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 string
For security, the real cookie value can be embedded somewhere within a longer string.
The offset directs the application switch to the starting point of the real cookie value
within the longer cookie string.
Length of the cookie value
This 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 (for
client IP persistence) as the load-balancing metric to maintain session persistence.
With cookie-based persistence enabled, session persistence for browsers that do not accept
cookies will be based on the source IP address. However, individual client requests coming
from a proxy 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.
315394-J, January 2005
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:
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 RIP
value, and a 4 byte RPORT value
In this mode, the client sends a request to visit the Web site. The application switch performs
load balancing and selects a real server. The real server responds without a cookie. The appli-
cation switch inserts a cookie and forwards the new request with the cookie to the client.
Figure 17-2 Insert Cookie Mode
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
Rewrite Cookie Server and Switch HTTP Header No
Internet
1. Configure switch to insert cookie values
Web Server
Farm
Client
Alteon Application
Switch
Proxy Firewall
2. Client visits the Web site via HTTP request
3. Alteon Application Switch
selects server via SLB
4. Server responds
without any cookie
5. Alteon Application switch inserts a cookie and
forwards the request to the client.
315394-J, January 2005
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 Server
Farm
Client
Alteon Application
Switch
Proxy Firewall
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.
315394-J, January 2005
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 value
to 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 or
it can be the real server IP address. The rewritten cookie value is encoded.
Internet
1. Configure switch to rewrite cookie values
Web Server
Farm
Client
Alteon Application
Switch
Proxy Firewall
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 SLB
2. Client visits the Web site via HTTP request
315394-J, January 2005
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
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)
315394-J, January 2005
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.
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/group 2/metric hash (Select hash as server group metric)
>> # /cfg/slb/virt 1/service 80/pbind
Current persistent binding mode: disabled
Enter clientip|cookie|sslid|disable persistence mode: cookie
Enter insert|passive|rewrite cookie persistence mode [i/p/r]: p
Enter cookie name: CookieSession1
Enter starting point of cookie value [1-64]: 1
Enter number of bytes to extract [0-64]: 8
Look for cookie in URI [e|d]: d
315394-J, January 2005
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
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: 12/31/04@11:59
Current persistent binding for http: disabled
New persistent binding for http: cookie
New cookie persistence mode: insert
Inserted cookie expires on Mon 12/31/04 at 11:59
Enter cookie expiration: 32:25:61
Current persistent binding for http: disabled
New persistent binding for http: cookie
New cookie persistence mode: insert
Inserted cookie expires after 33 days 2 hours 1 minutes
>> # /cfg/slb/virt 1/service 80/pbind cookie passive UID 1 8 dis
315394-J, January 2005
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
315394-J, January 2005
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.
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 servers Set-
Cookie: value and directs all subsequent connections to the server that assigned the cookie.
For example, if Server 1 sets the cookie as Set-Cookie: sid=12345678, then all 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 sid 1 16 dis
>> # /cfg/slb/virt 1/service 80/pbind cookie passive
ASPSESSIONID* 1 16 dis
315394-J, January 2005
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
servers encrypted IP address:
Set-Cookie: sid=cdb20f04rsistence;
All subsequent traffic from a specific client with this cookie will be directed to the same
real server.
Rewrite server cookie with the encrypted real server IP address and virtual server IP
address:
If the cookie length is 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 8 dis
>> # /cfg/slb/virt 1/service 80/pbind cookie rewrite sid 1 16 dis
315394-J, January 2005
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>/rcount
Current Cookie search response count:
Enter new Cookie search response count [1-16]:
315394-J, January 2005
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-
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 pbind
clientip.
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.
315394-J, January 2005
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.
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.
Internet
Web Server
Farm
Client 1
Client 2
Firewall
Alteon Application
Switch
315394-J, January 2005
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.
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
315394-J, January 2005
315394-J, January 2005
539
CHAPTER 18
Advanced Denial of Service
Protection
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
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.
315394-J, January 2005
540 Chapter 18: Advanced Denial of Service Protection
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.
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 capability
to 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.
315394-J, January 2005
Chapter 18: Advanced Denial of Service Protection 541
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 2005
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.
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.
315394-J, January 2005
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.
Viewing IP ACL statistics
You can view the accumulated blocked packets for each IP address /mask pair by entering the
following command:
>> /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: disabled
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 9702
192.168.40.65 563
315394-J, January 2005
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. 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: disabled
New DOS attack detection: enabled
Jun 18 22:33:32 ALERT security: DoS Attack:Fraggle
sip:192.115.106.200 dip:192.115.106.255 ingress port:1
315394-J, January 2005
The following command shows DOS statistics on all ports where DOS protection is enabled:
Viewing DOS statistics per port
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/dump
------------------------------------------------------------------
Port 1:
Smurf: 0 LandAttack: 0 Fraggle: 107
Nullscan: 0 Xmascan: 0 ScanSynFin: 0
PortZero: 0 Blat: 0
------------------------------------------------------------------
Port 2:
PortZero: 0 Blat: 0
>> /stats/security/dos/port 1
Port 1:
PortZero: 0 Blat: 0
>> /stats/security/dos help
315394-J, January 2005
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
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
315394-J, January 2005
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 , and
drops any matching packets.
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 servers input buffer, and can cause
a system to crash, hang, or reboot.
User action: Configure Matching and Denying Large PacketsICMP Ping of Death
Example on page 562.
sourceIP destinationIP sport dport =
315394-J, January 2005
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 of
the above protocols, and then rate limiting is enabled or disabled in the Filtering Advanced
menu.
TCP Rate Limiting: limits new TCP connection requests, or SYN packets. The switch
monitors the rate of incoming TCP connection requests to a virtual IP address and limits
the client requests with a known set of IP addresses. See TCP Rate Limiting 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 Limits
A 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.
315394-J, January 2005
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 connection
requests 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 Limiting
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 filter
increment the TCP Rate session counter. If the counter reaches the threshold value before the
TCP Rate session ages out, then a hold down period is reached. During the hold down period
no new TCP sessions from this client that match this 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 clients IP address and the configured filter do not match, then the default filter is
applied.
315394-J, January 2005
In Figure 18-1, the default filter 2048 configured for Any is applied for all other connection
requests.
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.
Internet
Real servers Clients
1
2
3
4
Filter 10: 10 conn/sec
Filter 2048: Allow Any
Client 1 limit: 10 conn/sec
Alteon
Application
Switch
315394-J, January 2005
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.
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.
>> 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)
>> Rate Limiting Advanced# timewin 3 (Denotes a 3-second time window)
>> Rate Limiting Advanced# holddur 4 (Set the hold duration)
315394-J, January 2005
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.
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.
>> 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)
315394-J, January 2005
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.
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.
>> 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)
Internet
Real servers Clients
1
2
3
4
Client 1, 2, 3, and 4 are limited
to 100 conn/sec to virtual IP address
VIP: 10.10.10.100
S1
S2
Alteon Application
Switch
315394-J, January 2005
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.
2. Add the filter to the ingress port 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)
>> Filter 30 # adv/security (Select the Security menu)
>> 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: disabled
New port 2 filtering: enabled
>> SLB port 2# add 30 (Add the rate limit filter to the port)
Filter 30 added to port 2.
315394-J, January 2005
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,
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-2000
Enter max packet rate per second (1 to 20000000): 1000
/cfg/security/port 1/udpblast ena
315394-J, January 2005
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 pattern
data, 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.
315394-J, January 2005
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.
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.
IP Header
Version Length Service Type Total Length
Identification Flags Fragment Offset
Time to Live Protocol Header Checksum
Source IP Address

Destination IP Address
IP Options (optional) Padding
Data
IP payload
Each row is 4 bytes long.
Pattern matching examines
from the beginning of the IP
payload portion of the packet.
315394-J, January 2005
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 the
specified 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
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 and
enabled the Advanced Denial of Service Protection software key.
>> /cfg/slb/layer7/slb/addstr
315394-J, January 2005
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.
Enter type of string [l7lkup|pattern]: pattern (Add the first pattern)
Enter match pattern type [ascii|binary]: binary (Select binary matching)
Enter HEX string: 014F (For this Binary pattern)
Enter offset in bytes from start of IP frame (0-1500): 2 (Starting from 3rd byte)
Enter depth in bytes to search from offset (0-1500): 0 (Search length of the pattern)
Enter operation (eq|gt|lt): eq (For values equal to this Binary pattern)
>> Server Loadbalance Resource# add (Add the second pattern)
Enter type of string [l7lkup|pattern]: pattern
Enter match pattern type [ascii|binary]: ascii (Select ascii matching)
Enter ASCII string: /default.htm (Match this ascii string)
Enter offset in bytes from start of IP frame (0-1500): 44 (Search from 45th byte)
Enter depth in bytes to search from offset (0-1500): 30 (through 30th byte)
ID 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
315394-J, January 2005
3. In the security menu, configure a pattern group and name it something relevant and easy
to remember.
4. Add the new pattern/offset pairs to the pattern group using their ID numbers.
Refer back to Step 2, where you typed the cur command, if you need to recall the ID number
associated with the SLB string.
5. Configure a filter and its appropriate protocol in which the patterns are found.
6. Configure the filter source and destination ports.
7. Configure the filter to deny.
8. Apply the pattern group you configured in Step 3 and Step 4 to the filter.
9. Enable pattern matching on the filter.
This command will automatically enable Layer 7 lookup on the filter.
10. Apply the filter to the client port.
>> /cfg/security/pgroup 1/name (Name pattern group 1)
Current pattern group name:
Enter new pattern group name: virus_x (Name the group)
>> Pattern Match Group 1# add 8 (Add the first binary pattern)
>> Pattern Match Group 1# add 9 (Add the ascii string pattern)
>> /cfg/slb/filt 90 (Go to the Filter 90 menu)
>> Filter 90 # sport any (From any TCP source port)
>> Filter 90 # dport http (To HTTP destination port)
Current action: none
Pending new action: deny
>> Main# /cfg/slb/filt 90/adv/security/addgrp 1(Add pattern group 1 to the filter)
Group ID 1 added.
>> /cfg/slb/filt 90/adv/security/pmatch enable
Current Pattern Match: disabled
New Pattern Match: enabled
315394-J, January 2005
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.
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:
>> SLB Port 3# filt ena (Enable filtering on the client port)
>> SLB Port 3# add 90 (Add Filter #90 to the client port)
>> /cfg/slb/filt 90/adv/security/matchall ena(Enable matching all criteria)
Current Match-all Criteria: disabled
New Match-all Criteria: enabled
315394-J, January 2005
Matching and Denying Large PacketsICMP 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 servers input buffer, and can cause a system to crash, hang, or
reboot.
Large ICMP packets, such as in an ICMP ping of death attack, can be blocked using a deny 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.
Enter type of string [l7lkup|pattern]: pattern (Add the pattern)
Enter HEX string: 0000 (non-zero IP offset)
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)
Enter type of string [l7lkup|pattern]: pattern (Add the pattern)
Enter HEX string: 4000 (More-Fragments bit set)
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)
315394-J, January 2005
3. Apply the new configuration.
4. Identify the IDs of the defined patterns.
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.
>> Server Loadbalance Resource# apply
ID SLB String
1 ida
2 %c1%9c
3 %c0%af
4 playdog.com
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
315394-J, January 2005
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.
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.
Current action: none
Pending new action: deny
>> Filter 190 # adv/icmp
>> Filter 190 Advanced# icmp
Current ICMP message type: any
Enter 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.
>> /cfg/slb/filt 190/adv/security/pmatch enable
Current Pattern Match: disabled
New Pattern Match: enabled
>> Security# matchall ena
Current Match-all Criteria: disabled
New 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)
315394-J, January 2005
565
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
An overview of firewalls and the various FWLB solutions supported by Alteon Applica-
tion switches.
Basic FWLB on page 568
Explanation 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.
315394-J, January 2005
566 Chapter 19: Firewall Load Balancing
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:
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.
"Dirty" Public Network
Internet
DMZ
Firewall
Private
Network
"Clean" Private Network
315394-J, January 2005
Chapter 19: Firewall Load Balancing 567
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-
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.
315394-J, January 2005
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
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 complexity
increases dramatically. The four-subnet FWLB solution is usually preferred in larger scale,
high-availability topologies (see page 580).
"Dirty" Side of Network
Firewalls
"Clean" Side of Network
Internet
Internal
Network
Alteon Application
Switch
Alteon Application
Switch
315394-J, January 2005
Basic FWLB Implementation
In this example, traffic is load balanced among the available firewalls.
Figure 19-3 Basic FWLB Process
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.
"Dirty" Side "Clean" Side
Internet
Firewalls
Servers
Alteon Application
Switch
Client
3
4
5
8
7
6
1
2
9
10
1. Client sends a request
2. Redir filter selects upper or lower path
3. Static route directs request through
the selected firewall
4. Firewall forwards valid traffic
5. SLB selects an available server
6. Server responds
7. Redir filter selects reverse path
8. Static route directs response back
through the same firewall
9. Firewall forwards valid traffic
10. Client receives response
Alteon Application
Switch
315394-J, January 2005
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 specific
IP 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).
315394-J, January 2005
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.
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.
Internet
Firewall 1
Firewall 2
Servers
Alteon Application
Switch 1
IF1: 192.16.12.1
Alteon Application
Switch 2
IF1: 20.1.1.1
Virtual Server:
20.1.1.10
20.1.1.2
20.1.1.3
Dirty Side:
10.1.2.10
IF2: 10.1.1.1
IF3: 10.1.2.1
IF2: 10.1.3.1
IF3: 10.1.4.1
Dirty Side:
10.1.1.10
Clean Side:
10.1.4.10
Clean Side:
10.1.3.10
1
2
3
2
3
4
5
315394-J, January 2005
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.
Later in this procedure, youll 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 server
group, then real server 1 IP interface on the dirty side should be connected to Firewall 1.
Selecting the same real server ensures that the 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 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 2# addr 10.1.1.1 (Set the IP address for interface 2)
>> 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)
315394-J, January 2005
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.
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# health icmp (Select ICMP as health check type)
>> Real server group 1# metric hash (Select SLB hash metric for group 1)
>> 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)
315394-J, January 2005
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.
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 10# /cfg/slb/filt 15 (Select filter 15)
>> Filter 15# proto any (For any protocol)
>> Filter 15# action redir (Perform redirection)
>> Filter 15# group 1 (To real server group 1)
>> Filter 15# adv/fwlb ena
>> 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# 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
>> # apply
>> # save
315394-J, January 2005
Configure the Clean-Side Alteon Application Switch
1. Define the clean-side IP interfaces.
Create one clean-side IP interface on a different subnet for each firewall being load balanced.
NOTE An extra IP interface (IF 1) prevents server-to-server traffic from being redirected.
2. Configure the dirty-side IP interfaces as if they were real servers on the clean side.
You should already have configured a dirty-side IP interface on a different subnet for each fire-
wall path being load balanced. Create two real servers on the clean-side switch, using the IP
address of each dirty-side IP interface.
NOTE The real server index number must be the same on both sides of the 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.
NOTE Each of the four IP interfaces (two on each application switch) in this example must
be configured for a different IP subnet.
>> IP Interface 5# /cfg/slb/real 1 (Select real server 1)
>> Real server 1# rip 10.1.1.1 (Assign dirty-side IF 1 address)
>> Real server 2# rip 10.1.2.1 (Assign dirty-side IF 2 address)
315394-J, January 2005
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)
315394-J, January 2005
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.
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 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)
>> 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
315394-J, January 2005
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.
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.
>> 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 15# action redir (Perform redirection)
>> Filter 15# group 1 (To real server group 1)
>> Filter 15# /cfg/slb/port 4 (Select ingress port 4)
>> SLB Port 4# /cfg/slb/port 5 (Select ingress port 5)
315394-J, January 2005
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
>> # apply
>> # save
315394-J, January 2005
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:
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.
Subnet 1 Subnet 2 Subnet 3 Subnet 4
Dirty Side Clean Side
Internet
Routers
Simple
Switches
Simple
Switches
Firewalls
Primary
Secondary
Alteon Application
Switch
Primary
Secondary
Alteon Application
Switch
Servers
315394-J, January 2005
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).
315394-J, January 2005
Four-Subnet FWLB Implementation
In this example, traffic between the redundant Alteon Application Switches is load balanced
among the available firewalls.
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 a
mathematical 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.
Subnet 1 Subnet 2 Subnet 3 Subnet 4
Internet
Routers
Simple
Switches
Simple
Switches
Firewalls
Secondary
Alteon Application
Switch
Primary Primary
Secondary
Alteon Application
Switch Servers
1
2
3
1. VRRP forces incoming traffic to converge on primary dirty-side application switch
2. Firewall load balancing occurs between primary application switches
3. Primary clean-side application switch performs standard SLB
315394-J, January 2005
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 same
firewall 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.
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 switchs configuration with the second-
ary.
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
Router
195.1.1.1
Router
195.1.1.2
Firewall #1
Dirty: 10.10.2.3
Clean: 10.10.3.3
Firewall #2
Dirty: 10.10.2.4
Clean: 10.10.3.4
10.10.4.20
10.10.4.21
10.10.4.22
Alteon Application
Switch #3
IF1: 10.10.4.10/24
IF2: 10.10.3.1/24
IF3: 10.10.3.2/32
VIP: 10.10.4.100 (VSR)
Alteon Application
Switch #4
IF1: 10.10.4.11/24
IF2: 10.10.3.11/24
IF3: 10.10.3.12/32
VIP: 10.10.4.100 (VSR)
Alteon Application
Switch #1
IF1: 195.1.1.10/24
IF2: 10.10.2.1/24
IF3: 10.10.2.2/32
Alteon Application
Switch #2
IF1: 195.1.1.11/24
IF2: 10.10.2.11/24
IF3: 10.10.2.12/32
VIR
195.1.1.9
VIR
10.10.2.9
VIR
10.10.3.9
VIR
10.10.4.9
25
25
25
26
26 26
28
28
28
28
Primary
Primary
Secondary Secondary
315394-J, January 2005
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 application
switch.
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)
315394-J, January 2005
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:
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.
Table 2 Four-Subnet Firewall IP Address Configuration
Item Address
Firewall 1
Dirty-side IP interface
Clean-side IP interface
Default Gateway
Route Added
10.10.2.3
10.10.3.3
10.10.2.9 (Subnet 2 VIR)
10.10.4.100 (virtual server) via 10.10.3.9 (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)
315394-J, January 2005
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 (IFs) 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.
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/l2/vlan 2
>> # add 26 (Port 26 connects to the firewall)
>> # add 28 (Port 28 is the inter-switch
connection)
>> # ena
>> # /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
315394-J, January 2005
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:
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.
>> # /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
>> # apply
>> # save
>> # /boot/reset
315394-J, January 2005
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.
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/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
>> # /cfg/l3/if 3
>> # mask 255.255.255.255
>> # addr 10.10.2.12
>> # vlan 2
>> # ena
>> # 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
315394-J, January 2005
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.
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.
>> # apply
>> # save
>> # /boot/reset
>> # /cfg/l2/vlan 3
>> # add 25
>> # add 28
>> # ena
>> # /cfg/l2/vlan 4
>> # add 26
>> # ena
>> # /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
315394-J, January 2005
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:
Configure Connectivity for the Secondary Clean-Side Switch
1. Configure VLANs on the secondary clean-side application switch.
>> # 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
>> # /boot/reset
>> # /cfg/l2/vlan 3
>> # add 25
>> # add 28
>> # ena
>> # /cfg/l2/vlan 4
>> # add 26
>> # ena
315394-J, January 2005
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.
4. Configure static routes on the secondary clean-side application switch.
>> # /cfg/l3/if 1
>> # mask 255.255.255.0
>> # addr 10.10.4.11
>> # vlan 4
>> # ena
>> # /cfg/l3/if 2
>> # mask 255.255.255.0
>> # addr 10.10.3.11
>> # vlan 3
>> # ena
>> # /cfg/l3/if 3
>> # mask 255.255.255.255
>> # addr 10.10.3.12
>> # vlan 3
>> # ena
>> # 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
>> # /boot/reset
315394-J, January 2005
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.
In this example, the secondary application switch is configured to use primary dirty-side inter-
face 1 as its peer.
>> # ping 10.10.2.1
Response; 10.10.2.1: #1 OK, RTT 1 msec.
>> # ping 10.10.2.2
>> # ping 10.10.2.11
>> # ping 10.10.2.12
>> # /cfg/l3/vrrp/on
>> # /cfg/slb
>> # on
>> # sync/peer 1
>> # addr 195.1.1.10
>> # ena
>> # apply
>> # save
315394-J, January 2005
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
lower firewall. Therefore, the first address will represent the primary clean-side IF 2, and the
second 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 maintained
for their duration (persistence).
>> # /cfg/slb
>> # on
>> # sync/peer 1
>> # addr 10.10.4.10
>> # ena
>> # apply
>> # save
>> # /cfg/slb
>> # on
>> # real 1
>> # rip 10.10.3.1
>> # ena
>> # rip 10.10.3.2
>> # ena
>> # add 1
>> # add 2
>> # metric hash
315394-J, January 2005
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.
>> # dip 195.1.1.0
>> # dmask 255.255.255.0
>> # ena
>> # dip 224.0.0.0
>> # dmask 255.255.255.0
>> # ena
>> # action redir
>> # group 1
>> # ena
>> # /cfg/slb/port 1
>> # filt ena
>> # add 10
>> # add 20
>> # add 2048
315394-J, January 2005
3. Configure VRRP on the primary dirty-side application switch.
VRRP in this example requires two virtual routersone for the subnet attached to the routers,
and one for the subnet attached to the firewalls.
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.
>> # /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
>> # ifs ena
>> # ports ena
>> # /cfg/slb/sync
>> # prios d
>> # peer 1
>> # ena
>> # addr 195.1.1.11
>> # apply
>> # save
>> # /oper/slb/sync
315394-J, January 2005
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.
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.
>> # /cfg/slb
>> # on
>> # real 1
>> # rip 10.10.2.1 (IF2 of the primary dirty-side application switch)
>> # ena
>> # rip 10.10.2.2 (IF2 of the primary dirty-side application switch)
>> # ena
>> # add 1
>> # add 2
>> # metric hash
315394-J, January 2005
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:
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.
>> # /cfg/slb (Select the SLB menu)
>> # real 20 (Select real server 20)
>> # rip 10.10.4.20 (Set IP address of real server 20)
>> # ena (Enable)
>> # /cfg/slb/real 21 (Select real server 21)
>> # ena (Enable)
>> # /cfg/slb/real 22 (Select real server 22)
>> # ena (Enable)
>> # add 20 (Add the real servers to the group)
>> # add 21
>> # add 22
>> # metric leastconns (Select least connections as 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)
>> # 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)
315394-J, January 2005
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.
>> # dip 10.10.4.0
>> # dmask 255.255.255.0
>> # ena
>> # dip 224.0.0.0
>> # dmask 255.255.255.0
>> # ena
>> # action redir
>> # group 1
>> # ena
>> # filt ena
>> # add 10
>> # add 20
>> # add 2048
315394-J, January 2005
4. Configure VRRP on the primary clean-side application switch.
VRRP in this example requires two virtual routers to be configuredone for the subnet attached
to the real servers, and one for the subnet attached to the firewalls.
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.
>> # /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
>> # vrid 4
>> # addr 10.10.3.9
>> # if 2
>> # prio 101
>> # share dis
>> # ena
>> # track
>> # ifs ena
>> # ports ena
>> # 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
315394-J, January 2005
7. Synchronize primary and secondary dirty-side application switches for the VRRP config-
uration.
>> # apply
>> # save
>> # /oper/slb/sync
315394-J, January 2005
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.
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
Internet
Firewall 1
Firewall 2
Servers
Alteon Application
Switch 1
IF1: 192.16.12.1
Alteon Application
Switch 2
IF1: 20.1.1.1
Virtual Server:
20.1.1.10
20.1.1.2
20.1.1.3
Dirty Side:
10.1.2.10
IF2: 10.1.1.1
IF3: 10.1.2.1
IF2: 10.1.3.1
IF3: 10.1.4.1
Dirty Side:
10.1.1.10
Clean Side:
10.1.4.10
Clean Side:
10.1.3.10
1
2
3
2
3
4
5
315394-J, January 2005
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.
NOTE Some metrics allow other options (such as weights) to be configured.
>> # /cfg/slb/port 4/rem 2048
>> # filt ena
>> # filt ena
>> # metric <metric type>
315394-J, January 2005
Free-Metric with Four-Subnet FWLB
For this example, review the four-subnet example network.
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:
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
Router
195.1.1.1
Router
195.1.1.2
Firewall #1
Dirty: 10.10.2.3
Clean: 10.10.3.3
Firewall #2
Dirty: 10.10.2.4
Clean: 10.10.3.4
10.10.4.20
10.10.4.21
10.10.4.22
Alteon Application
Switch #3
IF1: 10.10.4.10/24
IF2: 10.10.3.1/24
IF3: 10.10.3.2/32
VIP: 10.10.4.100 (VSR)
Alteon Application
Switch #4
IF1: 10.10.4.11/24
IF2: 10.10.3.11/24
IF3: 10.10.3.12/32
VIP: 10.10.4.100 (VSR)
Alteon Application
Switch #1
IF1: 195.1.1.10/24
IF2: 10.10.2.1/24
IF3: 10.10.2.2/32
Alteon Application
Switch #2
IF1: 195.1.1.11/24
IF2: 10.10.2.11/24
IF3: 10.10.2.12/32
VIR
195.1.1.9
VIR
10.10.2.9
VIR
10.10.3.9
VIR
10.10.4.9
25
25
25
26
26 26
28
28
28
28
Primary
Primary
Secondary Secondary
315394-J, January 2005
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.
>> # filt ena
>> # metric <metric type>
315394-J, January 2005
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. A
typical firewall load balancing configuration with a DMZ is shown in Figure 19-10.
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.
Firewalls
DMZ
Alteon Application
Switches
Internet
Private
Network
Note: There can be
one or two DMZs.
Alteon Application
Switches
315394-J, January 2005
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.
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 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 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)
>> 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)
>> SLB Port 1# save
315394-J, January 2005
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 it
across 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 to
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 the
Server 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
315394-J, January 2005
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 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/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)
>> # /cfg/slb/port #/add 2048 (Add the dummy filter)
315394-J, January 2005
609
CHAPTER 20
Virtual Private Network Load
Balancing
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 server
from 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
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.
315394-J, January 2005
610 Chapter 20: Virtual Private Network Load Balancing
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 the
source and destination address, because the address may be encrypted inside the datagram.
Also, the source/destination IP address of the packet may change as the packet traverses from
the dirty-side switches to clean-side switches and back.
To support VPN load balancing, the 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).
315394-J, January 2005
Chapter 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.
Clean Side
Dirty Side
Client
Alteon Application
Switch 1
VPN 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 DIP 5
SMAC 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 software
D3 = Cluster IP address of the VPN devices
E10 = IP address of the Real server
315394-J, January 2005
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.
Figure 20-2 VPN Load-Balancing Configuration Example
>> # /cfg/slb/port <port number>/rts ena
1
25
26
1
25
25
25
1
1
26
26
26
VPN Device 1
Client:
192.168.10.100
Default Gateway:
192.168.10.50
IF 1 = 192.168.10.10/24
IF 2 = 10.0.0.10/24
IF 3 = 10.0.0.11/32
IF 1 = 30.0.0.10/24
IF 2 = 20.0.0.10/24
IF 3 = 20.0.0.11/32
IF 1 = 30.0.0.11/24
IF 2 = 20.0.0.20/24
IF 3 = 20.0.0.21/32
IF 1 = 192.168.10.11/24
IF 2 = 10.0.0.20/24
IF 3 = 10.0.0.21/32
VPN Device 2
IF 1 = 10.0.0.101
IF 2 = 20.0.0.101
IF 1 = 10.0.0.102
IF 2 = 20.0.0.102
Mgmt. Server:
30.0.0.100
VIR
192.168.10.50
VIR
10.0.0.1
VIR
20.0.0.1
VIR
30.0.0.50
Alteon Application
Switch DA
Alteon Application
Switch DB
Alteon Application
Switch CA
Alteon Application
Switch CB
L2 Switch L2 Switch
Internal network:
30.0.0.0./2
Default Gateway:
30.0.0.50
Static Routes
(Both Dirty Web Switches):
20.0.0.10 via 10.0.0.101 IF 2
20.0.0.11 via 10.0.0.102 IF 3
20.0.0.20 via 10.0.0.101 IF 2
20.0.0.21 via 10.0.0.102 IF 3
Static Routes:
(Both Clean Web Switches)
20.0.0.10 via 10.0.0.101 IF 2
20.0.0.11 via 10.0.0.102 IF 3
20.0.0.20 via 10.0.0.101 IF 2
20.0.0.21 via 10.0.0.102 IF 3
VPN Static Routes
(Both VPN Devices)
Default via 10.0.0.1
30.0.0.0/24 via 20.0.0.1
Cables:
Straight-through
Crossover
315394-J, January 2005
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).
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)
315394-J, January 2005
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# add 10.0.0.20 (Enter destination IP address)
>> IP Static Route# add 10.0.0.21 (Static route destination IP address)
315394-J, January 2005
6. Configure VRRP for virtual routers 1 and 2.
7. Enable Server Load Balancing (SLB) on the first clean switch.
8. Configure real servers for health checking VPN devices.
>> # /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)
>> # /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)
315394-J, January 2005
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.
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.
>> # /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
>> # save
>> # /boot/reset
315394-J, January 2005
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 VPN
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.
7. Enable SLB.
>> # /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/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
>> Virtual Router Redundancy Protocol# vr 1
>> VRRP Virtual Router 1# share dis
>> VRRP Virtual Router 1# track/vrs ena
>> VRRP Virtual Router 1 Priority Tracking# /cfg/l3/vrrp/vr 2
>> VRRP Virtual Router 2# 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
315394-J, January 2005
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-DA
1. Turn off BOOTP.
3. Turn off STP.
4. Configure IP interfaces 1, 2, and 3.
>> 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# save
>> SLB port 25# /boot/reset
315394-J, January 2005
5. Define static routes for each of the IP interfaces you configured in Step 4, using the VPN
One static route is required for each VPN device being load balanced.
7. Enable SLB.
8. Configure real servers for health-checking VPN devices.
>> # /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
>> Virtual Router Redundancy Protocol# /cfg/l3/vrrp/vr 1
>> VRRP Virtual Router 1# prio 101
>> 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# prio 101
>> 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
315394-J, January 2005
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.
12. Create a filter to allow the management firewall (Policy Server) to reach the VPN firewall.
>> 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
>> # ena
>> # sip any
>> # dip 192.168.10.0/dmask 255.255.255.0
>> # action allow
>> # ena
>> # sip any
>> # dip 224.0.0.0/dmask 255.0.0.0
>> # action allow
>> # ena
>> # sip any
>> # 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
>> # filt ena
>> # add 100/add 110/add 2048
315394-J, January 2005
Configure the Second Dirty-Side Application Switch-DB
1. Turn off BOOTP.
3. Turn off STP.
4. Configure IP interfaces 1, 2, and 3.
5. Configure routes for each of the IP interfaces you configured in Step 4.
>> # apply
>> # save
>> # /boot/reset
>> # /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
315394-J, January 2005
7. Enable SLB.
9. Enable the real server group, and place real servers 1-4 into the real server group.
>> # ena
>> # vrid 1
>> # if 1
>> # addr 192.168.10.50
>> # share dis
>> # track
>> # vrs ena
>> # ports ena
>> # ena
>> # vrid 2
>> # if 2
>> # addr 10.0.0.1
>> # share dis
>> # track
>> # vrs ena
>> # ports ena
>> # /cfg/slb/on
>> # /cfg/slb/real 1/ena/rip 20.0.0.10
>> # metric hash
>> # add 1/add 2/add 3/add 4
315394-J, January 2005
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.
13. Apply and save the configuration and reboot the switch.
>> # ena
>> # sip any
>> # dip 192.168.10.0/dmask 255.255.255.0
>> # ena
>> # sip any
>> # dip 224.0.0.0/dmask 255.0.0.0
>> # ena
>> # sip any
>> # dip any
>> # proto any
>> # action redir
>> # /cfg/slb/filt 2048/adv
>> # fwlb ena
>> # filt ena
>> # add 100/add 110/add 2048
>> # apply
>> # save
>> # /boot/reset
315394-J, January 2005
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.
NOTE To help simplify the logs, the health checks are not logged.
>> # /info/slb/dump (Verify which servers are up)
315394-J, January 2005
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.
Enter vpnuser for user name and alteon for the password.
315394-J, January 2005
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
address). VPN Device 1 and VPN Device 2 belong to one cluster IP.
315394-J, January 2005
627
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
Using Border Gateway Protocol for GSLB on page 667
Verifying GSLB Operation on page 668
315394-J, January 2005
628 Chapter 21: Global Server Load Balancing
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 switchs 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.
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 only
DSSP 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.
315394-J, January 2005
Chapter 21: Global Server Load Balancing 629
Migrating Old GSLB Configurations into
Alteon 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
GSLB Overview
GSLB allows balancing server traffic load across multiple physical sites. The Alteon GSLB
implementation takes into account an individual sites health, response time, and geographic
location to smoothly integrate the resources of the dispersed server sites for complete global
performance.
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 sites health status changes.
This ensures that each active site has valid state knowledge and statistics. DSSP v1.0 and
DSSP v2.0 are supported.
GSLB implementation takes geography as well as network topology into account.
Creative control is given to the network administrator or Webmaster to build and control
content by user, location, target application, and more.
GSLB is easy to deploy, manage, and scale. Switch 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.
315394-J, January 2005
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.
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 clients DNS asks its upstream DNS, which in turn asks the next, and so on, until the
address is resolved.
Eventually, the request reaches an upstream DNS server that has the IP address information
available or the request reaches one of the Example, Inc. DNS servers.
Internet
Switches regularly exchange performance information
Example Site 1:San Jose Example Site 2: Denver
Client Site
DNS
DNS
Web
Servers
Web
Servers
DNS
Alteon
Application
Switch
Alteon
Application
Switch
Best Service!
4
3
2
1
5
DNS response
lists best site's
IP address first
DNS
Request HTTP
Request
315394-J, January 2005
3. The Example Inc.s San Jose DNS tells the local DNS to query the Alteon Application
Switch 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 clients 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-
ents 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. Denvers virtual server IP address first when responding to the
DNS request.
5. The client connects to Example Inc. Denver for the best service.
The clients Web browser will use the IP address information obtained from the DNS request
to open a connection to the best available site. The IP addresses represent virtual servers at any
site, which are locally load balanced according to regular SLB 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 to
another 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
GSLB Enhancements
GSLB has been enhanced with the following new features in Alteon OS 22.0.
Distributed Site Selection Protocol version 2DSSP 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 Tablesupports 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/domaineach 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 processingseveral new met-
rics have been added for rule-based processing, as described in GSLB Metrics on page
633.
Prioritization and weighting of GSLB metricsselection 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 (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.
315394-J, January 2005
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 thresholdThis 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 preferenceThis 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
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 timeThis 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 distri-
bution of the servers.
315394-J, January 2005
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 IP
address and domain name. The hash calculation uses only the servers that are available for
the domain. The server selected may be affected when a server become available or not
available since the hash calculation uses only the servers that are available.
DNS localThis metric selects the local virtual server only when the local virtual server
is available. This metric applies to DNS-based GSLB only.
DNS alwaysThis metric selects the local virtual server even though the local virtual
server is not available. This metric applies to DNS-based GSLB only.
RemoteThis metric selects the remote real servers only. This metric was introduced in
Alteon OS 21.0.5.
315394-J, January 2005
Metric preferences
This 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
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.
315394-J, January 2005
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.
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.
315394-J, January 2005
Basic GSLB Requirements
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
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.
San JoseSite 1 DenverSite 2
200.200.200.X Network 174.14.70.X Network
Web Servers:
200.2.2.10
200.2.2.20
VLAN 201
Web Servers:
174.40.7.11
174.40.7.21
VLAN 202
10
20 21
11
IP Interface 101
200.200.200.1
VIP: 200.200.200.100
VLAN 101
IP Interface 201
200.2.2.201
VLAN 201
IP Interface 102:
174.14.70.2
VIP: 174.14.70.200
VLAN 102
IP Interface 202
174.40.7.202
VLAN 202
Internet
Alteon 2424 GSLB 1 Alteon 2424 GSLB 2
DNS Server
Default GW
200.200.200.101
Default GW
174.14.70.101
DNS Server
315394-J, January 2005
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)
Current status: disabled
New status: enabled
315394-J, January 2005
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.
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:
>> # /cfg/l2/vlan 201/name servers (VLAN 201 for local servers)
New status: enabled
>> IP Interface 201# mask 255.255.255.0 (Assign network mask)
>> IP Interface 201# vlan 201 (Assign interface to VLAN 201)
>> 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)
315394-J, January 2005
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 each
distributed 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:
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.
>> # apply
>> # save
Table 21-1 GSLB Example: San Jose Real Server IP Addresses
Server 10 200.2.2.10
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)
315394-J, January 2005
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.
5. On the San Jose switch, define the type of Layer 4 traffic processing each port must sup-
port.
>> 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 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)
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
315394-J, January 2005
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
and enable the remote switchs Internet-facing IP interface address. In this example, there is
only one remote site: Denver, with an IP interface address of 74.14.70.2. The following 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.
>> SLB port 6# /cfg/slb/on
>> Virtual server 1# /cfg/slb/gslb/on
>> # /cfg/slb/gslb/version 2 (Enable DSSP version 2 updates)
>> # /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)
315394-J, January 2005
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
2s vip address, rather than the usual IP address of a local physical server. Do not confuse this
value with the IP interface address on the remote switch.
Also, the remote parameter is enabled, and the real server entry is added to the real server
group under the local virtual server for the intended service. Finally, since the real server
health checks are performed across the Internet, the health-checking interval should be
increased to 30 or 60 seconds to avoid generating excess 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
on each virtual server.
In this example, the domain name for the Example Inc. is gslb.example.com, and the host
name for the only service (HTTP) is www. These values are configured as follows:
To define other services (such as FTP), make additional hostname entries.
>> # /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)
>> Virtual server 1# dname gslb.example.com (Define domain name)
>> Virtual server 1# service 80/hname www (Define HTTP host name)
315394-J, January 2005
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)
315394-J, January 2005
Task 4: Configure the Basics at the Denver Site
Following 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)
New status: enabled
315394-J, January 2005
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.
9. Configure the local DNS server to recognize the local GSLB switch as the authoritative
>> # /cfg/l2/vlan 202/name servers (VLAN 202 for local servers)
>> VLAN 202# add 11/ena (Add port 11 to vlan 202)
New status: enabled
>> Default gateway 1# addr 174.14.70.101 (Assign IP address for the gateway)
>> # apply
>> # save
315394-J, January 2005
distributed 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.
4. On the Denver switch, define a virtual server.
Table 21-3 Denver Real Server IP Addresses
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)
>> 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 http service# group 1 (Associate virtual port to real group)
>> Virtual server 1 http service# /cfg/slb/virt 1/ena(Enable the virtual
server)
315394-J, January 2005
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)
>> # /cfg/slb/on
315394-J, January 2005
Task 6: Configure the Denver Site for GSLB
Following 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 switchs IP address interface. In this example, there is only one remote site:
San Jose, with an IP interface address of 200.200.200.1. The following commands are used:
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
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 one
virtual 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.
>> 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)
315394-J, January 2005
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:
Examine the resulting information. If any settings are incorrect, make and apply any appropri-
ate changes, and then check again.
>> 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)
>> 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)
315394-J, January 2005
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-
dors 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
Figure 21-3 GSLB Topology Example 2with Standalone GSLB
San Jose SLB Site 1 Denver SLB Site 2
200.200.200.X Network 174.14.70.X Network
Web Servers:
200.2.2.10
200.2.2.20
VLAN 201
Web Servers:
174.40.7.11
174.40.7.21
VLAN 202
10
20 21
11
IP Interface 101
200.200.200.1
VIP: 200.200.200.100
VLAN 101
IP Interface 201
200.2.2.201
VLAN 201
IP Interface 102:
174.14.70.2
VIP: 174.14.70.200
VLAN 102
IP Interface 202
174.40.7.202
VLAN 202
Alteon 2424 SLB 1 Alteon 2424 SLB 2
Internet
DNS Server
Default GW
200.200.200.101
Default GW
174.14.70.101
DNS Server
Tokyo GSLB
43.10.10.X Network
IP Interface
43.10.10.3
VLAN 103
Standalone
Alteon 2424 GSLB
Default GW
43.10.10.103
DNS Server
315394-J, January 2005
Task 1: Configure the Basics at the Tokyo Site
Following a similar procedure as described in Configuring Basic GSLB on page
637, configure a third siteTokyoin 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)
New status: enabled
>> Default gateway 1# addr 43.10.10.103 (Assign IP address for the gateway)
>> # apply
>> # save
315394-J, January 2005
6. Configure the local DNS server to recognize the local GSLB switch as the authoritative
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 GSLB
Following 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.
NOTE Take care to note where each configured value originates, or this step can result in
>> # /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)
>> 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)
>> # /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)
315394-J, January 2005
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)
315394-J, January 2005
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 is
selected before any subsequent metric is used to select other servers.
3. Geographical preference
The third metric in rule 1 is set to Geographical Preference so that the IANA-defined geo-
graphical region based on the client source IP is used to redirect the request to the clients
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
315394-J, January 2005
The last metric in rule 1 should be configured as dnsalways so that the GSLB selection
selects at least the local virtual server when all servers are not available. In this case, metric 6
can be 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.
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 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)
>> # /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
315394-J, January 2005
Task 2: Configure the second time-based rule
Using 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
315394-J, January 2005
Using the Availability Metric in a Rule
The availability metric selects the next server in a priority list when any capacity thresholds of
the previous servers has been reached.
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
315394-J, January 2005
Configuring GSLB Network Preference
Alteon 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.
315394-J, January 2005
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 Bs requests are always forwarded to Sites 2
or 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.
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
VIP: 2.2.2.100
IF: 3.3.3.3 / 16
VIP: 3.3.3.100
IF: 4.4.4.4 / 24
VIP: 4.4.4.100
Web
Servers
Web
Servers
DNS DNS
DNS DNS
Alteon Application
Switch
Site 3 Site 2
Site 4 Site 1
Web
Servers
Web
Servers
Alteon Application
Switch
Alteon Application
Switch
Alteon Application
Switch
Master switch returns
Client's request with the
VIP of the preferred site
2. The master switch looks through its
network preference rule, and responds to
the 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 3
Prefers
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.
315394-J, January 2005
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)
315394-J, January 2005
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 redirection
function 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.
315394-J, January 2005
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.
Figure 21-5 HTTP and Non-HTTP Redirects
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 1s 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 2s
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.
1a
2a
1b
Client Site
Client Request
Site 1
Web
Servers
Web
Servers
DNS
Alteon Application
Switch
Alteon Application
Switch
Site 2
HTTP Applications
Non HTTP Applications
Proxy IP address is
configured on Client
port for non-HTTP
applications.
DNS
2b
315394-J, January 2005
How Proxy IP Works
Figure 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.
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 1s 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 1s virtual server IP
address as the source IP address, and Site 2s proxy IP address as the destination IP
address.
Proxy Disabled For
Local Real Servers
Proxy Enabled For
Remote Server
San Jose Site #1
174.14.70.X Network
A
B
C
D
Proxy Disabled For
Local Real Servers
Proxy IP Address
174.14.70.4
Proxy IP Address
200.200.200.4
Internet
200.200.200.X Network
HTTP/POP3
Local Servers
200.200.200.2
200.200.200.3
Remote Server
174.14.70.1
Alteon
Application
Switch
Virtual Server
200.200.200.1
Denver: Site #2
HTTP/POP3
Local Servers
174.14.70.2
174.14.70.3
Remote Server
200.200.200.1
Virtual Server
174.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 For
Remote Server
6 4
315394-J, January 2005
6. The switch at Site 1 receives the frame and translates it, using Site 1s virtual server IP
address as the source IP address and the clients IP address as the destination IP address.
This cycle continues for the remaining frames to transmit all the clients mail, until a FIN
frame is received.
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)
>> # /cfg/slb/port 4/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 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)
315394-J, January 2005
Using Border Gateway Protocol for GSLB
Border Gateway Protocol (BGP)-based GSLB utilizes the Internets 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 Providers (ISPs) network and is then advertised,
using BGP, throughout the Internet.
Because of the way IP routing works, BGP-based GSLB allows for the routing protocols to
route DNS requests to the closest location, which then returns IP addresses of that particular
site, locking in the requests to that site. In effect, the Internet is making the decision of the best
location for you, avoiding the need for advanced GSLB.
Some corporations use more than one ISP as a way to increase the reliability and bandwidth of
their Internet connection. Enterprises with more than one ISP are referred to as being multi-
homed. Instead of multi-homing a network to several other networks, BGP-based GSLB
enables you to multi-home a particular piece of content (DNS information) to the Internet by
distributing the IP blocks that contain that content to several sites.
When using DNS to select the site, a single packet is used to make the decision so that the
request will not be split to different locations. Through the response to the DNS packet, a client
is locked in to a particular site, resulting in 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 the
GSLB 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.
315394-J, January 2005
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 information
again.
Examine the /stats/slb and /stats/slb/gslb statistics on each switch.
315394-J, January 2005
669
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 2005
670 Chapter 22: Bandwidth Management
Enabling Bandwidth Management
To use the bandwidth management features, you must purchase an additional software license
and password key. Instructions for obtaining a password key are provided with your software
license 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 switchs MAC
address, the switch will accept the password, permanently record it in the switchs non-volatile
RAM (NVRAM), and will then enable the feature.
315394-J, January 2005
Chapter 22: Bandwidth Management 671
Contracts
A 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 2005
When Virtual Matrix Architecture (VMA) is enabled, traffic classification is done on the
ingress portthat is, the port on which the frame is received (not the client port or the server
port). If the 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
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

Internet
1. A client accesses a
site's VIP address
2. The VIP address has been
assigned a bandwidth contract
and 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
Alteon Application
Switch
315394-J, January 2005
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-
tiona 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 #15, 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.
315394-J, January 2005
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
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 14 are part of a contract group, the Total hard limit allowed for the group in this
example is 100 Mbps.
315394-J, January 2005
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 limitsContracts 1 and 4.
Contract 1 requests 15 Mbps, which is 5 Mbps over its hard limit. Because Contract 1
requested 5 of the 25 Mbps BW over the total BW Hard Limit for the contract group, it
will thus receive one-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
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.
10
Adjusted Hard Limit 12 20 20 48 100
(All units in Mbps)
x10 2 = x10 8 =
315394-J, January 2005
The soft and reserved (CIR) limits of each contract are not part of the grouped contracts calcu-
lation, and remain set at their individual contracts 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 that
can 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 users IP
address, monitoring the amount of bandwidth used per second, and dropping any traffic that
exceeds the configured limit. In order to monitor a users bandwidth, the switch creates a user
entry that records the source or destination IP address, and the amount of bandwidth used. This
user entry is called an IP user entry, because the user is 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 contracts
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 contracts 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
315394-J, January 2005
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 kbpsand traffic for a user (IP address) is egressing port 1 (SP 1) and 20 (SP
2) that user (IP address) will be restricted to 64 kbps egressing on port 1 and 64 kbps 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, as
described below.
Bandwidth Policy Index
Each BWM contract is assigned a bandwidth policy index and (optionally) a name. This index
can be viewed using the /cfg/bwm/cont menu. Contracts can be enabled and disabled. The
set of 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.
315394-J, January 2005
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 switchs 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.
315394-J, January 2005
Rate Limiting
A 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 switchthat is, the port
from which the frame is leaving. However, in the case of multiple routes or trunk groups, the
egress port can actually be one of several ports (from the point-of-view of where the queues are
located).
Hard Limit
Soft Limit
Reserved Limit
User Limit
315394-J, January 2005
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 on
the 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
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.
315394-J, January 2005
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 contracts 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
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 ISPs 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-
315394-J, January 2005
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.
Bandwidth Management Information
Statistics are stored in the individual Switch Processors (SP) and then collected every second
by the MP (Management Processor). The MP then combines the statistics, as statistics for
some classifications may be spread across multiple SPs.
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.
315394-J, January 2005
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
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:
/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)
315394-J, January 2005
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 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.
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 more
information 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.
Specific configuration examples begin on page 688.
1. Configure the switch as you normally would for SLB. Configuration includes the follow-
ing tasks:
315394-J, January 2005
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 policy
underlimit and overlimit.
There are two parameters for specifying the TOS bits: underlimit (utos) and overlimit
(otos). These TOS values are used to overwrite the TOS values of IP packets if the 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).
>> # /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)
315394-J, January 2005
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
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.
>> 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)
>> BWM Contract 1# wtos ena (Enables TOS overwriting for
contract)
>> BWM Contract 1# pol 1 (Assign policy 1 to BWM contract 1)
315394-J, January 2005
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. 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.
>> 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)
>> Bandwidth Management# /info/bwm <contract number>(View BWM information)
>> Bandwidth Management# /stats/bwm <contract number>(View BWM statistics)
315394-J, January 2005
Additional BWM Configuration Examples
Examples 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: page
710
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
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.
315394-J, January 2005
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.
8. On the switch, select the second BWM contract and name the contract.
>> # /cfg/bwm/pol 1 (Select BWM policy 1)
>> 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)
>> BWM Contract 2# name broadband (Assign contract name broadband)
315394-J, January 2005
11. Assign the BWM contracts to different switch ports.
Physical switch ports are used to classify which frames are managed by each contractthat is,
one BWM contract will be applied to all frames from a specific port. The second contract will
be applied to all frames from another specified port.
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.
>> 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)
315394-J, January 2005
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 the
member 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 contracts share in the group. In effect, the contract with only 10 Mbps may
be allowed at times to share any unused resources in the group and burst up to a higher hard
limit. If that contract is removed from the group, then the contract will revert to its individual
hard limits, and any 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.
4. Configure BWM contract 1.
>> /cfg/bwm/on
>> Policy 1# hard 10M (Set never exceed rate)
>> Policy 1# soft 5M (Set desired bandwidth rate)
>> Policy 1# resv 1M (Set committed information rate)
315394-J, January 2005
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)
315394-J, January 2005
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 apply
policy 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 contractthat 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.
18. Check the BWM information.
>> 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.
>> Port 2# apply (Make your changes active)
>> Port 2# /cfg/bwm/cur (View current BWM settings)
315394-J, January 2005
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 students IP address, the egress port number, and the contract
number, as well as the number of octets transferred for that second. The session updates
the number of octets being transferred every second, thus maintaining 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)
/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)
315394-J, January 2005
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.
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:
/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
315394-J, January 2005
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# /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)
315394-J, January 2005
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)
>> 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)
315394-J, January 2005
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
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
>> 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)
315394-J, January 2005
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 management
feature.
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
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.
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
315394-J, January 2005
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
5. Assign BWM contracts to each string using the syntax shown:
>> 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
ID SLB String BWM
Contract
1 any 4
2 .gif 1
3 .jpg 1
4 .cgi 2
5 .bin 2
6 .exe 2
7 .html 3
>> Main# /cfg/slb/layer7/slb/cont <String ID> <BWM Contract number>
315394-J, January 2005
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 you
enter 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:
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.
>> Server Load Balance Resource# cur
1: any, cont 4
2: .gif, cont 1
3: .jpg, cont 1
4: .cgi, cont 2
5: .bin, cont 2
6: .exe, cont 2
7: .html, cont 3
>> # /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)
315394-J, January 2005
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
315394-J, January 2005
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.
>> # /cfg/slb/virt 1/service 80
>> Virtual Server 1 http Service# httpslb cookie ena
Enter the starting point of the cookie value [1-64]: 1
Enter the number of bytes to be extract [1-64]: 8
Look for cookie in URI [e|d]: d
Internet
Proxy Firewall
Client #1
Alteon Application
Switch
Client #2
First
Business
For Virtual IP address: 172.17.1.1
First = 2 Mbs
Business = 1 Mbs
315394-J, January 2005
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/adv/direct dis
>> # /cfg/slb/pip
>> Proxy IP Address# add 12.12.12.12
>> SLB Port 2# proxy ena
315394-J, January 2005
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 are
two 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:
1. Configure the string and assign contracts for the strings and services.
>> # /cfg/slb/on
Internet
Proxy 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
ir
s
t B
u
s
i
n
e
s
s
First = 3 Mbs
Business = 2 Mbs
315394-J, January 2005
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 define
a 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.
3. Set the hard, soft, and reserved rate limits for this policy in Kilobytes.
>> # /cfg/slb/virt 1/service 80/ urlcont <URL path ID> <BW Contract number>
>> Policy 1# hard 250k (Set never exceed rate)
>> Policy 1# soft 250k (Set desired bandwidth rate)
>> Policy 1# resv 250k (Set committed information rate)
315394-J, January 2005
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)
315394-J, January 2005
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 switchs 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.
2. Create a BWM contract that will contain the time policies.
!
CAUTIONWhen 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)
>> /cfg/bwm/cont 1
315394-J, January 2005
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 all
other 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 weekday
Current Time Policy Day: everyday
Pending new Time Policy Day: weekday
>> BW Contract 1 Time Policy 1# from 7am
Current Time Policy from hour: 12am
Pending new Time Policy from hour: 7am
>> BW Contract 1 Time Policy 1# to 7pm
Current Time Policy to hour: 12am
Pending new Time Policy to hour: 7pm
>> BW Contract 1 Time Policy 1# policy 1 (Assign highest BW policy to this
time policy)
>> BW Contract 1 Time Policy 1# ena
New 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 1
Current BW Contract: 256
New pending BW Contract: 1
315394-J, January 2005
Configuring Egress Bandwidth Tuning for Connections
to Lower Speed Networks
In 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)
315394-J, January 2005
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 Traffic
Management Users 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 Number
315397-J) and the Alteon Intelligent Traffic Management Users 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
frequently to verify if the policies are being enforced.
315394-J, January 2005
315394-J, January 2005
713
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 2005
714 Appendix A: Troubleshooting
Port Mirroring
Mirroring Individual Ports
The port mirroring feature in the Alteon OS allows you to attach a sniffer to a monitoring port
that is configured to receive a copy of all packets that are forwarded from the mirrored port.
Alteon OS enables you to mirror port traffic for all layers (Layer 2 - 7). Port mirroring can be
used as a troubleshooting tool or to enhance the security of your network. For example, an IDS
server can be connected to the monitor port to detect intruders attacking the network.
As shown in Figure A-1, port 19 is monitoring ingress traffic (traffic entering the switch) on
port 3 and egress traffic (traffic leaving the switch) on port 11. You can attach a device to port
19 to monitor the traffic on ports 3 and 11.
Figure A-1 Monitoring Ports
Figure A-1 shows two mirrored ports monitored by a single port. Similarly, you can have a sin-
gle or groups of
a mirrored port to a monitored port
many mirrored ports to one monitored port
a mirrored port on one or more vlans to a monitored port (see page 716)
many mirrored ports on one or more vlans to one monitored port (see page 716)
Alteon OS does not support a single port being monitored by multiple ports.
Ingress traffic is duplicated and sent to the mirrored ports before processing and egress traffic
is duplicated and sent to the mirrored ports after processing.
Ingress traffic
Egress traffic
11
3 19
Monitoring port
Mirrored ports
315394-J, January 2005
Appendix A: Troubleshooting 715
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 2005
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 commands
described 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 2005
Appendix A: Troubleshooting 717
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:
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.
>> # /info/slb/sess/cip 10.10.10.1
Printing Sessions for SP 1
1,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 0
1,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
1,01: 10.10.10.1 2595, 172.21.31.100 http -> 14308 10.20.1.3 http age 0
1,01: 10.10.10.1 2596, 172.21.31.100 http -> 14309 10.20.1.4 http age 0
1,01: 10.10.10.1 2597, 172.21.31.100 http -> 14310 10.20.1.3 http age 0
1,01: 10.10.10.1 2598, 172.21.31.100 http -> 14311 10.20.1.4 http age 0
1,01: 10.10.10.1 2599, 172.21.31.100 http -> 14339 10.20.1.3 http age 0
1,01: 10.10.10.1 2600, 172.21.31.100 http -> 14340 10.20.1.4 http age 0
1,01: 10.10.10.1 2601, 172.21.31.100 http -> 14367 10.20.1.3 http age 0
1,01: 10.10.10.1 2602, 172.21.31.100 http -> 14384 10.20.1.2 http age 10
1,01: 10.10.10.1 2603, 172.21.31.100 http -> 14385 10.20.1.3 http age 10
1,01: 10.10.10.1 2604, 172.21.31.100 http -> 14414 10.20.1.2 http age 10
>> Session Table Information#
315394-J, January 2005
315394-J, January 2005
719
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 2005
720 Appendix B: Layer 7 String Handling
Exclusionary String Matching for Real Servers
URL-based SLB and application redirection can match or exclude up to 128 strings. Examples
of strings are as follows:
/product, matches URLs that starts with /product.
product, matches URLs that have the string product anywhere in the URL.
You can assign one or more strings to each real server. When more than one URL string is
assigned to a real server, requests matching any string are redirected to that real server. There
is also a special string known as any that matches all content.
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 = cgi
string 2 = NOT cgi/form_A
string 3 = NOT cgi/form_B
As a result, all cgi scripts are matched except form_A and form_B.
Configuring Exclusionary URL String Matching
This 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:
Enable SLB.
315394-J, January 2005
Appendix B: Layer 7 String Handling 721
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 handle
any 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
1 any
2 test
3 /images
4 /product
>> Real Server 1 Layer 7 commands# addlb 2
>> Real Server 1 Layer 7 commands# exclude enable
315394-J, January 2005
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:
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.
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
315394-J, January 2005
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 Expressions
The regular expression feature is applicable to both path strings used for URL-based server
load balancing, and expression strings used for URL-based application redirection. 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
315394-J, January 2005
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,
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.
315394-J, January 2005
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 balanced
among 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
315394-J, January 2005
HTTP Host and URL SLB
The HTTP Host header takes precedence because it is specified first. Because and is the
operator, both a Host Header and URL string 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
Alteon Application
Switch
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
315394-J, January 2005
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 up
for 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 a
URL 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.asp
2. 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)
315394-J, January 2005
Configurable HTTP Methods
Various types of HTTP methods to be processed by the Alteon Application Switchs 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, and
enter 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 BCOPY
5 BMOVE 6 BDELETE 7 BPROPPATCH 8 COPY
9 CONNECT 10 DELETE 11 LINK 12 MKCOL
13 MOVE 14 OPTIONS 15 POLL 16 PUT
17 PROPFIND 18 PROPPATCH 19 SEARCH 20 SUBSCRIBE
21 TRACE 22 UNLINK
>> # /cfg/slb/layer7/slb/addmeth 2 (Add HTTP POST method)
315394-J, January 2005
729
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 Load
Balancing
A type of load balancing that operates differently from virtual server-based load balancing.
With this type of load balancing, requests are transparently intercepted and redirected to
a server group. Transparently means that requests are not 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
that of one of the real servers. Therefore, redirection-based load balancing is designed to
load balance devices that normally operate transparently in your networksuch as a fire-
wall, spam filter, or transparent cache.
315394-J, January 2005
730 : Glossary
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 switch
is 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 with
one 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 2005
: Glossary 731
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 didnt, 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
732 : Glossary
315394-J, January 2005
733
Index
Symbols
[ ]....................................................................... 28
Numerics
80 (port) ................................................... 639, 646
802.1Q VLAN tagging................................... 76, 77
A
accessing the switch
defining source IP addresses........................... 52
RADIUS authentication................................. 53
security........................................................ 49
using EMS................................................... 43
using the Browser-based Interface................... 45
using the CLI ............................................... 34
active cookie mode............................................ 527
active-active redundancy.................................... 484
configuration.............................................. 484
Server Load Balancing ................................ 486
synchronization .......................................... 512
active-standby redundancy ................................. 480
configuration.............................................. 481
administrator account........................................... 56
aggregating routes ............................................. 134
example..................................................... 141
allow (filtering) ................................. 184, 300, 332
Alteon EMS........................................................ 35
application health checking ................................ 438
application ports................................................ 192
application redirection................................ 334, 367
client IP address authentication ..................... 381
example with NAT...................................... 373
games and real-time applications................... 381
non cacheable sites ...................................... 381
non-HTTP redirects for GSLB...................... 663
proxies.................................... 370, 373 to 379
rport .................................................. 373, 380
See cache redirection
topologies .................................................. 371
Web-cache redirection example ......... 369 to 381
authenticating, in OSPF...................................... 157
authoritative name servers .................................. 631
autonomous systems (AS) .................................. 150
B
backup servers................................................... 201
bandwidth management
burst limit................................................... 684
configuration, general ....................... 671 to 687
configuration, preferential service ................. 695
configuration, security ................................. 706
configuration, user fairness........................... 688
content intelligent............................. 698 to 702
contracts ............................................ 674, 681
cookie-based .............................................. 703
data pacing................................................. 681
egress bandwidth tuning............................... 710
grouped contracts ........................ 674, 676, 690
operational keys.......................................... 670
overwriting TCP window............................. 710
precedence ................................................. 673
rate limiting................................................ 687
rate limiting timeslots .................................. 681
statistics and history .................................... 682
time policy ................................................. 678
315394-J, January 2005
734 : Index
configuration example708 to 709
traffic shaping .....................................681, 687
user limits....................................... 676 to 677
configuration example694 to 695
VMA.........................................................672
bandwidth managment
policies.......................................................677
bandwidth metric ...............................................198
bandwidth policies
rates...........................................................680
BBI
See Browser-Based Interface.........................151
blat ...........................................................544, 547
Border Gateway Protocol (BGP)..........................129
attributes ....................................................136
failover configuration...................................138
route aggregation.........................................134
route maps..................................................131
selecting route paths.....................................137
use with GSLB............................................667
Bridge Protocol Data Unit (BPDU) ......................101
broadcast domains............................75, 77, 80, 121
Browser-Based Interface.....151, 427, 512, 639, 646
C
cache redirection
browser-based.............................................392
delayed binding...........................................375
example......................................................371
HTTP header-based .....................................391
layer 7 traffic ..............................................382
RTSP.................................................376, 398
See application redirection
servers.................................... 369 to 371, 372
URL hashing...............................................393
URL-based .................................................383
CGI-bin scripts ..........................................187, 200
Cisco EtherChannel..............................................94
client traffic processing...............................187, 190
command conventions ..........................................28
Command Line Interface...............................34, 151
configuring
BGP failover .............................................. 138
cache redirection......................................... 371
cookie-based persistence.............................. 528
default filter ............................................... 336
delayed binding .......................................... 236
DNS load balancing .................................... 248
dynamic NAT............................................. 353
filter-based security..................................... 346
FTP Server Load Balancing ......... 240, 241, 246
IDS load balancing...................................... 279
IP load balancing ........................................ 239
IP routing................................................... 119
LDAP load balancing .................................. 244
multiple services......................................... 194
multi-response cookie search........................ 534
OSPF ........................................................ 164
port trunking ................................................ 93
proxy IP addresses ...................................... 223
RTSP cache redirection ............................... 377
server load balancing................................... 188
spanning tree groups.................................... 111
stateful failover........................................... 514
static NAT ................................................. 352
tunable hash for filter redirection................... 344
VLAN-based filters..................................... 340
WAP load balancing.................... 266, 268, 271
configuring WAN links
basic example............................................. 310
summary.................................................... 308
with SLB................................................... 320
connection time-out ........................................... 200
console port ........................................................ 34
content intelligent
contracts, bandwidth management....................... 674
cookie
active ........................................................ 527
different types ............................................ 525
expiration timer .......................................... 529
header ....................................................... 523
names........................................................ 524
passive mode.............................................. 526
permanent .................................................. 523
rewrite....................................................... 527
temporary .................................................. 523
values........................................................ 524
cookie-based persistence .................................... 522
315394-J, January 2005
: Index 735
D
data pacing ....................................................... 681
datagram........................................................... 610
default gateway................................................. 118
configuration example... 84, 120, 640, 647, 653
VLAN-based................................................ 81
default password ................................................. 56
default route
OSPF ........................................................ 155
delayed binding...................................... 234 to 236
denial of service protection...................... 544 to 564
deny (filtering) .................................. 184, 300, 332
detecting SYN attacks........................................ 236
dip (destination IP address for filtering)............... 337
Direct Access Mode (DAM)....................... 315, 325
direct real server access...................................... 228
Direct Server Return (DSR)................................ 228
disabling real servers ......................................... 193
Distributed Site State Protocol (DSSP) ................ 630
dmask
destination mask for filtering........................ 337
DNS load balancing........................................... 248
Domain Name Server................................. 318, 329
Domain Name System (DNS)
filtering ............................................. 345, 348
Global SLB (diagram) ................................. 631
load balancing, layer 4................................. 245
load balancing, layer 7................................. 250
round robin ........................................ 182, 299
dport (filtering option) ............................... 346, 374
DSSP. See Distributed Site State Protocol.
duplex mode for jumbo frames ............................. 85
dynamic NAT ................................................... 353
E
egress traffic ..................................................... 610
Element Management System (EMS) .................... 43
encrypt ............................................................. 610
End user access control
configuring .................................................. 67
EtherChannel ...................................................... 90
as used with port trunking.............................. 94
expiration timer, insert cookie............................. 529
external routing ......................................... 130, 150
F
failed server protection, SLB ...................... 182, 299
failover
active-active ............................................... 470
overview.................................................... 479
stateful....................................................... 513
fault tolerance
port trunking................................................. 92
Server Load Balancing......................... 186, 299
filter redirection
tunable hash ............................................... 344
filtering
configuration example ................................. 346
default filter........................................ 335, 346
IP address ranges ........................................ 337
layer 7 deny................................................ 363
NAT configuration example .............. 351 to 353
numbering.................................................. 336
order of precedence ............................. 334, 335
proto (option) ..................................... 346, 374
rate limiting................................................ 551
security example ......................................... 345
session dumps............................................. 717
filtering-based VLANs ....................................... 340
firewalls............................................................ 345
fraggle ...................................................... 544, 546
fragmenting jumbo frames.......................... 116, 118
frame processing.................................................. 85
frame tagging. See VLANs tagging.
FTP
applications ................................................ 192
proxy IP..................................................... 663
Server Load Balancing................................. 240
configuring240, 241, 246
G
gateway. See default gateway.
Gigabit adapters
jumbo frames................................................ 85
315394-J, January 2005
736 : Index
Global SLB
configuration tutorial........638 to 651, ?? to 655
Distributed Site State Protocol.......................630
DNS resolution (diagram).............................631
domain name configuration...........................644
health check interval ....................................644
hostname configuration ................................644
HTTP redirect .............................................632
port states ...................................................642
real server groups ........................................641
real servers .................................................641
remote site configuration ..............................643
tests ...........................................................668
using proxy IP.............................................663
group SLB, metrics ............................................195
grouped contracts, bandwidth..............674, 676, 690
example.......................................... 690 to 694
H
half-duplex for jumbo frames ................................85
hash metric ........................................................196
hashing
redirection filters .........................................344
hashing on any HTTP header...............................216
health checks .............................................373, 447
configuration using scripts ............................433
format ........................................................428
Global SLB interval .....................................644
hostname for HTTP content .............. 438 to 439
HTTPS/SSL................................................451
IMAP server ...............................................447
RADIUS server............................... 449 to 450
real server parameters...................................438
real servers .................................................194
script-based..................................... 427 to 436
SNMP........................................................442
verifying scripts...........................................436
wireless session protocol .................. 452 to 457
WTLS........................................................457
high-availability.................................................463
Host routes
OSPF.........................................................160
hostname, for HTTP health checks...............438, 644
hot-standby redundancy......................................494
configuration...............................................496
HP-OpenView..................................................... 35
HTTP
application health checks ............................. 438
redirects (Global SLB option)....................... 632
HTTP header
hashing...................................................... 216
HTTP redirection
IP-based.......................................... 405 to 407
MIME header-based......................... 410 to 411
TCP service port-based..................... 408 to 409
URL-based................................................. 412
HTTP URL request............................................ 363
HTTPS/SSL health checks ................................. 451
I
ICMP ............................................................... 333
IDS load balancing ............................................ 279
IEEE 802.1Q VLAN tagging ................................ 77
IF. See IP interfaces.
IGMP............................................................... 333
IMAP server health checks ................................. 447
imask ............................................................... 194
inbound traffic................................................... 302
incoming route maps.......................................... 132
ingress traffic .................................................... 610
insert cookie mode
expiration timer .......................................... 529
Intelligent Traffic Management........................... 711
internal routing.......................................... 130, 150
Internet Service Provider (ISP), SLB example...... 185
inter-switch port states, for hot-standby redundancy....
494
Intrusion Detection System (IDS)........................ 274
IP address
conservation............................................... 351
filter ranges ................................................ 337
local route cache ranges ............................... 123
private ....................................................... 351
proxies ................... 186, 219, 370, 373 to 379
real server groups................ 189, 388, 489, 641
real servers......... 184, 188, 300, 311, 321, 641
routing example.................................... 83, 119
SLB real servers ......................................... 189
virtual servers.... 184, 186, 190, 300, 317, 327,
642
315394-J, January 2005
: Index 737
IP interfaces
configuration example......... 188, 640, 647, 653
example configuration................... 83, 119, 122
VLAN #1 (default)........................................ 77
VLANs ....................................................... 77
IP packet format ................................................ 557
IP proxies
for application redirection ............................ 379
for Global Server Load Balancing................. 663
for Server Load Balancing ........................... 219
See also proxies, proxy IP address (PIP).
IP routing ......................................................... 187
cross-subnet example .................................. 116
default gateway configuration................. 84, 120
IP interface configuration............... 83, 119, 122
IP subnets .................................................. 117
network diagram......................................... 117
subnet configuration example....................... 119
switch-based topology................................. 118
IP subnets ......................................................... 118
routing............................................... 117, 118
VLANs ................................................. 75, 77
ISL Trunking ...................................................... 90
ITM. See Intelligent Traffic Management
J
jumbo frames
fragmenting to normal size................... 116, 118
frame size .................................................... 85
Gigabit adapter ............................................. 85
isolating with VLANs ................................... 85
routing............................................... 116, 118
supported duplex modes ................................ 85
VLANs ....................................................... 85
L
landattack ................................................. 544, 545
Layer 4
administrator account .................................... 56
server load balancing........................... 188, 306
Layer 7
deny filter................................................... 363
precedence lookup....................................... 724
regular expression matching ......................... 722
string matching ........................................... 720
Layer 7 lookup
with deny filter ........................................... 363
LDAP load balancing......................................... 244
least connections (SLB Real Server metric).......... 197
leastconn metric................................................. 197
Link load balancing
using filters ................................................ 300
link load balancing
basic example ............................................. 310
benefits...................................................... 298
configuration summary ................................ 308
example with SLB....................................... 320
inbound traffic ............................................ 302
outbound traffic .......................................... 301
using virtual servers..................................... 300
WAN links................................................. 297
lmask (local route cache parameter)..................... 123
lnet (local route cache parameter) ........................ 123
load balancing
DNS.................................................. 245, 250
FTP traffic.................................................. 240
IDS traffic.................................................. 274
layer 7 traffic.............................................. 202
RTSP......................................................... 253
SIP traffic................................................... 293
TCP-based DNS queries .............................. 245
TFTP traffic ............................................... 241
types of........................................... 239 to 297
UDP-based DNS queries.............................. 245
WAN traffic ............................................... 297
WAP traffic................................................ 263
local route cache address range ........................... 123
local route cache parameters
lmask......................................................... 123
lnet............................................................ 123
log
filtering option............................................ 332
log (filtering option)........................................... 345
logical segment. See IP subnets.
LSAs ................................................................ 149
315394-J, January 2005
738 : Index
M
MAC address.....................................................612
Main Menu
Command-Line Interface (CLI) .......................34
management port
setting up......................................................47
management port, using........................................46
Management Processor (MP)
use in switch security .....................................52
manual style conventions ......................................28
mapping ports ....................................................380
mapping virtual ports to real ports........................225
matchall ............................................................561
matching TCP flags............................................357
maxcons limit ............................................200, 201
maximum connections ................................200, 201
metrics
real server groups ........................................195
MIME header, in HTTP redirection ......... 410 to 411
minimum misses (SLB real server metric) ............195
minmiss metric ..................................................195
mirroring ports...................................................714
monitoring ports.................................................714
monitoring real servers .......................................233
multi-homing.....................................................667
WAN links .................................................297
multi-links between switches
using port trunking.........................................89
using VLANs................................................80
multimedia servers .............................................253
multiple services, configuring..............................194
multiple spanning tree groups..............................106
N
name servers, Global SLB configuration example .631
Network Address Translation (NAT) ...................373
configuration example...................... 351 to 353
filter action .................................................334
filter example..............................................354
proxy .........................................................354
static example .............................................351
network management............................................35
network performance
statistics, with use of proxy addresses.............219
NFS server ........................................................185
non cacheable sites in application redirection........381
none (port processing mode) example ..................190
non-HTTP redirects for GSLB............................ 663
nullscan .................................................... 544, 546
O
offset ................................................................ 557
optional software............................................... 368
OSPF
area types................................................... 146
authentication............................................. 157
configuration examples..................... 165 to 180
default route............................................... 155
external routes ............................................ 163
filtering criteria........................................... 333
host routes.................................................. 160
link state database ....................................... 149
neighbors ................................................... 149
overview.................................................... 146
redistributing routes............................. 131, 135
route maps ......................................... 131, 133
route summarization.................................... 154
router ID.................................................... 157
virtual link ................................................. 156
outbound traffic................................................. 301
outgoing route maps .......................................... 132
overflow servers ................................................ 201
P
parallel links ....................................................... 80
password
administrator account .................................... 56
default ......................................................... 56
L4 administrator account................................ 56
user account ................................................. 56
pattern group..................................................... 558
pattern matching
criteria....................................................... 556
depth......................................................... 557
groups ....................................................... 558
matchall..................................................... 561
offset ......................................................... 557
operation.................................................... 558
TCP or UDP............................................... 556
persistence
Client IP-based ................................ 520 to 521
cookie-based .............................................. 522
multi-response cookie search........................ 534
SSL session ID-based....................... 535 to 537
315394-J, January 2005
: Index 739
persistent
bindings..................................................... 187
port sessions............................................... 516
ping flood................................................. 547, 554
ping of death.................................. 547, 562 to 564
PIP. See proxies, proxy IP address.
POP3 ............................................................... 663
port 80...................................................... 639, 646
port mapping..................................................... 380
port mirroring ........................................... 714, 716
port processing mode
client ......................................................... 190
none.......................................................... 190
server ................................................ 187, 190
port smurf......................................................... 544
port states ......................................................... 642
port trunking....................................................... 90
configuration example................................... 92
description ................................................... 94
EtherChannel ............................................... 90
fault tolerance............................................... 92
ports
for services ................................................ 192
monitoring................................................. 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 .................................................... 370
PVID (port VLAN ID)......................................... 76
Q
QuickTime Streaming Server.............................. 254
R
RADIUS
authentication ............................................... 53
health checks ................................... 449 to 450
port 1812 and 1645.............. 192, 265, 266, 269
port 1813 ................................... 192, 270, 273
SSH/SCP ..................................................... 66
RADIUS snooping..................................... 267, 270
RADIUS static session entries............................. 265
RADIUS/WAP persistence ................................. 270
Rate limiting ..................................................... 680
rate limiting............................................... 679, 687
filter .......................................................... 551
hold down periods....................................... 549
protocol-based ................................. 548 to 554
TCP........................................................... 549
time window............................................... 548
timeslots .................................................... 681
UDP and ICMP .......................................... 549
real server groups
configuration example ................. 388, 489, 641
real servers........................................................ 186
backup/overflow servers .............................. 201
configuration example ................................. 641
connection timeouts..................................... 200
disable/enable............................................. 193
health checks .............................................. 438
maximum connections ................................. 200
monitoring ................................................. 233
SLB configuration example.......................... 189
weights ...................................................... 199
redirect (HTTP) ................................................. 632
redirecting filters
tunable hash ............................................... 344
redirecting non-HTTP applications...................... 663
redirection. See application redirection
redistributing routes ........................... 131, 135, 141
redundancy
active-active ............................................... 484
active-standby............................................. 480
hot-standby ................................................ 494
remote (Global SLB real server property)............. 644
response metric.................................................. 198
Return-to-Sender (RTS)
for link load balancing ......... 303, 315, 324, 326
315394-J, January 2005
740 : Index
RIP (Routing Information Protocol)
advertisements ............................................128
distance vector protocol................................127
hop count....................................................127
metric.........................................................127
routing table................................................128
TCP/IP route information .......................26, 127
UDP ..........................................................128
version 1.....................................................127
roundrobin
SLB Real Server metric................................197
route aggregation .......................................134, 141
route cache, sample ..............................................82
route maps.........................................................131
configuring .................................................133
incoming and outgoing.................................132
route paths in BGP .............................................137
Router ID
OSPF.........................................................157
routers.................................................84, 117, 120
border ........................................................150
peer ...........................................................150
port trunking.................................................90
switch-based routing topology.......................118
using redirection to reduce Internet congestion 367
web-cache redirection example......................369
routes, advertising ..............................................150
routing ..............................................................130
internal and external.....................................150
Routing Information Protocol. See RIP
rport (filtering)...........................................373, 380
RSA keys ............................................................65
RTSP
S
scalability, service ..................................... 182, 299
scan synfin................................................ 544, 546
SCP
client commands.................................. 63 to 64
configuring administrator password................. 62
enabling....................................................... 62
services........................................................ 63
script-based health checks ....................... 427 to 436
searching for cookie........................................... 534
SecurID.............................................................. 66
security
allowable SIP addresses................................. 52
denial of service protection................ 544 to 564
filter-based................................................. 345
filtering.............................................. 332, 345
firewalls..................................................... 345
from viruses ............................................... 332
IP access control lists........................ 542 to 543
layer 7 deny filter........................................ 363
port mirroring............................................. 714
private networks ......................................... 351
RADIUS authentication................................. 53
switch management....................................... 52
VLANs........................................................ 75
segmentation. See IP subnets.
segments. See IP subnets.
server (port processing mode) example................ 190
server failure..................................................... 461
315394-J, January 2005
: Index 741
across subnets............................................. 116
active-active redundancy ............................. 486
backup servers............................................ 201
complex network topologies................. 218, 219
configuration example......................... 185, 219
direct real server access ............................... 228
distributed sites........................................... 630
DNS.................................................. 245, 250
failed server protection ........................ 182, 299
fault tolerance..................................... 186, 299
FTP........................................................... 240
health checks.............................................. 438
IDS................................................... 274, 293
maximum connections................................. 200
metrics ...................................................... 195
overflow servers ......................................... 201
overview.................................................... 183
persistent bindings ...................................... 187
port processing modes ......................... 187, 190
proxies .............................................. 186, 219
proxy IP addresses ...................................... 232
real server group......................... 189, 388, 489
real server IP address (RIP) .................. 184, 300
real servers................................................. 186
remote sites................................................ 630
RTSP ........................................................ 253
topology considerations ............................... 186
virtual IP address (VIP) ............... 184, 186, 300
virtual servers............................. 184, 190, 300
WAN links................................................. 297
WAP......................................................... 263
weights...................................................... 199
server pool ........................................................ 182
server port processing ........................................ 187
service failure ................................................... 461
service ports...................................................... 192
session dumps ................................................... 717
Session Initiation Protocol (SIP) ......................... 293
shared services .......................................... 182, 299
sharing ............................................................. 471
SIP (source IP address for filtering)..................... 337
smask
source mask for filtering .............................. 337
SMTP .............................................................. 663
smurf ............................................................... 545
SNMP ........................................................ 35, 151
Alteon EMS ................................................. 35
assign health check...................................... 427
HP-OpenView.............................................. 35
SNMP content health check.......................... 442
SNMP health check ........................................... 442
Spanning-Tree Protocol
eliminating bridge loops with VRRP ............. 510
multiple instances........................................ 106
replacing with hot-standby failover................ 496
VLANs........................................................ 80
spoofing, prevention of......................................... 52
sport (filtering option) ................................ 346, 374
SSH
client commands .................................. 63 to 64
generating RSA keys ..................................... 65
RSA host and server keys............................... 65
SSH/SCP
client commands .................................. 63 to 64
configuring................................................... 61
encryption and authentication methods............. 65
with Radius authentication ............................. 66
with SecurID................................................ 66
stateful failover.................................................. 513
static NAT ........................................................ 351
static session entries........................................... 265
statistical load distribution.................................... 90
streaming media ................................................ 253
summarizing routes............................................ 154
switch failover................................................... 479
switch management
security........................................................ 52
via IP interface.............................................. 77
switch ports VLANs membership.......................... 76
switch-centric virtual router group....................... 494
syslog
messages.................................................... 332
T
tagging. See VLANs tagging.
TCP.................................................. 333, 348, 349
health checking using .................................. 194
port 80....................................................... 233
TCP flags.......................................................... 357
TCP window size
overwriting................................................. 710
TCP/UDP port numbers ..................................... 225
TDT (Theoretical Departure Times) .................... 681
315394-J, January 2005
742 : Index
Telnet ...............................................................345
text conventions ...................................................28
Theoretical Departure Times (TDT).....................681
timeouts for real server connections .....................200
TOS burst limit for bandwidth management..........684
tracking
switch-based virtual router groups .................477
virtual routers..............................................475
Traffic shaping...........................................680, 681
traffic shaping............................................681, 687
bandwidth management................................681
transparent proxies ................. 219, 370, 373 to 379
troubleshooting ..................................................717
tunable hashing..................................................344
tunneling ...........................................................610
typographic conventions .......................................28
U
UDP .................................................333, 348, 349
jumbo frame traffic fragmentation .................118
RIP............................................................128
server status using........................................194
UDP blast protection ..........................................555
URL, in HTTP redirection...................................412
user account.........................................................56
user limits, bandwidth............................. 676 to 677
Using proxy IP
GSLB ........................................................663
V
virtual clocks .....................................................681
virtual interface router (VIR)...............................464
virtual IP address (VIP) ......................184, 186, 300
virtual link, OSPF ..............................................156
Virtual Local Area Networks. See VLANs.
Virtual Matrix Architecture (VMA) .....................218
virtual port mapping to multiple real ports 225 to 228
virtual router
ID numbering..............................................511
virtual router group
switch-based ...............................................474
Virtual Router Redundancy Protocol
tracking virtual routers .................................475
virtual server router ............................................468
virtual servers ............................................184, 300
configuration example..................................190
IP address...........................190, 317, 327, 642
virus attacks, preventing..................................... 363
VLAN-based..................................................... 716
VLAN-based filtering ........................................ 340
VLANs
broadcast domains..................... 75, 77, 80, 121
default PVID................................................ 76
example showing multiple VLANs ................. 78
filtering...................................................... 340
gateway, default............................................ 81
ID numbers .................................................. 76
IP interface configuration............................. 122
IP interfaces ................................................. 77
jumbo frames ............................................... 85
multiple links ............................................... 80
multiple spanning trees ................................ 100
multiple VLANs ..................................... 76, 77
parallel links example.................................... 80
port members ............................................... 76
port mirroring............................................. 716
PVID........................................................... 76
routing....................................................... 121
security........................................................ 75
Spanning-Tree Protocol ......................... 80, 100
tagging ............................................... 76 to 79
topologies .................................................... 77
VLAN #1 (default).................. 76, 77, 189, 372
VLAN-tagging adapter support for.................. 77
VPN................................................................. 609
VPN cluster ...................................................... 610
VPN Load Balancing overview........................... 610
VRRP (Virtual Router Redundancy Protocol)
active-active redundancy.............................. 484
active-standby redundancy........................... 480
holdoff timer .............................................. 478
hot-standby redundancy............................... 494
inter-switch port states................................. 494
master, backup and init ................................ 465
overview............................................ 464, 475
owners and renters ...................................... 465
priority ...................................................... 466
sharing ...................................................... 471
switch-based virtual router group .................. 474
synchronization .......................................... 512
synchronizing configurations........................ 494
tracking service-based virtual router groups.... 477
virtual interface router ................................. 464
virtual router ID numbering.......................... 511
virtual server router ..................................... 468
vrid ........................................................... 464
315394-J, January 2005
: Index 743
W
WAN links
configuration summary................................ 308
configuring basic example ........................... 310
configuring with SLB.................................. 320
inbound traffic............................................ 302
load balancing ............................................ 300
multi-homing ............................................. 297
outbound traffic.......................................... 301
WAP
WTLS health check..................................... 457
WAP Gateway .................................................. 263
WAP load balancing
RADIUS snooping.............................. 267, 270
RADIUS/WAP persistence .......................... 270
static session entries .................................... 265
Web cache redirection
See application redirection
Web hosting...................................................... 185
weights ............................................................. 199
Wide Area Networking (WAN)
load balancing ............................................ 297
Wireless Application Protocol............................. 263
World Wide Web, client security for browsing ..... 345
WSP health checks ................................. 452 to 457
WTLS health check ........................................... 457
X
xmascan.................................................... 544, 546
315394-J, January 2005
744 : Index

Alteon OS 22.0.2 Application Guide

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Alteon OS 22.0.2 Application Guide

Transféré par

Droits d'auteur :

Formats disponibles

4655 Great America Parkway

Santa Clara, CA 95054

are registered trademarks of Cisco

Vous aimerez peut-être aussi