Nortel Networks Web Os 212777 Users Manual 10.0 Application Guide
212777 to the manual 1943b641-118f-4c3f-ab8d-4d33c4bbc66a
2015-01-26
: Nortel-Networks Nortel-Networks-Web-Os-212777-Users-Manual-346441 nortel-networks-web-os-212777-users-manual-346441 nortel-networks pdf
Open the PDF directly: View PDF .
Page Count: 482
Download | |
Open PDF In Browser | View PDF |
Web OS Switch Software 10.0 Application Guide Part Number: 212777, Revision A, February 2002 50 Great Oaks Boulevard San Jose, California 95119 408-360-5500 Main 408-360-5501 Fax www.nortelnetworks.com Web OS 10.0 Application Guide Copyright 2002 Nortel Networks, Inc., 50 Great Oaks Boulevard, San Jose, California 95119, USA. All rights reserved. Part Number: 212777, Revision A. 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 noninfringement 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. Web OS, 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. 2 212777-A, February 2002 Contents Preface 21 Who Should Use This Guide 21 What You’ll Find in This Guide 21 Typographic Conventions 23 Contacting Us 24 Part 1: Basic Switching & Routing Chapter 1: Basic IP Routing 27 IP Routing Benefits 28 Routing Between IP Subnets 28 Example of Subnet Routing 31 Defining IP Address Ranges for the Local Route Cache 35 Border Gateway Protocol (BGP) 36 Internal Routing Versus External Routing 36 Forming BGP Peer Routers 37 BGP Failover Configuration 37 DHCP Relay 41 DHCP Overview 41 DHCP Relay Agent Configuration 42 Chapter 2: VLANs 43 VLAN ID Numbers 44 VLAN Tagging 44 VLANs and the IP Interfaces 45 VLAN Topologies and Design Issues 45 Example 1: Multiple VLANS with Tagging Adapters 46 Example 2: Parallel Links with VLANs 48 3 212777-A, February 2002 Web OS 10.0 Application Guide VLANs and Spanning Tree Protocol 49 Bridge Protocol Data Units (BPDUs) 50 Multiple Spanning Trees 51 VLANs and Default Gateways 58 Segregating VLAN Traffic 58 Configuring the Local Network 60 Configuring Default Gateways per VLAN 60 VLANs and Jumbo Frames 63 Isolating Jumbo Frame Traffic using VLANs 63 Routing Jumbo Frames to Non-Jumbo Frame VLANs 64 Chapter 3: Port Trunking 65 Overview 65 Statistical Load Distribution 66 Built-In Fault Tolerance 66 Port Trunking Example 67 Chapter 4: OSPF 69 OSPF Overview 69 Types of OSPF Areas 70 Types of OSPF Routing Devices 71 Neighbors and Adjacencies 72 The Link-State Database 72 The Shortest Path First Tree 73 Internal Versus External Routing 73 OSPF Implementation in Web OS 74 Configurable Parameters 74 Defining Areas 75 Interface Cost 77 Electing the Designated Router and Backup 77 Summarizing Routes 77 Default Routes 78 Virtual Links 79 Router ID 80 Authentication 80 Host Routes for Load Balancing 82 OSPF Features Not Supported in This Release 82 4 n Contents 212777-A, February 2002 Web OS 10.0 Application Guide OSPF Configuration Examples 83 Example 1: Simple OSPF Domain 84 Example 2: Virtual Links 86 Example 3: Summarizing Routes 90 Example 4: Host Routes 92 Verifying OSPF Configuration 98 Chapter 5: Secure Switch Management 99 Setting Allowable Source IP Address Ranges 100 Secure Switch Management 101 Authentication and Authorization 101 Requirements 102 RADIUS Authentication and Authorization 103 RADIUS Authentication Features in Web OS 104 Web Switch User Accounts 105 Secure Shell and Secure Copy 107 Encryption of Management Messages 108 SCP Services 108 RSA Host and Server Keys 109 Radius Authentication 110 SecurID Support 110 Port Mirroring 113 Part 2: Web Switching Fundamentals Chapter 6: Server Load Balancing 117 Understanding Server Load Balancing 118 Identifying Your Network Needs 118 How Server Load Balancing Works 119 Implementing Basic Server Load Balancing 121 Network Topology Requirements 122 Configuring Server Load Balancing 124 Additional Server Load Balancing Options 128 Extending SLB Topologies 136 Proxy IP Addresses 136 Mapping Ports 139 Direct Server Interaction 142 Delayed Binding 146 Contents 212777-A, February 2002 n 5 Web OS 10.0 Application Guide Load Balancing Special Services 149 IP Server Load Balancing 149 FTP Server Load Balancing 150 Domain Name Server (DNS) Load Balancing 151 Real Time Streaming Protocol SLB 155 Wireless Application Protocol SLB 158 Intrusion Detection System Server Load Balancing 163 WAN Link Load Balancing 166 Chapter 7: Filtering 169 Overview 170 Filtering Benefits 170 Filtering Criteria 170 Stacking Filters 172 Overlapping Filters 172 The Default Filter 173 VLAN-based Filtering 174 Optimizing Filter Performance 176 Filter Logs 176 IP Address Ranges 178 Cache-Enabled versus Cache-Disabled Filters 178 TCP Rate Limiting 179 Configuring TCP Rate Limiting Filters 180 Tunable Hash for Filter Redirection 184 Filter-based Security 185 Network Address Translation 191 Static NAT 191 Dynamic NAT 193 FTP Client NAT 195 Matching TCP Flags 197 Matching ICMP Message Types 201 6 n Contents 212777-A, February 2002 Web OS 10.0 Application Guide Chapter 8: Application Redirection 203 Overview 204 Web Cache Redirection Environment 204 Additional Application Redirection Options 205 RTSP Web Cache Redirection 211 IP Proxy Addresses for NAT 213 Excluding Noncacheable Sites 215 Chapter 9: Virtual Matrix Architecture 217 Chapter 10: Health Checking 219 Real Server Health Checks 221 DSR Health Checks 222 Link Health Checks 223 Configuring the Switch for Link Health Checks 223 TCP Health Checks 224 ICMP Health Checks 224 Script-Based Health Checks 225 Configuring the Switch for Script-Based Health Checks 225 Script Format 226 Scripting Guidelines 227 Script Configuration Examples 227 Application-Specific Health Checks 230 HTTP Health Checks 231 UDP-Based DNS Health Checks 233 FTP Server Health Checks 234 POP3 Server Health Checks 235 SMTP Server Health Checks 236 IMAP Server Health Checks 237 NNTP Server Health Checks 238 RADIUS Server Health Checks 239 HTTPS/SSL Server Health Checks 240 WAP Gateway Health Checks 240 LDAP Health Checks 243 ARP Health Checks 245 Failure Types 246 Service Failure 246 Server Failure 246 Contents 212777-A, February 2002 n 7 Web OS 10.0 Application Guide Chapter 11: High Availability 247 VRRP Overview 248 VRRP Components 248 VRRP Operation 251 Selecting the Master VRRP Router 251 Active-Standby Failover 252 Failover Methods 253 Active-Standby Redundancy 254 Active-Active Redundancy 255 Hot-Standby Redundancy 256 Synchronizing Configurations 258 Web OS Extensions to VRRP 259 Virtual Server Routers 259 Sharing/Active-Active Failover 260 Tracking VRRP Router Priority 261 High Availability Configurations 263 Active-Standby Virtual Server Router Configuration 263 Active-Active VIR and VSR Configuration 265 Active/Active Server Load Balancing Configuration 267 VRRP-Based Hot-Standby Configuration 275 Virtual Router Deployment Considerations 277 Mixing Active-Standby and Active-Active Virtual Routers 277 Synchronizing Active/Active Failover 277 Eliminating Loops with STP and VLANs 278 Assigning VRRP Virtual Router ID 280 Configuring the Switch for Tracking 280 Synchronizing Configurations 282 Stateful Failover of Layer 4 and Layer 7 Persistent Sessions 283 What Happens When a Switch Fails 284 Viewing Statistics on Persistent Port Sessions 286 8 n Contents 212777-A, February 2002 Web OS 10.0 Application Guide Part 3: Advanced Web Switching Chapter 12: Global Server Load Balancing 289 GSLB Overview 290 Benefits 290 Compatibility with Other Web OS Features 290 How GSLB Works 291 Configuring GSLB 293 IP Proxy for Non-HTTP Redirects 304 How IP Proxy Works 305 Configuring Proxy IP Addresses 307 Verifying GSLB Operation 308 Configuring Client Site Preferences 308 Using Border Gateway Protocol for GSLB 312 Chapter 13: Firewall Load Balancing 313 Firewall Overview 314 Basic FWLB 316 Basic FWLB Implementation 317 Configuring Basic FWLB 319 Four-Subnet FWLB 326 Four-Subnet FWLB Implementation 327 Configuring Four-Subnet FWLB 329 Advanced FWLB Concepts 346 Free-Metric FWLB 346 Adding a Demilitarized Zone (DMZ) 349 Firewall Health Checks 351 Chapter 14: Virtual Private Network Load Balancing 353 Overview 354 Virtual Private Networks 354 How VPN Load Balancing Works 354 VPN Load-Balancing Configuration 356 Requirements 356 VPN Load-Balancing Configuration Example 356 Contents 212777-A, February 2002 n 9 Web OS 10.0 Application Guide Chapter 15: Content Intelligent Switching 371 Overview 372 Parsing Content 373 HTTP Header Inspection 374 Buffering Content with Multiple Frames 374 Content Intelligent Server Load Balancing 375 URL-Based Server Load Balancing 375 Virtual Hosting 380 Cookie-Based Preferential Load Balancing 383 Browser-Smart Load Balancing 386 URL Hashing for Server Load Balancing 387 Header Hash Load Balancing 389 DNS Load Balancing 390 Layer 7 RTSP Load Balancing 392 Content Intelligent Web Cache Redirection 394 URL-Based Web Cache Redirection 395 HTTP Header-Based Web Cache Redirection 403 Browser-Based Web Cache Redirection 405 URL Hashing for Web Cache Redirection 406 Layer 7 RTSP Streaming Cache Redirection 409 Exclusionary String Matching for Real Servers 410 Configuring for Exclusionary URL String Matching 410 Regular Expression Matching 412 Standard Regular Expression Characters 412 Configuring Regular Expressions 413 Content Precedence Lookup 414 Requirements 415 Using the or and and Operators 415 Assigning Multiple Strings 416 Layer 7 Deny Filter 417 10 n Contents 212777-A, February 2002 Web OS 10.0 Application Guide Chapter 16: Persistence 421 Overview of Persistence 422 Using Source IP Address 422 Using Cookies 423 Using SSL Session ID 423 Cookie-Based Persistence 424 Permanent and Temporary Cookies 425 Cookie Formats 425 Cookie Properties 426 Client Browsers that Do Not Accept Cookies 426 Cookie Modes of Operation 427 Configuring Cookie-Based Persistence 430 Server-Side Multi-Response Cookie Search 436 SSL Session ID-Based Persistence 437 How SSL Session ID-Based Persistence Works 437 Chapter 17: Bandwidth Management 441 Overview 442 Bandwidth Policies 444 Rate Limits 445 Bandwidth Policy Configuration 445 Data Pacing 446 Classification Criteria 447 Server Output Bandwidth Control 447 Application Bandwidth Control 447 Combinations 448 Precedence 448 Bandwidth Classification Configuration 448 Frame Discard 449 URL-Based Bandwidth Management 449 HTTP Header-Based Bandwidth Management 451 Cookie-Based Bandwidth Management 451 Bandwidth Statistics and History 452 Statistics Maintained 452 Statistics and Management Information Bases 452 Packet Coloring (TOS bits) for Burst Limit 453 Operational Keys 453 Contents 212777-A, February 2002 n 11 Web OS 10.0 Application Guide Configuring Bandwidth Management 454 Additional Configuration Examples 457 Preferential Services Examples 460 Glossary 471 Index 475 12 n Contents 212777-A, February 2002 Figures Figure 1-1: Figure 1-2: Figure 1-3: Figure 1-4: Figure 1-5: The Router Legacy Network 29 Switch-Based Routing Topology 30 iBGP and eBGP 37 BGP Failover Configuration Example 38 DHCP Relay Agent Configuration 42 Figure 2-1: Figure 2-2: Figure 2-3: Figure 2-4: Figure 2-5: Figure 2-6: Figure 2-7: Example 1: Multiple VLANs with Tagging Gigabit Adapters 46 Example 2: Parallel Links with VLANs 48 Using Multiple Instances of Spanning Tree Protocol 51 VLAN 3 Isolated in a Single Spanning Tree Group 52 Implementing Multiple Spanning Tree Groups 53 Default Gateways per VLAN 58 Jumbo Frame VLANs 64 Figure 3-1: Figure 3-2: Port Trunk Group 65 Port Trunk Group Configuration Example 67 Figure 4-1: Figure 4-2: Figure 4-3: Figure 4-4: Figure 4-5: Figure 4-6: Figure 4-7: Figure 4-8: OSPF Area Types 70 OSPF Domain and an Autonomous System 71 Injecting Default Routes 78 OSPF Authentication 80 A Simple OSPF Domain 84 Configuring a Virtual Link 86 Summarizing Routes 90 Configuring OSPF Host Routes 92 Figure 5-1: Figure 5-2: Authentication and Authorization: How It Works 103 Monitoring Ports 113 13 212777-A, February 2002 Web OS 10.0 Application Guide Figure 6-1: Figure 6-2: Figure 6-3: Figure 6-4: Figure 6-5: Figure 6-6: Figure 6-7: Figure 6-8: Figure 6-9: Figure 6-10: Figure 6-11: Traditional Versus SLB Network Configurations 119 Web Hosting Configuration Without SLB 121 Web Hosting with SLB Solutions 121 SLB Client/Server Traffic Routing 122 Example Network for Client/Server Port Configuration 123 Basic Virtual Port to Real Port Mapping Configuration 140 Direct Server Return 143 Mapped and Nonmapped Server Access 144 DoS SYN Attacks without Delayed Binding 146 Repelling DoS SYN Attacks With Delayed Binding 147 Layer 4 DNS Load Balancing 151 Figure 7-1: Figure 7-2: Figure 7-3: Figure 7-4: Figure 7-5: Figure 7-6: Figure 7-7: Figure 7-8: Figure 7-9: Figure 7-10: Figure 7-11: Assigning Filters According to Range of Coverage 172 Assigning Filters to Overlapping Ranges 172 Assigning a Default Filter 173 VLAN-based Filtering 174 Configuring Clients with Different Rates 180 Limiting User Access to Server 183 Security Topology Example 185 Static Network Address Translation 192 Dynamic Network Address Translation 193 Active FTP for Dynamic NAT 195 TCP ACK Matching Network 197 Figure 8-1: Figure 8-2: Traditional Network Without Web Cache Redirection 204 Network with Web Cache Redirection 205 Figure 11-1: Example 1: VRRP Router 250 Figure 11-2: Example 2: VRRP Router 252 Figure 11-3: A Non-VRRP, Hot-Standby Configuration 253 Figure 11-4: Active-Standby Redundancy 254 Figure 11-5: Active-Active Redundancy 255 Figure 11-6: Hot-Standby Redundancy 256 Figure 11-7: Active-Active High Availability 260 Figure 11-8: Active-Standby High-Availability Configuration 263 Figure 11-9: Active-Active High-Availability Configuration 265 Figure 11-10: Hot-Standby Configuration 275 Figure 11-11: Loops in Active-Active Configuration 278 Figure 11-12: Cross-Redundancy Creates Loops, But STP Resolves Them 279 Figure 11-13: Using VLANs to Create Non-Looping Topologies 279 Figure 11-14: Stateful Failover Example when the Master Switch Fails 284 14 n Figures 212777-A, February 2002 Web OS 10.0 Application Guide Figure 12-1: Figure 12-2: Figure 12-3: Figure 12-4: Figure 12-5: Figure 12-6: DNS Resolution with Global Server Load Balancing 291 GSLB Topology Example 294 HTTP and Non-HTTP Redirects 304 POP3 Request Fulfilled via IP Proxy 305 GSLB Proximity Tables: How They Work 309 Configuring Client Proximity Table 310 Figure 13-1: Typical Firewall Configuration Before FWLB 314 Figure 13-2: Basic FWLB Topology 316 Figure 13-3: Basic FWLB Process 317 Figure 13-4: Basic FWLB Example Network 319 Figure 13-5: Four-Subnet FWLB Topology 326 Figure 13-6: Four-Subnet FWLB Process 327 Figure 13-7: Four-Subnet FWLB Example Network 329 Figure 13-8: Basic FWLB Example Network 346 Figure 13-9: Four-Subnet FWLB Example Network 347 Figure 13-10: Typical Firewall Load-Balancing Topology with DMZ 349 Figure 14-1: Basic Network Frame Flow and Operation 355 Figure 14-2: VPN Load-Balancing Configuration Example 356 Figure 14-3: Checkpoint Rules for Both VPN Devices as Seen in the Policy Editor 368 Figure 15-1: Figure 15-2: Figure 15-3: Figure 15-4: Figure 15-5: Figure 15-6: Figure 15-7: Figure 15-8: Figure 15-9: Content Intelligent Load Balancing Example 372 URL-Based Server Load Balancing 376 Balancing Nontransparent Caches 387 Load Balancing DNS Queries 390 URL-Based Web Cache Redirection 396 URL Hashing for WCR 408 Content Precedence Lookup Protectors Example 415 Content Precedence Lookup Multiple Strings Example 416 Configuring Layer 7 Deny Filter 417 Figure 16-1: Figure 16-2: Figure 16-3: Figure 16-4: Figure 16-5: Cookie-Based Persistence: How It Works 424 Insert Cookie Mode 427 Passive Cookie Mode 428 Rewrite Cookie Mode 429 SSL Session ID-Based Persistence 438 Figures 212777-A, February 2002 n 15 Web OS 10.0 Application Guide Figure 17-1: Figure 17-2: Figure 17-3: Figure 17-4: Figure 17-5: Figure 17-6: Figure 17-7: 16 n Bandwidth Management: How It Works 442 Bandwidth Rate Limits 444 Virtual Clocks and TDT 446 URL-Based Bandwidth Management 450 URL-Based Bandwidth Management with Web Cache Redirection 450 Cookie-Based Bandwidth Management 451 Cookie-Based Preferential Services 467 Figures 212777-A, February 2002 Tables Table 1-1: Table 1-2: Table 1-3: Table 1-4: Subnet Routing Example: IP Address Assignments 31 Subnet Routing Example: IP Interface Assignments 31 Subnet Routing Example: Optional VLAN Ports 33 Local Routing Cache Address Ranges 35 Table 2-1: Table 2-2: Table 2-3: Ports, Trunk Groups, and VLANs 49 Multiple Spanning Tree Groups per VLAN 54 Route Cache Example 59 Table 5-1: Table 5-2: User Access Levels 105 Web OS Alteon Levels 106 Table 6-1: Table 6-2: Table 6-3: Table 6-4: Web Host Example: Real Server IP Addresses 124 Web Host Example: Port Usage 126 Well-Known Application Ports 128 Proxy Example: Port Usage 137 Table 7-1: Table 7-2: Table 7-3: Table 7-4: Table 7-5: Table 7-6: Well-Known Protocol Types 171 Well-Known Application Ports 171 Filtering IP Address Ranges 178 Web Cache Example: Real Server IP Addresses 186 TCP Flags 197 ICMP Message Types 201 Table 8-1: Web Cache Example: Real Server IP Addresses 206 Table 11-1: Table 11-2: Table 11-3: Active Standby Configuration 252 Sharing Active-Active Failover 260 VRRP Tracking Parameters 261 17 212777-A, February 2002 Web OS 10.0 Application Guide 18 n Table 12-1: Table 12-2: Table 12-3: Table 12-4: Table 12-5: GSLB Example: California Real Server IP Addresses 296 GSLB Example: California Alteon 180 Port Usage 297 Denver Real Server IP Addresses 300 Web Host Example: Alteon 180 Port Usage 301 HTTP Versus Non-HTTP Redirects 305 Table 15-1: Table 15-2: Standard Regular Expression Special Characters 412 Real Server Content 416 Table 16-1: Comparison Among the Three Cookie Modes 427 Table 17-1: Table 17-2: Bandwidth Rate Limits 445 Bandwidth Policy Limits 445 Tables 212777-A, February 2002 New Features The following table lists the new features in Web OS 10.0 and the supported platforms: Feature Alteon Web Switches Alteon Web Switches AD3/180e AD4/184 Vlan-based default gateway No Yes Vlan Filtering No Yes Multiple Instances of Spanning Tree Yes Yes Layer 7 deny filter Yes Yes Increase real server support to 1024 No Yes SYN Attack Detection/Protection Yes Yes Enhanced Port Mirroring Yes Yes Reporting Classification Manager: SYSLOG and No SNMP Yes Reporting Classification Manager: Ability to fil- No ter SYSLOG based on severity Yes Reporting Classification Manager: SNMP traps defined for VRRP state changes No Yes Reporting Classification Manager: SNMP traps defined for failed login No Yes Selectable Hash Parameters Yes Yes Layer 4 DNS Load Balancing (UDP and TCP ports) Yes Yes L7 DNS Load Balancing Yes Yes Enhanced DNS Health Check Yes Yes TCP Rate Limiting Yes Yes 19 212777-A, February 2002 Web OS 10.0 Application Guide 20 n Feature Alteon Web Switches Alteon Web Switches AD3/180e AD4/184 Hash on any HTTP header Yes Yes Increase support of 16 rport to vport No Yes Increased number of scripted health check to 16 No Yes Descriptive names for filters Yes Yes OSPF No Yes LDAP health check Yes Yes Streaming Cache Redirection Yes Yes L7 Parsing of RTSP SLB Yes Yes ARP health check Yes Yes Telnet client Yes Yes Increase logging buffer Yes Yes Support of OPER command on Web OS BBI and No SNMP Yes Enhanced Web OS Browser-based Interface support No Yes Configurable prompt name Yes Yes Bandwidth management No Yes New Features 212777-A, February 2002 Preface This Application Guide describes how to configure and use the Web OS software on the Alteon Web switches. For documentation on installing the switches physically, see the Hardware Installation Guide for your particular switch model. Who Should Use This Guide This Application Guide is intended for network installers and system administrators engaged in configuring and maintaining a network. The administrator should be familiar with Ethernet concepts, IP addressing, Spanning Tree Protocol, and SNMP configuration parameters. What You’ll Find in This Guide This guide will help you plan, implement, and administer Web OS software. Where possible, each section provides feature overviews, usage examples, and configuration instructions. Part 1: Basic Switching & Routing n Chapter 1, “Basic IP Routing,” describes how to configure the Web switch for IP routing using IP subnets, Border Gateway Protocol (BGP), or DHCP Relay. n Chapter 2, “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. n Chapter 3, “Port Trunking,” describes how to group multiple physical ports together to aggregate the bandwidth between large-scale network devices. n Chapter 4, “OSPF,” describes OSPF concepts, how OSPF is implemented in Web OS, and four examples of how to configure your switch for OSPF support. 21 212777-A, February 2002 Web OS 10.0 Application Guide n Chapter 5, “Secure Switch Management,” describes how to manage the switch using specific IP addresses, RADIUS authentication, Secure Shell (SSH), and Secure Copy (SCP). Part 2: Web Switching Fundamentals n Chapter 6, “Server Load Balancing,” describes how to configure the Web switch to balance network traffic among a pool of available servers for more efficient, robust, and scalable network services. n Chapter 7, “Filtering,” describes how to configure and optimize network traffic filters for security and Network Address Translation purposes. n Chapter 8, “Application Redirection,” describes how to use filters for redirecting traffic to such network streamlining devices as Web caches. n Chapter 9, “Virtual Matrix Architecture,” describes how to optimize system resources by distributing the workload to multiple processors. n Chapter 10, “Health Checking,” describes how to configure the Web switch to recognize the availability of the various network resources used with the various load-balancing and application redirection features. n Chapter 11, “High Availability,” describes how to use the Virtual Router Redundancy Protocol (VRRP) to ensure that network resources remain available if one Web switch fails. Part 3: Advanced Web Switching 22 n n Chapter 12, “Global Server Load Balancing,” describes configuring Server Load Balancing across multiple geographic sites. n Chapter 13, “Firewall Load Balancing,” describes how to combine features to provide a scalable solution for load balancing multiple firewalls. n Chapter 14, “Virtual Private Network Load Balancing,” describes using your Web switch to load balance secure point-to-point links. n Chapter 15, “Content Intelligent Switching,” 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). n Chapter 16, “Persistence,” describes how to ensure that all connections from a specific client session reach the same server. Persistence can be based on cookies or SSL session ID. n Chapter 17, “Bandwidth Management,” describes how to configure the Web switch for allocating specific portions of the available bandwidth for specific users or applications. Preface 212777-A, February 2002 Web OS 10.0 Application Guide Typographic Conventions The following table describes the typographic styles used in this book. 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 Main# prompts. AaBbCc123 This bold type appears in command examples. It shows text that must be typed in exactly as shown. Main# sysThis italicized type appears in command To establish a Telnet session, enter: examples as a parameter placeholder. Replace host# telnet the indicated text with the appropriate real name or value when using the command. Do not type the brackets. [ ] This also shows book titles, special terms, or words to be emphasized. Read your User’s Guide thoroughly. Command items shown inside brackets are optional and can be used or excluded as the situation demands. Do not type the brackets. host# ls [-a] Preface 212777-A, February 2002 n 23 Web OS 10.0 Application Guide Contacting Us For complete product support and sales information, visit the Nortel Networks website at the following URL: http://www.nortelnetworks.com See the contact information on this site for regional support and sales phone numbers and e-mail addresses. 24 n n In North America, dial toll-free 1-800-4NORTEL. n Outside North America, call 987-288-3700. Preface 212777-A, February 2002 Part 1: Basic Switching & Routing This section discusses basic Layer 1 through Layer 3 switching and routing functions. In addition to switching traffic at near line rates, the Web switch can perform multi-protocol routing. This section includes the following basic switching and routing topics: n Basic IP Routing n VLANs n Jumbo Frames n Port Trunking n Border Gateway Protocol (BGP) n Open Shortest Path First (OSPF) n Secure Switch Management 25 212777-A, February 2002 Web OS 10.0 Application Guide 26 n Basic Switching & Routing 212777-A, February 2002 CHAPTER 1 Basic IP Routing This chapter provides configuration background and examples for using the Alteon Web switch to perform IP routing functions. The following topics are addressed in this chapter: n “IP Routing Benefits” on page 28 n “Routing Between IP Subnets” on page 28 n “Example of Subnet Routing” on page 31 n “Defining IP Address Ranges for the Local Route Cache” on page 35 n “Border Gateway Protocol (BGP)” on page 36 n “DHCP Relay” on page 41 27 212777-A, February 2002 Web OS 10.0 Application Guide IP Routing Benefits The Alteon Web switch uses a combination of configurable IP switch interfaces and IP routing options. The switch IP routing capabilities provide the following benefits: n Connects the server IP subnets to the rest of the backbone network. n Performs server load balancing (using both Layer 3 and Layer 4 switching in combination) to server subnets that are separate from backbone subnets. n Provides another means to invisibly introduce Jumbo frame technology into the serverswitched network by automatically fragmenting UDP Jumbo frames when routing to nonJumbo frame VLANs or subnets. n 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 Web switches are intelligent and fast enough to perform routing functions on a par with wire speed Layer 2 switching. The combination of faster routing and switching in a single device provides another service— it allows you to build versatile topologies that account for legacy configurations. 28 n Chapter 1: Basic IP Routing 212777-A, February 2002 Web OS 10.0 Application Guide For example, consider the following topology migration: Admin. Subnet Admin/Sales Hub Switch Eng. Subnet Eng/Staff2/Sales Hub Switch Staff Subnet Staff/Eng2 Hub Switch Server Subnet Server Subnet Web Switch FDDI Router Internet FDDI Internet Router Figure 1-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 crosssubnet communication. This compromises efficiency in two ways: n 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. n Traffic to the router increases, increasing congestion. Even if every end-station could be moved to better logical subnets (a daunting task), competition for access to common server pools on different subnets still burdens the routers. This problem is solved by using Alteon Web switches with built-in IP routing capabilities. Cross-subnet LAN traffic can now be routed within the Web 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. Chapter 1: Basic IP Routing 212777-A, February 2002 n 29 Web OS 10.0 Application Guide Take a closer look at the Alteon Web switch in the following configuration example: First Floor 10/100 Client Subnet 100.20.10.1-254 Primary Default Router: 205.21.17.1 Second Floor 10/100 Client Subnet 131.15.15.1-254 1000 Mbps IF#2 1000 Mbps Third Floor 10/100 Client Subnet 208.31.177.1-254 IF#3 IF#4 IF#1 IF#5 1000 Mbps IP Routing Secondary Default Router: 205.21.17.2 Alteon Web Switch Server Subnet: 206.30.15.1-254 Figure 1-2 Switch-Based Routing Topology The Alteon Web switch connects the Gigabit Ethernet and Fast Ethernet trunks from various switched subnets throughout one building. Common servers are placed on another subnet attached to the switch. A primary and backup router are attached to the switch on yet another subnet. Without Layer 3 IP routing on the switch, cross-subnet communication is relayed to the default gateway (in this case, the router) for the next level of routing intelligence. The router 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 Web switch, routing between different IP subnets can be accomplished entirely within the switch. This leaves the routers free to handle 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 automatic frame conversion allows servers to communicate using Jumbo frames, all transparently to the user. 30 n Chapter 1: Basic IP Routing 212777-A, February 2002 Web OS 10.0 Application Guide 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 Web OS Command Reference. 1. Assign an IP address (or document the existing one) for each real server, router, and client workstation. In the example topology in Figure 1-2 on page 30, the following IP addresses are used: Table 1-1 Subnet Routing Example: IP Address Assignments 2. 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.1-254 3 Second Floor Client Workstations 131.15.15.1-254 4 Third Floor Client Workstations 208.31.177.1-254 5 Common Servers 206.30.15.1-254 Assign an IP interface for each subnet attached to the switch. Since there are five IP subnets connected to the switch, five IP interfaces are needed: Table 1-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.16 IF 3 Second Floor Client Workstations 131.15.15.1 IF 4 Third Floor Client Workstations 208.31.177.2 IF 5 Common Servers 206.30.15.200 Chapter 1: Basic IP Routing 212777-A, February 2002 n 31 Web OS 10.0 Application Guide IP interfaces are configured using the following commands at the CLI: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> # /cfg/ip/if IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface 1 1# 1# 1# 2# 2# 2# 3# 3# 3# 4# 4# 4# 5# 5# addr 205.21.17.3 ena ../if 2 addr 100.20.10.16 ena ../if 3 addr 131.15.15.1 ena ../if 4 addr 208.31.177.2 ena ../if 5 addr 206.30.15.200 ena (Select IP interface 1) (Assign IP address for the interface) (Enable IP interface 1) (Select IP interface 2) (Assign IP address for the interface) (Enable IP interface 2) (Select IP interface 3) (Assign IP address for the interface) (Enable IP interface 3) (Select IP interface 4) (Assign IP address for the interface) (Enable IP interface 4) (Select IP interface 5) (Assign IP address for the interface) (Enable IP interface 5) 3. Set each server and workstation’s default gateway to the appropriate switch IP interface (the one in the same subnet as the server or workstation). 4. Configure the default gateways to the routers’ addresses. Configuring the default gateways allows the switch to send outbound traffic to the routers: >> >> >> >> >> >> 5. IP Interface 5# Default gateway Default gateway Default gateway Default gateway Default gateway ../gw 1 1# addr 205.21.17.1 1# ena 1# ../gw 2 2# addr 205.21.17.2 2# ena (Select primary default gateway) (Assign IP address for primary router) (Enable primary default gateway) (Select secondary default gateway) (Assign address for secondary router) (Enable secondary default gateway) Enable, apply, and verify the configuration. >> >> >> >> Default gateway 2# ../fwrd IP Forwarding# on IP Forwarding# apply IP Forwarding# /cfg/ip/cur (Select the IP Forwarding Menu) (Turn IP forwarding on) (Make your changes active) (View current IP settings) Examine the resulting information. If any settings are incorrect, make the appropriate changes. 6. Save your new configuration changes. >> IP# save 32 n (Save for restore after reboot) Chapter 1: Basic IP Routing 212777-A, February 2002 Web OS 10.0 Application Guide Using VLANs to Segregate Broadcast Domains In the previous example, devices that share a common IP network are all in the same broadcast domain. If you want to limit the broadcasts on your network, you could use VLANs to create distinct broadcast domains. For example, as shown in the following procedure, you could create one VLAN for the client trunks, one for the routers, and one for the servers. In this example, you are adding to the previous configuration. 1. Determine which switch ports and IP interfaces belong to which VLANs. The following table adds port and VLAN information: Table 1-3 Subnet Routing Example: Optional VLAN Ports VLAN Devices 1 2 3 2. IP Interface Switch Port First Floor Client Workstations 2 1 Second Floor Client Workstations 3 2 Third Floor Client Workstations 4 3 Primary Default Router 1 4 Secondary Default Router 1 5 Common Servers 1 5 6 Common Servers 2 5 7 Add the switch ports to their respective VLANs. The VLANs shown in Table 1-3 are configured as follows: >> >> >> >> >> >> >> >> >> >> >> >> >> # /cfg/vlan 1 VLAN 1# add port 1 VLAN 1# add port 2 VLAN 1# add port 3 VLAN 1# ena VLAN 1# ../VLAN 2 VLAN 2# add port 4 VLAN 2# add port 5 VLAN 2# ena VLAN 2# ../VLAN 3 VLAN 3# add port 6 VLAN 3# add port 7 VLAN 3# ena (Select VLAN 1) (Add port for 1st floor to VLAN 1) (Add port for 2nd floor to VLAN 1) (Add port for 3rd floor to VLAN 1) (Enable VLAN 1) (Select VLAN 2) (Add port for default router 1) (Add port for default router 2) (Enable VLAN 2) (Add port for default router 3) (Select VLAN 3) (Select port for common server 1) (Enable VLAN 3) Chapter 1: Basic IP Routing 212777-A, February 2002 n 33 Web OS 10.0 Application Guide Each time you add a port to a VLAN, you may get the following prompt: Port 4 is untagged and VLAN 2 is not a configured PVID for port 4. Would you like to change all PVIDS for port 4 to VLAN 2 [y n]? Enter y to set the default Port VLAN ID (PVID) for the port. 3. Add each IP interface to the appropriate VLAN. Now that the ports are separated into three VLANs, the IP interface for each subnet must be placed in the appropriate VLAN. From Table 1-3 on page 33, the settings are made as follows: >> >> >> >> >> >> >> >> >> >> 4. VLAN 3# /cfg/ip/if 1 IP Interface 1# vlan 2 IP Interface 1# ../if 2 IP Interface 2# vlan 1 IP Interface 2# ../if 3 IP Interface 3# vlan 1 IP Interface 3# ../if 4 IP Interface 4# vlan 1 IP Interface 4# ../if 5 IP Interface 5# vlan 3 (Select IP interface 1 for def. routers) (Set to VLAN 2) (Select IP interface 2 for first floor) (Set to VLAN 1) (Select IP interface 3 for second floor) (Set to VLAN 1) (Select IP interface 4 for third floor) (Set to VLAN 1) (Select IP interface 5 for servers) (Set to VLAN 3) Apply and verify the configuration. >> IP Interface 5# apply >> IP Interface 5# /info/vlan >> Information# port (Make your changes active) (View current VLAN information) (View current port information) Examine the resulting information. If any settings are incorrect, make the appropriate changes. 5. Save your new configuration changes. >> Information# save 34 n (Save for restore after reboot) Chapter 1: Basic IP Routing 212777-A, February 2002 Web OS 10.0 Application Guide 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/ip/frwd/local/add command) 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 produces a range that includes all Internet addresses for route caching: 0.0.0.0 through 255.255.255.255. To limit the route cache to your local hosts, you could configure the parameters as shown in the following example: Table 1-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 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. Chapter 1: Basic IP Routing 212777-A, February 2002 n 35 Web OS 10.0 Application Guide Border Gateway Protocol (BGP) 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 Web switches can advertise their IP interfaces and virtual server IP addresses using BGP and take BGP feeds from as many as four BGP router peers. This allows more resilience and flexibility in balancing traffic from the Internet. 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, internal routing protocols, such as RIP, RIPv2, and OSPF. It is also useful to tell routers outside your network (upstream providers or peers) about the routes you can access in your network. External networks (those outside your own) that are under the same administrative control are referred to as autonomous systems (AS). Sharing of routing information between autonomous systems is known as external routing. External BGP (eBGP) is used to exchange routes between different autonomous systems whereas internal BGP (iBGP) is used to exchange routes within the same autonomous system. An iBGP is a type of internal routing protocol you can use to do active routing inside your network. It also carries AS path information, which is important when you are an ISP or doing BGP transit. NOTE – The iBGP peers must be part of a fully meshed network, as shown in Figure 1-3. 36 n Chapter 1: Basic IP Routing 212777-A, February 2002 Web OS 10.0 Application Guide AS 11 AS 20 ISP A iBGP eBGP Internet AS 50 Web Switches ISP B Figure 1-3 iBGP and eBGP Typically, an AS has one or more multiple border routers—peer routers that exchange routes with other ASs—and an internal routing scheme that enables routers in that AS to reach every other router and destination within that AS. When you advertise routes to border routers on other autonomous systems, you are effectively committing to carry data to the IP space represented in the route being advertised. For example, if you advertise 192.204.4.0/24, you are declaring that if another router sends you data destined for any address in 192.204.4.0/24, you know how to carry that data to its destination. 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. BGP Failover Configuration Use the following example to create redundant default gateways for an Alteon Web 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. Chapter 1: Basic IP Routing 212777-A, February 2002 n 37 Web OS 10.0 Application Guide As shown in Figure 1-4, the switch is connected to ISP 1 and ISP 2. The customer negotiates with both ISPs to allow the Web switch to use their peer routers as default gateways. The ISP peer routers will then need to announce themselves as default gateways to the Web switch. Peer 1 Router (Primary) IP: 200.200.200.2 ISP 1 ISP 2 AS 100 AS 200 Default gateway, with routes having shorter AS PATH Web switch announces routes with metric of "3" Peer 2 Router (Secondary) IP: 210.210.210.2 Alteon metric = AS path length (metric of '3' = local AS repeated 3 times VIP: 200.200.200.200 Alteon Web switch IP: 200.200.200.1 IP:210.210.210.1 AS 300 AS 300 Real server 1 IP: 200.200.200.10 Real server 2 IP: 200.200.200.11 Figure 1-4 BGP Failover Configuration Example On the Web 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. 1. Configure the switch as you normally would for Server Load Balancing (SLB). n Assign an IP address to each of the real servers in the server pool. n Define each real server. n Define a real server group. n Define a virtual server. n Define the port configuration. For more information about SLB configuration, refer to Chapter 6. 38 n Chapter 1: Basic IP Routing 212777-A, February 2002 Web OS 10.0 Application Guide 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. >> # /cfg/vlan 1 >> vlan 1# add >> vlan 1# ena 3. (Select VLAN 1) (Add a port to the VLAN membership) (Enable VLAN 1) 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. /cfg/ip/rearp 10 IP# metrc strict IP# if 1 IP Interface 1# ena IP Interface 1# addr 200.200.200.1 IP Interface 1# mask 255.255.255.0 IP Interface 1# broad 200.200.200.255 IP Interface 1# vlan 1 IP Interface 1# ../ip/if 2 IP Interface 2# ena IP Interface 2# addr 210.210.210.1 IP Interface 2# mask 255.255.255.0 IP Interface 2# broad 210.210.210.255 IP Interface 2# vlan 1 (Set re-ARP period for interface to 10) (Set metric for default gateway) (Select default gateway interface 1) (Enable switch interface 1) (Configure IP address of interface 1) (Configure IP subnet address mask) (Configure IP broadcast address) (Configure VLAN # for this interface) (Select default gateway interface 2) (Enable switch interface 2) (Configure IP address of interface 2) (Configure IP subnet address mask) (Configure IP broadcast address) (Configure VLAN # for this interface) Enable IP forwarding. IP forwarding is used for VLAN-to-VLAN (non-BGP) routing. You need to enable IP forwarding 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/ip/ frwd on (Enable IP forwarding) NOTE – To help eliminate the possibility for a Denial of Service (DoS) attack, the forwarding of directed broadcasts is disabled by default. Chapter 1: Basic IP Routing 212777-A, February 2002 n 39 Web OS 10.0 Application Guide 5. Configure BGP peer router 1 and 2. Peer 1 is the primary gateway router. Peer 2 is configured with a metric of “3.” The metric option is key to ensuring gateway traffic is directed to Peer 1, as it will make Peer 2 appear to be three router hops away from the switch. Thus, the switch should never use it unless Peer 1 goes down. >> >> >> >> >> >> >> >> >> >> >> >> >> # /cfg/ip/bgp/peer 1 BGP Peer 1# ena BGP Peer 1# addr 200.200.200.2 BGP Peer 1# if 200.200.200.1 BGP Peer 1# las 300 BGP Peer 1# ras 100 BGP Peer 1# ../peer 2 BGP Peer 2# ena BGP Peer 2# addr 210.210.210.2 BGP Peer 2# if 210.210.210.1 BGP Peer 2# las 300 BGP Peer 2# ras 200 BGP Peer 2# metric 3 (Select BGP peer router 1) (Enable this peer configuration) (Set IP address for peer router 1) (Set IP interface for peer router 1) (Set local AS number) (Set remote AS number) (Select BGP peer router 2) (Enable this peer configuration) (Set IP address for peer router 2) (Set IP interface for peer router 2) (Set local AS number) (Set remote AS number) (Set AS path length to 3 router hops) The metric command in the peer menu tells the Alteon Web switch to create an AS path of “3” when advertising via BGP. 6. On the switch, apply and save your configuration changes. >> BGP Peer 2# apply >> save 40 n (Make your changes active) (Save for restore after reboot) Chapter 1: Basic IP Routing 212777-A, February 2002 Web OS 10.0 Application Guide DHCP Relay Dynamic Host Configuration Protocol (DHCP) is a transport protocol that provides a framework 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 different place in the network. DHCP is an extension of another network IP management protocol, Bootstrap Protocol (BOOTP), with an additional capability of being able to dynamically allocate reusable network addresses and 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 significant 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. DHCP Overview DHCP is described in RFC 2131, and the DHCP relay agent supported on Alteon Web 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 Web switch acts as a relay agent. The DHCP relay feature (/cfg/ip/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 destination IP (DIP) addresses. The request is then forwarded as a UDP Unicast MAC layer message to two BOOTP servers whose IP addresses are configured on the switch. The servers Chapter 1: Basic IP Routing 212777-A, February 2002 n 41 Web OS 10.0 Application Guide respond as a a UDP Unicast message back to the switch, with the default gateway and IP address for the client. The destination IP address in the server response represents the interface address on the switch that received the client request. This interface address tells the switch on which VLAN to send the server response to the client. DHCP Relay Agent Configuration To enable the Alteon Web switch to be the BOOTP forwarder, you need to configure the DHCP/BOOTP server IP addresses on the switch. Generally, you should configure the command on the switch IP interface closest to the client so that the DHCP server knows from which IP subnet the newly allocated IP address should come. The following figure shows a basic DHCP network example: Boston Atlanta 20.1.1.1 DHCP Client 10.1.1.2 Web Switch DHCP Relay Agent DHCP Server Figure 1-5 DHCP Relay Agent Configuration In Alteon Web switch implementation, there is no need for primary or secondary servers. 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: >> >> >> >> >> >> # /cfg/ip/bootp Bootstrap Protocol Bootstrap Protocol Bootstrap Protocol Bootstrap Protocol Bootstrap Protocol Relay# Relay# Relay# Relay# Relay# addr addr2 on off cur (Set IP address of BOOTP server) (Set IP address of 2nd BOOTP server) (Globally turn BOOTP relay on) (Globally turn BOOTP relay off) (Display current configuration) Additionally, DHCP Relay functionality can be assigned on a per interface basis. Use the following command to enable the Relay functionality: >> # /cfg/ip/if /relay ena 42 n Chapter 1: Basic IP Routing 212777-A, February 2002 CHAPTER 2 VLANs This chapter describes network design and topology considerations for using Virtual Local Area Networks (VLANs). VLANs are commonly used to split up groups of network users into manageable broadcast domains, to create logical segmentation of workgroups, and to enforce security policies among logical segments. The following topics are discussed in this chapter: n “VLAN ID Numbers” on page 44 n “VLAN Tagging” on page 44 n “VLANs and the IP Interfaces” on page 45 This section briefly describes how management functions can only be accomplished from stations on VLANs that include an IP interface to the switch. n “VLAN Topologies and Design Issues” on page 45 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. n “VLANs and Spanning Tree Protocol” on page 49 n “VLANs and Default Gateways” on page 58 n “VLANs and Jumbo Frames” on page 63 NOTE – Basic VLANs can be configured during initial switch configuration (see “Using the Setup Utility” in the Web OS Command Reference). More comprehensive VLAN configuration can be done from the Command Line Interface (see “VLAN Configuration” as well as “Port Configuration” in the Web OS Command Reference). 43 212777-A, February 2002 Web OS 10.0 Application Guide VLAN ID Numbers Web OS supports up to 246 VLANs per switch. Even though the maximum number of VLANs supported at any given time is 246, each can be identified with any number between 1 and 4094. 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 44). Each port in the switch has a configurable default VLAN number, known as its PVID. The factory default value of all PVIDs is 1. This places all ports on the same VLAN initially, although each port’s PVID is configurable to any VLAN number between 1 and 4094. Any untagged frames (those with no VLAN specified) are classified with the sending port’s PVID. VLAN Tagging Web OS software supports 802.1Q VLAN tagging, providing standards-based VLAN support 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. 44 n Chapter 2: VLANs 212777-A, February 2002 Web OS 10.0 Application Guide VLANs and the IP Interfaces Carefully consider how you create VLANs within the switch, so that communication with the switch Management Processor (MP) 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 Interface Menu” section in the Web OS Command Reference). Likewise, you can cut off access to management functions to any VLAN by excluding IP interfaces from the VLAN’s membership. 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 Web OS software has a single VLAN configured on every port. This configuration 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 Web 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. Chapter 2: VLANs 212777-A, February 2002 n 45 Web OS 10.0 Application Guide Example 1: Multiple VLANS with Tagging Adapters Server #1 VLAN #3 Server #2 Gigabit/Tagged adapter (All VLANs) Alteon Web Switch Shared Media PC #1 VLAN #2 PC #2 VLAN #2 PC #3 VLAN #1 PC #4 VLAN #3 PC #5 Gigabit/Tagged adapter VLANs #1 & #2 Figure 2-1 Example 1: Multiple VLANs with Tagging Gigabit Adapters The features of this VLAN are described below: 46 n Component Description Web Switch This switch is configured for three VLANs that represent three different 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 subnets. The server has an VLAN-tagging adapter installed with VLAN tagging turned on. The adapter is attached to one of the Web 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. Chapter 2: VLANs 212777-A, February 2002 Web OS 10.0 Application Guide Component Description 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 only communicate with Server 2 and PC 5. PC #4 A member of VLAN 3, this PC can only communicate with 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 communicate with 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. NOTE – VLAN tagging is required only on ports that are connected to other Alteon Web switches or on ports that connect to tag-capable end-stations, such as servers with VLANtagging adapters. Chapter 2: VLANs 212777-A, February 2002 n 47 Web OS 10.0 Application Guide Example 2: Parallel Links with VLANs Web Switch 3 4 5 6 7 8 Data Link TX 2 1000 Base-SX 1 RX Gigabit Powered 10/100/10000 Mbps Ethernet Server Switch Data Link Active 9 Data Link Active RX TX RX TX RX TX RX TX RX TX RX TX RX TX Power RX Gigabit Ethernet Port 7 VLAN #10, VLAN #22 Web Switch Gigabit Powered 2 3 4 5 6 7 8 Data Link TX 1 1000 Base-SX 10/100/10000 Mbps Ethernet Server Switch Data Link Active Console Gigabit Ethernet Port 8 VLAN #32, VLAN #109 RX TX 9 Data Link Active TX RX TX RX TX RX TX RX TX RX TX RX TX RX TX RX Power Console 020 Figure 2-2 Example 2: Parallel Links with VLANs The following items describe the features of this example: 48 n n 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. n Two Alteon Web switches are connected with two different Gigabit Ethernet links. Without VLANs, this configuration would create a broadcast loop, but the STP topology resolution process resolves parallel loop-creating links. n To prevent broadcast loops, port 7 is on VLAN 10 and VLAN 22, port 8 is on VLAN 32 and VLAN 109. Both switch-to-switch links are on different VLANs and, thus, are separated into their own broadcast domains. n Ports 1 and 2 on both switches are on VLAN 10; ports 3 and 4 on both switches are on VLAN 22; Ports 5 and 6 on both switches are on VLAN 32; port 9 on both switches are on VLAN 109. n It is necessary to turn on Spanning Tree Protocol (STP) on at least one of the switch-toswitch links or, alternately, turned on in both switches. STP Bridge Protocol Data Units (BPDUs) will be transmitted out both Gigabit Ethernet ports and interpreted by the switch that there is a loop to resolve. n Spanning Tree is VLAN-aware. Chapter 2: VLANs 212777-A, February 2002 Web OS 10.0 Application Guide VLANs and Spanning Tree Protocol 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 2-1. Table 2-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 NOTE – Due to Spanning Tree’s sequence of listening, learning, and forwarding or blocking, lengthy delays may occur. For more information on using STP in cross-redundant topologies, see “Eliminating Loops with STP and VLANs” on page 278. Chapter 2: VLANs 212777-A, February 2002 n 49 Web OS 10.0 Application Guide Bridge Protocol Data Units (BPDUs) To create a Spanning Tree, the Web 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 Web switch adds its own bridge ID number and increments the path cost of the BPDU. The Web switch uses this information to block any necessary ports. Determining the Path for Forwarding BPDUs When determining which port to use for forwarding and which port to block, Web 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 Web OS 10.0 Command Reference. Much like least-cost routing, root cost assigns lower values to highbandwidth 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 19, and a 1000-Mbps (or Gigabit Ethernet) link has a cost of 4. The objective is to use the fastest links so that the route with the lowest cost is chosen. 50 n Chapter 2: VLANs 212777-A, February 2002 Web OS 10.0 Application Guide Multiple Spanning Trees Web OS 10.0 supports up to 16 instances of Spanning Trees or Spanning Tree groups. Each VLAN can be placed on a unique Spanning Tree group per switch except for the default Spanning 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 2-3 shows a simple example of why we need multiple Spanning Trees. Two VLANs, VLAN 1 and VLAN 100 exist between Web switch A and Web 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 Web switches without losing connectivity. VLAN 1 Web Switch A VLAN 100 Web Switch B Spanning Tree Group 1: VLAN 1 Spanning Tree Group 2: VLAN 100 Figure 2-3 Using Multiple Instances of Spanning Tree Protocol Chapter 2: VLANs 212777-A, February 2002 n 51 Web OS 10.0 Application Guide Example of a Four-Switch Topology with a Single Spanning Tree In the four-switch topology example shown in Figure 2-4 on page 52, and assuming Web switch A has a higher priority, you can have at least three loops on the network: n Data flowing from Web switches A to B to C and back to Web switch A. n Data flowing from Web switches A to C to D and back to Web switch A n Data flowing from Web switches A to B to C to D and back to Web switch A. With a single Spanning Tree environment, as shown in Figure 2-4, you will have two links blocked to prevent loops on the network. It is possible that the blocks may be between Web switches C and D and between Web switches B and C, depending on the bridge priority, port priority, and port cost. The two blocks would prevent looping on the network, but the blocked link between Web switches B and C will inadvertently isolate VLAN 3 altogether. NOTE – For more information on bridge priority, port priority, and port cost see the Web OS 10.0 Command Reference. Web Switch A AN VL AN 1 VL VLAN 1 Web Switch D Web Switch B STG 1 VL AN 2 N 3 A VL 1 Blocked Port Web Switch C Figure 2-4 VLAN 3 Isolated in a Single Spanning Tree Group 52 n Chapter 2: VLANs 212777-A, February 2002 Web OS 10.0 Application Guide Example of a 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 2-5 shows the same four-switch topology as in Figure 2-4 on page 52, but with multiple Spanning Trees enabled. The VLANs are identified on each of the three shaded areas connecting the switches. The port numbers are shown next to each switch. The Spanning Tree Group (STG) number for each VLAN is shown at the switch. Web Switch A STG 1 STG 2 Port 8 Port 1 Port 2 STG 1 Web Switch D VLAN 2 STG 1 Port 1 Port 1 Web Switch B VLAN 1 Port 8 Port 8 STG 2 VLAN 3 Port 2 Port 1 Port 8 STG 2 STG 1 Web Switch C Figure 2-5 Implementing Multiple Spanning Tree Groups Three instances of Spanning Tree are configured in the example shown in Figure 2-5. Refer to Table 2-2 on page 54 to identify the Spanning Tree group a VLAN is participating in for each switch. Chapter 2: VLANs 212777-A, February 2002 n 53 Web OS 10.0 Application Guide Table 2-2 Multiple Spanning Tree Groups per VLAN Web Switch A VLAN 1 VLAN 2 Spanning Tree Group 1 Ports 1 and 2 Spanning Tree Group 2 Port 8 Web Switch B Spanning Tree Group 1 Port 1 Web Switch C Spanning Tree Group 1 Ports 1 and 2 Web Switch D Spanning Tree Group 1 Ports 1 and 8 VLAN 3 Spanning Tree Group 2 Port 8 Spanning Tree Group 2 Port 8 Switch-Centric Spanning Tree Protocol In Figure 2-5 on page 53, VLAN 2 is shared by Web switch A and B on ports 8 and 1 respectively. Web switch A identifies VLAN 2 in Spanning Tree group 2 and Web switch B identifies VLAN 2 in Spanning Tree group 1. Spanning Tree group is switch-centric—it is used to identify the VLANs participating in the Spanning Tree groups. The Spanning Tree group ID is not transmitted in the BPDU. Each Spanning Tree decision is based on the configuration of that switch. 54 n Chapter 2: VLANs 212777-A, February 2002 Web OS 10.0 Application Guide VLAN Participation in Spanning Tree Groups The VLAN participation for each Spanning Tree group in Figure 2-5 on page 53 is discussed in the following sections: n VLAN 1 Participation If Web switch A is the root bridge, then Web switch A will transmit the BPDU for VLAN 1 on ports 1 and 2. Web switch C receives the BPDU on its port 2 and Web switch D receives the BPDU on its port 1. Web switch D will block port 8 or Web switch C will block port 1 depending on the information provided in the BPDU. n VLAN 2 Participation Web switch A, the root bridge generates another BPDU for Spanning Tree Group 2 and forwards it out from port 8. Web switch B receives this BPDU on its port 1. Port 1 on Web switch B is on VLAN 2, Spanning Tree group 1. Because Web switch B has no additional ports participating in Spanning Tree group 1, this BPDU is not be forwarded to any additional ports and Web switch A remains the designated root. n VLAN 3 Participation For VLAN 3 you can have Web switch B or C to be the root bridge. If Web switch B is the root bridge for VLAN 3, Spanning Tree group 2, then Web switch B transmits the BPDU out from port 8. Web switch C receives this BPDU on port 8 and is identified as participating in VLAN 3, Spanning Tree group 2. Since Web switch C has no additional ports participating in Spanning Tree group 2, this BPDU is not forwarded to any additional ports and Web switch B remains the designated root. Chapter 2: VLANs 212777-A, February 2002 n 55 Web OS 10.0 Application Guide Configuring Multiple Spanning Tree Groups This configuration shows how to configure the three instances of Spanning Tree groups on the Web switches A, B, C, and D illustrated in Figure 2-5 on page 53. 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 Web switch A: Add port 8 to VLAN 2 and define Spanning Tree group 2 for VLAN 2. >> >> >> >> >> # /cfg/vlan2 VLAN 2# add 8 VLAN 2# ../stp Enter Spanning Tree group index [1-16]# 2 Spanning Tree Group 2# add 2 (Select VLAN 2 menu) (Add port 8) (Select STP menu) (Select Spanning Tree Group 2) (Add VLAN 2) VLAN 2 is automatically removed from Spanning Tree Group 1. 2. Configure the following on Web switch B: Add port 1 to VLAN 2, port 8 to VLAN 3 and define Spanning Tree groups 2 for VLAN 3. >> >> >> >> >> >> >> >> # /cfg/vlan2 (Select VLAN 2 menu) VLAN 2# add 1 (Add port 1) VLAN 2# ../stp (Select STP menu) VLAN 2# ../vlan3 (Select VLAN 3 menu) VLAN 3# add 8 (Add port 8) VLAN 3# ../stp (Select STP menu) Enter Spanning Tree group index [1-16]# 2(Select group 2) Spanning Tree Group 2# add 2 (Add 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. 56 n Chapter 2: VLANs 212777-A, February 2002 Web OS 10.0 Application Guide 3. Configure the following on Web switch C: Add port 8 to VLAN 3 and define Spanning Tree group 3 for VLAN 3. >> >> >> >> >> # /cfg/vlan3 VLAN 3# add 8 VLAN 3# ../stp Enter Spanning Tree group index [1-16]# 3 Spanning Tree Group 2# add 3 (Select VLAN 3 menu) (Add port 8) (Select STP menu) (Select group 3) (Add VLAN 3) VLAN 3 is automatically removed from Spanning Tree group 1 and by default VLAN 2 remains in Spanning Tree Group 1. NOTE – Web switch D does not require any special configuration for multiple Spanning Trees, because it configured for the default Spanning Tree group (STG 1) only. Chapter 2: VLANs 212777-A, February 2002 n 57 Web OS 10.0 Application Guide VLANs and Default Gateways Web OS allows you to assign different default gateways for each VLAN. You can effectively map multiple customers to specific gateways on a single switch. The benefits of segregating customers to different default gateways are: n Resource optimization n Enhanced customer segmentation n Improved service differentiation Segregating VLAN Traffic Deploy this feature in an environment where you want to segregate VLAN traffic to a configured default gateway. In Figure 2-6, 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. Router 1 VLAN 4 10.10.1.20 Gateway 5: 10.10.1.20 Gateway 6: 10.10.1.30 Gateway 1: 10.10.4.1 nortelnetworks.com 192.168.20.200 yahoo.com 200.1.2.200 7 1 2 Internet Router 2 VLAN 4 10.10.1.30 VLAN 2 using Gateway 5 172.21.2.1 Web Switch 3 IF 3: 172.21.2.200 IF 4: 172.21.3.200 8 IF 1: 10.10.1.1 IF 2: 10.10.4.40 VLAN 3 using Gateway 6 172.21.3.1 Router 3 VLAN 1 10.10.4.1 Figure 2-6 Default Gateways per VLAN You can configure 246 default gateways per VLAN with values starting from 5 through 250. If default 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. 58 n Chapter 2: VLANs 212777-A, February 2002 Web OS 10.0 Application Guide In the example shown in Figure 2-6, if default 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/arp/dump on the switch command line will display the entries in the route cache similar to those shown in Table 2-3. The destination IP addresses (see the last two rows) are associated with the MAC addresses of the default gateways. Table 2-3 Route Cache Example Destination IP address Flags MAC address VLAN 10.10.1.1 P 00:60:cf:46:48:60 4 10.10.1.20 00:60:cf:44:cd:a0 4 1 empty 10.10.1.30 00:60:cf:42:3b:40 4 2 empty 10.10.4.1 00:60:cf:42:77:e0 1 3 empty 00:60:cf:46:48:60 1 00:50:da:17:c8:05 2 00:60:cf:46:48:60 2 00:c0:4f:09:3e:56 3 10.10.4.40 P 172.21.2.27 172.21.2.200 P 172.21.3.14 Port Referenced ports 1-9 1-9 7 1 1-9 8 2 172.21.2.200 P 00:60:cf:46:48:60 3 1-9 192.168.20.200 R 00:60:cf:44:cd:a0 4 1 7 200.1.2.200 R 00:60:cf:42:3b:40 4 2 8 As shown in Table 2-3, 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 configured default Gateway. Chapter 2: VLANs 212777-A, February 2002 n 59 Web OS 10.0 Application Guide 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. NOTE – Web OS allows you to configure up to five local networks. Configuring Default Gateways per VLAN Follow this procedure to configure the example shown in Figure 2-6: 1. Assign an IP address for each router and client workstation. 2. Assign an IP interface for each subnet attached to the switch. >> /cfg/ip/if 1 60 n >> >> >> >> >> >> >> >> >> >> IP IP IP IP IP IP IP IP IP IP Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface 1# 1# 1# 1# 1# 2# 2# 2# 2# 2# addr 10.10.1.1 mask 255.255.255.0 broad 10.10.1.255 vlan 4 ../if 2 addr 10.10.4.40 mask 255.255.255.0 broad 10.10.4.255 vlan 1 ../if 3 >> >> >> >> >> IP IP IP IP IP Interface Interface Interface Interface Interface 3# 3# 3# 3# 3# addr 172.21.2.200 mask 255.255.255.0 broad 172.21.2.255 vlan 2 ../if 4 >> >> >> >> IP IP IP IP Interface Interface Interface Interface 4# 4# 4# 4# addr 172.21.3.200 mask 255.255.255.0 broad 172.21.3.255 vlan 3 (Select IP interface 1 for gateway 5 & 6 subnet) (Assign IP address for interface 1) (Assign mask for IF 1) (Assign broadcast address for IF 1) (Assign VLAN 4 to IF 1) (Select IP interface 2 for gateway 1) (Assign IP address for interface 2) (Assign mask for IF 2) (Assign broadcast address for IF 2) (Assign VLAN 1 to IF 2) (Select IP interface 3 for VLAN 2 subnet) (Assign IP address for interface 3) (Assign mask for IF 3) (Assign broadcast address for IF 3) (Assign VLAN 2 to IF 3) (Select IP interface 4 for VLAN 3) subnet) (Assign IP address for interface 4) (Assign mask for IF 4) (Assign broadcast address for IF 4) (Assign VLAN 3 to IF 4) Chapter 2: VLANs 212777-A, February 2002 Web OS 10.0 Application Guide 3. Configure the default gateways. Configuring default gateways 5 and 6 for VLANs 2 and 3 respectively. Configure default gateway 1 for load balancing session requests and as backup when default gateways 5 and 6 fail. >> >> >> >> >> >> /cfg/ip/gw 5 Default gateway Default gateway Default gateway Default gateway Default gateway 5# 5# 6# 6# 1# addr 10.10.1.20 ../gw 6 addr 10.10.1.30 ../gw 1 addr 10.10.4.1 (Select default gateway 5) (Assign IP address for gateway 5) (Select default gateway 6) (Assign IP address for gateway 6) (Select default gateway 1) (Assign IP address for gateway 1) NOTE – The IP address for default gateways 1 to 4 must be unique. IP addresses for default gateways 5 to 250 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 default gateways and enable them. >> >> >> >> >> >> >> >> 5. /cfg/ip/gw 5 Default gateway Default gateway Default gateway Default gateway Default gateway Default gateway Default gateway 5# 5# 5# 6# 6# 6# 1# vlan 2 ena ../ gw 6 vlan 3 ena ../gw 1 ena (Select default gateway 5) (Add VLAN 2 for default gateway 5) (Enable default gateway 5) (Select default gateway 6) (Add VLAN 3 for default gateway 6) (Enable default gateway 6) (Select default gateway 1) (Enable gateway 1 for all VLAN s) Apply and verify your configuration. >> Default gateway 1# ../cur (View current IP settings) Examine the results under the gateway section. If any settings are incorrect, make the appropriate changes. Chapter 2: VLANs 212777-A, February 2002 n 61 Web OS 10.0 Application Guide 6. (Optional) Configure the local networks to ensure that the VLANs use the configured default gateways. >> IP# frwd/local >> IP Forwarding# add 10.10.0.0 >> >> >> >> >> 7. IP IP IP IP IP Forwarding# Forwarding# Forwarding# Forwarding# Forwarding# mask 255.255.0.0 add 172.21.2.0 mask 255.255.255.0 add 172.21.3.0 mask 255.255.255.0 (Select the local network Menu) (Specify the network for routers 1, 2, & 3) (Add the mask for the routers) (Specify the network for VLAN 2) (Add the mask for VLAN 2 network) (Specify the network for VLAN 3) (Add the mask for VLAN 3) Apply and save your new configuration changes. >> IP Forwarding# apply >> IP Forwarding# save 62 n Chapter 2: VLANs 212777-A, February 2002 Web OS 10.0 Application Guide VLANs and Jumbo Frames To reduce host frame processing overhead, Gigabit network adapters that can handle frame sizes of 9K and higher (such as the 3COM PCI-X/PCI Gigabit adapters) and Alteon Web switches, both running operating Web OS version 2.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. 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. 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 Web switches can communicate across both the Jumbo frame VLANs and regular frame VLANs at the same time. In the example illustrated in Figure 2-7 on page 64, 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. Chapter 2: VLANs 212777-A, February 2002 n 63 Web OS 10.0 Application Guide Jumbo Frame VLAN Normal Frame VLAN Normal Frame VLAN Figure 2-7 Jumbo Frame VLANs Routing Jumbo Frames to Non-Jumbo Frame VLANs When IP routing is used to route traffic between VLANs, the switch will fragment Jumbo UDP datagrams when routing from a Jumbo frame VLAN to a non-Jumbo frame VLAN. The resulting Jumbo frame to regular frame conversion makes implementation even easier. 64 n Chapter 2: VLANs 212777-A, February 2002 CHAPTER 3 Port Trunking Trunk groups can provide super-bandwidth, multi-link connections between Alteon Web 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: n Overview n “Port Trunking Example” on page 67 Overview When using port trunk groups between two Alteon Web switches as shown in Figure 3-1, you can create a virtual link between the switches operating up to six gigabits per second, depending on how many physical ports are combined. The switch supports up to four trunk groups per switch, each with two to six links. 6 7 Web Switch Gigabit Powered 8 Data Link Gigabit Powered 10/100/10000 Mbps Ethernet Server Switch Data Link Active 9 Data Link Active 1 2 3 4 5 6 7 8 Data Link RX 5 TX 4 TX 3 RX 2 1000 Base-SX 1 1000 Base-SX Web Switch 10/100/10000 Mbps Ethernet Server Switch Data Link Active 9 Data Link Active TX RX TX RX TX RX TX RX TX RX TX RX TX RX TX Power RX Console TX RX TX RX TX RX TX RX TX RX TX RX TX RX TX RX Power Console 041 Aggregate Port Trunk Figure 3-1 Port Trunk Group Trunk groups are also useful for connecting an Alteon Web 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 Networks trunk group technology is compatible with these devices when they are configured manually. 65 212777-A, February 2002 Web OS 10.0 Application Guide Statistical Load Distribution Network traffic is statistically load balanced between the ports in a trunk group. The Web OSpowered 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 packet’s particular combination of source and destination MAC addresses results in selecting one line in the trunk group for data transmission. If there are enough Layer 2 devices feeding the trunk lines, then traffic distribution becomes relatively even. In some topologies, however, only a limited number of Layer 2 devices (such as a handful 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. 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. 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. 66 n Chapter 3: Port Trunking 212777-A, February 2002 Web OS 10.0 Application Guide Port Trunking Example In the example below, three ports will be trunked between two Alteon Web switches. Switch #1 Switch #2 Data Link Active TX RX 2 TX RX TX RX 5 4 5 TX RX TX RX 6 7 8 Data Link 1 2 3 Data Link Active TX RX TX RX TX RX Power Gigabit Powered 10/100/10000 Mbps Ethernet Server Switch Data Link Active 9 Console TX RX TX RX TX RX 4 4 TX RX 5 TX RX 6 6 TX RX 7 TX RX 8 TX Data Link TX 4 9 RX RX 3 TX 2 RX 1 1000 Base-SX 10/100/10000 Mbps Ethernet Server Switch Data Link Active Web Switch Gigabit Powered 1000 Base-SX Web Switch Power 9 Console 042 Trunk 1: Ports 2, 4, and 5 on Switch 1 Trunk 3: Ports 4, 6, and 9 on Switch 2 Figure 3-2 Port Trunk Group Configuration Example Prior to configuring each switch in the above example, you must connect to the appropriate switch’s Command Line Interface (CLI) as the administrator. NOTE – For details about accessing and using any of the menu commands described in this example, see the Web OS Command Reference. 1. Connect the switch ports that will be involved in the trunk group. 2. Follow these steps on Web switch 1: (a) Define a trunk group. >> >> >> >> >> # /cfg/trunk 1 Trunk group 1# Trunk group 1# Trunk group 1# Trunk group 1# add 2 add 4 add 5 ena (Select trunk group 1) (Add port 2 to trunk group 1) (Add port 4 to trunk group 1) (Add port 5 to trunk group 1) (Enable trunk group 1) (b) Apply and verify the configuration. >> Trunk group 1# apply >> Trunk group 1# cur (Make your changes active) (View current trunking configuration) Examine the resulting information. If any settings are incorrect, make appropriate changes. (c) Save your new configuration changes. >> Trunk group 1# save (Save for restore after reboot) Chapter 3: Port Trunking 212777-A, February 2002 n 67 Web OS 10.0 Application Guide 3. Repeat the process on Web switch 2. >> >> >> >> >> >> >> >> # /cfg/trunk 3 Trunk group 3# Trunk group 3# Trunk group 3# Trunk group 3# Trunk group 3# Trunk group 3# Trunk group 3# add 4 add 6 add 9 ena apply cur save (Select trunk group 3) (Add port 4 to trunk group 3) (Add port 6 to trunk group 3) (Add port 9 to trunk group 3) (Enable trunk group 3) (Make your changes active) (View current trunking configuration) (Save for restore after reboot) Trunk group 1 (on Web switch 1) is now connected to trunk group 3 (on Web switch 2). NOTE – In this example, two Alteon Web 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 configured manually. Connection problems could arise when using automatic trunk group negotiation on the third-party device. 4. Examine the trunking information on each switch. >> /info/trunk (View trunking information) Information about each port in each configured trunk group will be displayed. Make sure that trunk groups consist of the expected ports and that each port is in the expected state. The following restrictions apply: 68 n n Any physical switch port can belong to only one trunk group. n Up to four ports can belong to the same trunk group. n Best performance is achieved when all ports in any given trunk group are configured for the same speed. n Trunking from non-Alteon devices must comply with Cisco® EtherChannel® technology. Chapter 3: Port Trunking 212777-A, February 2002 CHAPTER 4 OSPF Web OS 10.0 supports the Open Shortest Path First (OSPF) routing protocol. The Web OS implementation conforms to the OSPF version 2 specifications detailed in Internet RFC 1583. The following sections discuss OSPF support for the Alteon AD4/184 Web switches: n “OSPF Overview” on page 69. 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. n “OSPF Implementation in Web OS” on page 74. This section describes how OSPF is implemented in Web OS, such as configuration parameters, electing the designated router, summarizing routes, defining route maps and so forth. n “OSPF Configuration Examples” on page 83. This section provides step-by-step instructions on configuring four different configuration examples: o Creating a simple OSPF domain o Creating virtual links o Summarizing routes o Creating host routes OSPF Overview OSPF is designed for routing traffic within a single IP domain called an Autonomous System (AS). The AS can be divided into smaller logical units known as areas. All routing devices maintain link information in their own Link State Database (LSDB). 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. 69 212777-A, February 2002 Web OS 10.0 Application Guide Types of OSPF Areas An AS can be broken into logical units known as areas. In any AS with multiple areas, one area must be designated as area 0, known as the backbone. The backbone acts as the central OSPF area. All other areas in the AS must be connected to the backbone. Areas inject summary routing information into the backbone, which then distributes it to other areas as needed. As shown in Figure 4-1, OSPF defines the following types of areas: n Stub Area—an area that is connected to only one other area. External route information is not distributed into stub areas. n 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. n Transit Area—an area that allows area summary information to be exchanged between routing devices. The backbone (area 0), any area that contains a virtual link to connect two areas, and any area that is not a stub area or an NSSA are considered transit areas. Backbone Area 0 (Also a Transit Area) ABR ABR ABR Internal LSA Routes Stub Area Transit Area Virtual Link No External Routes from Backbone Not-So-Stubby Area (NSSA) ABR External LSA Routes ASBR Non-OSPF Area RIP/BGP AS ABR = Area Border Router ASBR = Autonomous System Boundary Router Stub Area, NSSA, or Transit Area Connected to Backbone via Virtual Link Figure 4-1 OSPF Area Types 70 n Chapter 4: OSPF 212777-A, February 2002 Web OS 10.0 Application Guide Types of OSPF Routing Devices As shown in Figure 4-2, OSPF uses the following types of routing devices: n Internal Router (IR)—a router that has all of its interfaces within the same area. IRs maintain LSDBs identical to those of other routing devices within the local area. n 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. n 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. OSPF Autonomous System Backbone Area 0 BGP External Routes Area 3 Inter-Area Routes (Summary Routes) ASBR ABR RIP ABR ASBR Area 1 ABR Internal Router Area 2 Figure 4-2 OSPF Domain and an Autonomous System Chapter 4: OSPF 212777-A, February 2002 n 71 Web OS 10.0 Application Guide Neighbors and Adjacencies In areas with two or more routing devices, neighbors and adjacencies are formed. Neighbors are routing devices that maintain information about each others’ health. To establish neighbor relationships, routing devices periodically send hello packets on each of their interfaces. All routing devices that share a common network segment, appear in the same area, and have the same health parameters (hello and dead intervals) and authentication parameters respond to each other’s hello packets and become neighbors. Neighbors continue to send periodic hello packets to advertise their health to neighbors. In turn, they listen to hello packets to determine the health of their neighbors and to establish contact with new neighbors. The hello process is used for electing one of the neighbors as the area’s Designated Router (DR) and one as the area’s Backup Designated Router (BDR). The DR is adjacent to all other neighbors and acts as the central contact for database exchanges. Each neighbor sends its database information to the DR, which relays the information to the other neighbors. The BDR is adjacent to all other neighbors (including the DR). Each neighbor sends its database information to the BDR just as with the DR, but the BDR merely stores this data and does not distribute it. If the DR fails, the BDR will take over the task of distributing database information to the other neighbors. The Link-State Database OSPF is a link-state routing protocol. A link represents an interface (or routable path) from the routing device. By establishing an adjacency with the DR, each routing device in an OSPF area maintains an identical Link-State Database (LSDB) describing the network topology for its area. Each routing device transmits a Link-State Advertisement (LSA) on each of its interfaces. LSAs are entered into the LSDB of each routing device. OSPF uses flooding to distribute LSAs between routing devices. When LSAs result in changes to the routing device’s LSDB, the routing device forwards the changes to the adjacent neighbors (the DR and BDR) for distribution to the other neighbors. OSPF routing updates occur only when changes occur, instead of periodically. For each new route, if an adjacency is interested in that route (for example, if configured to receive 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. 72 n Chapter 4: OSPF 212777-A, February 2002 Web OS 10.0 Application Guide The Shortest Path First Tree The routing devices use a link-state algorithm (Dijkstra’s algorithm) to calculate the shortest path to all known destinations, based on the cumulative cost required to reach the destination. The cost of an individual interface in OSPF is an indication of the overhead required to send packets across it. The cost is inversely proportional to the bandwidth of the interface. A 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 autonomous 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. Chapter 4: OSPF 212777-A, February 2002 n 73 Web OS 10.0 Application Guide OSPF Implementation in Web OS Web OS 10.0 supports a single instance of OSPF and up to 1K routes on the network. The following sections describe OSPF implementation in Web OS: n “Configurable Parameters” on page 74 n “Defining Areas” on page 75 n “Interface Cost” on page 77 n “Electing the Designated Router and Backup” on page 77 n “Summarizing Routes” on page 77 n “Default Routes” on page 78 n “Virtual Links” on page 79 n “Router ID” on page 80 n “Authentication” on page 80 n “Host Routes for Load Balancing” on page 82 n “OSPF Features Not Supported in This Release” on page 82 Configurable Parameters In Web OS 10.0, OSPF parameters can be configured through the Command Line Interface (CLI), Web OS Browser-Based Interface (BBI) for Alteon AD4 and 184 switches, or through SNMP. 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: 74 n n Shortest Path First (SPF) interval—Time interval between successive calculations of the shortest path tree using the Dijkstra’s algorithm. n Stub area metric—A stub area can be configured to send a numeric metric value such that all routes received via that stub area carry the configured metric to potentially influence routing decisions. n Default routes—Default routes with weight metrics can be manually injected into transit areas. This helps establish a preferred route when multiple routing devices exist between two areas. It also helps route traffic to external networks. Chapter 4: OSPF 212777-A, February 2002 Web OS 10.0 Application Guide Defining Areas If you are configuring multiple areas in your OSPF domain, one of the areas must be designated as area 0, known as the backbone. The backbone is the central OSPF area and is usually physically connected to all other areas. The areas inject routing information into the backbone which, in turn, disseminates the information into other areas. Since the backbone connects the areas in your network, it must be a contiguous area. If the backbone is partitioned (possibly as a result of joining separate OSPF networks), parts of the AS will be unreachable, and you will need to configure virtual links to reconnect the partitioned areas (see “Virtual Links” on page 79). Up to three OSPF areas can be connected to a Web switch with Web OS 10.0 software. To configure an area, the OSPF number must be defined and then attached to a network interface on the Web switch. The full process is explained in the following sections. An OSPF area is defined by assigning two pieces of information—an area index and an area ID. The command to define an OSPF area is as follows: >> # /cfg/ip/ospf/aindex /areaid 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 option is actually just an arbitrary index (0-2) used only by the Web switch. This index does not necessarily represent the OSPF area number, though for configuration 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: n Area index and area ID agree /cfg/ip/ospf/aindex 0/areaid 0.0.0.0 (Use index 0 to set area 0 in ID octet format) /cfg/ip/ospf/aindex 1/areaid 0.0.0.1 (Use index 1 to set area 1 in ID octet format) n Area index set to an arbitrary value /cfg/ip/ospf/aindex 1/areaid 0.0.0.0 (Use index 1 to set area 0 in ID octet format) /cfg/ip/ospf/aindex 2/areaid 0.0.0.1 (Use index 2 to set area 1 in ID octet format) Chapter 4: OSPF 212777-A, February 2002 n 75 Web OS 10.0 Application Guide Using the Area ID to Assign the OSPF Area Number The OSPF area number is defined in the areaid option. The octet format is used in order to be compatible with two different systems of notation used by other OSPF network vendors. There are two valid ways to designate an area ID: n Placing the area number in the last octet (0.0.0.n) Most common OSPF vendors express the area ID number as a single number. For example, the Cisco IOS-based router command “network 1.1.1.0 0.0.0.255 area 1” defines the area number simply as “area 1.” On the Web switch, using the last octet in the area ID, “area 1” is equivalent to “areaid 0.0.0.1”. n 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 Web 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: >> # /cfg/ip/ospf/if /aindex For example, the following commands could be used to configure IP interface 14 for a presence on the 10.10.10.1/24 network, to define OSPF area 1, and to attach the area to the network: >> # /cfg/ip/if 14 >> IP Interface 14# addr 10.10.10.1 >> >> >> >> >> >> >> IP Interface 14# mask 255.255.255.0 IP Interface 14# ena IP Interface 14# ../ospf/aindex 1 OSPF Area (index) 1 # areaid 0.0.0.1 OSPF Area (index) 1 # ena OSPF Area (index) 1 # ../if 14 OSPF Interface 14# aindex 1 >> OSPF Interface 14# enable 76 n (Select menu for IP interface 14) (Define IP address on backbone network) (Define IP mask on backbone) (Enable IP interface 14) (Select menu for area index 1) (Define area ID as OSPF area 1) (Enable area index 1) (Select OSPF menu for interface 14) (Attach area to network on interface 14) (Enable interface 14 for area index 1) Chapter 4: OSPF 212777-A, February 2002 Web OS 10.0 Application Guide Interface Cost The OSPF link-state algorithm (Dijkstra’s algorithm) places each routing device at the root of a tree and determines the cumulative cost required to reach each destination. Usually, the cost is inversely proportional to the bandwidth of the interface. Low cost indicates high bandwidth. You can manually enter the cost for the output route with the following command: >> # /cfg/ip/ospf/if /cost 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 Web switch’s OSPF interfaces. The command is as follows: >> # /cfg/ip/ospf/if /prio 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 lowest router ID wins. Summarizing Routes Route summarization condenses routing information. Without summarization, each routing device in an OSPF network would retain a route to every subnet in the network. With summarization, routing devices can reduce some sets of routes to a single advertisement, reducing both the load on the routing device and the perceived complexity of the network. The importance of route summarization increases with network size. Summary routes can be defined for up to 16 IP address ranges using the following command: >> # /cfg/ip/ospf/range /addr /mask where is a number 1 to 16, is the base IP address for the range, and is the IP address mask for the range. For a detailed configuration example, see “Example 3: Summarizing Routes” on page 90. Chapter 4: OSPF 212777-A, February 2002 n 77 Web OS 10.0 Application Guide Default Routes When an OSPF routing device encounters traffic for a destination address it does not recognize, 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 Web 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 4-3), any traffic for IP address destinations outside the area is forwarded to the switch’s IP interface, and then into the connected transit area (usually the backbone). Since this is automatic, no further configuration is required for such areas. Stub Area Area 1 Backbone Area 0 ABR IR Default Route IF 2 Metric: 900 ABR IF 1 Priority Default Route IF 1 IF 1 Metric: 10 Metric: Metric: 201 201 Metric: 200 Stub Area Area 2 IR IF 2 Priority Default Route IF 2 ABR ASBR to External Networks Figure 4-3 Injecting Default Routes In more complex OSPF areas with multiple ABRs or ASBRs (such as area 0 and area 2 in Figure 4-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 setting the metric value: >> # /cfg/ip/ospf/default where 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. To clear a default route metric from the switch, use the following command: >> # /cfg/ip/ospf/default none 78 n Chapter 4: OSPF 212777-A, February 2002 Web OS 10.0 Application Guide 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 4-1 on page 70). The area which contains a virtual link must be a transit area and have full routing information. Virtual links cannot be configured inside a stub area or NSSA. The area type must be defined as transit using the following command: >> # /cfg/ip/ospf/aindex /type transit The virtual link must be configured on the routing devices at each endpoint of the virtual link, though they may traverse multiple routing devices. To configure an Alteon Web switch as one endpoint of a virtual link, use the following command: >> # /cfg/ip/ospf/virt /aindex /nbr where is a value between 1 and 3, is the OSPF area index of the transit area, and 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 Web 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 86. Chapter 4: OSPF 212777-A, February 2002 n 79 Web OS 10.0 Application Guide 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 interface range or in any OSPF area. The router ID can be configured in one of the following two ways: n n Dynamically—OSPF protocol configures the lowest IP interface IP address as the router ID. This is the default. Statically—Use the following command to manually configure the router ID: >> # /cfg/ip/ospf/rtrid n To modify the router ID from static to dynamic, set the router ID to 0.0.0.0, save the configuration, and reboot the Web switch. To view the router ID, enter: >> # /info/ospf/gen Authentication OSPF protocol exchanges are authenticated so that only trusted routing devices can participate. This ensures less processing on routing devices that are not listening to OSPF packets. OSPF allows packet authentication and uses IP multicast when sending and receiving packets. Routers participate in routing domains based on predefined passwords. Web OS 10.0 supports simple password authentication (type 1 plain text passwords) only. This type of authentication allows a password to be configured per area. Figure 4-4 shows authentication configured for area 0 with the password test. Simple authentication is also configured for the virtual link between area 2 and area 0. Area 1 is not configured for OSPF authentication. Area 0 Simple authentication key=test Area 1 ABR IF 4 Web switch 2 IF 5 ABR IF 2 Web switch 1 Web switch 3 IF 3 Web switch 4 Area 2 IF 1 Virtual link key=alteon ASBR to External Networks Web switch 5 Figure 4-4 OSPF Authentication 80 n Chapter 4: OSPF 212777-A, February 2002 Web OS 10.0 Application Guide To configure OSPF passwords on the Web switches shown in Figure 4-4 use the following commands: 1. Enable OSPF authentication for Area 0 on Web switches 1, 2, and 3. >> # /cfg/ip/ospf/aindex 0/auth password (Turn on OSPF password authentication) 2. Configure a simple text password up to eight characters for each OSPF IP interface in Area 0 on Web switches 1, 2, and 3. >> >> >> >> >> >> 3. # /cfg/ip/ospf/if 1 OSPF Interface 1 # key test OSPF Interface 1 # ../if 2 OSPF Interface 2 # key test OSPF Interface 1 # ../if 3 OSPF Interface 3 # key test Enable OSPF authentication for Area 2 on Web switch 4. >> # /cfg/ip/ospf/aindex 2/auth password (Turn on OSPF password authentication) 4. Configure a simple text password up to eight characters for the virtual link between Area 2 and Area 0 on Web switches 2 and 4. >> # /cfg/ip/ospf/virt 1/key alteon Chapter 4: OSPF 212777-A, February 2002 n 81 Web OS 10.0 Application Guide Host Routes for Load Balancing Web OS 10.0 implementation of OSPF includes host routes. Host routes are used for advertising network device IP addresses to external networks, accomplishing the following goals: n Server Load Balancing (SLB) within OSPF Host routes advertise virtual server IP addresses to external networks. This allows standard SLB between the Web switch and the server pools in an OSPF environment. For more information on SLB, see Chapter 6, “Server Load Balancing and your Web OS 10.0 Command Reference. n 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 Web switch provides identical services but advertises a host route for a different virtual server IP address to the external network. If each virtual server IP address serves a different and equal portion of the external world, incoming traffic from the upstream router should be split evenly among ABRs. n 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 Web switch defaults to the OSPF-derived route. For a configuration example, see “Example 4: Host Routes” on page 92. OSPF Features Not Supported in This Release The following OSPF features are not supported in this release: 82 n n Redistributing routes into OSPF (Web OS 10.0 does not allow your switch to emulate an ASBR) n Summarizing external routes n Filtering OSPF routes n Configuring equal cost route load balancing n Using OSPF to forward multicast routes n Configuring OSPF on non-broadcast multi-access networks (such as frame relay, X.25, and ATM) Chapter 4: OSPF 212777-A, February 2002 Web OS 10.0 Application Guide OSPF Configuration Examples A summary of the basic steps for configuring OSPF on the Web 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 Web switch. 2. (Optional) Configure the router ID. The router ID is required only when configuring virtual links on the Web 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. Chapter 4: OSPF 212777-A, February 2002 n 83 Web OS 10.0 Application Guide Example 1: Simple OSPF Domain In this example, two OSPF areas are defined—one area is the backbone and the other is a stub area. A stub area does not allow advertisements of external routes, thus reducing the size of the database. Instead, a default summary route of IP address 0.0.0.0 is automatically inserted into the stub area. Any traffic for IP address destinations outside the stub area will be forwarded to the stub area’s IP interface, and then into the backbone. Backbone Stub Area Area 0 Area 1 (0.0.0.0) (0.0.0.1) IF 1 IF 2 10.10.7.1 10.10.12.1 Network 10.10.7.0/24 Network 10.10.12.0/24 Figure 4-5 A Simple OSPF Domain Follow this procedure to configure OSPF support as shown in Figure 4-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. # /cfg/ip/if IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface 1 1 1 1 1 1 2 2 1 # # # # # # # # addr 10.10.7.1 mask 255.255.255.0 broad 10.10.7.255 enable ../if 2 addr 10.10.12.1 enable mask 255.255.255.0 Enable OSPF. >> IP Interface 2 # /cfg/ip/ospf/on 84 n (Select menu for IP interface 1) (Set IP address on backbone network) (Set IP mask on backbone network) (Set the broadcast address) (Enable IP interface 1) (Select menu for IP interface 2) (Set IP address on stub area network) (Enable IP interface 2) (Set IP mask on backbone network) (Enable OSPF on the Web switch) Chapter 4: OSPF 212777-A, February 2002 Web OS 10.0 Application Guide 3. Define the backbone. The backbone is always configured as a transit area using areaid 0.0.0.0. >> >> >> >> 4. Shortest Path First # aindex 0 Area (index) 0 # areaid 0.0.0.0 Area (index) 0 # type transit Area (index) 0 # enable OSPF OSPF OSPF OSPF Area Area Area Area (index) (index) (index) (index) 0 1 1 1 # # # # ../aindex 1 areaid 0.0.0.1 type stub enable (Select OSPF menu for IP interface 1) (Attach network to backbone index) (Enable the backbone interface) Attach the network interface to the stub area. >> OSPF Interface 1 # ../if 2 >> OSPF Interface 2 # aindex 1 >> OSPF Interface 2 # enable 7. (Select menu for area index 1) (Set the area ID for OSPF area 1) (Define area as stub type) (Enable the area) Attach the network interface to the backbone. >> OSPF Area 1 # ../if 1 >> OSPF Interface 1 # aindex 0 >> OSPF Interface 1 # enable 6. (Select menu for area index 0) (Set the ID for backbone area 0) (Define backbone as transit type) (Enable the area) Define the stub area. >> >> >> >> 5. Open OSPF OSPF OSPF (Select OSPF menu for IP interface 2) (Attach network to stub area index) (Enable the stub area interface) Apply and save the configuration changes. >> OSPF Interface 2 # apply >> OSPF Interface 2 # save (Global command to apply all changes) (Global command to save all changes) Chapter 4: OSPF 212777-A, February 2002 n 85 Web OS 10.0 Application Guide Example 2: Virtual Links In the example shown in Figure 4-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. Backbone Area 0 Transit Area Switch #1 (0.0.0.0) Area 1 Stub Area Switch #2 (0.0.0.1) Area 2 (0.0.0.2) IF 1 IF 2 IF 1 IF 2 10.10.7.1 10.10.12.1 10.10.12.2 10.10.24.1 Virtual Link 1 10.10.7.0/24 Network Router ID: 10.10.10.1 10.10.12.0/24 Network Router ID: 10.10.14.1 10.10.24.0/24 Network Figure 4-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. # /cfg/ip/if IP Interface IP Interface IP Interface IP Interface IP Interface 1 1 1 1 2 2 # # # # # addr 10.10.7.1 enable ../if 2 addr 10.10.12.0 enable (Select menu for IP interface 1) (Set IP address on backbone network) (Enable IP interface 1) (Select menu for IP interface 2) (Set IP address on transit area network) (Enable interface 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 Web Switch 2, the router ID specified here will be used as the target virtual neighbor (nbr) address. >> IP Interface 2 # /cfg/ip/ospf/rtrid 10.10.10.1(Set static router ID on Web switch 1) 3. Enable OSPF. >> IP # /cfg/ip/ospf/on 86 n (Enable OSPF on Web switch 1) Chapter 4: OSPF 212777-A, February 2002 Web OS 10.0 Application Guide 4. Define the backbone. >> >> >> >> 5. Open OSPF OSPF OSPF Shortest Path First # aindex 0 Area (index) 0 # areaid 0.0.0.0 Area (index) 0 # type transit Area (index) 0 # enable (Select menu for area index 0) (Set the area ID for backbone area 0) (Define backbone as transit type) (Enable the area) Define the transit area. The area that contains the virtual link must be configured as a transit area. >> >> >> >> 6. OSPF OSPF OSPF OSPF Area Area Area Area (index) (index) (index) (index) 0 1 1 1 # # # # ../aindex 1 areaid 0.0.0.1 type transit enable Attach the network interface to the backbone. >> OSPF Area (index) 1 # ../if 1 >> OSPF Interface 1 # aindex 0 >> OSPF Interface 1 # enable 7. (Select OSPF menu for IP interface 1) (Attach network to backbone index) (Enable the backbone interface) Attach the network interface to the transit area. >> OSPF Interface 1 # ../if 2 >> OSPF Interface 2 # aindex 1 >> OSPF Interface 2 # enable 8. (Select menu for area index 1) (Set the area ID for OSPF area 1) (Define area as transit type) (Enable the area) (Select OSPF menu for IP interface 2) (Attach network to transit area index) (Enable the transit area interface) Configure the virtual link. The nbr router ID configured in this step must be the same as the router ID that will be configured for Switch #2 in Step 2 on page 88. >> >> >> >> 9. OSPF OSPF OSPF OSPF Interface 2 # ../virt 1 Virtual Link 1 # aindex 1 Virtual Link 1 # nbr 10.10.14.1 Virtual Link 1 # enable (Specify a virtual link number) (Specify the transit area for the virtual link) (Specify the router ID of the recipient) (Enable the virtual link) Apply and save the configuration changes. >> OSPF Interface 2 # apply >> OSPF Interface 2 # save (Global command to apply all changes) (Global command to save all changes) Chapter 4: OSPF 212777-A, February 2002 n 87 Web OS 10.0 Application Guide Configuring OSPF for a Virtual Link on Switch #2 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. # /cfg/ip/if IP Interface IP Interface IP Interface IP Interface IP Interface 1 1 1 1 2 2 # # # # # addr 10.10.12.2 enable ../if 2 addr 10.10.24.1 enable (Select menu for IP interface 1) (Set IP address on transit area network) (Enable IP interface 1) (Select menu for IP interface 2) (Set IP address on stub area network) (Enable IP interface 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 Web switch 1 in Step 8 on page 87. >> IP Interface 2 # /cfg/ip/rtrid 10.10.14.1 (Set static router ID on Web switch 2) 3. Enable OSPF. (Enable OSPF on Web switch 2) >> IP# /cfg/ip/ospf/on 4. Define the backbone. This version of Web OS 10.0 requires that a backbone index be configured on the non-backbone end of the virtual link as follows: >> Open Shortest Path First # aindex 0 >> OSPF Area (index) 0 # areaid 0.0.0.0 >> OSPF Area (index) 0 # enable 5. Define the transit area. >> >> >> >> 88 n (Select the menu for area index 0) (Set the area ID for OSPF area 0) (Enable the area) OSPF OSPF OSPF OSPF Area Area Area Area (index) (index) (index) (index) 0 1 1 1 # # # # ../aindex 1 areaid 0.0.0.1 type transit enable (Select menu for area index 1) (Set the area ID for OSPF area 1) (Define area as transit type) (Enable the area) Chapter 4: OSPF 212777-A, February 2002 Web OS 10.0 Application Guide 6. Define the stub area. >> >> >> >> 7. OSPF OSPF OSPF OSPF Area Area Area Area (index) (index) (index) (index) 1 2 2 2 # # # # ../aindex 2 areaid 0.0.0.2 type stub enable Attach the network interface to the backbone. >> OSPF Area (index) 2 # ../if 1 >> OSPF Interface 1 # aindex 1 >> OSPF Interface 1 # enable 8. (Select OSPF menu for IP interface 1) (Attach network to transit area index) (Enable the transit area interface) Attach the network interface to the transit area. >> OSPF Interface 1 # ../if 2 >> OSPF Interface 2 # aindex 2 >> OSPF Interface 2 # enable 9. (Select the menu for area index 2) (Set the area ID for OSPF area 2) (Define area as stub type) (Enable the area) (Select OSPF menu for IP interface 2) (Attach network to stub area index) (Enable the stub area interface) Configure the virtual link. The nbr router ID configured in this step must be the same as the router ID that was configured for Web switch #1 in Step 2 on page 86. >> >> >> >> OSPF OSPF OSPF OSPF Interface 2 # ../virt 1 Virtual Link 1 # aindex 1 Virtual Link 1 # nbr 10.10.10.1 Virtual Link 1 # enable (Specify a virtual link number) (Specify the transit area for the virtual link) (Specify the router ID of the recipient) (Enable the virtual link) 10. Apply and save the configuration changes. >> OSPF Interface 2 # apply >> OSPF Interface 2 # save (Global command to apply all changes) (Global command to save all changes) Other Virtual Link Options n You can use redundant paths by configuring multiple virtual links. n 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. Chapter 4: OSPF 212777-A, February 2002 n 89 Web OS 10.0 Application Guide 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 configure 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.0.0 through 36.128.254.255 except for the routes in the range 36.128.200.0 through 36.128.200.255. Backbone Stub Area Area 0 Area 1 (0.0.0.0) (0.0.0.1) IF 1 IF 2 10.10.7.1 36.128.192.1 Summary Route 36.128.192.x to 36.128.254.x ABR 10.10.7.0/24 Network 36.128.192.0/18 Network Figure 4-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. Follow this procedure to configure OSPF support as shown in Figure 4-7: 1. Configure IP interfaces for each network which will be attached to OSPF areas. >> # /cfg/ip/if >> IP Interface >> IP Interface >> IP Interface >> IP Interface >> IP Interface 2. 1 1 1 1 2 2 # # # # # addr 10.10.7.1 ena ../if 2 addr 36.128.192.1 ena Enable OSPF. >> IP Interface 2 # /cfg/ip/ospf/on 90 n (Select menu for IP interface 1) (Set IP address on backbone network) (Enable IP interface 1) (Select menu for IP interface 2) (Set IP address on stub area network) (Enable IP interface 2) (Enable OSPF on the Web switch) Chapter 4: OSPF 212777-A, February 2002 Web OS 10.0 Application Guide 3. Define the backbone. >> >> >> >> 4. Shortest Path First # aindex 0 Area (index) 0 # areaid 0.0.0.0 Area (index) 0 # type transit Area (index) 0 # enable OSPF OSPF OSPF OSPF Area Area Area Area (index) (index) (index) (index) 0 1 1 1 # # # # ../aindex 1 areaid 0.0.0.1 type stub enable OSPF OSPF OSPF OSPF OSPF Interface 2 # Summary Range Summary Range Summary Range Summary Range ../range 1 1 # addr 36.128.192.0 1 # mask 255.255.192.0 1 # aindex 0 1 # enable (Select menu for summary range) (Set base IP address of summary range) (Set mask address for summary range) (Inject summary route into backbone) (Enable summary range) Use the hide command to prevent a range of addresses from advertising to the backbone. >> >> >> >> 9. (Select OSPF menu for IP interface 2) (Attach network to stub area index) (Enable the stub area interface) Configure route summarization by specifying the starting address and mask of the range of addresses to be summarized. >> >> >> >> >> 8. (Select OSPF menu for IP interface 1) (Attach network to backbone index) (Enable the backbone interface) Attach the network interface to the stub area. >> OSPF Interface 1 # ../if 2 >> OSPF Interface 2 # aindex 1 >> OSPF Interface 2 # enable 7. (Select menu for area index 1) (Set the area ID for OSPF area 1) (Define area as stub type) (Enable the area) Attach the network interface to the backbone. >> OSPF Area (index) 1 # ../if 1 >> OSPF Interface 1 # aindex 0 >> OSPF Interface 1 # enable 6. (Select menu for area index 0) (Set the ID for backbone area 0) (Define backbone as transit type) (Enable the area) Define the stub area. >> >> >> >> 5. Open OSPF OSPF OSPF OSPF OSPF OSPF OSPF Interface 2 # Summary Range Summary Range Summary Range ../range 2 # addr 2 # mask 2 # hide 2 36.128.200.0 255.255.200.255 enable (Select menu for summary range) (Set base IP address) (Set mask address) (Hide the range of addresses) Apply and save the configuration changes. >> OSPF Summary Range 2 # apply >> OSPF Summary Range 2 # save (Global command to apply all changes) (Global command to save all changes) Chapter 4: OSPF 212777-A, February 2002 n 91 Web OS 10.0 Application Guide Example 4: Host Routes The Web OS 10.0 implementation of OSPF includes host routes. Host routes are used for advertising network device IP addresses to external networks and allows for Server Load Balancing (SLB) within OSPF. It also makes ABR load sharing and failover possible. Consider the example network in Figure 4-8. Both Web 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. Web 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. Web 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 Web switches and uses the host route with the lowest cost for each. Traffic for 10.10.10.1 goes to Web switch #1 because its host route has the lowest cost for that address. Traffic for 10.10.10.2 goes to Web switch #2 because its host route has the lowest cost. This effectively shares the load among ABRs. Both Web switches then use standard Server Load Balancing (SLB) to distribute traffic among available real servers. In addition, if one of the Web switches were to fail, the upstream routing device would forward the traffic to the ABR whose host route has the next lowest cost. In this example, the remaining Web switch would assume the entire load for both virtual servers. Web Switch #1 Virtual Servers/Host Routes: 10.10.10.1, Cost 1 10.10.10.2, Cost 100 Backbone Area 0 Stub Area Area 1 Preferred path (lowest cost) to Host Route 10.10.10.1 Real Servers with Identical Content Preferred path (lowest cost) to Host Route 10.10.10.2 Web Switch #2 Virtual Servers/Host Routes: 10.10.10.1, Cost 100 10.10.10.2, Cost 1 ABR Load Sharing Standard SLB Figure 4-8 Configuring OSPF Host Routes 92 n Chapter 4: OSPF 212777-A, February 2002 Web OS 10.0 Application Guide Configuring OSPF for Host Routes on Web Switch #1 1. Configure basic SLB parameters. Web 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. >> >> >> >> >> >> >> >> >> >> >> 2. Layer 4# SLB Port SLB Port SLB Port port 4 4 # client ena 4 # ../port 5 5 # server ena (Select switch port 4) (Enable client processing on Port 4) (Select switch Port 5) (Enable server processing on Port 5) Enable direct access mode. >> Layer 4 Port 5# ../adv >> Layer 4 Advanced# direct ena >> Layer 4 Advanced# .. 4. (Select menu for real server 1) (Set the IP address for real server 1) (Enable the real server) (Select menu for real server 2) (Set the IP address for real server 2) (Enable the real server) (Select menu for real server group 1) (Add real server 1 to group) (Add real server 2 to group) (Enable the group) (Turn SLB on) Configure client and server processing on specific ports. >> >> >> >> 3. # /cfg/slb/real 1 Real server 1 # rip 100.100.100.25 Real server 1 # ena Real server 1 # ../real 2 Real server 2 # rip 100.100.10.26 Real server 2 # ena Real server 2 # ../group 1 Real server group 1 # add 1 Real server group 1 # add 2 Real server group 1 # enable Real server group 1 # ../on (Select the SLB advance menu) (Enable DAM) (Return to the SLB menu) Configure the primary virtual server. Alteon Web Switch # 1 will be preferred for virtual server 10.10.10.1. >> >> >> >> >> Layer 4 Virtual Virtual Virtual Virtual # virt server server server server 1 1 1 1 1 # vip 10.10.10.1 # ena # service http http service # group 1 (Select menu for virtual server 1) (Set the IP address for virtual server 1) (Enable the virtual server) (Select menu for service on virtual server) (Use real server group 1 for http service) Chapter 4: OSPF 212777-A, February 2002 n 93 Web OS 10.0 Application Guide 5. Configure the backup virtual server. Alteon Web 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. >> >> >> >> >> 6. Virtual Virtual Virtual Virtual Virtual server server server server server 2 1 1 1 1 http service # /cfg/slb/virt 2 (Select menu for virtual server 2) # vip 10.10.10.2 (Set the IP address for virtual server 2) # ena (Enable the virtual server) # service http (Select menu for service on virtual server) # group 1 (Use real server group 1 for http service) Configure IP interfaces for each network that will be attached to OSPF areas. >> Virtual server >> IP Interface 1 >> IP Interface 1 >> IP Interface 1 >> IP Interface 2 >> IP Interface 2 7. 1 # # # # # # /cfg/ip/if 1 addr 10.10.7.1 enable ../if 2 addr 10.10.10.40 enable Enable OSPF on Web switch 1. >> IP Interface 2 # ../ospf/on 8. n Open OSPF OSPF OSPF Shortest Path First # aindex 0 Area (index) 0 # areaid 0.0.0.0 Area (index) 0 # type transit Area (index) 0 # enable (Select menu for area index 0) (Set the ID for backbone area 0) (Define backbone as transit type) (Enable the area) Define the stub area. >> >> >> >> 94 (Enable OSPF on Web switch 1) Define the backbone. >> >> >> >> 9. (Select menu for IP interface 1) (Set IP address on backbone network) (Enable IP interface 1) (Select menu for IP interface 2) (Set IP address on stub area network) (Enable IP interface 2) OSPF OSPF OSPF OSPF Area Area Area Area (index) (index) (index) (index) 0 1 1 1 # # # # ../aindex 1 areaid 0.0.0.1 type stub enable (Select menu for area index 1) (Set the ID for stub area 1) (Define area as stub type) (Enable the area) Chapter 4: OSPF 212777-A, February 2002 Web OS 10.0 Application Guide 10. Attach the network interface to the backbone. >> OSPF Area (index) 1 # ../if 1 >> OSPF Interface 1 # aindex 0 >> OSPF Interface 1 # enable (Select OSPF menu for IP interface 1) (Attach network to backbone index) (Enable the backbone interface) 11. Attach the network interface to the stub area. >> OSPF Interface 1 # ../if 2 >> OSPF Interface 2 # aindex 1 >> OSPF Interface 2 # enable (Select OSPF menu for IP interface 2) (Attach network to stub area index) (Enable the stub area interface) 12. Configure host routes. One host route is needed for each virtual server on Web switch 1. Since virtual server 10.10.10.1 is preferred for Web switch 1, its host route has a low cost. Because virtual server 10.10.10.2 is used as a backup in case Web switch 2 fails, its host route has a high cost. >> >> >> >> >> >> >> >> >> >> OSPF OSPF OSPF OSPF OSPF OSPF OSPF OSPF OSPF OSPF Interface 2 # ../host 1 Host Entry 1 # addr 10.10.10.1 Host Entry 1 # aindex 0 Host Entry 1 # cost 1 Host Entry 1 # enable Host Entry 1 # ../host 2 Host Entry 2 # addr 10.10.10.2 Host Entry 2 # aindex 0 Host Entry 2 # cost 100 Host Entry 2 # enable (Select menu for host route 1) (Set IP address same as virtual server 1) (Inject host route into backbone area) (Set low cost for preferred path) (Enable the host route) (Select menu for host route 2) (Set IP address same as virtual server 2) (Inject host route into backbone area) (Set high cost for use as backup path) (Enable the host route) 13. Apply and save the configuration changes. >> OSPF Host Entry 2 # apply >> OSPF Host Entry 2 # save (Global command to apply all changes) (Global command to save all changes) Chapter 4: OSPF 212777-A, February 2002 n 95 Web OS 10.0 Application Guide Configuring OSPF for Host Routes on Web Switch 2 1. Configure basic SLB parameters. Web 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. # /cfg/slb/real 1 Real server 1 # rip 100.100.100.27 Real server 1 # enable Real server 1 # ../real 2 Real server 2 # rip 100.100.10.28 Real server 2 # enable Real server 2 # ../group 1 Real server group 1 # add 1 Real server group 1 # add 2 Real server group 1 # enable Real server group 1 # ../on (Select menu for real server 1) (Set the IP address for real server 1) (Enable the real server) (Select menu for real server 2) (Set the IP address for real server 2) (Enable the real server) (Select menu for real server group 1) (Add real server 1 to group) (Add real server 2 to group) (Enable the group) (Turn SLB on) Configure the virtual server parameters. The same virtual servers are configured as on Web switch 1. >> >> >> >> >> >> >> >> >> >> 3. Layer 4 Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual # virt server server server server server server server server server 1 1 1 1 1 2 1 1 1 1 (Select menu for virtual server 1) # vip 10.10.10.1 (Set the IP address for virtual server 1) # enable (Enable the virtual server) # service http (Select menu for service on virtual server) http service # group 1 (Use real server group 1 for http service) http service # /cfg/slb/virt 2 (Select menu for virtual server 2) # vip 10.10.10.2 (Set the IP address for virtual server 2) # enable (Enable the virtual server) # service http (Select menu for service on virtual server) # group 1 (Use real server group 1 for http service) Configure IP interfaces for each network that will be attached to OSPF areas. >> Virtual server >> IP Interface 1 >> IP Interface 1 >> IP Interface 1 >> IP Interface 2 >> IP Interface 2 96 n 1 # # # # # # /cfg/ip/if 1 addr 10.10.7.2 enable ../if 2 addr 10.10.10.41 enable (Select menu for IP Interface 1) (Set IP address on backbone network) (Enable IP interface 1) (Select menu for IP Interface 2) (Set IP address on stub area network) (Enable IP interface 2) Chapter 4: OSPF 212777-A, February 2002 Web OS 10.0 Application Guide 4. Enable OSPF on Web switch #2. >> IP Interface 2 # ../ospf/on 5. Define the backbone. >> >> >> >> 6. Open OSPF OSPF OSPF Shortest Path First # aindex 0 Area (index) 0 # areaid 0.0.0.0 Area (index) 0 # type transit Area (index) 0 # enable OSPF OSPF OSPF OSPF Area Area Area Area (index) (index) (index) (index) 0 1 1 1 # # # # ../aindex 1 areaid 0.0.0.1 type stub enable (Select menu for area index 1) (Set the ID for stub area 1) (Define area as stub type) (Enable the area) Attach the network interface to the backbone. >> OSPF Area (index) 1 # ../if 1 >> OSPF Interface 1 # aindex 0 >> OSPF Interface 1 # enable 8. (Select menu for area index 0) (Set the ID for backbone area 0) (Define backbone as transit type) (Enable the area) Define the stub area. >> >> >> >> 7. (Enable OSPF on Web switch #2) (Select OSPF menu for IP interface 1) (Attach network to backbone index) (Enable the backbone interface) Attach the network interface to the stub area. >> OSPF Interface 1 # ../if 2 >> OSPF Interface 2 # aindex 1 >> OSPF Interface 2 # enable (Select OSPF menu for IP interface 2) (Attach network to stub area index) (Enable the stub area interface) Chapter 4: OSPF 212777-A, February 2002 n 97 Web OS 10.0 Application Guide 9. Configure host routes. Host routes are configured just like those on Web switch 1, except their costs are reversed. Since virtual server 10.10.10.2 is preferred for Web 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 Web switch 1 fails, its host route has been given a high cost. >> >> >> >> >> >> >> >> >> >> OSPF OSPF OSPF OSPF OSPF OSPF OSPF OSPF OSPF OSPF Interface 2 # ../host 1 Host Entry 1 # addr 10.10.10.1 Host Entry 1 # aindex 0 Host Entry 1 # cost 100 Host Entry 1 # enable Host Entry 1 # ../host 2 Host Entry 2 # addr 10.10.10.2 Host Entry 2 # aindex 0 Host Entry 2 # cost 1 Host Entry 2 # enable (Select menu for host route 1) (Set IP address same as virtual server 1) (Inject host route into backbone area) (Set high cost for use as backup path) (Enable the host route) (Select menu for host route 2) (Set IP address same as virtual server 2) (Inject host route into backbone area) (Set low cost for primary path) (Enable the host route) 10. Apply and save the configuration changes. >> OSPF Host Entry 2 # apply >> OSPF Host Entry 2 # save (Global command to apply all changes) (Global command to save all changes) Verifying OSPF Configuration Use the following commands to verify the OSPF configuration on your switch: n /info/ospf/general n /info/ospf/nbr n /info/ospf/dbase/dbsum n /info/ospf/route n /stats/route Refer to the Web OS 10.0 Command Reference for information on the above commands. 98 n Chapter 4: OSPF 212777-A, February 2002 CHAPTER 5 Secure Switch Management This chapter discusses the use of secure tunnels so that the data on the network is encrypted and secured for messages between a remote administrator and the switch. To limit access to the switch’s Management Processor 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 Web OS Browser-Based Interface (BBI). This will also help prevent spoofing or attacks on the switch’s TCP/IP stack. The following sections are addressed in this chapter: n “Setting Allowable Source IP Address Ranges” on page 100 n “Secure Switch Management” on page 101 n “RADIUS Authentication and Authorization” on page 103 n “Secure Shell and Secure Copy” on page 107 n “Port Mirroring” on page 113 99 212777-A, February 2002 Web OS 10.0 Application Guide Setting Allowable Source IP Address Ranges The allowable management IP address range is configured using the system mnet and mmask options available on the Command Line Interface (CLI) System Menu (/cfg/sys). NOTE – The mnet and mmask commands in the /cfg/slb/adv menu are used for a different purpose. When an IP packet reaches the Management Processor, the source IP address is checked against the range of addresses defined by mnet and mmask. 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 silently. Example: Assume that the mnet is set to 192.192.192.0 and the mmask is set to 255.255.255.128. This defines the following range of allowed IP addresses: 192.192.192.1 to 192.192.192.127. n 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 Management Processor. n 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 mnet and mmask or modify the mnet to be 192.192.192.128 and the mmask to be 255.255.255.128. This would put the 192.192.192.192 host within the valid range allowed by the mnet and mmask (192.192.192.128-255). NOTE – When the mnet and mmask Management Processor filter is applied, Routing Interface Protocol (RIP) updates received by the switch will be discarded if the source IP address of the RIP packet(s) falls outside the specified range. You can correct this by configuring static routes. 100 n Chapter 5: Secure Switch Management 212777-A, February 2002 Web OS 10.0 Application Guide Secure Switch Management Secure switch management is needed for environments that perform significant management functions across the Internet. The following are some of the functions for secured management: n Authentication of remote administrators Authentication is the action of determining and verifying who the administrator is; it usually involves a name and a password. The password can be either a fixed password or a challenge-response query. n Authorization of remote administrators Once an administrator has been authenticated, authorization is the action of determining what that user is allowed to do. Authorization does not merely provide yes or no answers but may also customize the service for a particular administrator. n Encryption of management information exchanged between the remote administrator and the switch Examples of protocols to encrypt management information are SSH (Secure Shell) and SCP (Secure Copy). Authentication and Authorization NOTE – While authentication and authorization (AA) protocols and servers are designed to authenticate remote dial-up users (in addition to authorizing remote access capabilities to users), this overview is focused on using the AA model to authenticate and authorize remote administrators for managing a switch. The AA model is based on a client/server model. The Remote Access Server (RAS)—the switch—is a client to the back-end database server. A remote user (the remote administrator) interacts only with the RAS, not the back-end server and database. Two prominent AA protocols used to control dial-up access into networks are Cisco’s TACACS+ (Terminal Access Controller Access Control System) and Livingston Enterprise’s RADIUS (Remote Authentication Dial-In User Service). Web OS supports only the RADIUS authentication method. Chapter 5: Secure Switch Management 212777-A, February 2002 n 101 Web OS 10.0 Application Guide Requirements The following components are required for authorization and authentication: n A remote administrator n The Web switch with authentication and authorization protocol support, acting as a client in the AA model n A back-end authentication and authorization server that performs the following functions: o Authenticates remote administrators o Checks the remote administrator’s authorization to access the switch o Optionally, tracks and logs the administrator’s activity while logging on n 102 n An AA database that contains information about authorized administrators and their specific capabilities and privileges Chapter 5: Secure Switch Management 212777-A, February 2002 Web OS 10.0 Application Guide RADIUS Authentication and Authorization RADIUS is an access server authentication, authorization, and accounting protocol used to secure remote access to networks and network services against unauthorized access. RADIUS consists of three components: n A protocol with a frame format that utilizes UDP over IP (based on RFC 2138 and 2866) n A centralized server that stores all the user authorization information n A client, in this case, the switch The operation of RADIUS authentication and authorization protocol is based on the AA model described previously. The switch—acting as the RADIUS client—will communicate 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 RADIUS server are authenticated through the use of a shared secret, which is never 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. 1. Remote administrator connects to switch and provides user name and password 2. Using Authentication/Authorization protocol, the switch sends request to authentication server Authentication Servers Internet Alteon Web Switch 3. Authentication server 4. Using RADIUS protocol, checks request against the authentication server the user ID database instructs the switch to grant or deny admim access Figure 5-1 Authentication and Authorization: How It Works Chapter 5: Secure Switch Management 212777-A, February 2002 n 103 Web OS 10.0 Application Guide RADIUS Authentication Features in Web OS The following Radius Authentication features are supported in Web OS: n Supports RADIUS client on the switch, based on the protocol definitions in RFC 2138 and 2866. n Enables/disables support of RADIUS authentication and authorization. The default disables the use of RADIUS for authentication and authorization. n Allows RADIUS secret password up to 32 bytes and less than 16 octets. n Supports secondary authentication server so that when the primary authentication server is unreachable, the switch can send client authentication requests to the secondary authentication server. Use the /cfg/sys/radius/cur command to show the currently active RADIUS authentication server. n Supports user-configurable RADIUS server retry and time-out values. The parameters are: o Time-out value = 1-10 seconds o 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. n Supports user-configurable RADIUS application port. The default is 1645/UDP based on RFC 2138. Port 1812 is also supported. 104 n n Allows network administrator to define privileges for one or more specific users to access the switch at the RADIUS user database. n SecurID is supported if the RADIUS server can do an ACE/Server client proxy. The password is the PIN number, plus the token code of the SecurID card. Chapter 5: Secure Switch Management 212777-A, February 2002 Web OS 10.0 Application Guide Web Switch User Accounts The user accounts listed in Table 5-1 can be defined in the RADIUS server dictionary file. Table 5-1 User 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 Web servers and other Internet ser- slboper vices 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. Layer 4 Operator The Layer 4 Operator manages traffic on the lines leading to the l4oper 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. Operator The Operator manages all functions of the switch. In addition to oper SLB Operator functions, the Operator can reset ports or the entire switch. SLB Administrator The SLB Administrator configures and manages Web servers slbadmin and other Internet services and their loads. In addition to SLB Operator functions, the SLB Administrator can configure parameters on the SLB menus, with the exception of not being able to configure filters or bandwidth management. Layer 4 Administrator The Layer 4 Administrator configures and manages traffic on the l4admin lines leading to the shared Internet services. In addition to SLB Administrator functions, the Layer 4 Administrator can configure all parameters on the SLB menus, including filters and bandwidth management. Administrator The super-user Administrator has complete access to all menus, admin information, and configuration commands on the switch, including the ability to change both the user and administrator passwords. Chapter 5: Secure Switch Management 212777-A, February 2002 n 105 Web OS 10.0 Application Guide 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 user privileges are Web OS-proprietary definitions. Table 5-2 Web OS Alteon Levels 106 n User Name/Access User-Service-Type Value User Vendor-supplied 255 SLB Operator Vendor-supplied 254 Layer 4 Operator Vendor-supplied 253 Operator Vendor-supplied 252 SLB Administrator Vendor-supplied 251 Layer 4 Administrator Vendor-supplied 250 Chapter 5: Secure Switch Management 212777-A, February 2002 Web OS 10.0 Application Guide Secure Shell and Secure Copy Although a remote network administrator can manage the configuration of an Alteon Web switch via Telnet, this method does not provide a secure connection. Using Secure Shell (SSH) and Secure Copy (SCP), messages between a remote administrator and the switch use secure tunnels so that the data on the network is encrypted and secured. Figure 5-1 on page 103 illustrates secure switch management. NOTE – SSH/SCP features are configured via the console port, using the CLI. However, SCP putcfg and TFTP getcfg can also change the SSH/SCP configuration.When SSH is enabled, SCP is also enabled. SSH is a protocol that enables a remote administrator to log securely into another computer over a network to execute management commands. All the data sent over the network using SSH is encrypted and secured. Using SSH gives administrators an alternate way to manage the switch, one that provides strong security. 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 Web switch, SCP is used to download and upload the switch configuration via secure channels. The benefits of using SSH and SCP are listed below: n Authentication of remote administrators Identifying the administrator using Name/Password n Authorization of remote administrators Determining the permitted actions and customizing service for individual administrators n Encryption of management messages Encrypting messages between the remote administrator and switch n Secure copy support NOTE – The Web OS implementation of SSH is based on SSH version 1.5 and supports SSH1.5-1.x.xx. SSH clients of other versions (especially version 2) will not be supported. The following SSH clients have been tested: n SSH 1.2.23 and SSH 1.2.27 for Linux (freeware) n SecureCRT 3.0.2 and SecureCRT 3.0.3 for Windows NT (Van Dyke Technologies, Inc.) n F-Secure SSH 1.1 for Windows (Data Fellows) Chapter 5: Secure Switch Management 212777-A, February 2002 n 107 Web OS 10.0 Application Guide NOTE – There can be a maximum number of four simultaneous Telnet/SSH/SCP connections at one time. The /cfg/sys/radius/telnet command also applies to SSH/SCP connections. Encryption of Management Messages The supported encryption and authentication methods for both SSH and SCP are listed below: Server Host Authentication: Client RSA authenticates the switch at the beginning of every connection Key Exchange: RSA Encryption: 3DES-CBC, DES User Authentication: Local password authentication, RADIUS, SecurID (via RADIUS, for SSH only—does not apply to SCP) SCP Services Administrator privileges are required to perform SCP commands. Set the SCP admin password (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: n getcfg is used to download the switch's configuration to the remote host via SCP. n putcfg is used to upload the switch's configuration from a remote host to the switch; the diff command will be automatically executed at the end of putcfg to notify the remote client of the difference between the new and the current configurations. n putcfg_apply will run the apply command after the putcfg is done. n 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. 108 n Chapter 5: Secure Switch Management 212777-A, February 2002 Web OS 10.0 Application Guide RSA Host and Server Keys 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 Web switch. The server key is 768 bits and is used to make it impossible to decipher a captured session by breaking into the Web switch at a later time. When the SSH server is first enabled and applied, the switch will automatically generate the host and server keys and will then store them into the FLASH memory. NOTE – The Web 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. n To generate a host key: >> # /cfg/sys/sshd/hkeygen n To generate a server key: >> # /cfg/sys/sshd/skeygen Again, the host and server key are automatically stored in FLASH memory when generated. NOTE – For security reasons, the SSHD menu options are available via the console port only and not via Telnet, SNMP, or the Browser-Based Interface (BBI). 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 will automatically generate them during the system reboot. 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/intrval where the number of hours must range between 0–24, and 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 will be skipped if the switch is busy doing other key or cipher generation when the timer expires. Chapter 5: Secure Switch Management 212777-A, February 2002 n 109 Web OS 10.0 Application Guide 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. SecurID Support SSH/SCP can also work with SecurID, a token card-based authentication method. The use of SecurID requires the interactive mode during login, which is not provided by the SSH connection. NOTE – There is no SNMP or Browser-Based Interface (BBI) support for SecurID because the SecurID server, ACE, is a one-time password authentication and requires an interactive session. To log in using SSH without difficulties, you need to use a special username, “ace,” to log in and bypass the SSH authentication. After an SSH connection is established, you will then be prompted to enter the username and password (the SecurID authentication is being performed now). You will need to provide your actual username and the token in your SecurID card as a regular Telnet user would do in order to log in. To use SCP, you need to use the SCP-only administrator’s password (that is, the scpadm option under the /cfg/sys/sshd menu) to bypass the checking of SecurID. 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. A SCP-only administrator’s password is typically used when SecurID is used. For example, it can be used in an automation program (in which the tokens of SecurID are not available) to back up (download) the switch configurations each day. NOTE – The SCP-only administrator’s password must be different from the regular administrator’s 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. 110 n Chapter 5: Secure Switch Management 212777-A, February 2002 Web OS 10.0 Application Guide Configuring SSH/SCP SSH/SCP parameters can be configured only via the console port, using the CLI. The switch SSH daemon uses TCP port 22 only and is not configurable. To enable or disable the SSH/SCP feature, use the following commands: >> # /cfg/sys/sshd/on >> # /cfg/sys/sshd/off (Turn SSH/SCP on) (Turn SSH/SCP off) To set the interval of RSA server key autogeneration, use this command: >> # /cfg/sys/sshd/intrval where the number of hours must range between 0–24, and a value of 0 denotes that RSA server key autogeneration is disabled. When greater than 0, the switch will auto-generate the RSA server key every interval specified; however, RSA server key generation will be skipped if the switch is busy doing other key or cipher generation when the timer expires. To enable or disable the SCP apply and save (SCP putcfg_apply and putcfg_apply_save commands), use these commands: >> # /cfg/sys/sshd/ena >> # /cfg/sys/sshd/dis (Enable SSH/SCP apply and save) (Disable SSH/SCP apply and save) The following commands are useful for obtaining information about the current SSH/SCPrelated configuration: >> # /cfg/sys/sshd/cur >> # diff (View current SSH/SCP settings) (View pending changes) To apply the pending changes from the new configuration, use this command: >> # apply NOTE – If SSH/SCP is enabled and an apply command is issued, the switch will automatically generate the RSA host and server keys if they are not available. It will take several minutes to complete this process. Chapter 5: Secure Switch Management 212777-A, February 2002 n 111 Web OS 10.0 Application Guide To save the current configuration to FLASH, use this command: >> # save Usually, there will be no need to generate manually the RSA host and server keys. However, you may still do so by using the following commands: >> # /cfg/sys/sshd/hkeygen >> # /cfg/sys/sshd/skeygen (Generates the host key) (Generates the server key) NOTE – These two commands will take effect immediately without the need of an apply command being issued. Some Supported Client Commands Up to four simultaneous Telnet/SSH/SCP connections are supported on a switch. n To log in to the switch: ssh or ssh -l n To download the switch configuration using SCP: scp :getcfg n To upload the configuration to the switch: scp :putcfg Some examples are listed below: >> >> >> >> # # # # ssh ssh scp scp 205.178.15.157 -l dleu 205.178.15.157 205.178.15.157:getcfg ad4.cfg ad4.cfg 205.178.15.157:putcfg where 205.178.15.157 is the IP address of the example switch. Please also note that apply and save commands are still needed after the last command (scp ad4.cfg 205.178.15.157:putcfg) is issued. Or, instead, you can use the following commands: >> # scp ad4.cfg 205.178.15.157:putcfg_apply >> # scp ad4.cfg 205.178.15.157:putcfg_apply_save 112 n Chapter 5: Secure Switch Management 212777-A, February 2002 Web OS 10.0 Application Guide Port Mirroring Port mirroring is implemented 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. The port mirroring feature in Web OS 10.0 allows you to attach a sniffer to a monitoring port that is configured to receive a copy of every single packet that is forwarded from the mirrored port. Web OS enables you to mirror port traffic for all layers (Layer 2 - 7). As shown in Figure 5-2, port 5 is monitoring ingress traffic (traffic entering the switch) on port 1 and egress traffic (traffic leaving the switch) on port 3. You can attach a device to port 5 to monitor the traffic on ports 1 and 3. Mirrored ports Monitoring port 3 4 5 6 7 8 Data Link RX 2 TX 1 1000 Base-SX Gigabit Powered Data Link Active 9 Data Link Active TX RX TX RX TX RX TX RX TX RX TX RX TX RX TX Power RX Console Ingress traffic Egress traffic Figure 5-2 Monitoring Ports Figure 5-2 shows two mirrored ports monitored by a single port. Similarly, you can have a single or groups of n a mirrored port to a monitored port n many mirrored ports to one monitored port Web OS 10.0 does not support a single port being monitored by multiple ports. Packets are duplicated and sent to the mirrored ports after client or server port processing is completed. Data packets sent from a client to a virtual server are seen at the mirrored port as follows: n source IP address = client IP address n destination IP address = real server IP address rather than the virtual server IP address. Conversely, the response from the server to the client will be seen as follows: n source IP address =virtual server IP address n destination IP address=client IP address Chapter 5: Secure Switch Management 212777-A, February 2002 n 113 Web OS 10.0 Application Guide NOTE – Port mirroring and bandwidth management cannot be enabled at the same time. To configure port mirroring for the example shown in Figure 5-2, 1. Specify the monitoring port. >> # /cfg/pmirr/monport 5 2. (Select port 5 for monitoring) Select the ports that you want to mirror. >> Port 5 # add 1 (Select port 1 to mirror) >> Enter port mirror direction [in, out, or both]: in (Monitor ingress traffic on port 1) (Select port 3 to mirror) >> Port 5 # add 3 >> Enter port mirror direction [in, out, or both]: out (Monitor egress traffic on port 3) 3. Enable port mirroring. >> # /cfg/pmirr/mirr ena 4. Apply and save the configuration. >> PortMirroring# apply >> PortMirroring# save 5. n (Apply the configuration) (Save the configuration) View the current configuration. >> PortMirroring# cur Port mirroring is enabled Monitoring Ports Mirrored Ports 1 none 2 none 3 none 4 none 5 (1, in) (3, out) 6 none 7 none 8 none 9 none 114 (Enable port mirroring) (Display the current settings) Chapter 5: Secure Switch Management 212777-A, February 2002 Part 2: Web 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. Web switching goes beyond IP and makes intelligent switching decisions based on the application and its data. This sections details the following fundamental Web switching features: n Server Load Balancing n Filtering n Application Redirection n Virtual Matrix Architecture n Health Checking n High Availability 115 212777-A, February 2002 Web OS 10.0 Application Guide 116 n Web Switching Fundamentals 212777-A, February 2002 CHAPTER 6 Server Load Balancing Server Load Balancing (SLB) allows you to configure the Alteon Web switch to balance user session traffic among a pool of available servers that provide shared services. The following sections in this chapter describe how to configure and use SLB: n “Understanding Server Load Balancing” on page 118. This section discusses the benefits of server load balancing and how it works. n “Implementing Basic Server Load Balancing” on page 121. This section discusses how implementing SLB provides reliability, performance, and ease of maintenance on your network. o “Network Topology Requirements” on page 122. This section provides key requirements to consider before deploying server load balancing. o “Configuring Server Load Balancing” on page 124. o “Additional Server Load Balancing Options” on page 128. n “Extending SLB Topologies” on page 136. This section discusses proxy IP addresses, mapping a virtual port to real ports, monitoring real server ports, and delayed binding. n “Load Balancing Special Services” on page 149. This section discusses load balancing based on special services, such as source IP addresses, FTP, RTSP, DNS, WAP, IDS, and WAN link. For additional information about the SLB feature, see your Web OS Command Reference. 117 212777-A, February 2002 Web OS 10.0 Application Guide Understanding Server Load Balancing SLB benefits your network in a number of ways: n Increased efficiency for server utilization and network bandwidth With SLB, your Alteon Web 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 connections on overutilized servers. For even greater control, traffic is distributed according to a variety of user-selectable rules. n 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. n Increased scalability of services As users are added and the server pool’s capabilities are saturated, new servers can be added to the pool transparently. Identifying Your Network Needs SLB may be the right option for addressing these vital network concerns: 118 n n A single server no longer meets the demand for its particular application. n The connection from your LAN to your server overloads the server’s capacity. n Your NT and UNIX servers hold critical application data and must remain available even in the event of a server failure. n 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. n You want to use multiple servers or hot-standby servers for maximum server uptime. n You must be able to scale your applications to meet client and LAN request capacity. n You can’t afford to continue using an inferior load-balancing technique, such as DNS round robin or a software-only system. Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide 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 traffic to an appropriate server, based on a variety of load-balancing algorithms. Trading Lending Trading Trading Trading Trading Trading Retail Retail Clients Retail Retail Trading Retail Trading Lending Trading Lending Lending Retail Trading Clients Figure 6-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). Chapter 6: Server Load Balancing 212777-A, February 2002 n 119 Web OS 10.0 Application Guide The Web switch, with SLB software, acts as a front-end to the servers, interpreting user session requests and distributing them among the available servers. Load balancing in Web OS can be done in the following ways: n 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 256 virtual servers on the switch, each distributing up to eight different services (up to a total of 2048 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. IP, FTP, RTSP, IDS, and static session WAP are examples of some of the services that use virtual servers for load balancing. n 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, redirected 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. n 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. 120 n Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Implementing Basic Server Load Balancing Consider a situation where customer Web sites are being hosted by a popular Web hosting company and/or Internet Service Provider (ISP). The Web content is relatively static and is kept on a single NFS server for easy administration. As the customer base increases, the number of simultaneous Web connection requests also increases. Web Server Web Clients As clients increase, the server becomes overloaded NFS Server Internet Web Host Router Figure 6-2 Web Hosting Configuration Without SLB Such a company has three primary needs: n Increased server availability n Server performance scalable to match new customer demands n Easy administration of network and servers Layer 4 Switching & Server Load Balancing Web Clients Web Server Farm A Web Switch B C Internet Web Host Routers Layer 2 Switching Layer 2 Switching NFS Server Figure 6-3 Web Hosting with SLB Solutions Chapter 6: Server Load Balancing 212777-A, February 2002 n 121 Web OS 10.0 Application Guide All of the above issues can be addressed by adding an Alteon Web switch with SLB software. n Reliability is increased by providing multiple paths from the clients to the Web switch and by accessing a pool of servers with identical content. If one server fails, the others can take up the additional load. n Performance is improved by balancing the Web request load across multiple servers. More servers can be added at any time to increase processing power. n For ease of maintenance, servers can be added or removed dynamically, without interrupting shared services. Network Topology Requirements When deploying SLB, there are a few key aspects to consider: n 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 6-4. If there is a path between the client and the real servers that does not pass through the switch, the Web switch can be configured to proxy requests in order to guarantee that responses use the correct path (see “Proxy IP Addresses” on page 136). Router Internet NFS Server Web Switch Switch Router Clients Switch Alternate path is not valid with Layer 4 services. IP proxy addresses must be used on the Alteon Web switch Server Pool #1 Server Pool #2 Figure 6-4 SLB Client/Server Traffic Routing n Identical content must be available to each server in the same pool. Either of these methods can be used: o Static applications and data are duplicated on each real server in the pool. o Each real server in the pool has access to the same data through use of a shared file system or back-end database server. 122 n Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide n Some services require that a series of client requests go to the same real server so that session-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 services must be configured as persistent (see Chapter 16, “Persistence”) or must use the minmisses or hash metrics (see “Metrics for Real Server Groups” on page 131). n 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. o 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. o Layer 4 server processing: Ports that are configured to process server responses to client requests provide address translation from the real server IP address to the virtual server IP address. These ports require real servers to be connected to the Web switch directly or through a hub, router, or another switch. NOTE – Switch ports configured for Layer 4 client/server processing can simultaneously provide Layer 2 switching and IP routing functions. Consider the following network topology: Web servers initiate DNS requests which are load balanced to DNS servers Web Switch C Client Processing S Server Processing Router Internet 1 S C S C A 3 DNS Server Pool 2 Clients on the Internet B initiate HTTP sessions which are load balanced to Web servers Web Server Pool Figure 6-5 Example Network for Client/Server Port Configuration In Figure 6-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 2) is asked to perform both server and client processing. Some topologies require special configuration. For example, if clients were added to Switch B as shown in Figure 6-5, these clients could not access the Web server pool using SLB services, except through a proxy IP address that is configured on port 2 of the Alteon Web switch. Chapter 6: Server Load Balancing 212777-A, February 2002 n 123 Web OS 10.0 Application Guide 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 128 for more options. The following is required prior to configuration: n You must be connected to the switch Command Line Interface (CLI) as the administrator. n The SLB software must be enabled. NOTE – For details about any of the menu commands described in this example, see your Web 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 performs the SLB functions. This IP routing is most easily accomplished by placing the switches and servers on the same IP subnet, although advanced routing techniques can be used as long as they do not violate the topology rules outlined in “Network Topology Requirements” on page 122. For this example, the three Web-host real servers have been given the following IP addresses on the same IP subnet: Table 6-1 Web Host Example: Real Server IP Addresses Real Server IP address Server A 200.200.200.2 Server B 200.200.200.3 Server C 200.200.200.4 NOTE – 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 129). 124 n Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide 2. Define an IP interface on the switch. The switch must have an IP route to all of the real servers that receive Web 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: >> # /cfg/ip/if 1 >> IP Interface 1# addr 200.200.200.100 >> IP Interface 1# ena (Select IP interface 1) (Assign IP address for the interface) (Enable IP interface 1) NOTE – The IP interface and the real servers must belong to the same VLAN, if they are in the same subnet. This example assumes that all ports and IP interfaces use default VLAN 1, requiring no special VLAN 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. IP Interface 1# /cfg/slb/real 1 Real server 1# rip 200.200.200.2 Real server 1# ena Real server 1# ../real 2 Real server 2# rip 200.200.200.3 Real server 2# ena Real server 2# ../real 3 Real server 3# rip 200.200.200.4 Real server 3# ena (Server A is real server 1) (Assign Server A IP address) (Enable real server 1) (Server B is real server 2) (Assign Server B IP address) (Enable real server 2) (Server C is real server 3) (Assign Server C IP address) (Enable real server 3) Define a real server group and add the three real servers to the service group. >> >> >> >> Real Real Real Real server server server server 3# /cfg/slb/group 1 group 1# add 1 group 1# add 2 group 1# add 3 (Select real server group 1) (Add real server 1 to group 1) (Add real server 2 to group 1) (Add real server 3 to group 1) Chapter 6: Server Load Balancing 212777-A, February 2002 n 125 Web OS 10.0 Application Guide 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: >> >> >> >> >> Real server group 1# /cfg/slb/virt 1 Virtual server 1# vip 200.200.200.1 Virtual server 1# ena Virtual server 1# service http Virtual server 1 http Service# group 1 (Select virtual server 1) (Assign a virtual server IP address) (Enable the virtual server) (Select the HTTP service menu) (Associate virtual port to real group) 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 “WellKnown Application Ports” on page 128. To configure multiple services, see “Configuring Multiple Services” on page 130. 6. Define the port settings. In this example, the following ports are being used on the Web switch: Table 6-2 Web Host Example: Port Usage 126 n 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 Web content for all three None real servers. This port does not require Web switching features. 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 Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide The ports are configured as follows: >> >> >> >> >> >> >> >> >> >> 7. Virtual server 1# /cfg/slb/port 1 SLB port 1# server ena SLB port 1# ../port 2 SLB port 2# server ena SLB port 2# ../port 3 SLB port 3# server ena SLB port 3# ../port 5 SLB port 5# client ena SLB port 5# ../port 6 SLB port 6# client ena (Select physical switch port 1) (Enable server processing on port 1) (Select physical switch port 2) (Enable server processing on port 2) (Select physical switch port 3) (Enable server processing on port 3) (Select physical switch port 5) (Enable client processing on port 5) (Select physical switch port 6) (Enable client processing on port 6) Enable, apply, and verify the configuration. >> >> >> >> SLB port Layer 4# Layer 4# Layer 4# 6# .. on apply cur (Select the SLB Menu) (Turn Server Load Balancing on) (Make your changes active) (View current settings) Examine the resulting information. If any settings are incorrect, make the appropriate changes. 8. Save your new configuration changes. >> Layer 4# save (Save for restore after reboot) NOTE – You must apply any changes in order for them to take effect, and you must save changes if you wish them to remain in effect after switch reboot. 9. Check the SLB information. >> Layer 4# /info/slb/dump (View SLB information) Check that all SLB parameters are working according to expectation. If necessary, make any appropriate configuration changes and then check the information again. Chapter 6: Server Load Balancing 212777-A, February 2002 n 127 Web OS 10.0 Application Guide Additional Server Load Balancing Options In the previous section (“Configuring Server Load Balancing” on page 124), many of the SLB options are left to their default values. The following configuration options can be used to customize SLB on your Web switch: n n n n n n n n n n “Supported Services and Applications” on page 128 “Disabling and Enabling Real Servers” on page 129 “IP Address Ranges Using imask” on page 129 “Health Checks for Real Servers” on page 130 “Configuring Multiple Services” on page 130 “Metrics for Real Server Groups” on page 131 “Weights for Real Servers” on page 134 “Connection Time-outs for Real Servers” on page 134 “Maximum Connections for Real Servers” on page 134 “Backup/Overflow Servers” on page 135 Supported Services and Applications Each virtual server can be configured to support up to eight services, limited to a total of 256 services per switch. Using the /cfg/slb/virt /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. Table 6-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 NOTE – Load balancing some applications (such as FTP and RTSP) require special attention. See “Load Balancing Special Services” on page 149 for more information. 128 n Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Disabling and Enabling Real Servers If you need to reboot a server, you must make sure that new sessions are not sent to the real server and that old sessions are not discarded. When the session count gets to zero, you may shut down the server. Use the following command to disable real servers: >> # /oper/slb/dis When maintenance is complete, use the following command to enable the real server: >> # /oper/slb/ena IP Address Ranges Using imask The imask option lets you define a range of IP addresses for the real and virtual servers configured 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: n A virtual server is configured with an IP address of 172.16.10.1. n Real servers 172.16.20.1 and 172.16.30.1 are assigned to service the virtual server. n 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. Chapter 6: Server Load Balancing 212777-A, February 2002 n 129 Web OS 10.0 Application Guide 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 configured as part of each service. For more information, see “Configuring Multiple Services” on page 130. For UDP services, the switch pings servers to determine their status. By default, the switch checks each service on each real server every two seconds. If the real server is busy processing connections, it may not respond to a health check. By default, if a service does not respond to four consecutive health checks, the switch declares the service unavailable. As shown below, the health check interval and the number of retries can be changed: >> # /cfg/slb/real >> Real server# inter 4 >> Real server# retry 6 (Select the real server) (Check real server every 4 seconds) (Declare down after 6 checks fail) For more complex health-checking strategies, see Chapter 10, “Health Checking.” Configuring Multiple Services When you configure multiple services in a 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.” If you are configuring two independent services such as FTP and SMTP—where the real server failure on one service does not affect other services that the real server supports, then configure two groups with the same real servers but different services. If a real server configured for both FTP and SMTP fails FTP, the real server is still available for SMTP. This allows the services to act independently even though they are using the same real servers. If you are configuring two dependent services such as HTTP and HTTPS—where the real server failure on one service blocks the real server for other services, then configure a single group with multiple services. If a real server configured for both HTTP and HTTPS fails for the HTTP service, then the server is blocked from supporting any HTTPS requests. The switch will block HTTPS requests, (even though HTTPS has not failed) until the HTTP service becomes available again. This helps in troubleshooting so you know which service has failed. 130 n Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Metrics for Real Server Groups Metrics are used for selecting which real server in a group will receive the next client connection. The available metrics minmisses (minimum misses), hash, leastconns (least connections), roundrobin, bandwidth, and response (response time) are explained in detail below. The default metric is leastconns. To change a real server group metric to minmisses, for example, enter: >> # /cfg/slb/group >> Real server group# metric minmisses (Select the real server group) (Use minmisses metric) Minimum Misses The minmisses metric is optimized for Application Redirection. It uses IP address information in the client request to select a server. The specific IP address information used depends on the application: n For Application Redirection, the client destination IP address is used. All requests for a specific IP destination address is sent to the same server. This metric is particularly useful in caching applications, helping to maximize successful cache hits. Best statistical load balancing is achieved when the IP address destinations of load-balanced frames are spread across a broad range of IP subnets. n 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 metric, server load becomes most evenly balanced as the number of active clients with different source or destination addresses increases. When selecting a server, the switch calculates a score for each available real server based on the relevant IP address information. The server that scores the highest is assigned the connection. This metric attempts to minimize the disruption of persistency when servers are removed from service. This metric should be used only when persistence is a must. NOTE – 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. Chapter 6: Server Load Balancing 212777-A, February 2002 n 131 Web OS 10.0 Application Guide Hash The hash metric uses IP address information in the client request to select a server. The specific IP address information used depends on the application: n 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. n 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. n 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 stable. However, if a server is added to or leaves the mix, 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. 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. Least Connections With the leastconns metric, the number of connections currently open on each real server is measured in real time. The server with the fewest current connections is considered to be the best choice for the next client connection request. This option is the most self-regulating, with the fastest servers typically getting the most connections over time. Round Robin With the roundrobin metric, new connections are issued to each server in turn; that is, the first real server in the group gets the first connection, the second real server gets the next connection, followed by the third real server, and so on. When all the real servers in this group have received at least one connection, the issuing process starts over with the first real server. 132 n Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide 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 fluctuations in traffic distribution for the real server groups that use the leastconns or roundrobin metrics. Bandwidth The bandwidth metric uses real server octet counts to assign sessions to a server. The switch monitors the number of octets sent between the server and the switch. Then, the real server weights are adjusted so they are inversely proportional to the number of octets that the real server processes during the last interval. Servers that process more octets are considered to have less available bandwidth than servers that have processed fewer octets. For example, the server that processes half the amount of octets over the last interval receives twice the weight of the other servers. The higher the bandwidth used, the smaller the weight assigned to the server. Based on this weighting, the subsequent requests go to the server with the highest amount of free bandwidth. These weights are automatically assigned. The bandwidth metric requires identical servers with identical connections. NOTE – The effects of the bandwidth weighting apply directly to the real servers and are not necessarily 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 bandwidth 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 roundrobin metrics. Chapter 6: Server Load Balancing 212777-A, February 2002 n 133 Web OS 10.0 Application Guide Weights for Real Servers Weights can be assigned to each real server. These weights 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: >> # /cfg/slb/real >> Real server# weight 10 (Select the real server) (10 times the number of connections) NOTE – Weights are not applied when using the hash or minmisses metrics. Connection Time-outs for Real Servers In some cases, open TCP/IP sessions might not be closed properly (for example, the switch receives the SYN for the session, but no FIN is sent). If a session is inactive for 10 minutes (the default), it is removed from the session table in the switch. To change the time-out period, enter the following: >> # /cfg/slb/real >> Real server# tmout 4 (Select the real server) (Specify an even numbered interval) The example above would change the time-out period of all connections on the designated real server to four minutes. Maximum Connections for Real Servers You can set the number of open connections each real server is allowed to handle for SLB. To set the connection limit, enter the following: >> # /cfg/slb/real >> Real server# maxcon 1600 (Select the real server) (Allow 1600 connections maximum) Values average from approximately 500 HTTP connections for slower servers to 1500 for quicker, multiprocessor servers. The appropriate value also depends on the duration of each session and how much CPU capacity is occupied by processing each session. Connections that use a lot of Java or CGI scripts for forms or searches require more server resources and thus a lower maxcon limit. You may wish to use a performance benchmark tool to determine how many connections your real servers can handle. When a server reaches its maxcon limit, the switch no longer sends new connections to the server. When the server drops back below the maxcon limit, new sessions are again allowed. 134 n Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide 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: >> >> >> >> >> >> >> (Select real server 4 as backup) (Assign backup IP address) (Enable real server 4) (Select real server 1) (Real server 4 is backup for 1) (Select real server 2) (Real server 4 is backup for 2) # /cfg/slb/real 4 Real server 4# rip 200.200.200.5 Real server 4# ena Real server 4# /cfg/slb/real 1 Real server 1# backup 4 Real server 1# /cfg/slb/real 2 Real server 2# backup 4 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. >> # /cfg/slb/group >> Real server group# backup r4 (Select real server group) (Assign real server 4 as backup) Real server groups can also use another real server group for backup/overflow: >> # /cfg/slb/group >> Real server group# backup g2 (Select real server group) (Assign real server group 2 as backup) Chapter 6: Server Load Balancing 212777-A, February 2002 n 135 Web OS 10.0 Application Guide 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 Web switch. In complex network topologies, routers and other devices can create alternate paths around the Web switch managing SLB functions (see Figure 6-4 on page 122). Under such conditions, the Web switch with Web OS provides the following solutions: n Proxy IP Addresses n Mapping Ports n Direct Server Interaction n Delayed Binding Proxy IP Addresses In complex network topologies (see Figure 6-4 on page 122), SLB functions can be managed using a proxy IP address on the client switch ports. When the client requests services from the switch’s virtual server, the client sends its own IP address for use as a return address. If a proxy IP address is configured for the client port on the switch, the switch replaces the client’s source IP address with the switch’s own proxy IP address before sending the request to the real server. This creates the illusion that the switch originated the request. The real server uses the switch’s proxy IP address as the destination address for any response. SLB traffic is forced to return through the proper switch, regardless of alternate paths. Once the switch receives the proxied data, it puts the original client IP address into the destination address and sends the packet to the client. This process is transparent to the client. NOTE – Because requests appear to come from the switch proxy IP address rather than the client source IP address, the network administrator should be aware of this behavior during debugging and statistics collection. The proxy IP address can also be used for direct access to the real servers (see “Direct Server Interaction” on page 142). 136 n Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide 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 6-2 on page 126, the following revised port conditions are used: Table 6-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 Web content for all three real servers. This port does not require Web 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 Client requests originate. The following commands are used to disable server processing on ports 1-3: >> >> >> >> >> >> 2. # /cfg/slb/port 1 SLB port 1# server dis SLB port 1# ../port 2 SLB port 2# server dis SLB port 2# ../port 3 SLB port 3# server dis (Select switch port 1) (Disable server processing on port 1) (Select switch port 2) (Disable server processing on port 2) (Select switch port 3) (Disable server processing on port 3) Add proxy IP addresses to the client ports. Each client port requires a proxy IP address. Each proxy IP address must be unique on your network. The following commands are used to configure client proxies: >> >> >> >> # /cfg/slb/port 5 SLB port 5# pip 200.200.200.68 SLB port 5# ../port 6 SLB port 6# pip 200.200.200.69 (Select network port 5) (Set proxy IP address for client port 5) (Select network port 6) (Set proxy IP address for client port 6) The proxies are transparent to the user. Chapter 6: Server Load Balancing 212777-A, February 2002 n 137 Web OS 10.0 Application Guide 3. If the Virtual Matrix Architecture (VMA) feature is enabled, add proxy IP addresses for all other switch ports (except port 9). VMA is normally enabled on the switch. In addition to enhanced resource management, VMA eliminates many of the restrictions found in earlier versions of the Web OS. VMA does require, that when any switch port is configured with a proxy IP address, all ports must be configured with unique proxy IP addresses. If VMA is disabled, only the client port needs a proxy IP address and this step can be skipped. The following commands can be used for configuring the additional unique proxy IP addresses: >> >> >> >> >> >> >> >> >> >> >> >> SLB SLB SLB SLB SLB SLB SLB SLB SLB SLB SLB SLB port port port port port port port port port port port port 6# 1# 1# 2# 2# 3# 3# 4# 4# 7# 7# 8# /cfg/slb/port 1 pip 200.200.200.70 ../port 2 pip 200.200.200.71 ../port 3 pip 200.200.200.72 ../port 4 pip 200.200.200.73 ../port 7 pip 200.200.200.74 ../port 8 pip 200.200.200.75 (Select network port 1) (Set proxy IP address for port 1) (Select network port 2) (Set proxy IP address for port) (Select network port 3) (Set proxy IP address for port 3) (Select network port 4) (Set proxy IP address for port 4) (Select network port 7) (Set proxy IP address for port 7) (Select network port 8) (Set proxy IP address for port 8) NOTE – Port 9 does not require a proxy IP address under VMA. For conceptual information, see “Virtual Matrix Architecture” on page 217 of this manual and for information on using the commands, see the Web OS Command Reference (/cfg/slb/adv/matrix) for more information. 4. 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. 138 n Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Mapping Ports An Alteon Web 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 144), mapping is required when administrators choose to execute their real server processes on different ports than the well-known TCP/UDP ports. Otherwise, virtual server ports are mapped directly to real server ports by default and require no mapping 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 following: >> # /cfg/slb/virt 1/service 80 (Select virtual server port 80) >> Virtual Server 1 http Service# rport 8004 (Map to real port 8004) NOTE – If filtering is enabled, a proxy IP address is configured, or URL parsing is enabled on any switch port, then port mapping is supported with Direct Access Mode (DAM). For information about DAM, refer to “Using Direct Access Mode” on page 143. Mapping a Single Virtual Server Port to Multiple Real Server Ports To take advantage of multi-CPU or multi-process servers, Web OS can be configured to map a single virtual port to multiple real ports. This capability allows the Web site managers, for example, to differentiate users of a service by using multiple service ports to process client requests. An Alteon Web 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 Web 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. Chapter 6: Server Load Balancing 212777-A, February 2002 n 139 Web OS 10.0 Application Guide Consider the following network: Real Servers Web Clients 192.168.2.1 8001 8002 Web Switch 192.168.2.2 8001 8002 Internet Web Host Routers 192.168.2.3 8001 8002 192.168.2.4 8001 8002 Figure 6-6 Basic Virtual Port to Real Port Mapping Configuration Domain Name virtual server IP Ports Activated address Port Mapping Real Server IP Address www.right.com 192.168.2.100 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) 80 (HTTP) 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: 140 n n 192.168.2.1/8001 n 192.168.2.1/8002 n 192.168.2.2/8001 n 192.168.2.2/8002 n 192.168.2.3/8001 n 192.168.2.3/8002 n 192.168.2.4/8001 n 192.168.2.4/8002 Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide 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 /service , 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 multiple 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. /cfg/slb/real ../real 2/rip ../real 3/rip ../real 4/rip 1/rip 192.168.2.1/ena 192.168.2.2/ena 192.168.2.3/ena 192.168.2.4/ena Add all four servers to a group. >> >> >> >> >> 3. # # # # # /cfg/slb/group 1 Real server Group 1# Real server Group 1# Real server Group 1# Real server Group 1# add add add add 1 2 3 4 Configure a virtual server IP address. >> # /cfg/slb/virt 1/vip 192.168.2.100/ena Chapter 6: Server Load Balancing 212777-A, February 2002 n 141 Web OS 10.0 Application Guide 4. Turn on multiple rport for Port 80. >> # /cfg/slb/virt 1/service 80/rport 0 5. Add the ports to which the Web server listens. >> >> >> >> >> >> >> >> # # # # # # # # /cfg/slb/real 1/addport 8001 addport 8002 ../real 2/addport 8001 addport 8002 ../real 3/addport 8001 addport 8002 ../real 4/addport 8001 addport 8002 (Add port 8001 to real server 1) (Add port 8002 to real server 1) (Add port 8001 to real server 2) (Add port 8002 to real server 2) (Add port 8001 to real server 3) (Add port 8002 to real server 3) (Add port 8001 to real server 4) (Add port 8002 to real server 4) Direct Server Interaction Direct access to real servers can be provided in the following ways: n Using Direct Server Return n Using Direct Access Mode n Assigning Multiple IP Addresses n Using Proxy IP Addresses n Mapping Ports n Monitoring Real Servers Using 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 splicing. NOTE – DSR requires that the server be set up to receive frames that have a destination IP address that is equal to the virtual server IP address. 142 n Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide The sequence of steps that are executed in this scenario are shown in Figure 6-7: Web Switch Server farm 2 Client 1 Internet Layer 2 Switch 3 Figure 6-7 Direct Server Return 1. A client request is forwarded to the Web 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 /submac ena >> # /cfg/slb/virt /service /nonat ena Using Direct Access Mode When Direct Access Mode (DAM) (/cfg/slb/direct) is enabled on a switch, any client can communicate with any real server’s load-balanced service. Also, with DAM enabled, any number of virtual services can be configured to load balance a real service. Traffic sent directly to real server IP addresses is excluded from load-balancing decisions. The same clients may also communicate to the virtual server IP address for load-balanced requests. 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. 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. Chapter 6: Server Load Balancing 212777-A, February 2002 n 143 Web OS 10.0 Application Guide Using Proxy IP Addresses Proxy IP addresses are used primarily to eliminate SLB topology restrictions in complex networks (see “Proxy IP Addresses” on page 136). Proxy IP addresses can also provide direct access to real servers. If the switch port to the client is configured with a proxy IP address, the client can access each real server directly using the real server’s IP address. The switch port must be connected to the real server and client processing must be disabled (see the server and client options under the /cfg/slb/port command in your Web OS Command Reference). SLB is still accessed using the virtual server IP address. Mapping Ports When SLB is used without proxy IP addresses and without DAM, the Web 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 Web switch, with the real server IP address getting remapped back to the virtual server IP address on the Web 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 Web switch must be mapped to the proper real server port. In Figure 6-8, clients can access SLB services through well-known TCP port 80 at the virtual server’s IP address. The Web switch behaving like a virtual server is mapped to TCP port 8000 on the real server. For direct access that bypasses the virtual server and SLB, clients can specify well-known TCP port 80 as the real server’s IP address. Direct Access via Real Server IP & Port 80 Client Network 80 8000 Virtual Server on the Alteon Web Switch Real Server Layer 4 Mapped Access via Virtual Server IP & Port Figure 6-8 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 139. 144 n Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide 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: n mnet: If defined, management traffic with this source IP address is allowed direct (nonSLB) 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. n mmask: This IP address mask is used with mnet to select management traffic that is allowed direct real server access only. Chapter 6: Server Load Balancing 212777-A, February 2002 n 145 Web OS 10.0 Application Guide Delayed Binding The delayed binding feature on the switch prevents SYN Denial-of-Service (DoS) attacks on the server. DoS occurs when the server or switch is denied servicing the client because it is saturated with invalid 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 acknowledges the SYN ACK by sending an acknowledgement (ACK) back to the server, thus completing the three-way handshake. Figure 6-9 on page 146 illustrates a classic type of SYN DoS attack. If the client does not acknowledge the server’s SYN ACK with a data request (REQ) and, instead, sends another SYN request, the server gets saturated with SYN requests. As a result, all of the servers resources are consumed and it can no longer service legitimate client requests. Normal Request Client Server Client sends a SYN request Server reserves session and sends SYN ACK Client sends an ACK or DATA REQ Server responds with DATA DoS SYN Attack Client Server Client sends a SYN request Server reserves session and sends SYN ACK Client ignores SYN ACK and continues to send new SYN requests Server continues reserving sessions. Server is eventually saturated and cannot process legitimate requests. Figure 6-9 DoS SYN Attacks without Delayed Binding Using an Alteon Web switch with delayed binding, as illustrated in Figure 6-10 on page 147, the Web switch intercepts the client SYN request before it reaches the server. The Web switch responds to the client with a SYN ACK that contains embedded client information. The Web switch does not allocate a session until a valid SYN ACK is received from the client or the three-way handshake is complete. 146 n Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Normal Request with Delayed Binding Server Web Switch Client Internet Client sends a SYN request Switch responds with special SYN ACK Client sends an ACK or DATA REQ Switch recognizes valid three-way handshake Switch sends a SYN request to server Server responds with SYN ACK Switch sends ACK or DATA REQ Server responds with DATA and switch splices connection to client DoS SYN Attack with Delayed Binding Web Switch Client Server Internet Client sends a SYN request Switch responds with special SYN ACK Client sends new SYN requests Switch responds with another SYN ACK No session entry is made until a valid three-way handshake is complete. Switch and server resources are protected for legitimate requests Figure 6-10 Repelling DoS SYN Attacks With Delayed Binding Once the Web switch receives a valid ACK or DATA REQ from the client, the Web 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 Web switch delays binding the client session to the server until the proper handshakes are complete. Thus, with delayed binding, two independent TCP connections span a Web session: one from the client to the Web switch and the second from the Web 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. Chapter 6: Server Load Balancing 212777-A, February 2002 n 147 Web OS 10.0 Application Guide Configuring Delayed Binding To configure your switch for delayed binding, use the following command: >> # /cfg/slb/virt /service /dbind NOTE – Enable delayed binding without configuring any HTTP SLB processing or persistent binding types. To configure delayed binding for Web cache redirection, see “Delayed Binding for Web Cache Redirection” on page 210. Detecting SYN Attacks In Web OS, SYN attack detection is enabled by default, whenever delayed binding is enabled. SYN attack detection: n Provides a way to track half open connections n Activates a trap notifying that the configured threshold is exceeded n Monitors DoS attacks and proactively signals alarm n Provides enhanced security n 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 Web switch. Half-open sessions show an incomplete three-way handshake between the server and the client. You can view the total number of half-open sessions from the /stat/slb/layer7/maint menu. To detect SYN attacks, the Web 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. 148 n Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Load Balancing Special Services This section discusses load balancing based on special services, such as n IP Server Load Balancing n FTP Server Load Balancing n Domain Name Server (DNS) Load Balancing n Real Time Streaming Protocol SLB n Wireless Application Protocol SLB n Intrusion Detection System Server Load Balancing n WAN Link Load Balancing IP Server Load Balancing IP server load balancing allows you to configure your Web switch for server load balancing based on client’s IP address only. Typically, the client IP address is used with the client port number to produce a session identifier. When the Layer 3 option is enabled, the switch uses only the client IP address as the session identifier. To configure the switch for IP load balancing: >> >> >> >> # /cfg/slb/virt Virtual Server 1# layr3 ena Virtual Server 1# service ip Virtual Server 1 IP Service# group IP server load balancing must be used if IP traffic is totally encrypted and you do not have access to the content. Chapter 6: Server Load Balancing 212777-A, February 2002 n 149 Web OS 10.0 Application Guide FTP Server Load Balancing As defined in RFC 959, FTP uses two connections—one for control information and another for data. Each connection is unique. Unless the client requests a change, the server always uses TCP port 21 (a well-known port) for control information, and TCP port 20 as the default data port. FTP uses TCP for transport. After the initial three-way handshake, a connection is established. When the client requests any data information from the server, it will issue a PORT command (such as ls, dir, get, put, mget and mput) via the control port. There are two modes of FTP operation, active and passive: n n In Active FTP, the FTP server initiates the data connection. In Passive FTP, the FTP client initiates the data connection. Because the client also initiates the connection to the control channel, the passive FTP mode does not pose a problem with firewalls and is the most common mode of operation. FTP Network Topology Restrictions FTP network topology restrictions are listed below: n n n FTP uses both a control channel and a data channel; both channels need to be bound to the same real server. The FTP server may initiate FTP data sessions. Information exchanged on the control channel is used to determine the IP address and port for data connections between the FTP server and the FTP client. 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. >> # /cfg/slb/virt >> Virtual Server 1# service ftp 3. Enable FTP parsing. >> Virtual Server 1 ftp Service# ftpp ena 4. To make your configuration changes active, enter apply at any prompt in the CLI. >> Virtual Server 1 ftp Service# apply NOTE – 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. 150 n Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Domain Name Server (DNS) Load Balancing In previous releases of Web OS, DNS load balancing was based on virtual server IP address and virtual port (VPORT) only. In Web OS 10.0 however, 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. Figure 6-11 shows four real servers load balancing UDP and TCP queries between two groups. Real servers 10.10.10.20 Group 1 UDP health udpdns 20 10.10.10.21 21 vip 20.20.20.20 Internet Client Real servers Web Switch 22 Group 2 TCP health dns 26 10.10.10.22 10.10.10.26 Figure 6-11 Layer 4 DNS Load Balancing NOTE – You can configure both UDP and TCP DNS queries for the same virtual server IP address. Chapter 6: Server Load Balancing 212777-A, February 2002 n 151 Web OS 10.0 Application Guide Preconfiguration Tasks 1. Enable server load balancing. >> # /cfg/slb/ena 2. Configure the four real servers and their real IP addresses. >> >> >> >> >> >> >> >> >> >> >> >> 3. # /cfg/slb/real Real server 20 # Real server 20 # Real server 20 # Real server 21 # Real server 21 # Real server 20 # Real server 22 # Real server 22 # Real server 20 # Real server 26 # Real server 26 # 20 ena rip 10.10.10.20 ../real 21 ena rip 10.10.10.21 ../real 22 ena rip 10.10.10.22 ../real 26 ena rip 10.10.10.26 (Enable real server 20) (Specify the IP address) (Enable real server 21) (Specify the IP address) (Enable real server 22) (Specify the IP address) (Enable real server 26) (Specify the IP address) Configure group 1 for UDP and group 2 for TCP. >> # /cfg/slb/group 1 >> Real server group 1 # metric roundrobin >> >> >> >> Real Real Real Real server server server server group group group group 1 1 1 1 # # # # health udpdns add 20 add 21 ../group 2 >> Real server group 2 # metric roundrobin >> Real server group 2 # health dns >> Real server group 2 # add 22 >> Real server group 2 # add 26 (Select real server group 1) (Specify the load balancing metric for group 1) (Set the health check to UDP) (Add real server 20) (Add real server 21) (Specify the load balancing metric for group 2) (Set the health check to TCP) (Add real server 22) (Add real server 26) For more information on configuring health check, see “UDP-Based DNS Health Checks” on page 233. 4. Define and enable the server ports and the client ports. For more information, see Step 6 “Define the port settings.” on page 126. Some DNS servers initiate upstream requests and must be configured both as server and client. 152 n Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Configuring UDP-based DNS Load Balancing 1. Configure and enable a virtual server IP address 1 on the switch. >> # /cfg/slb/virt 1/vip 20.20.20.20 >> Virtual Server 1# ena 2. (Specify the virt server IP address) (Enable the virtual server) Set up the DNS service for the virtual server, and add real server group 1. >> Virtual Server 1# service dns (Specify the DNS service) >> Virtual Server 1 DNS Service# group 1 (Select the real server group) 3. Disable delayed binding. Delayed binding is not required because UDP does not process session requests with a TCP three-way handshake. >> Virtual Server 1 DNS Service# dbind dis (Disable delayed binding) 4. Enable UDP DNS queries. >> Virtual Server 1 DNS Service# udp ena 5. (Enable UDP balancing) Apply and save your configuration. >> Virtual Server 1 DNS Service# apply >> Virtual Server 1 DNS Service# save Chapter 6: Server Load Balancing 212777-A, February 2002 n 153 Web OS 10.0 Application Guide Configuring TCP-based DNS Load Balancing 1. Configure and enable the virtual server IP address 2 on the switch. >> # /cfg/slb/virt 2/vip 20.20.20.20 >> Virtual Server 2# ena 2. (Specify the virt server IP address) (Enable the virtual server) Set up the DNS service for virtual server, and select real server group 2. >> Virtual Server 2# service dns (Specify the DNS service) >> Virtual Server 2 DNS Service# group 2 (Select the real server group) 3. Enable delayed binding. >> Virtual Server 2 DNS Service# dbind ena(Enable delayed binding) 4. As this is TCP-based load balancing, make sure to disable UDP DNS queries. >> Virtual Server 2 DNS Service# udp dis 5. (Disable UDP balancing) Apply and save your configuration. >> Virtual Server 2 DNS Service# apply >> Virtual Server 2 DNS Service# save 154 n Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide 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 used as a “network remote control” for multimedia servers. 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. Web OS supports one Layer 7 metric (URL hashing and URL pattern matching) and all Layer 4 load-balancing metrics. 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. Typically, an RTSP client establishes a control connection to an RTSP server over TCP port 554 and the data flows over UDP or TCP. For information on using RTSP with Web cache redirection, see “RTSP Web Cache Redirection” on page 211. 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. In a typical scenario, the RTSP client issues several sequences of commands to establish connections for each component stream of a presentation. There are several variations to this procedure, depending upon the RTSP client and the server involved. For example, there are two prominent RTSP server and client implementations: Real Server marketed by Real Networks Chapter 6: Server Load Balancing 212777-A, February 2002 n 155 Web OS 10.0 Application Guide Corporation, and Quicktime Streaming Server marketed by the Apple Inc. The RTSP stream setup sequence is different for these two servers, and the switch handles each differently. Some of these differences are described below. n Real Server Real Server supports both UDP and TCP transport protocols for the RTSP streams. The actual transport is negotiated during the initialization of the connection. If TCP transport is selected, then all streams of data will flow in the TCP control connection itself. If UDP transport is chosen, the client and server negotiate a client UDP port, which is manually configurable. The real media files that the Real Server plays have the extension “.rm”, “.ram” or “.smil”. n QuickTime Streaming Server Apple Inc.’s QuickTime Streaming Server typically runs on the Apple platforms. QuickTime files that can be played over the Internet using RTSP are specially formatted and are called “hinted QuickTime files.” Normal QuickTime files cannot be used for streaming. The QuickTime files have the extension “.mov”. QuickTime uses UDP protocol exclusively for transport and TCP for control connection. Each stream of a QuickTime presentation sends Real Time Protocol (RTP), and Real Time Control Protocol (RTCP) data using two UDP connections. Typically, a QuickTime presentation has two streams and therefore uses four UDP connections and one TCP control connection. QuickTime clients use a UDP port, which is manually configurable. RTSP Implementation RTSP implementation in Web OS supports the following: 156 n n Alteon AD3, Alteon AD4, Alteon 180e, and Alteon 184 platforms n Private addressing on the server side n Layer 7 URL-hashing metric, URL pattern matching, and all Layer 4 metrics for load balancing. n All the stream connections and the control connections are switched to the same cache server to facilitate caching of entire presentations. n RTSP-compliant applications (excludes Windows Media Player because it is not RTSP compliant). Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Configuring RTSP Load Balancing Before configuring your Web switch for RTSP load balancing, do the following: 1. n Enable Virtual Matrix Architecture (VMA) n Enable Direct Access Mode (DAM) n Disable port-based Bandwidth Management n Disable proxy IP addressing 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/virt /service rtsp 2. To configure a virtual server for Layer 7 URL hashing of RTSP, select rtsp as a virtual service and enable rtspslb. This command enables URL hashing using the entire URL; however, any extension of the type (.xxx) occurring at the end of the URL is omitted from hash computation. >> # /cfg/slb/virt 1/service rtsp/rtspslb hash|pattern|dis 3. Apply and save your configuration. >> Virtual Server 2 rtsp Service# apply >> Virtual Server 2 rtsp Service# save Chapter 6: Server Load Balancing 212777-A, February 2002 n 157 Web OS 10.0 Application Guide 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 systems—with the goal of inter-operability. A WAP Gateway translates Wireless Markup Language (WML)— which is a WAP version of HTML—into HTML/HTTP so that requests for information can be serviced by traditional Web servers. To load balance WAP traffic among available parallel servers, the switch must provide persistency so that the clients can always go to the same WAP gateway to perform WAP operation. Web OS allows the Web switch to decide which real gateway the request should go. WAP SLB is based on RADIUS static session entry or RADIUS snooping. The following topics are discussed in this section: n Using RADIUS Static Session Entries n Using RADIUS Snooping n Preconfiguring WAP Server Load Balancing n Enabling Wireless Application Protocol SLB n Configuring RADIUS Snooping Using RADIUS Static Session Entries RADIUS is a client/server protocol and software that enables remote access servers to communicate with a central server to authenticate dial-in users and authorize their access to the requested network or service. RADIUS allows a company to maintain user profiles in a central database that all remote servers can share. It provides better security, allowing a company to set up a policy that can be applied at a single administered network point. RADIUS is an industry standard used by network product companies and is a proposed IETF standard. The RADIUS server uses a static session entry to determine which real WAP gateway should receive the user’s 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). 158 n Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide TPCP is Alteon’s proprietary protocol that is used to establish communication between the RADIUS servers and the Alteon Web switch. It is UDP-based and uses ports 3121, 1812, and 1645. Using TPCP, a static session entry is added or removed by the external devices, such as the RADIUS servers. A regular session entry is usually added or removed by the switch itself. A static session entry, like a regular session entry, contains information such as the client IP address, the client port number, real port number, virtual (destination) IP address, virtual (destination) port number. A static session entry added via TPCP to the switch does not age out. The entry will only be deleted by another TPCP Delete Session request. If the user adds session entries using the traditional server load balancing methods, the entries will continue to age out. Since TPCP is UDP-based, the Add/Delete Session requests may get lost during transmission. The WAP gateway issues another Add Session request on detecting that it has lost a request. The WAP gateway detects this situation when it receives WAP 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 Using 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 an Add Session request from the RADIUS server and adds a session entry to its session table to bind a WAP gateway with that user. 5. A response (RADIUS Accept) packet is sent back to the RAS by the RADIUS server. 6. The RAS receives a RADIUS Accept packet and allows the WAP traffic for that user. 7. If the user disconnects, the RAS detects it and sends a RADIUS Accounting Stop message to the RADIUS server. 8. The RADIUS server sends a Delete session message and removes the session entry for that user. Chapter 6: Server Load Balancing 212777-A, February 2002 n 159 Web OS 10.0 Application Guide Using RADIUS Snooping Radius snooping allows the Alteon Web switch to examine RADIUS accounting packets for client information. This information is needed to add to or delete static session entries to the session table of the switch 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 Using 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 information it needs. It needs to know the type of the RADIUS Accounting message, the client IP address, the caller ID, and the user’s name. If it finds this information, the switch adds a session entry to its session table. If any of this information is missing, the switch will not take any action to handle the session entry. When the client ends the WAP connection, RAS sends RADIUS Accounting Stop packet. If the switch finds the needed information in a RADIUS Accounting Stop packet, it removes the corresponding session entry from its table. The following steps occur for RADIUS snooping: 160 n 1. The user is authenticated on dialing. 2. The RAS establishes a session with the client and sends a RADIUS Accounting Start message 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. Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Preconfiguring WAP Server Load Balancing n Configure WAP server load balancing on Alteon AD4 and Alteon 184 platforms only. n Enable Virtual Matrix Architecture (VMA). >> # /cfg/slb/adv/matrix ena n Disable DAM (Direct Access Mode). >> # /cfg/slb/adv/direct dis n Disable pbind and enable udp under the WAP services (ports 9200 to 9203) menu. >> # /cfg/slb/virt /service /pbind dis >> # /cfg/slb/virt /service /udp ena n Configure for RADIUS service 1812 and 1645. NOTE – The radius service number specified on the switch must match with the service specified on the server. Enabling Wireless Application Protocol SLB 1. Enable the external notification from WAP gateway to add and delete session request. >> # cfg/slb/adv/tpcp ena 2. Enable TPCP for adding and deleting WAP sessions. >> # cfg/slb/wap/tpcp ena Configuring RADIUS Snooping Consider the following items before configuring RADIUS snooping: n The same virtual server IP address must be used when load balancing both the RADIUS accounting traffic and WAP traffic. n All the RADIUS servers must use the same UDP port for RADIUS accounting services. n Before a session entry is recorded on the switch, WAP packets for a user can go to any of the real WAP gateways. Chapter 6: Server Load Balancing 212777-A, February 2002 n 161 Web OS 10.0 Application Guide n If a session entry for a client cannot be added because of resource constraints, the subsequent WAP packets for that client will not be load balanced correctly; and the client will need to drop the connection and then reconnect to his wireless service. n The persistence of a session cannot be maintained if the number of healthy real WAP gateways changes during the session. For example, if a new WAP server comes into service or some of the existing WAP servers are down, the number of healthy WAP gateway changes and, in this case, the persistence for a user cannot be maintained. n 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. Configure the following filter on the switch to examine a RADIUS accounting packet: 1. Set the basic filter parameters. >> >> >> >> >> >> >> >> 2. # /cfg/slb/filt 1 Filter 1 # dip 10.10.10.100 Filter 1 # dmask 255.255.255.255 Filter 1 # proto udp Filter 1 # dport 1813 Filter 1 # action redir Filter 1 # group 1 Filter 1 # rport 1813 Turn on proxy and RADIUS snooping. >> Filter 1 # adv >> Filter 1 Advanced# proxy ena >> Filter 1 Advanced# rdsnp ena 3. (Select the filter) (Set the destination IP address) (Set the destination IP mask) (Set the protocol to UDP) (Set the destination port) (Set the action to redirect) (Set the group for redirection) (Set server port for redirection) (Select the advance filter menu) (Enable proxy) (Enable RADIUS snooping) Apply and save your configuration. >> Filter 1 Advanced# apply >> Filter 1 Advanced# save NOTE – Web OS supports Virtual Router Redundancy Protocol (VRRP) and stateful failover, using both static session entries and RADIUS snooping. However, active-active configuration with Stateful Failover is not supported. 162 n Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Intrusion Detection System Server Load Balancing Intrusion Detection System (IDS) is a type of security management system for computers and networks. An Intrusion Detection System gathers and analyzes information from various areas within a computer or a network to identify possible security breaches, which include both intrusions (attacks from outside the organization) and misuse (attacks from within the organization). Intrusion detection functions include: n Monitoring and analyzing both user and system activities n Analyzing system configurations and vulnerabilities n Assessing system and file integrity n Recognizing patterns typical of attacks n Analyzing abnormal activity patterns n Tracking user policy violations Intrusion detection devices inspect every packet before it enters a network, looking for any signs of an attack. The attacks are recorded and logged in an attempt to guard against future attacks and to record the information about the intruders. IDS Server Load Balancing helps scale intrusion detection systems since it is not possible for an individual server to scale information being processed at gigabit speeds. How Intrusion Detection Server Load Balancing Works Web OS allows the switch to forward the IP packets to an Intrusion Detection server at the end of the filtering process or at the end of client processing (when filtering is not enabled). The user must enable IDS SLB on the port and allocate a real server group for IDS Server Load Balancing. The IDS SLB-enabled switch copies all incoming packets to this group of intrusion detection servers. For each session entry created on the switch, an IDS server is selected based on the IDS server load-balancing metric. The IDS server receives copies of all the processed frames that are forwarded to the destination devices. Session entries are maintained so that all the frames of a given session are forwarded to the same IDS server. Each IDS server must be connected directly to a different switch port or VLAN because no field in the packet header can be substituted. Substituting a field would corrupt the packet that must also be forwarded to its real destination. Chapter 6: Server Load Balancing 212777-A, February 2002 n 163 Web OS 10.0 Application Guide Load Balancing Metrics for IDS The following metrics are supported in IDS load balancing: n minmisses n roundrobin Disable delayed binding if you select this metric. n hash To select a real server, Web OS allows you to implement the hash metric in two ways: o Client processing on port If the port is configured for client processing only, then the switch hashes on the source IP address. o Filter processing on the port If a filter is configured on the port, then the switch allows you to hash with source IP address, destination IP address, or both. NOTE – The leastconns, bandwidth, and response metrics are not applicable to IDS server load balancing. Configuring IDS Server Load Balancing To configure your switch for IDS, do the following: NOTE – IDS SLB is supported only when RTSP SLB or WAP RADIUS Snooping are disabled on the Web switch. 1. Configure real servers on the switch that correspond to your IDS servers. NOTE – Real servers are configured by providing the IP address of the actual server. If your IDS servers are implemented without an IP address then you should configure a dummy address for the real server. Also, set the health check of the IDS group to link health check as shown in Step 5 of this procedure. For example, if your IDS servers are connected to port 1 and port 2 on the switch and are not using IP addresses, you could configure dummy addresses as follows: >> # /cfg/slb/real 1/rip 1.1.1.1/ena >> # /cfg/slb/real 2/rip 2.2.2.2/ena 164 n (Define a dummy address) (Define a dummy address) Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide 2. Create a group and add IDS servers to the group. Each IDS server must be connected directly to a different switch port or VLAN. If the IDS group will be configured for link health check, match the IDS server number to the physical port number (1 to 9) to which it is connected. For ICMP health check, the IDS server number can be between 1 and 31. >> # /cfg/slb/group >>Real Server Group # add 1 >>Real Server Group # add 2 3. Define the IDS server load balancing group. >> # /cfg/slb/adv/idslb 4. (Select the group with the IDS servers) Enable the IDS ports for the clients. >> >> >> >> 5. (Define a group) (Add IDS server 1) (Add IDS server 2) # /cfg/slb/port 5 SLB port 5# idslb ena SLB port 5# ../port 6 SLB port 6# idslb ena (Select IDS port 1) (Enable IDS on port 1) (Select IDS port 2) (Enable IDS on port 2) Define the group health check. If you implemented IDS without an IP address, link health check is specifically developed for IDS load balancing. Use ICMP health check if your IDS servers are configured with an IP address. >> # /cfg/slb/group /health link 6. Apply and save your changes. >> Real server group 1# apply >> Real server group 1# save Chapter 6: Server Load Balancing 212777-A, February 2002 n 165 Web OS 10.0 Application Guide WAN Link Load Balancing Wide Area Networking (WAN) is a telecommunications network system spread across a broad geographic area. A WAN may be privately owned or rented, but the term usually means the inclusion of public (shared user) networks, such as the telephone system. WANs can also be connected through leased lines and satellites. WANs are typically composed of powerful routers and switches that link business enterprises, universities, remote offices, and so on, around the world. To handle the high volume of data on the Internet, some corporations are using more than one Internet Service provider (ISP) as a way to increase reliability of Internet connections. Such enterprises with more than one ISP are referred to as being multi-homed. In addition to reliability, a multi-homed network architecture enables enterprises to distribute load among multiple connections and to provide more optimal routing. The WAN link load-balancing feature introduces additional resilience for networks in multihomed environment. When users want to control which WAN link the traffic traverses, WAN link load balancing can be used to steer requests initiated within the user’s network and his/her responses over the appropriate link at that moment in time. How WAN Link Load Balancing Works The Web switch uses redirection filters to redirect traffic initiated from within the user’s network to a group of devices that exist at the other end of the WAN link (routers, for example). These filters determine which link is the best at the time the request is generated. To ensure that the responses traverse the same link, the source IP address of the request is translated to one of the addresses that the selected ISP owns. The design of WAN link load balancing is identical to standard redirection, except that it substitutes the source IP address of each frame with the proxy IP address of the port to which the WAN link is connected. Configuring WAN Link Load Balancing Before configuring the Web switch for WAN Link load balancing, make sure of the following: 166 n n Disable NAT Web Cache Redirection. WAN Link load balancing and NAT Web Cache Redirection cannot be configured on the same switch. n Configure the load balancing metric for response time only. n Do not configure your ports into trunk groups. n Do not configure WAN link load balancing with two or more WAN links connected through the same switch port. This feature uses the proxy IP address of the destination port when translating the source IP address of the requests. Chapter 6: Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide To configure the switch for WAN link load balancing: 1. Define a real server with proxy disabled. >> >> >> >> 2. (Select the real server menu) (Enable real server 1) (Set the real server IP address) (Disable proxy) # /cfg/slb/real 1 Real server 1# ena Real server 1# rip Real server 1# proxy dis Add the real server to a real server group using the response metric. >> # /cfg/slb/group 1 >> Real server group 1# add 1 >> Real server group 1# metric response 3. Define the WAN link load balancing redirection filter. >> >> >> >> 4. Real server group 1# /cfg/slb/filt 1 Filter 1# ena Filter 1# action redir Filter 1# group 1 Enable WAN link load balancing for the redirection filter. >> # /cfg/slb/filt 1/adv/linklb ena 5. Enable WAN link load balancing proxy for the redirection filter. >> # /cfg/slb/filt 1/adv/proxy ena 6. Apply and save your changes. >> Filter 1 Advanced# apply >> Filter 1 Advanced# save Chapter 6: Server Load Balancing 212777-A, February 2002 n 167 Web OS 10.0 Application Guide 168 n Chapter 6: Server Load Balancing 212777-A, February 2002 CHAPTER 7 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). The following topics are discussed in this chapter: n “Overview” on page 170. This section describes the benefits and filtering criteria to allow for extensive filtering at the IP and TCP/UDP levels. o “Filtering Benefits” on page 170 o “Filtering Criteria” on page 170 o “Stacking Filters” on page 172 o “Overlapping Filters” on page 172 o “The Default Filter” on page 173 o “VLAN-based Filtering” on page 174 o “Optimizing Filter Performance” on page 176 o “Filter Logs” on page 176 o “IP Address Ranges” on page 178 o “Cache-Enabled versus Cache-Disabled Filters” on page 178 n “TCP Rate Limiting” on page 179. This section explains how TCP rate limiting allows you to monitor the number of new TCP connections within a configurable time window. n “Tunable Hash for Filter Redirection” on page 184 allows you to select any hash parameter for filter redirection. n “Filter-based Security” on page 185. This section provides an example of configuring filters for providing the best security. n “Network Address Translation” on page 191. This section provides two examples: Internal client access to the Internet and external client access to the server. n “Matching TCP Flags” on page 197 and “Matching ICMP Message Types” on page 201. Describes the ACK filter criteria which provides greater filtering flexibility and lists ICMP message types that can be filtered respectively. 169 212777-A, February 2002 Web OS 10.0 Application Guide Overview Alteon Web switches are used to deliver content efficiently and secure your servers from unauthorized intrusion, probing, and Denial-of-Service (DoS) attacks. Web OS includes extensive filtering capabilities at the IP and TCP/UDP levels. Filtering Benefits Layer 3 (IP) and Layer 4 (application) filtering give the network administrator a powerful tool with the following benefits: n Increased security for server networks Filters can be configured to allow or deny traffic according to various IP address, protocol, and Layer 4 port criteria. 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 “Layer 7 Deny Filter” on page 417. This gives the administrator control over the types of traffic permitted through the switch. Any filter can be optionally configured to generate system log messages for increased security visibility. n 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. Filtering Criteria Up to 2048 filters can be configured on Alteon 184 and Alteon AD4 Web switches. Up to 224 filters are supported on other Alteon Web switches. Descriptive names can be used to define filters. Each filter can be set to allow, deny, redirect, or translate traffic based on any combination of the following filter options: 170 n n sip: source IP address or range (see “IP Address Ranges” on page 178) n dip: destination IP address or range (dip and dmask) Chapter 7: Filtering 212777-A, February 2002 Web OS 10.0 Application Guide n proto: protocol number or name as shown in Table 7-1 Table 7-1 Well-Known Protocol Types n Number Protocol Name 1 2 6 17 89 112 icmp igmp tcp udp ospf vrrp sport: TCP/UDP application or source port as shown in Table 7-2, or source port range (such as 31000-33000) Table 7-2 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 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 ftp-data ftp ssh telnet smtp time name whois domain tftp gopher NOTE – The service number specified on the switch must match the service specified on the server. n n n dport: TCP/UDP application or destination port as shown in Table 7-2, or destination port range (such as 31000-33000) invert: reverse the filter logic in order to activate the filter whenever the specified conditions are not met. Advanced filtering options such as TCP flags (page 197) or ICMP message types (page 201) are also available. Using these filter criteria, you can 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. Chapter 7: Filtering 212777-A, February 2002 n 171 Web OS 10.0 Application Guide 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 184 and Alteon AD4 Web switches, and 1 though 224 on other Alteon Web switches. When multiple filters are stacked together on a port, the filter’s number determines its order of precedence: the filter with the lowest number is checked first. When traffic is encountered at the switch port, if the filter matches, its configured action takes place and the rest of the filters are ignored. If the filter criteria doesn’t 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: Filtering by Destination IP Address Ranges 0.0.0.0 255.255.255.255 Deny Allow Deny Redirect Filter 2 Filter 4 Filter 3 Filter 1 Figure 7-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. 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: Filtering by Destination IP Address Ranges 0.0.0.0 255.255.255.255 Deny Redirect Allow Filter 3 Filter 2 Filter 1 Figure 7-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. 172 n Chapter 7: Filtering 212777-A, February 2002 Web OS 10.0 Application Guide 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: Filtering by Destination IP Address Ranges 0.0.0.0 255.255.255.255 Deny Filter 224 Allow Redirect Filter 2 Filter 1 Figure 7-3 Assigning a Default Filter In this example, the default filter is defined as Filter 224 in order to give it the lowest order of precedence. All matching criteria in Filter 224 are set to the any state. If no other filter acts on the traffic, Filter 224 processes it, denying and logging unwanted traffic. >> >> >> >> >> >> # /cfg/slb/filt 224 Filter 224# sip any Filter 224# dip any Filter 224# proto any Filter 224# action deny Filter 224# name deny unwanted traffic >> Filter 224# ena >> Filter 224# adv >> Filter 224 Advanced# log enable (Select the default filter) (From any source IP addresses) (To any destination IP addresses) (For any protocols) (Deny matching traffic) (Provide a descriptive name for the filter) (Enable the default filter) (Select the advanced menu) (Log matching traffic to syslog) Default filters are recommended (but not required) when configuring filters for IP traffic control 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. Chapter 7: Filtering 212777-A, February 2002 n 173 Web OS 10.0 Application Guide VLAN-based Filtering Filters are applied per switch, per port, or per VLAN. VLAN-based filtering allows a single Web switch to provide differentiated services for multiple customers, groups, or departments. For example, you can define separate filters for Customers A and B on the same Web 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 7-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 7 is configured to deny ingress traffic from VLAN 70. VLAN 20 r2 lte Unique Filters per VLAN (up to 2048) Fi Filter 3 VLAN 30 Internet Web Switch STOP Fi lte r7 VLAN 70 Figure 7-4 VLAN-based Filtering 174 n Chapter 7: Filtering 212777-A, February 2002 Web OS 10.0 Application Guide 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 destination IP addresses if originating from any HTTP source port: >> >> >> >> >> >> >> >> >> >> # /cfg/slb/filt 2 Filter 2# sip any Filter 2# dip 205.177.15.0 Filter 2# dmask 255.255.255.0 Filter 2# proto tcp Filter 2# sport http Filter 2# dport any Filter 2# action allow Filter 2# vlan 20 Filter 2# ena (Select the menu for Filter 2) (From any source IP address) (To base local network dest. address) (For entire subnet range) (For TCP protocol traffic) (From any source HTTP port) (To any destination port) (Allow matching traffic to pass) (Assign VLAN 20 to Filter 2) (Enable the filter) 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: >> >> >> >> >> >> >> >> >> # /cfg/slb/filt 3 Filter 3# sip any Filter 3# dip 205.177.15.0 Filter 3# dmask 255.255.255.0 Filter 3# proto tcp Filter 3# sport telnet Filter 3# dport any Filter 3# action allow Filter 3# name allow clients to telnet >> Filter 3# vlan 30 >> Filter 3# ena (Select the menu for Filter 3) (From any source IP address) (To base local network dest. address) (For entire subnet range) (For TCP protocol traffic) (From a Telnet port) (To any destination port) (Allow matching traffic to pass) (Provide a descriptive name for the filter) (Assign VLAN 30 to Filter 3) (Enable the filter) Chapter 7: Filtering 212777-A, February 2002 n 175 Web OS 10.0 Application Guide 3. Configure Filter 7 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. >> >> >> >> >> >> >> >> >> >> # /cfg/slb/filt 7 Filter 7# sip any Filter 7# dip 205.177.15.0 Filter 7# dmask 255.255.255.0 Filter 7# proto tcp Filter 7# sport http Filter 7# dport any Filter 7# action deny Filter 7# vlan 70 Filter 7# ena (Select the menu for Filter 7) (From any source IP address) (To base local network dest. address) (For entire subnet range) (For TCP protocol traffic) (From a Telnet port) (To any destination port) (Allow matching traffic to pass) (Assign VLAN 70 to Filter 7) (Enable the filter) 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, filters 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. Filter Logs To provide enhanced troubleshooting and session inspection capability, packet source and destination 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. 176 n Chapter 7: Filtering 212777-A, February 2002 Web OS 10.0 Application Guide 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: >> >> >> >> >> # /cfg/slb/filt 15 Filter 15# sip any Filter 15# dip any Filter 15# action allow Filter 15# name allow matching traffic >> >> >> >> >> >> >> >> Filter 15# proto icmp Filter 15# ena Filter 15# adv/log enable Filter 15 Advanced# /cfg/slb/port 7 SLB port 7# add 15 SLB port 7# filt ena SLB port 7# apply SLB port 7# save (Select filter 15) (From any source IP address) (To any destination IP address) (Allows matching traffic to pass) (Provide a descriptive name for the filter) (For the ICMP protocol) (Enable the filter) (Log matching traffic to syslog) (Select a switch port to filter) (Add the filter to the switch port) (Enable filtering on the switch port) (Apply the configuration changes) (Save the configuration changes) When applied to one or more switch ports, this simple 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: slb: filter 15 fired on port 7, 206.118.93.110 -> 20.10.1.10 Chapter 7: Filtering 212777-A, February 2002 n 177 Web OS 10.0 Application Guide 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 destination IP (dip) address defines the base IP address in the desired range. The source mask (smask) or destination mask (dmask) is the mask that is applied to produce the range. For example, to determine if a client request’s destination IP address should be redirected to the cache servers attached to a particular switch, the destination IP address is masked (bit-wise AND) with the dmask and then compared to the destination IP address. As another example, the switch could be configured with two filters so that each would handle traffic filtering for one half of the Internet. To do this, you could define the following parameters: Table 7-3 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 Cache-Enabled versus Cache-Disabled Filters To improve efficiency, by default, the Web switch performs filter processing only 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 fashion as the initial frame. These filters create a session entry in the Web switch and are known as cache-enabled. 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 cache-disabled. All filters are cache-enabled by default. To change the status of a filter, use the following commands: >> # /cfg/slb/filt /adv >> Filter 1 Advanced # cache ena|dis (Select the advanced filter menu) (Enable or disable filter caching) 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. 178 n Chapter 7: Filtering 212777-A, February 2002 Web OS 10.0 Application Guide TCP Rate Limiting Web OS 10.0 allows you to prevent a client or a group of clients from claiming all the TCP resources on the servers. This is done by monitoring the rate of incoming TCP connection requests to a virtual IP address and limiting the client requests with a known set of IP addresses. TCP rate limiting is similar to bandwidth management. In both features, you configure filters to limit the TCP connection requests; but in bandwidth management the limiting factor is portbased, and in TCP rate limit it is user-based. The TCP rate limit is defined as the maximum number of TCP connection requests within a configured time window. The switch monitors the number of new TCP connections and when it exceeds the configured limit, any new TCP connection request is blocked. When this occurs, the client is said to be held down. The client is held down for a specified duration of time, after which new TCP connection requests from the client are allowed to pass through again. Figure 7-5 on page 180 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 connections per second. When the rate of new TCP connections from clients 1, 2, 3, and 4 reach a pre-determined threshold, any new connection request from the client is blocked for a pre-determined amount of time. If the client’s IP address and the configured filter do not match, then the default filter is applied. Chapter 7: Filtering 212777-A, February 2002 n 179 Web OS 10.0 Application Guide In Figure 7-5, the default filter 224 configured for Any is applied for all other connection requests. Clients Client 1 limit: 10 conn/sec Client 2 limit: 20 conn/sec Client 3 limit: 30 conn/sec Client 4 limit: 10 conn/sec Real servers 1 2 Web Switch Internet 3 4 Filter 10: 10 conn/sec Filter 20: 20 conn/sec Filter 30: 30 conn/sec Filter 224: Allow Any Figure 7-5 Configuring Clients with Different Rates Configuring TCP Rate Limiting Filters TCP rate limiting can be configured for all filter types (allow, redir, SIP, and DIP) and parameters. You can specify the source IP address and mask options in the filter configuration menu to monitor a client or a group of clients. The destination IP address and mask options are used to monitor connections to a virtual IP address or a group of virtual IP addresses. Basic TCP Rate Limiting Filter The following example shows how to configure TCP rate limiting for Filter 10 in Figure 7-5. 1. Enable TCP rate limiting for the filter. >> # /cfg/slb/filt 10/adv/tcp >> TCP Advanced menu # tcplim ena 2. (Enable TCP rate limiting) Configure maximum number of TCP connections. >> TCP Advanced menu # maxcon 3 (Set the max. number of connections) The maxcon value is specified in units of 10. The value of 3 indicates a total of 30 TCP connections. 180 n Chapter 7: Filtering 212777-A, February 2002 Web OS 10.0 Application Guide 3. Set the timewin parameter and calculate the total time window in seconds. >> # /cfg/slb/adv/timewin 3 (Set the time window) The total time window is a multiple of fastage (for information on fastage, see the Configuration chapter in the Web OS 10.0 Command Reference). The total time window is calculated with the following equation: Total Time window = timewin x fastage If the default value for fastage is 1 second, then the configured total time window is 3 seconds. NOTE – From Step 2 and 3, the TCP 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 connections per second). For a small site, 30 TCP connections per second provides a good indication if your site is being attacked. The default is 100 TCP connections per second. For larger sites, TCP rate limit greater than 2550 connection per second indicates the possibility that your switch is under attack. 4. Set the holddur parameter and calculate the hold down time in minutes. >> # /cfg/slb/adv/holddur 2 (Set the hold duration) The hold down time is a multiple of slowage (for information on slowage, see the Configuration chapter in the Web OS 10.0 Command Reference). The hold down time is calculated with the following equation: Hold down time = holddur x slowage If slowage is set to the default value of 0 (2 minutes), then the configured value for hold down time is Hold down time = 2 x 2 = 4 minutes If a client exceeds the TCP rate limit, then the client is not allowed to make any new TCP connections for 4 minutes. The following two configuration examples illustrate how to use TCP rate limiting to limit user access based on source IP address and virtual IP address. Chapter 7: Filtering 212777-A, February 2002 n 181 Web OS 10.0 Application Guide TCP 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 150 TCP connections per second. Once a user exceeds that limit, they are not allowed any new TCP connections for 10 minutes. Configure the following on the switch: >> >> >> >> >> >> >> >> >> # /cfg/slb/filt 100/ena Filter 100 # sip 30.30.30.0 Filter 100 # smask 255.255.255.0 Filter 100 # adv/tcp TCP advanced# tcplim en TCP advanced# maxconn 15 TCP advanced# /cfg/slb/adv Layer 4 Advanced # timewin 1 Layer 4 Advanced # holddur 5 (Enable the filter) (Specify the source IP address) (Specify the source IP address mask) (Select the advanced filter menu) (Enable TCP rate limiting) (Specify the maximum connections) (Select the Layer 4 advanced menu) (Set the time window for the session) (Set the hold duration for the session) Fastage and slowage are set at their default values: Fastage = 0 (1 sec) slowage = 0 (2 minutes). Time window = timewin x fastage = 1 x 1 second = 1 second Hold down time = holddur x slowage = 5 x 2 minutes = 10 minutes Max rate = maxcon/time window = 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 connections per second to any single destination. When the rate limit of 150 is met, the hold down time takes effect and the client is not allowed to make any new TCP connections to the same destination for 10 minutes. 182 n Chapter 7: Filtering 212777-A, February 2002 Web OS 10.0 Application Guide TCP Rate Limiting Filter Based on Virtual Server IP Address This example defines a filter that limits clients to 100 TCP connections per second to a specific destination (VIP 10.10.10.100). Once a client exceeds that limit, the client is not allowed to make any new TCP connection request to that destination for 40 minutes. Figure 7-6 shows how to use this feature to limit client access to a specific destination. Clients 1 Real servers Client 1, 2, 3, and 4 are limited to 100 conn/sec to virtual IP address S1 2 Web Switch Internet 3 VIP: 10.10.10.100 Filter 100: 100 conn/sec 4 S2 Figure 7-6 Limiting User Access to Server Configure the following on the switch: >> # /cfg/slb/filt 100/ena (Enable the filter) >> Filter 100 # dip 10.10.10.100/dmask 255.255.255.0 (Specify the virtual server IP address) >> Filter 100# adv/tcp (Select the advanced filter menu) >> TCP advanced# tcplim en (Enable TCP rate limiting) >> TCP advanced# maxconn 20 (Specify the maximum connections) >> TCP advanced# /cfg/slb/adv (Select the Layer 4 advanced menu) >> Layer 4 Advanced # timewin 1 (Set the time window for the session) >> Layer 4 Advanced # holddur 5 (Set the hold duration for the session) Fastage and slowage are set to 2 seconds and 8 minutes as follows: /cfg/slb/adv/fastage 1 /cfg/slb/adv/slowage 2 (Fastage is set to 2 seconds) (Slowage is set to 8 minutes) time window = timewin x fastage = 1 x 2 seconds = 2 seconds hold down time = holddur x slowage = 5 x 8 minutes = 40 minutes max rate = maxcon/time window = 200 connections/2 seconds = 100 connections/second Chapter 7: Filtering 212777-A, February 2002 n 183 Web OS 10.0 Application Guide All clients are limited to 100 new TCP connections/second to the server. If a client exceeds this rate, then the client is not allowed to make any new TCP connections to the server for 40 minutes. NOTE – All SLB sessions on the switch are affected when you make changes to the fastage or slowage parameters. Tunable Hash for Filter Redirection Web OS 10.0 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: >> >> >> >> >> >> >> >> # /cfg/slb/filt 10/ena Filter 10 # action redir Filter 10 # proto tcp Filter 10 # group 1 Filter 10 # rport 3128 Filter 10 # vlan any Filter 10 # adv TCP advanced menu # thash sip (Enable the filter) (Specify the redir action) (Specify the protocol) (Specify the group of real servers) (Specify the redirection port) (Specify the VLAN) (Select the advanced filter menu) (Select source IP address for hashing) Hashing on the 24-bit source IP address ensures that client requests access the same cache. 2. Set the metric for the real server group to minmisses or hash. The source IP address is passed to the real server group for either of the two metrics. >> # /cfg/slb/group 1 >> Real server group 1 # metric minmiss (Select the group of real servers) (Set the metric to minmiss or hash) 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. 184 n Chapter 7: Filtering 212777-A, February 2002 Web OS 10.0 Application Guide Filter-based Security This section provides an example of configuring filters for providing the best security. It is generally recommended that you configure filters to deny all traffic except for those services that you specifically wish to allow. Consider the following sample network: Alteon Web Switch Internet Client Switch Router Local Clients Web Server Mail Server 205.177.15.2 205.177.15.3 DNS 205.177.15.4 Figure 7-7 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. For best security, it is generally recommended that you configure filters to deny all traffic except for those services that you specifically wish to allow. In this example, the administrator wishes to install basic security filters to allow only the following traffic: n External HTTP access to the local Web server n External SMTP (mail) access to the local mail server n Local clients browsing the World Wide Web n Local clients using Telnet to access sites outside the intranet n 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, filtering does not replace the necessity for a well-constructed network firewall. Chapter 7: Filtering 212777-A, February 2002 n 185 Web OS 10.0 Application Guide 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 7-1 on page 171 and Table 7-2 on page 171 for a list of other well-known protocols and applications. 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: Table 7-4 Web Cache Example: Real Server IP Addresses 2. 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 Create a default filter that will deny and log unwanted traffic. The default filter is defined as Filter 224 in order to give it the lowest order of precedence: >> >> >> >> >> >> # /cfg/slb/filt 224 Filter 224# sip any Filter 224# dip any Filter 224# proto any Filter 224# action deny Filter 224# name deny unwanted traffic >> Filter 224# ena >> Filter 224# adv/log enable (Select the default filter) (From any source IP addresses) (To any destination IP addresses) (For any protocols) (Deny matching traffic) (Provide a descriptive name for the filter) (Enable the default filter) (Log matching traffic to syslog) NOTE – Because the proto parameter is not tcp or udp, the source port (sport) and destination port (dport) values are ignored and may be excluded from the filter configuration. 186 n Chapter 7: Filtering 212777-A, February 2002 Web OS 10.0 Application Guide 3. Create a filter that will allow external HTTP requests to reach the Web server. The filter must recognize and allow TCP traffic with the Web server’s destination IP address and HTTP destination port: >> >> >> >> >> >> >> >> >> Filter Filter Filter Filter Filter Filter Filter Filter Filter 224# ../filt 1 1# sip any 1# dip 205.177.15.2 1# dmask 255.255.255.255 1# proto tcp 1# sport any 1# dport http 1# action allow 1# name allow matching traffic >> Filter 1# ena 4. (Select the menu for filter 1) (From any source IP address) (To Web server dest. IP address) (Set mask for exact dest. address) (For TCP protocol traffic) (From any source port) (To an HTTP destination port) (Allow matching traffic to pass) (Provide a descriptive name for the filter) (Enable the filter) 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 Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter 1# 2# 2# 2# 2# 2# 2# 2# 2# 2# 3# 3# 3# 3# 3# 3# 3# 3# ../filt 2 sip any dip 205.177.15.3 dmask 255.255.255.255 proto tcp sport any dport smtp action allow ena ../filt 3 sip 205.177.15.3 smask 255.255.255.255 dip any proto tcp sport smtp dport any action allow ena (Select the menu for filter 2) (From any source IP address) (To mail server dest. IP address) (Set mask for exact dest. address) (For TCP protocol traffic) (From any source port) (To a SMTP destination port) (Allow matching traffic to pass) (Enable the filter) (Select the menu for filter 3) (From mail server source IP address) (Set mask for exact source address) (To any destination IP address) (For TCP protocol traffic) (From a SMTP port) (To any destination port) (Allow matching traffic to pass) (Enable the filter) Chapter 7: Filtering 212777-A, February 2002 n 187 Web OS 10.0 Application Guide 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: ../filt 4 (Select the menu for Filter 4) sip any (From any source IP address) dip 205.177.15.0 (To base local network dest. address) dmask 255.255.255.0 (For entire subnet range) proto tcp (For TCP protocol traffic) sport http (From any source HTTP port) dport any (To any destination port) action allow (Allow matching traffic to pass) name allow clients Web browse (Provide a descriptive name for the filter) >> Filter 4# ena (Enable the filter) >> >> >> >> >> >> >> >> >> 6. Filter Filter Filter Filter Filter Filter Filter Filter Filter 3# 4# 4# 4# 4# 4# 4# 4# 4# 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. Filter Filter Filter Filter Filter Filter Filter Filter Filter 4# 5# 5# 5# 5# 5# 5# 5# 5# ../filt 5 sip any dip 205.177.15.0 dmask 255.255.255.0 proto tcp sport telnet dport any action allow ena (Select the menu for Filter 5) (From any source IP address) (To base local network dest. address) (For entire subnet range) (For TCP protocol traffic) (From a Telnet port) (To any destination port) (Allow matching traffic to pass) (Enable the filter) 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). 188 n Chapter 7: Filtering 212777-A, February 2002 Web OS 10.0 Application Guide For UDP: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter 5# 6# 6# 6# 6# 6# 6# 6# 6# 6# 7# 7# 7# 7# 7# 7# 7# 7# ../filt 6 sip any dip 205.177.15.4 dmask 255.255.255.255 proto udp sport any dport domain action allow ena ../filt 7 sip 205.177.15.4 smask 255.255.255.255 dip any proto udp sport domain dport any action allow ena (Select the menu for Filter 6) (From any source IP address) (To local DNS Server) (Set mask for exact dest. address) (For UDP protocol traffic) (From any source port) (To any DNS destination port) (Allow matching traffic to pass) (Enable the filter) (Select the menu for Filter 7) (From local DNS Server) (Set mask for exact source address) (To any destination IP address) (For UDP protocol traffic) (From a DNS source port) (To any destination port) (Allow matching traffic to pass) (Enable the filter) Similarly, for TCP: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter 7# 8# 8# 8# 8# 8# 8# 8# 8# 8# 9# 9# 9# 9# 9# 9# 9# 9# ../filt 8 sip any dip 205.177.15.4 dmask 255.255.255.255 proto tcp sport any dport domain action allow ena ../filt 9 sip 205.177.15.4 smask 255.255.255.255 dip any proto tcp sport domain dport any action allow ena (Select the menu for Filter 8) (From any source IP address) (To local DNS Server) (Set mask for exact dest. address) (For TCP protocol traffic) (From any source port) (To any DNS destination port) (Allow matching traffic to pass) (Enable the filter) (Select the menu for Filter 9) (From local DNS Server) (Set mask for exact source address) (To any destination IP address) (For TCP protocol traffic) (From a DNS source port) (To any destination port) (Allow matching traffic to pass) (Enable the filter) Chapter 7: Filtering 212777-A, February 2002 n 189 Web OS 10.0 Application Guide 8. Assign the filters to the switch port that connects to the Internet. >> >> >> >> Filter 9# ../port 5 SLB Port 5# add 1-9 SLB Port 5# add 224 SLB Port 5# filt enable (Select the SLB port 5 to the Internet) (Add filters 1-9 to port 5) (Add the default filter to port 5) (Enable filtering for port 5) Web OS allows you to add and remove a contiguous block of filters with a single command. 9. Apply and verify the configuration. >> SLB Port 5# apply >> SLB Port 5# cur (Make your changes active) (View current settings) Examine the resulting information. If any settings are incorrect, make appropriate changes. 10. Save your new configuration changes. >> SLB Port 5# save (Save for restore after reboot) 11. Check the server load balancing information. >> SLB Port 5# /info/slb/dump (View 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. NOTE – Changes to filters on a given port do not take effect until the port’s session information 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 Web OS 10.0 Command Reference). 190 n Chapter 7: Filtering 212777-A, February 2002 Web OS 10.0 Application Guide Network Address Translation Network Address Translation (NAT) is an Internet standard that enables an Alteon Web switch to use one set of IP addresses for internal traffic and a second set of addresses for external traffic. Alteon Web switches use filters to implement NAT. NAT serves two main purposes: n Provides a type of firewall by hiding internal IP addresses and increases network security. n 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 advertised IP addresses and back again. NAT can be configured in one of the following two ways: n 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) n 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) Alteon Web switches use filters to implement NAT. Static NAT The static NAT (non-proxy) example requires two filters: one for the external client-side switch port, and one for the internal, server-side switch port. The client-side filter translates incoming requests for the publicly advertised server IP address to the server’s internal private network address. The filter for the server-side switch port reverses the process, translating the server’s private address information to a valid public address. Chapter 7: Filtering 212777-A, February 2002 n 191 Web OS 10.0 Application Guide In this example, clients on the Internet require access to servers on the private network: Outbound filter: NAT source info to public address Public IP Address: 205.178.13.x External Clients Router 1 Server: 10.10.10.1 (Private network) 2 Internet Inbound filter: NAT destination to private address Figure 7-8 Static Network Address Translation Configuring Static NAT >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 192 n # /cfg/slb/filt 10 Filter 10# action nat Filter 10# nat source Filter 10# sip 10.10.10.0 Filter 10# smask 255.255.255.0 Filter 10# dip 205.178.13.0 Filter 10# dmask 255.255.255.0 Filter 10# ena Filter 10# adv/proxy disable Filter 10 Advanced# /cfg/slb/filt 11 Filter 11# action nat Filter 11# nat dest Filter 11# sip 10.10.10.0 Filter 11# smask 255.255.255.0 Filter 11# dip 205.178.13.0 Filter 11# dmask 255.255.255.0 Filter 11# ena Filter 11# adv/proxy disable Filter 11 Advanced# /cfg/slb/port 1 SLB port 1# add 10 SLB port 1# filt enable SLB port 1# ../port 2 SLB port 2# add 11 SLB port 2# filt enable SLB port 2# apply SLB port 2# save (Select the menu for outbound filter) (Perform NAT on matching traffic) (Translate source information) (From the clients private IP address) (For the entire private subnet range) (To the public network address) (For the same subnet range) (Enable the filter) (Override any proxy IP settings) (Select the menu for inbound filter) (Use the same settings as outbound) (Reverse the translation direction) (Use the same settings as outbound) (Use the same settings as outbound) (Use the same settings as outbound) (Use the same settings as outbound) (Enable the filter) (Override any proxy IP settings) (Select server-side port) (Add the outbound filter) (Enable filtering on port 1) (Select the client-side port) (Add the inbound filter) (Enable filtering on port 2) (Apply configuration changes) (Save configuration changes) Chapter 7: Filtering 212777-A, February 2002 Web OS 10.0 Application Guide Note the following important points about this configuration: n Within each filter, the smask and dmask values are identical. n 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. n Filters for static (non-proxy) NAT should take precedence over dynamic NAT filters (following 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: Outbound filter: NAT source info to public address Public IP Address: 205.178.17.12 1 Hub Internal Clients 10.10.10.x (Private network) Internet Router Inbound proxy on public address Figure 7-9 Dynamic Network Address Translation 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. Chapter 7: Filtering 212777-A, February 2002 n 193 Web OS 10.0 Application Guide Configuring Dynamic NAT >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> # /cfg/slb/filt 14 Filter 14# invert ena Filter 14# dip 10.10.10.0 Filter 14# dmask 255.255.255.0 Filter 14# sip any Filter 14# action nat Filter 14# nat source Filter 14# ena Filter 14# adv/proxy enable Filter 14 Advanced# /cfg/slb/port 1 SLB port 1# add 14 SLB port 1# pip 205.178.17.12 SLB port 1# filt enable SLB port 1# proxy ena SLB port 1# apply SLB port 1# save (Select the menu for client filter) (Invert the filter logic) (If the destination is not private) (For the entire private subnet range) (From any source IP address) (Perform NAT on matching traffic) (Translate source information) (Enable the filter) (Allow PIP proxy translation) (Select SLB port 1) (Add the filter to port 1) (Set public IP address proxy) (Enable filtering on port 1) (Enable proxies on this port) (Apply configuration changes) (Save configuration changes) NOTE – The invert option in this example filter makes this specific configuration easier but is not a requirement for dynamic NAT. NOTE – Dynamic NAT solutions apply only to TCP/UDP traffic. Also, filters for dynamic NAT should be given a higher numbers than any static NAT filters (see “Static NAT” on page 191). 194 n Chapter 7: Filtering 212777-A, February 2002 Web OS 10.0 Application Guide FTP Client NAT Alteon Web switches provide NAT services to many clients with private IP addresses. In Web 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 channel, 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 command to a remote FTP server, the switch will look into the data part of the frame and modify the port command as follows: n The real server (client) IP address will be replaced by a public proxy IP address. If VMA is enabled, a pool (1-8) of proxy IP addresses is used instead of a single one. n The real server (client) port will be replaced with a proxy port. Outbound filter: NAT source info to public address (Pool of proxy IP addresses instead of a single proxy IP address) Public IP Address: 205.178.17.12 1 Hub Real servers 10.10.10.x (Private network) Internet Router Inbound proxy on public address Figure 7-10 Active FTP for Dynamic NAT Chapter 7: Filtering 212777-A, February 2002 n 195 Web OS 10.0 Application Guide 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. # /cfg/slb/filt 14 Filter 14# invert ena Filter 14# dip 10.10.10.0 Filter 14# dmask 255.255.255.0 Filter 14# sip any Filter 14# action nat Filter 14# nat source Filter 14# ena Filter 14# adv/proxy enable Filter 14 Advanced# /cfg/slb/port 1 SLB port 1# add 14 SLB port 1# pip 205.178.17.12 SLB port 1# filt enable SLB port 1# proxy ena SLB port 1# apply SLB port 1# save (Select the menu for client filter) (Invert the filter logic) (If the destination is not private) (For the entire private subnet range) (From any source IP address) (Perform NAT on matching traffic) (Translate source information) (Enable the filter) (Allow PIP proxy translation) (Select SLB port 1) (Add the filter to port 1) (Set public IP address proxy) (Enable filtering on port 1) (Enable proxies on this port) (Apply configuration changes) (Save configuration changes) Enable active FTP NAT using the following command: >> # /cfg/slb/filt /adv/ftpa ena 4. 196 n Apply and save the switch configuration. Chapter 7: Filtering 212777-A, February 2002 Web OS 10.0 Application Guide Matching TCP Flags Web OS supports packet filtering based on any of the following TCP flags. Table 7-5 TCP Flags Flag Description URG Urgent ACK Acknowledgement PSH Push RST Reset SYN Synchronize FIN Finish Any filter may be set to match against more than one TCP flag at the 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 cacheenabled and cache-disabled filters to the same switch port. For more information, see “CacheEnabled versus Cache-Disabled Filters” on page 178. 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: Web Switch 1 Internet Router SMTP Mail Server 3 2 Inside/ Trusted LAN Web Servers: 203.122.186.* Figure 7-11 TCP ACK Matching Network Chapter 7: Filtering 212777-A, February 2002 n 197 Web OS 10.0 Application Guide In this network, the Web servers inside the LAN must be able to transfer mail to any SMTPbased mail server out on the Internet. At the same time, you want to prevent access to the LAN from the Internet, except for HTTP. SMTP traffic uses well-known TCP Port 25. The Web servers will 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. A filter that allows the Web servers to pass SMTP requests to the Internet. >> >> >> >> >> >> >> >> >> 198 n # /cfg/slb/filt 10 Filter 10# sip 203.122.186.0 Filter 10# smask 255.255.255.0 Filter 10# sport any Filter 10# proto tcp Filter 10# dip any Filter 10# dport smtp Filter 10# action allow Filter 10# ena (Select a filter for trusted SMTP requests) (From the Web servers’ source IP address) (For the entire subnet range) (From any source port) (For TCP traffic) (To any destination IP address) (To well-known destination SMTP port) (Allow matching traffic to pass) (Enable the filter) Chapter 7: Filtering 212777-A, February 2002 Web OS 10.0 Application Guide 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 (ACK) of a TCP session. >> >> >> >> >> >> >> >> >> >> >> 3. 10# ../filt 15 15# sip any 15# sport smtp 15# proto tcp 15# dip 203.122.186.0 15# dmask 255.255.255.0 15# dport any 15# action allow 15# ena 15# adv/tcp 15 Advanced# ack ena (Select a filter for Internet SMTP ACKs) (From any source IP address) (From well-known source SMTP port) (For TCP traffic) (To the Web servers’ IP address) (To the entire subnet range) (To any destination port) (Allow matching traffic to pass) (Enable the filter) (Select the advanced TCP menu) (Match acknowledgments only) A filter that allows trusted HTTP traffic from the Internet to pass through the switch to the Web servers. >> >> >> >> >> >> >> >> >> 4. Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter 15 Advanced# /cfg/slb/filt 16(Select a filter for incoming HTTP traffic) 16# sip any (From any source IP address) 16# sport http (From well-known source HTTP port) 16# proto tcp (For TCP traffic) 16# dip 203.122.186.0 (To the Web servers’ IP address) 16# dmask 255.255.255.0 (To the entire subnet range) 15# dport http (To well-known destination HTTP port) 16# action allow (Allow matching traffic to pass) 16# ena (Enable the filter) A filter that allows HTTP responses from the Web servers to pass through the switch to the Internet. >> >> >> >> >> >> >> >> >> Filter Filter Filter Filter Filter Filter Filter Filter Filter 16# 17# 17# 17# 17# 17# 17# 17# 17# ../filt 17 sip 203.122.186.0 smask 255.255.255.0 sport http proto tcp dip any dport http action allow ena (Select a filter for outgoing HTTP traffic) (From the Web servers’ source IP address) (From the entire subnet range) (From well-known source HTTP port) (For TCP traffic) (To any destination IP address) (To well-known destination HTTP port) (Allow matching traffic to pass) (Enable the filter) Chapter 7: Filtering 212777-A, February 2002 n 199 Web OS 10.0 Application Guide 5. A default filter is required to deny all other traffic. 17# ../filt 224 (Select a default filter) 224# sip any (From any source IP address) 224# dip any (To any destination IP address) 224# action deny (Block matching traffic) 224# name deny matching traffic (Provide a descriptive name for the filter) >> Filter 224# ena (Enable the filter) >> >> >> >> >> 6. Apply the filters to the appropriate switch ports. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 200 n Filter Filter Filter Filter Filter Filter 224# SLB port 1# SLB port 1# SLB port 1# SLB port 1# SLB port 1# SLB port 2# SLB port 2# SLB port 2# SLB port 2# SLB port 2# SLB port 3# SLB port 3# SLB port 3# SLB port 3# SLB port 3# SLB port 3# ../port 1 add 15 add 16 add 224 filt ena ../port 2 add 10 add 17 add 224 filt ena ../port 3 add 10 add 17 add 224 filt ena apply save (Select the Internet-side port) (Add the SMTP ACK filter to the port) (Add the incoming HTTPS filter) (Add the default filter to the port) (Enable filtering on the port) (Select the first Web server port) (Add the outgoing SMTP filter to the port) (Add the outgoing HTTP filter to the port) (Add the default filter to the port) (Enable filtering on the port) (Select the other Web server port) (Add the outgoing SMTP filter to the port) (Add the outgoing HTTP filter to the port) (Add the default filter to the port) (Enable filtering on the port) (Apply the configuration changes) (Save the configuration changes) Chapter 7: Filtering 212777-A, February 2002 Web OS 10.0 Application Guide 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 7-6. Although ICMP packets can be filtered using the proto icmp option, by default, the Web 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. Web OS software supports filtering on the following ICMP message types: Table 7-6 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 Chapter 7: Filtering 212777-A, February 2002 n 201 Web OS 10.0 Application Guide The command to enable or disable ICMP message type filtering is entered from the Advanced Filtering menu as follows: >> # /cfg/slb/filt /adv >> Filter 1 Advanced# icmp 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. 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 “Cache-Enabled versus Cache-Disabled Filters” on page 178. 202 n Chapter 7: Filtering 212777-A, February 2002 CHAPTER 8 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 freeing valuable network bandwidth. The following topics are discussed in this chapter: n “Overview” on page 204. Application redirection helps reduce the traffic congestion during peak loads by accessing locally cached information. This section also discusses how performance is improved by balancing cached Web requests across multiple servers. n “Web Cache Configuration Example” on page 206. 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 Web cache servers. n “RTSP Web Cache Redirection” on page 211. 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. n “IP Proxy Addresses for NAT” on page 213. This section discusses the benefits of transparent proxies when used with application redirection. n “Excluding Noncacheable Sites” on page 215. This section describes how to filter out applications that keep real-time session information from being redirected to cache servers. NOTE – To access Application Redirection functionality, the optional Layer 4 software must be enabled on the Web switch (see “Filtering and Layer 4” in Chapter 8 of the Web OS Command Reference). 203 212777-A, February 2002 Web OS 10.0 Application Guide 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 Application redirection filters are properly configured for the Web OS-powered switch, outbound client requests for Internet data are intercepted and redirected to a group of application or Web cache servers on your network. The servers duplicate and store inbound Internet data that has been requested by your clients. If the servers recognize a client’s outbound request as one that can be filled with cached information, the servers supply the information rather than send the request across the Internet. In addition to increasing the efficiency of your network, accessing locally cached information can be much faster than requesting the same information across the Internet. Web Cache Redirection Environment Consider a network where client HTTP requests begin to regularly overload the Internet router. Client Switch Router Internet Client Switch Clients Congestion Targets Router Figure 8-1 Traditional Network Without Web Cache Redirection 204 n Chapter 8: Application Redirection 212777-A, February 2002 Web OS 10.0 Application Guide The network needs a solution that addresses the following key concerns: n The solution must be readily scalable n The administrator should not need to reconfigure all the clients’ browsers to use proxy servers. HTTP requests are redirected Client Switch A HTTP Requests B C Clients Cache farm proxies client requests Internet Client Switch Router Figure 8-2 Network with Web Cache Redirection Adding an Alteon Web switch with optional Layer 4 software addresses these issues: n Web cache servers can be added or removed dynamically without interrupting services. n Performance is improved by balancing the cached Web request load across multiple servers. More servers can be added at any time to increase processing power. n The proxy is transparent to the client. n 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 128 for details. Chapter 8: Application Redirection 212777-A, February 2002 n 205 Web OS 10.0 Application Guide Web Cache Configuration Example The following is required prior to configuration: n You must connect to the Web switch Command Line Interface (CLI) as the administrator. n Optional Layer 4 software must be enabled. NOTE – For details about the procedures above, and about any of the menu commands described in this example, see the Web OS Command Reference. In this example, an Alteon Web switch is placed between the clients and the border gateway to the Internet. The Web switch will be configured to intercept all Internet bound HTTP requests (on default TCP port 80), and redirect them to the Web cache servers. The Web switch will distribute HTTP requests equally to the Web cache servers based on the destination IP address of the requests. Also, filters are not limited to the few protocols and TCP or UDP applications shown in this example. See Table 6-3 on page 128 and Table 7-2 on page 171 for a list of other well-known protocols and services. 1. Assign an IP address to each of the Web cache servers. Similar to server load balancing, the Web 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 Web switch that will perform the Web cache redirection. In addition, the path from the Web switch to the real servers must not contain a router. The router would stop HTTP requests from reaching the Web cache servers and, instead, directing 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 213). For this example, the three Web cache real servers have the following IP addresses on the same IP subnet: Table 8-1 Web Cache Example: Real Server IP Addresses 206 n Web Cache Server IP address Server A 200.200.200.2 Server B 200.200.200.3 Server C 200.200.200.4 Chapter 8: Application Redirection 212777-A, February 2002 Web OS 10.0 Application Guide 2. Install transparent Web cache software on all three Web cache servers. 3. Define an IP interface on the Web switch. Since, by default, the Web switch only remaps destination MAC addresses, it must have an IP interface on the same subnet as the three Web cache servers. To configure an IP interface for this example, enter this command from the CLI: >> # /cfg/ip/if 1 >> IP Interface 1# addr 200.200.200.100 >> IP Interface 1# ena (Select IP interface 1) (Assign IP address for the interface) (Enable IP interface 1) NOTE – The IP interface and the real servers must be in the same subnet. This example assumes that all ports and IP interfaces use default VLAN 1, requiring no special VLAN configuration for the ports or IP interface. 4. Define each real server on the switch. For each Web cache real server, you must assign a real server number, specify its actual IP address, and enable the real server. For example: >> >> >> >> >> >> >> >> >> 5. ip# /cfg/slb/real 1 Real server 1# rip 200.200.200.2 Real server 1# ena Real server 1# ../real 2 Real server 2# rip 200.200.200.3 Real server 2# ena Real server 2# ../real 3 Real server 3# rip 200.200.200.4 Real server 3# ena (Server A is real server 1) (Assign Server A IP address) (Enable real server 1) (Server B is real server 2) (Assign Server B IP address) (Enable real server 2) (Server C is real server 3) (Assign Server C IP address) (Enable real server 3) Define a real server group. This places the three Web cache real servers into one service group: >> >> >> >> Real Real Real Real server server server server 3# ../group 1 group 1# add 1 group 1# add 2 group 1# add 3 (Select real server group 1) (Add real server 1 to group 1) (Add real server 2 to group 1) (Add real server 3 to group 1) Chapter 8: Application Redirection 212777-A, February 2002 n 207 Web OS 10.0 Application Guide 6. Set the real server group metric to minmisses. This setting helps minimize Web cache misses in the event real servers fail or are taken out of service: >> Real server group 1# metric minmisses 7. (Metric for minimum cache misses.) Verify that server processing is disabled on the ports supporting application redirection. NOTE – Do not use the “server” setting on a port with Application Redirection enabled. Server processing is used only with SLB. To disable server processing on the port, use the commands on the /cfg/slb/port menu, as described in Chapter 8 of the Web 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 redirect it to the proper port on the real server group: >> >> >> >> >> >> >> >> >> >> SLB port 6# /cfg/slb/filt 2 Filter 2# sip any Filter 2# dip any Filter 2# proto tcp Filter 2# sport any Filter 2# dport http Filter 2# action redir Filter 2# rport http Filter 2# group 1 Filter 2# ena (Select the menu for Filter 2) (From any source IP addresses) (To any destination IP addresses) (For TCP protocol traffic) (From any source port) (To an HTTP destination port) (Set the action for redirection) (Set the redirection port) (Select real server group 1) (Enable the filter) The rport 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 Web switch (see Step 3 on page 207), 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 Web switch, make sure to use the service port required by the specific software package. See “IP Proxy Addresses for NAT” on page 213 for more about IP proxy addresses. 208 n Chapter 8: Application Redirection 212777-A, February 2002 Web OS 10.0 Application Guide 9. Create a default filter. In this case, the default filter will allow all noncached traffic to proceed normally: >> >> >> >> >> >> Filter Filter Filter Filter Filter Filter 2# ../filt 224 224# sip any 224# dip any 224# proto any 224# action allow 224# ena (Select the default filter) (From any source IP addresses) (To any destination IP addresses) (For any protocols) (Set the action to allow traffic) (Enable the default filter) NOTE – When the proto parameter is not tcp or udp, then sport and dport are ignored. 10. Assign the 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: >> >> >> >> >> >> >> >> Filter 224# SLB Port 5# SLB Port 5# SLB Port 5# SLB Port 5# SLB Port 6# SLB Port 6# SLB Port 6# ../port 5 add 2 add 224 filt enable ../port 6 add 2 add 224 filt enable (Select the SLB port 5) (Add filter 1 to port 5) (Add the default filter to port 5) (Enable filtering for port 5) (Select the SLB port 6) (Add filter 1 to port 6) (Add the default filter to port 6) (Enable filtering for port 6) 11. Enable, apply, and verify the configuration. >> >> >> >> SLB Port Layer 4# Layer 4# Layer 4# 6# /cfg/slb on apply cur (Select Server Load Balancing Menu) (Activate Layer 4 software services) (Make your changes active) (View current settings) NOTE – SLB must be turned on in order for application redirection to work properly. The on command is valid only if the optional Layer 4 software is enabled on your Web switch (see “Activating Optional Software” in the Web OS Command Reference). 12. Examine the resulting information from the cur command. If any settings are incorrect, make appropriate changes. Chapter 8: Application Redirection 212777-A, February 2002 n 209 Web OS 10.0 Application Guide 13. Save your new configuration changes. >> Layer 4# save (Save for restore after reboot) 14. Check the SLB information. >> Layer 4# /info/slb (View SLB information) Check that all SLB parameters are working according to expectation. If necessary, make any appropriate configuration changes and then check the information again. 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 Web OS Command Reference). Delayed Binding for Web Cache Redirection To configure delayed binding on your Web switch for WCR only, use the following command: >> # /cfg/slb/filt /adv/urlp ena For more conceptual information on delayed binding, see “Delayed Binding” on page 146. 210 n Chapter 8: Application Redirection 212777-A, February 2002 Web OS 10.0 Application Guide RTSP Web Cache Redirection Web OS 10.0 supports Web Cache Redirection (WCR) for Real Time Streaming Protocol (RTSP). RTSP WCR is similar to HTTP WCR 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 WCR 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. You can also configure certain URL content to be non-cacheable. The requests for noncacheable URLs will bypass the cache server and be sent across the Internet to the origin server. The client packets are relayed to the server by using Layer 4 server load balancing. For a detailed information on load balancing two prominent commercial RTSP servers—Real Player and QuickTime—see “Real Time Streaming Protocol SLB” on page 155. RTSP Web Cache Redirection Example To configure RTSP for web cache redirection, follow this procedure: 1. Define RTSP WCR cache servers for RTSP WCR load balancing. >> # /cfg/slb/real 1 >> Real server 1# rip 1.1.1.1 >> # /cfg/slb/real 2 >> Real server 2# rip 1.1.1.2 2. (Enter an IP address, for example: 1.1.1.1 for RTSP cache Server 1) (Enter an IP address, for example: 1.1.1.2 for RTSP cache Server 2) Define RTSP cache server groups for RTSP WCR load balancing. >> # /cfg/slb/group 1 >> Group 1# add 1 >> Group 1# add 2 (Add RTSP cache server 1 to group 1) (Add RTSP cache server 2 to group 1) Chapter 8: Application Redirection 212777-A, February 2002 n 211 Web OS 10.0 Application Guide 3. Configure an RTSP redirection filter to cache data and balance the load among the cache servers. >> >> >> >> >> >> >> >> 4. # /cfg/slb/filt 2048 Filter 2048# sip any Filter 2048# dip any Filter 2048# ena Filter 2048# action allow (Select a default allow filter 2048) (From any source IP addresses) (To any destination IP addresses) (Enable a default allow filter) (Set the action to allow normal traffic) Turn on filtering on the port and add filters to the port to support basic WCR. >> >> >> >> 6. (Select the menu for filter 1) (Set the action for redirection) (Enter TCP protocol) (Enter service port for RTSP) (Enter redirection port for RTSP) (Select RTSP cache server group 1) (Select advanced menu for filter 1) (Disable proxy) Configure a default allow filter to facilitate traffic. >> >> >> >> >> 5. # /cfg/slb/filt 1 Filter 1# action redir Filter 1# proto tcp Filter 1# dport rtsp Filter 1# rport rtsp Filter 1# group 1 Filter 1# adv Filter 1# Advanced# proxy disable # /cfg/slb/port 1 SLB Port 1# add 1 SLB Port 1# add 2 SLB Port 1# filt ena (Select the menu for port 1) (Add RTSP filter 1 to port 1) (Add RTSP filter 2 to port 1) (Enable filtering on port 1) Apply and save the configuration. >> SLB Port 1# apply >> SLB Port 1# save 212 n Chapter 8: Application Redirection 212777-A, February 2002 Web OS 10.0 Application Guide 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. n With proxies IP addresses configured on redirected ports, the Web switch can redirect client requests to servers located on any subnet, anywhere. n The Web switch can perform transparent substitution for all source and destination addresses, including destination port remapping. This provides support for comprehensive, fully-transparent proxies. These proxies are transparent to the user. No additional client configuration is needed. The following procedure can be used for configuring proxy IP addresses: 1. Add proxy IP addresses to the redirection ports. Each of the ports using redirection filters require proxy IP addresses to be configured. Each proxy IP address must be unique on your network. These are configured as follows: >> >> >> >> >> >> 2. SLB SLB SLB SLB SLB SLB port port port port port port 3# 5# 5# 5# 6# 6# /cfg/slb/port 5 pip 200.200.200.68 proxy ena ../port 6 pip 200.200.200.69 proxy ena (Select network port 5) (Set proxy IP address for port 5) (Enable proxy port 5) (Select network port 6) (Set proxy IP address for port 6) (Enable proxy port 6) If VMA is enabled, add proxy IP addresses for all other switch ports (except port 9). Virtual Matrix Architecture (VMA) is normally enabled on the Web switch. In addition to enhanced resource management, this feature eliminates many of the restrictions found in earlier versions of the Web OS. It does require, however, that when any switch port is configured with an IP proxy address, all ports must be configured with IP proxy addresses. Otherwise, if VMA is disabled, only the client port with filters need proxy IP addresses and this step can be skipped. Chapter 8: Application Redirection 212777-A, February 2002 n 213 Web OS 10.0 Application Guide The following commands can be used to configure the additional unique proxy IP addresses: >> >> >> >> >> >> >> >> >> >> >> >> SLB SLB SLB SLB SLB SLB SLB SLB SLB SLB SLB SLB port port port port port port port port port port port port 6# 1# 1# 2# 2# 3# 3# 4# 4# 7# 7# 8# ../port 1 pip 200.200.200.70 ../port 2 pip 200.200.200.71 ../port 3 pip 200.200.200.72 ../port 4 pip 200.200.200.73 ../port 7 pip 200.200.200.74 ../port 8 pip 200.200.200.75 (Select network port 1) (Set proxy IP address for port 1) (Select network port 2) (Set proxy IP address for port 2) (Select network port 3) (Set proxy IP address for port 3) (Select network port 4) (Set proxy IP address for port 4) (Select network port 7) (Set proxy IP address for port 7) (Select network port 8) (Set proxy IP address for port 8) NOTE – Port 9 does not require a proxy IP address with VMA enabled. See the Web OS Command Reference for more information (/cfg/slb/adv/matrix). 3. 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: >> >> >> >> >> # /cfg/slb/filt 2 Filter 2# rport 8080 Filter 2# real 1/proxy enable Real server 1# ../real 2/proxy enable Real server 2# ../real 3/proxy enable (Select the menu for Filter 2) (Set proxy redirection port) (Enable proxy on real servers) (Enable proxy on real servers) (Enable proxy on real servers) NOTE – This configuration is not limited to HTTP Web service. Other TCP/IP services can be configured in a similar fashion. For example, if this had been a DNS redirect, rport would be sent to well-known port 53 (or the service port you want to remap to). For a list of other wellknown services and ports, see the Web OS Command Reference. 4. Apply and save your changes. 5. Check server statistics to verify that traffic has been redirected based on filtering criteria: >> # /info/slb/group /filter 214 n Chapter 8: Application Redirection 212777-A, February 2002 Web OS 10.0 Application Guide Excluding Noncacheable Sites Some Web 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 which allows this specific traffic to pass normally through the Web switch. This filter must have a higher precedence (a lower filter number) than the application redirection filter. For example, if you wished 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 Filter 1# dip 200.10.10.0 Filter 1# dmask 255.255.255.0 Filter 1# sip any Filter 1# proto tcp Filter 1# dport http Filter 1# sport any Filter 1# action allow Filter 1# ena Filter 1# ../port 5 SLB port 5# add 1 SLB port 5# ../port 6 SLB port 6# add 1 SLB port 6# apply SLB port 6# save (Select the menu for filter 1) (To the site’s destination IP address) (For entire subnet range) (From any source IP address) (For TCP traffic) (To an HTTP destination port) (From any source port) (Allow matching traffic to pass) (Enable the filter) (Select SLB port 5) (Add the filter to port 5) (Select SLB port 6) (Add the filter to port 6) (Apply configuration changes) (Save configuration changes) Chapter 8: Application Redirection 212777-A, February 2002 n 215 Web OS 10.0 Application Guide 216 n Chapter 8: Application Redirection 212777-A, February 2002 CHAPTER 9 Virtual Matrix Architecture Virtual Matrix Architecture (VMA) is a hybrid architecture that takes full advantage of the distributed processing capability in Alteon Web switches. With VMA, the switch makes optimal use of system resources by distributing the workload to multiple processors, thereby improving switch performance and increasing session capacity. VMA also removes the topology constraints introduced by using Direct Access Mode (DAM). The number of concurrent sessions per switch, with VMA enabled, is given below: n AD4 and A184: 512K n AD3 and A180E: 336K n AD2: 256K For better switch performance and higher session capacities, it is recommended that you enable VMA, especially when using Bandwidth Management and Content Intelligent Switching for multiple frames processing (up to 4500 bytes). Proxy IP Addresses and VMA By default, VMA is enabled on the Web switch (/cfg/slb/adv/matrix). If you are upgrading to Web OS from a previous release, however, VMA will be initially disabled if a proxy IP address is configured for any port on the switch. VMA requires that if any port is configured with a proxy IP address, then all ports (except port 9) must be configured with a unique proxy IP address prior to enabling VMA. With VMA, the concept of a per-port session table doesn’t apply; instead, there is a global session table. To identify which processor should process responses to proxied requests, a unique proxy IP address must be configured on each port (except port 9). The action of the unused proxy IP addresses can be disabled using /cfg/slb/port x/proxy dis. 217 212777-A, February 2002 Web OS 10.0 Application Guide Frames ingressing a port that has been configured with a proxy IP address and the proxy option enabled (/cfg/slb/port x/proxy ena) can be processed using a proxy IP address by any switch port. The client source address is substituted with the proxy IP address of the port processing the request. Frames ingressing switch ports that have been configured with a proxy IP address, but do not have the proxy option enabled, is processed by other ports that have been configured with a proxy IP address; but the client source address will not be replaced with a proxy IP address before it is forwarded to a server. >> # /cfg/slb/port >> # /cfg/slb/port >> # /cfg/slb/port >> # /cfg/slb/port >> # /cfg/slb/port >> # /cfg/slb/port and so on.... 1/pip 1/pip 2/pip 3/pip 4/pip 5/pip 10.10.10.10 10.10.10.11/proxy 10.10.10.11/proxy 10.10.10.12/proxy 10.10.10.13/proxy 10.10.10.14/proxy ena dis dis dis dis (Proxy IP for NAT, etc.) (Turns on address proxying) (Turns off address proxying) NOTE – VMA must be enabled if you are setting up Firewall Load Balancing (FWLB) with clean-side switches performing server load balancing (SLB) or URL-based SLB and Direct Access Mode (DAM) is enabled. 218 n Chapter 9: Virtual Matrix Architecture 212777-A, February 2002 CHAPTER 10 Health Checking Content intelligent Web switches allow Web masters to customize server health checks to verify content accessibility in large Web sites. As the amount of 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 Web OS health-checking topics are described in this chapter. n “Real Server Health Checks” on page 221. This section explains the switch’s default health check, which checks the status of each service on each real server every two seconds. n “DSR Health Checks” on page 222. 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. n “Link Health Checks” on page 223. This section describes how to perform Layer 1 health checking on an Intrusion Detection Server (IDS). n “TCP Health Checks” on page 224. TCP health checks help verify the TCP applications that cannot be scripted. n “ICMP Health Checks” on page 224. This section explains how ICMP health checks are used for UDP services. n “Script-Based Health Checks” on page 225. 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. n Application-based health checks: o “HTTP Health Checks” on page 231. This section provides examples of HTTP-based health checks using hostnames. o “UDP-Based DNS Health Checks” on page 233. This section explains the functionality of the DNS Health Checks using UDP packets. 219 212777-A, February 2002 Web OS 10.0 Application Guide o “FTP Server Health Checks” on page 234. This section describes how the File Transfer Protocol (FTP) server is used to perform health checks and explains how to configure the switch to perform FTP health checks. o “POP3 Server Health Checks” on page 235. This section explains how to use Post Office Protocol Version 3 (POP3) mail server to perform health checks between a client system and a mail server and how to configure the switch for POP3 health checks. o “SMTP Server Health Checks” on page 236. 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. o “IMAP Server Health Checks” on page 237. 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. o “NNTP Server Health Checks” on page 238. This section explains how to use Network News Transfer Protocol (NNTP) server to perform health checks between a client system and a mail server and how to configure the switch for NNTP health checks o “RADIUS Server Health Checks” on page 239. This section explains how the RADIUS protocol is used to authenticate dial-up users to Remote Access Servers (RASs). o “HTTPS/SSL Server Health Checks” on page 240. This section explains how the switch queries the health of the SSL servers by sending an SSL client “Hello” packet and then verifies the contents of the server’s “Hello” response. o “WAP Gateway Health Checks” on page 240. This section discusses how the Web switch provides a connectionless WSP health check for WAP gateways. o “LDAP Health Checks” on page 243. 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. 220 n n “ARP Health Checks” on page 245. This section describes how to perform health checks on Intrusion Detection Servers (IDS) that do not have full TCP/IP stack support. n “Failure Types” on page 246. This section explains the service failed and server failed states. Chapter 10: Health Checking 212777-A, February 2002 Web OS 10.0 Application Guide Real Server Health Checks Alteon Web 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 Web switch can remove the individual service from the loadbalancing algorithm without affecting other services provided by that server. By default, the Web switch checks the status of each service on each real server every two seconds. Sometimes, the real server may be too busy processing connections to respond to health checks. If a service does not respond to four consecutive health checks, the switch, by default, declares the service unavailable. You can modify both the health check interval and the number of retries. >> # /cfg/slb/real >> Real server# inter 4 >> Real server# retry 6 (Select the real server) (Check real server every 4 seconds) (If 6 consecutive health checks fail, declare real server down) NOTE – Health checks are performed sequentially when used in conjunction with a virtual server configured with multiple services and groups. As a result, the actual health-check interval could vary significantly from the value set for it using the inter parameter. Chapter 10: Health Checking 212777-A, February 2002 n 221 Web OS 10.0 Application Guide DSR Health Checks Direct Server Return (DSR) health checks are used to verify the existence of a server-provided service where the server replies directly back to the client without responding through the virtual server IP address. In this configuration, the server will be configured with a real server IP address and virtual server IP address. The virtual server IP address is configured to be the same address as the user’s virtual server IP address. When DSR health checks are selected, the specified health check is sent originating from one of the switch’s configured IP interfaces, and is destined to the virtual server IP address with the MAC address that was acquired from the real server IP address’s Address Resolution Protocol (ARP) entry. Web OS 10.0 allows you to perform health checks for DSR configurations. For more information, see “Using Direct Server Return” on page 142. 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. >> # /cfg/slb/group 1 2. (Select the Real Server Group 1 menu) Enable DSR VIP health checks for a real server group. For more information on DSR, see “Using Direct Server Return” on page 142. >> Real server group 1# viphlth enable|disable 3. Apply and save your configuration. >> DSR VIP Health Check# apply 222 n Chapter 10: Health Checking 212777-A, February 2002 Web OS 10.0 Application Guide Link Health Checks Link health check is performed at the Layer 1 (physical) level. The server is considered to be up when the link (connection) is present and the server is considered to be down when the link is absent. These checks are used on servers that do not respond to any other health checks. Intrusion Detection Servers (IDSs) fall into this category. 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 indicates the IDS is alive. To perform this health check, a link option has been added to the real server group health command. The real server number is used to determine which port the server is connected to. For example, real server 1 is assumed to be connected to port 1. The valid IDS real server numbers are from 1 to 9 when health check is in use. Configuring the Switch for 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. >> # /cfg/slb/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 3. Apply and save your configuration. >> # Real server group 1# apply >> # Real server group 1# save Chapter 10: Health Checking 212777-A, February 2002 n 223 Web OS 10.0 Application Guide 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-configurable 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. >> # /cfg/slb/group 1 2. Set the health check type to ICMP for group 1. >> # Real server group 1# health icmp 3. Apply and save your configuration. >> # Real server group 1# apply 224 n Chapter 10: Health Checking 212777-A, February 2002 Web OS 10.0 Application Guide Script-Based Health Checks The “send/expect” script-based health checks dynamically verify application and content availability using scripts. These scripts execute a sequence of tests to verify application and content availability. Configuring the Switch for 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. ASCII-based scripts can be used to verify application and content availability. NOTE – Only TCP services can be health checked, since UDP protocols are usually not ASCII based. The benefits of using script-based health checks are listed below: n Ability to send multiple commands n Check for any return string n Test availability of different applications n Test availability of multiple domains or Web sites Web OS supports the following capacity for a single switch: n 1024 bytes per script n 16 scripts per switch n approximately 10 to 15 health check statements (HTTP get and expect strings) A simple command line interface controls the addition and deletion of ASCII 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 port, send an ASCII request to the server, expect an ASCII string, and close a connection. The string configured with an expect 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 step and fails the health check. A script can contain any number of these commands, up to the allowable number of characters that a script supports. NOTE – Health check scripts can only be set up via the command line interface, but once entered, can be assigned as the health-check method using SNMP or the Browser-Based Interface (BBI). Chapter 10: Health Checking 212777-A, February 2002 n 225 Web OS 10.0 Application Guide Script Format The general format for health-check scripts is shown below: open application_port (e.g., 80 for HTTP, 23 for Telnet, etc.) send request1 expect response1 send request2 expect response2 send request3 expect response3 close NOTE – If you are doing HTTP 1.1 pipelining, you need to individually open and close each response in the script. n Each script should start with the command open port . The next line can be either a send or expect. n The first word is the method. This is usually get; however, HTTP supports several other commands, including put and head. The second word indicates the content desired, or request-URI, and the third word represents the version of the protocol used by the client. If you supplied HTTP/1.1 for the protocol version, you would also have to add in the following line: Host: www.hostname.com 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+. n In order to tell the Web 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. n 226 n 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 \\). Chapter 10: Health Checking 212777-A, February 2002 Web OS 10.0 Application Guide Scripting Guidelines n Use generic result codes that are standard and defined by the RFC, as applicable. This helps ensure that if the customer changes server software, the servers won’t start failing unexpectedly. n Search only for the smallest and most concise piece of information possible. Each script cannot exceed 1K in size, so use the space wisely. n Avoid tasks that may take a long time to perform or the health check will fail. For example, avoid tasks that exceed the interval for load balancing. Script Configuration Examples Script Example 1: A Basic 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. /cfg/slb/group x/health script1/content none /cfg/slb/adv/script1 open 80 send "GET /index.html HTTP/1.1\\r\\nHOST:www.hostname.com\\r\\n\\r\\n" expect "HTTP/1.1 200" close open 80 send "GET /script.cgi HTTP/1.1\\r\\nHOST:www.hostname.com\\r\\n\\r\\n" expect "HTTP/1.1 200" close open 443 … close NOTE – When you are using the command line interface to enter the send string as an argument to the send command, you must type two “\”s before an “n” or “r.” If you are instead prompted for the line, that is, the text string is entered after hitting , then only one “\” is needed before the “n” or “r.” Chapter 10: Health Checking 212777-A, February 2002 n 227 Web OS 10.0 Application Guide Script Example 2: GSLB URL Health Check In earlier Web OS releases, each remote Global Server Load Balancing site’s virtual server IP address was required to be a real server of the local switch. Each switch sends a health check request to the other switch’s virtual servers that are configured on the local switch. The health check is successful if there is at least one real server on the remote switch that is up. If all real servers on the remote switch are down, the remote real server (a virtual server of a remote switch) will respond with an HTTP Redirect message to the health check. Using the scriptable health check feature, you can set up health check statements to check all the substrings involved in all the real servers. Site 1 with Virtual Server 1 and the following real servers: n Real Server 1 and Real Server 2: “images” n Real Server 3 and Real Server 4: “html” n Real Server 5 and Real Server 6: “cgi” and “bin” n Real Server 7 (which is Virtual Server 2): “any” Site 2 with Virtual Server 2 and the following real servers: n Real Server 1 and Real Server 2: “images” n Real Server 3 and Real Server 4: “html” n Real Server 5 and Real Server 6: “cgi” and “bin” n Real Server 7 (which is Virtual Server 2): “any” A sample script is shown below: /cfg/slb/group x/health script2/content none /cfg/slb/adv/script2 open 80 send "GET /images/default.asp HTTP/1.1\\r\\nHOST: 192.192.1.2\\r\\n\\r\\n" expect "HTTP/1.1 200" close open 80 send "GET /install/default.html HTTP/1.1\\r\\nHOST: 192.192.1.2\\r\\n\\r\\n" expect "HTTP/1.1 200" close open 80 send "GET /script.cgi HTTP/1.1\\r\\nHOST: www.myurl.com \\r\\n\\r\\n" expect "HTTP/1.1 200" close 228 n Chapter 10: Health Checking 212777-A, February 2002 Web OS 10.0 Application Guide Script-based health checking is intelligent in that it will only send the appropriate requests to the relevant servers. In the example above, the first GET statement will only be sent to Real Server 1 and Real Server 2. Going through the health-check statements serially will ensure that all content is available by at least one real server on the remote site. Configure the remote real server IP address (the virtual server IP address of the remote site) to accept “any” URL requests. The purpose of the first GET is to check if Real Server 1 or Real Server 2 is up—that is, to check if the remote site has at least one server for “images” content. Either Real Server 1 or Real Server 2 will respond to the first GET health check. If all the real server IP addresses are down, Real Server 7 (the virtual server IP address of the remote site) will respond with an HTTP Redirect (respond code 302) to the health check. Thus, the health check will fail as the expected response code is 200, ensuring that the HTTP Redirect messages will not cause a loop. 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 command: >> # /info/slb/real 1 1: 205.178.13.225, 00:00:00:00:00:00, vlan 1, port 0, health 4, FAILED real ports: script 2, DOWN, current send GET / HTTP/1.0\r\n\r\n expect HTTP/1.0 200 The server is not responding to the get with the expect string. When the script succeeds in determining the health of a real server, the following information is displayed: >> # /info/slb/real 1 1: 205.178.13.223, 00:00:5e:00:01:24, vlan 1, port 2, health 4, up real ports: script 2, up, current Chapter 10: Health Checking 212777-A, February 2002 n 229 Web OS 10.0 Application Guide Application-Specific Health Checks Application-specific health checks include the following applications: n “HTTP Health Checks” on page 231 n “UDP-Based DNS Health Checks” on page 233 n “FTP Server Health Checks” on page 234 n “POP3 Server Health Checks” on page 235 n “SMTP Server Health Checks” on page 236 n “IMAP Server Health Checks” on page 237 n “NNTP Server Health Checks” on page 238 n “RADIUS Server Health Checks” on page 239 n “HTTPS/SSL Server Health Checks” on page 240 n “WAP Gateway Health Checks” on page 240 o “WSP Content Health Checks” on page 241 o “WTLS Health Checks” on page 242 n 230 n “LDAP Health Checks” on page 243 Chapter 10: Health Checking 212777-A, February 2002 Web OS 10.0 Application Guide HTTP Health Checks HTTP-based health checks can include the hostname for HOST: headers. The HOST: header and health check URL are constructed from the following components: Item 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 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 Health check is performed using: GET /page/gen/?_template=alteon HTTP/1.1 Host: raleighduram.cityguru.com Example 3: hname = (none) dname = jansus content = index.html Chapter 10: Health Checking 212777-A, February 2002 n 231 Web OS 10.0 Application Guide Health check is performed using: GET /index.html HTTP/1.1 Host: jansus Example 4: hname = (none) dname = (none) content = index.html Health check is performed using: GET /index.html HTTP/1.0 (since no HTTP HOST: header is required) Example 5: hname = (none) dname = (none) content = //everest/index.html Health check is performed using: GET /index.html HTTP/1.1 Host: everest 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. >> # /cfg/slb/group 1 2. (Select a real server group) Set the health check type to FTP for the real server group. >> # /cfg/slb/group 1/health http 3. Configure the health check content. >> # /cfg/slb/group 1/content 4. Apply and save your configuration. >> # Real server group 1# apply >> # Real server group 1# save 232 n Chapter 10: Health Checking 212777-A, February 2002 Web OS 10.0 Application Guide UDP-Based DNS Health Checks Web OS 10.0 supports UDP-based health checks along with TCP health checks, and performs load-balancing based on TCP and UDP protocols. DNS servers can be based on both TCP and UDP protocols. With UDP-based DNS health checks enabled, you can send TCP-based queries to one real server group and UDP-based queries to another real server group. The health check may be performed by sending a UDP-based query (for example, for www.nortelnetworks.com), and watching for the server’s reply. The domain name to be queried 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. 1. Select the real server group. >> # /cfg/slb/group 1 2. Set the health check type to UDP for the real server group. >> # Real server group 1# health udpdns 3. Set the content to domain name. >> # Real server group 1# content |// |none 4. Apply and save your configuration. >> # Real server group 1# apply >> # Real server group 1# save 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 server’s reply. The reply, even though negative (for example, “Server not found” since the query is from a dummy host), serves the purpose of a health check, nonetheless. Chapter 10: Health Checking 212777-A, February 2002 n 233 Web OS 10.0 Application Guide 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 control connection requests. The client sends a control message which indicates the port number on which the client is prepared to accept an incoming data connection request. When a transfer is being set up, it is always initiated by the client. However, either the client or the server may be the sender of data. Along with transferring user requested 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 anonymous user. Configuring the Switch for FTP Health Checks Create any file name from an FTP server under FTP server directory, for example, .txt, .exe, .bin and so forth. To configure the switch for FTP health checks: 1. Select the real server group. >> # /cfg/slb/group 1 2. (Select a real server group) Set the health check type to FTP for the real server group. >> # /cfg/slb/group 1/health ftp 3. Configure the health check content. >> # /cfg/slb/group 1/content 4. Apply and save your configuration. >> # Real server group 1# apply >> # Real server group 1# save 234 n Chapter 10: Health Checking 212777-A, February 2002 Web OS 10.0 Application Guide POP3 Server Health Checks The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host. The POP3 protocol is used to allow a workstation to retrieve mail that the server is holding for it. This protocol is documented in RFC 1939. When the user on a client host wants to enter a message into the transport system, it establishes an SMTP connection to its relay host and sends all mail to it. Initially, the server host starts the POP3 service by listening on TCP port 110. When a client host wants to make use of the service, it establishes a TCP connection with the server host. Configuring the Switch for POP3 Health Checks To support health checking on the UNIX POP3 server, the network administrator must configure 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: 1. Select the real server group. >> # /cfg/slb/group 1 2. (Select a real server group) Set the health check type to POP3 for the real server group.. >> # /cfg/slb/group 1/health pop3 3. Configure the health check content. >> # /cfg/slb/group 1/content : 4. Apply and save your configuration. >> # Real server group 1# apply >> # Real server group 1# save Chapter 10: Health Checking 212777-A, February 2002 n 235 Web OS 10.0 Application Guide SMTP Server Health Checks Simple Mail Transfer Protocol is a protocol to transfer e-mail messages between servers reliably 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. Configuring the Switch for SMTP Health Checks To support SMTP health checking, the network administrator must configure 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 SMTP health checks: 1. Select the health check menu for the real server group. >> # /cfg/slb/group 1 2. (Select a real server group) Set the health check type to SMTP for the real server group.. >> # /cfg/slb/group 1/health smtp 3. Configure the health check content. >> # /cfg/slb/group 1/content 4. Apply and save your configuration. >> # Real server group 1# apply >> # Real server group 1# save 236 n Chapter 10: Health Checking 212777-A, February 2002 Web OS 10.0 Application Guide IMAP Server Health Checks Internet Message Access Protocol (IMAP) is a mail server protocol used between a client system and a mail server that allows a user to retrieve and manipulate mail messages. IMAP is not used for mail transfers between mail servers. IMAP servers listen to TCP port 143. Configuring the Switch for IMAP Health Check To support IMAP health checking, the network administrator must configure 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 IMAP health checks: 1. Select the health check menu for the real server group. >> # /cfg/slb/group 1 2. (Select a real server group) Set the health check type to IMAP for the real server group.. >> # /cfg/slb/group 1/health imap 3. Configure the health check content. >> # /cfg/slb/group 1/content : 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 specify the client(s) or port(s) the user is allowed to access. 4. Apply and save your configuration. >> # Real server group 1# apply >> # Real server group 1# save Chapter 10: Health Checking 212777-A, February 2002 n 237 Web OS 10.0 Application Guide NNTP Server Health Checks Net News Transfer Protocol (NNTP) is a TCP/IP protocol based upon text strings sent bidirectionally over 7 bit ASCII TCP channels, and listens to port 119. It is used to transfer articles between servers as well as to read and post articles. NNTP specifies a protocol for the distribution, 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: 1. Select the real server group. >> # /cfg/slb/group 1 2. (Select a real server group) Set the health check type to NNTP for the real server group. >> # /cfg/slb/group 1/health nntp 3. Configure the health check content. >> # /cfg/slb/group 1/content Create nntp directory from MS Windows Option Pack4. 4. Apply and save your configuration. >> # Real server group 1# apply >> # Real server group 1# save 238 n Chapter 10: Health Checking 212777-A, February 2002 Web OS 10.0 Application Guide RADIUS Server Health Checks The Remote Authentication Dial-In User Service (RADIUS) protocol is used to authenticate dial-up users to Remote Access Servers (RASs) and the client application they will use during the dial-up connection. n RADIUS Content Health Check Enhancements o Include the switch IP as the Network-attached storage (NAS) IP parameter in the RADIUS content health check o RADIUS health check using the configured real server port (rport) o Variable-length RADIUS secret password. Supports less than 16 octets and up to 32 octets n 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. n 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 specify the client(s) or port(s) the user is allowed to access. NOTE – Network-attached storage (NAS) is hard disk storage that is set up with its own network address rather than being attached to the department computer that is serving applications to a network’s workstation users. By removing storage access and its management from the department server, both application programming and files can be served faster because they are not competing for the same processor resources. The network-attached storage device is attached to a local area network (typically, an Ethernet network) and assigned an IP address. File requests are mapped by the main server to the NAS file server. Configuring the Switch for RADIUS Server Content Health Checks The Alteon Web 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. The RADIUS health check is performed using the configured real server port (rport). To configure RADIUS health checks, use the /cfg/slb/virt <#>/service menu. Chapter 10: Health Checking 212777-A, February 2002 n 239 Web OS 10.0 Application Guide Configuring the Switch for RADIUS Secret and Password RADIUS is stateless and uses UDP as its transport protocol. To support RADIUS health checking, the network administrator must configure two parameters on the switch: n the /cfg/slb/secret value n the content parameter with a username:password value. >> # /cfg/slb/group >> # health radius >> # content : (Select the real server group) (Specify the type of health checking) (Specify the RADIUS username:password value) >> # /cfg/slb/adv/secret (Enter up to 32 alphanumeric characters used to encrypt and decrypt password) HTTPS/SSL Server Health Checks The sslh health check option on the Real Server Group Menu (/cfg/slb/group <#>) allows the switch to query the health of the SSL servers by sending an SSL client “Hello” packet and then verify the contents of the server’s “Hello” response. SSL health check is performed using the real server port configured, that is, the rport. The SSL enhanced health check behavior is summarized below: n The switch sends a SSL “Hello” packet to the SSL server. n If it is up and running, the SSL server responds with the “Server Hello” message. n The switch verifies fields in the response and marks the service “Up” if the fields are OK. During the handshake, the user and server exchange security certificates, negotiate an encryption and compression method, and establish a session ID for each session. WAP Gateway Health Checks Wireless Application protocol (WAP) carries Internet traffic to mobile devices and allows Web services to be delivered to mobile phones and handsets. The translation from HTTP/HTML to WAP/WML (Wireless Markup Language) is implemented by servers known as WAP gateways on the land-based part of the network. WAP devices can communicate in two ways: 240 n n Wireless Session Protocol (WSP) content health checks, the unencrypted mode of sending WML traffic (similar to HTTPS). n Wireless Transport Layer Security (WTLS) health checks, an encrypted mode of sending WML traffic (similar to HTTP). Chapter 10: Health Checking 212777-A, February 2002 Web OS 10.0 Application Guide WSP Content Health Checks Wireless Session Protocol content health checks can be configured in two modes: connectionless and connection-oriented. Connectionless WSP runs on UDP/IP protocol, port 9200. Therefore, Alteon Web switches can be used to load balance the gateways in this mode of operation. Web OS 10.0 provides a content-based health check mechanism where customized WSP packets can be sent to the gateways, and the switch can verify the expected response, in a manner similar to scriptable health checks. The content of the WSP/UDP packet that is sent to the gateway can be 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. The user 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. Configuring the Switch for WSP Content Health Checks 1. Select the WAP Health Check Menu. >> # /cfg/slb/adv/waphc 2. Use the sndcnt command to enter the content to be sent to the WSP gateway. >> WAP Health Check# 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 . 3. Enter the content that the switch expects to receive from the WSP gateway. >> WAP Health Check# rcvcnt Current Receive content: Enter new Receive content: 01 04 60 0e 03 94 NOTE – A maximum of 255 bytes of input are allowed on the switch command line. You may remove spaces in between the numbers to save space on the command line. For example, type 010203040506 instead of 01 02 03 04 05 06. Chapter 10: Health Checking 212777-A, February 2002 n 241 Web OS 10.0 Application Guide 4. Enter the WSP port. >> WAP Health Check# wspport 9200 5. Set the offset value. >> WAP Health Check# offset 0 6. Because WAP gateways are UDP-based and operate on a UDP port, configure UDP service in the virtual server menu. >> # /cfg/slb/virt 1 >> Virtual Server 1# service Enter virtual port: 9200 >> Virtual Server 1 9200 Service# group 1 >> Virtual Server 1 9200 Service# udp ena >> Virtual Server 1 9200 Service# apply 7. Enable WSP health checks for group 1. >> # /cfg/slb/group 1 >> Real server group 1# health wsp 8. (Configure virtual service 1) (On the default WSP port) (Set the real server group number) (Enable UDP load balancing) (Apply the configuration) (Select the Real Server Group 1 menu) (Set the health check type) Apply and save the configuration. >> Real server group 1# apply WTLS Health Checks Wireless Transport Layer Security (WTLS) can be configured to use ports 9202 and 9203 in connectionless and connection oriented modes respectively. The WTLS health check feature provides a WTLS Hello based health check for connectionoriented WTLS traffic on port 9203. The web 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. 242 n Chapter 10: Health Checking 212777-A, February 2002 Web OS 10.0 Application Guide Configuring the Switch for WTLS Health Checks 1. Select the group with the WAP gateway. >> Main# /cfg/slb/group 1 2. (Select the Real Server Group 1 menu) Use the sndcnt command to enter the content to be sent to the WSP gateway. >> Real server group 1# health wtls 3. Select a port number other than 9203, if you want to change the port number on which your gateway is listening to WTLS traffic. >> Main# /cfg/slb/adv/wap >> WAP Health Check Menu # wtlsprt 10203 4. Apply and save your configuration. >> WSP Health Check# apply LDAP Health Checks Lightweight Directory Access Protocol (LDAP) health checks enable the switch to determine whether the LDAP server is alive or not. LDAP versions 2 and 3 are described in RFC 1777 and RFC 2251. The LDAP health check process consists of three LDAP messages over one TCP connection: n 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. n 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. n Unbind request: If the server is alive, the switch sends a request to unbind the server. This request does not require a response. It is necessary to send an unbind request as the LDAP server may crash if too many protocol sessions are active. If the server is up, the switch closes the TCP connection after sending the unbind request. If the server is down, the connection is torn down after the bind response, if one arrives. The connection will also be torn down if it crosses the timeout limit, irrespective of the server’s condition. Chapter 10: Health Checking 212777-A, February 2002 n 243 Web OS 10.0 Application Guide Configuring the Switch for LDAP Health Checks Configure the switch to verify if the LDAP server is alive. 1. Select the health check menu for the real server group. >> # /cfg/slb/group 1 2. Set the health check type to LDAP for the real server group. >> # Real server group 1# health ldap 3. Apply and save your configuration. >> # Real server group 1# apply >> # Real server group 1# save Determining the Version of LDAP 1. Select the Advanced Menu. >> # Real server group 1# /cfg/slb/adv 2. Set the version of LDAP. The default version is 2. >> # # Real server group 1# ldap <2 | 3> 3. (Select the desired LDAP version) Apply and save your configuration. >> LDAP Health Check# apply >> LDAP Health Check# save 244 n Chapter 10: Health Checking 212777-A, February 2002 Web OS 10.0 Application Guide 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. >> /cfg/slb/group 1 2. Select the type of health check to use. >> Real server group 1# health arp 3. Enable ARP health checks for group 1. >> Real server group 1# arp enable 4. Apply and save your configuration. >> Real server group 1# apply Chapter 10: Health Checking 212777-A, February 2002 n 245 Web OS 10.0 Application Guide Failure Types Service Failure If a certain number of connection requests for a particular service fail, the session 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 session 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 loadbalancing 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. 246 n Chapter 10: Health Checking 212777-A, February 2002 CHAPTER 11 High Availability Alteon Web switches support high-availability network topologies through an enhanced implementation of the Virtual Router Redundancy Protocol (VRRP). The following topics are discussed in this chapter: n “VRRP Overview” on page 248. This section discusses VRRP operation and Web OS redundancy configurations. n “Failover Methods” on page 253. This section describes the three modes of high availability. n “Web OS Extensions to VRRP” on page 259. This section describes VRRP enhancements implemented in Web OS. n “High Availability Configurations” on page 263. This section discusses a few of the more useful and easily deployed redundant configurations. o “Active-Standby Virtual Server Router Configuration” on page 263 o “Active-Active VIR and VSR Configuration” on page 265 o “Active/Active Server Load Balancing Configuration” on page 267 o “VRRP-Based Hot-Standby Configuration” on page 275 n “Virtual Router Deployment Considerations” on page 277. This section describes issues to consider when deploying virtual routers. n “Stateful Failover of Layer 4 and Layer 7 Persistent Sessions” on page 283. This section describes how to enable stateful failover by mirroring Layer 7 and Layer 4 persistent transactional states on the peer switch. 247 212777-A, February 2002 Web OS 10.0 Application Guide 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 VRRPcapable 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 host’s gateway information does not change, no matter what path is used. A VRRP-based redundancy schema reduces administrative overhead because hosts need not be configured with multiple default gateways. VRRP Components Each physical router running VRRP is known as a VRRP router. Virtual Interface Router Two or more VRRP routers can be configured to form a virtual interface router (VIR). (RFC 2338 calls this entity a virtual router.) The term virtual interface router will be used to distinguish this type of entity from a virtual server router (VSR), as described in “Web OS Extensions to VRRP” on page 259. When the term virtual router is used herein, the concept applies to both virtual interface routers and virtual server routers. Each VRRP router may participate in one or more virtual interface routers. A virtual interface router acts as a default or next hop gateway for hosts on a LAN. Each virtual interface router consists of a user-configured virtual router identifier (VRID) and an IP address. 248 n Chapter 11: High Availability 212777-A, February 2002 Web OS 10.0 Application Guide Virtual Router MAC Address The VRID is used to build the virtual router MAC Address. The five highest-order octets of the virtual router MAC Address are the standard MAC prefix (00-00-5E-00-01) defined in RFC 2338. The VRID is used to form the lowest-order octet. Owners and Renters Only one of the VRRP routers in a virtual interface router may be configured as the IP address owner. This router has the virtual interface router’s IP address as its real interface address. This router responds to packets addressed to the virtual interface router’s IP address for ICMP pings, TCP connections, and so on. There is no requirement for any VRRP router to be the IP address owner. Most VRRP installations choose not to implement an IP address owner. For the purposes of this chapter, VRRP routers that are not the IP address owner are called renters. Master and Backup Virtual Router Within each virtual router, one VRRP router is selected to be the virtual router master. See “Selecting the Master VRRP Router” on page 251 for an explanation of the selection process. NOTE – If the IP address owner is available, it will always become the virtual router 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. 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. Chapter 11: High Availability 212777-A, February 2002 n 249 Web OS 10.0 Application Guide The Alteon Web switches in Figure 11-1 have been configured as VRRP routers. Together, they form a virtual interface router (VIR). Router VRRP Router VRID = 1 Router #1 = Master Active VR IP address = 205.178.13.226 MAC address = 00.00.SE.00.01.01 Priority = 255 IP interface = 205.178.13.226 Web Switch 1 Virtual Interface Router Internet Web Switch 2 Router Host #1 Default Gateway 205.178.13.226 VRRP Router VRID = 1 Router #2 = Backup Standby VR IP address = 205.178.13.226 MAC address = 00.00.SE.00.01.01 Priority = 100 IP interface = 205.178.13.225 Figure 11-1 Example 1: VRRP Router Web switch 1 in Figure 11-1 has its real interface configured with the IP address of the virtual interface router and is, therefore, the IP address owner. It also becomes the virtual router master. Web 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. Therefore, both of the VRRP routers have a MAC address = 00-00-5E-00-01-01. 250 n Chapter 11: High Availability 212777-A, February 2002 Web OS 10.0 Application Guide VRRP Operation The host shown in Figure 11-1 is configured with the virtual interface router’s IP address as its default gateway. The master forwards packets destined to remote subnets and responds to ARP requests. In this example, the master is also the virtual interface router’s IP address owner— therefore it also responds to ICMP ping requests and IP datagrams destined for the virtual interface router's IP address. The backup does not forward any traffic on behalf of the virtual interface router nor does it respond to ARP requests. 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. Selecting the Master VRRP Router Each VRRP router that is not an owner is configured with a priority between 1–254. According to the VRRP standard, an owner has a priority of 255. A bidding process determines which VRRP router is or becomes the master—the VRRP router with the highest priority. Owners have a higher priority than the range permitted for non-owners. If there is an IP address owner, it is always the master for the virtual interface router, as long as it is available. The master periodically sends advertisements to an IP multicast address. As long as the backups receive these advertisements, they remain in the backup state. If a backup does not receive an advertisement for three advertisement intervals, it initiates a bidding process to determine which VRRP router has the highest priority and takes over as master. If, at any time, a backup determines that it has higher priority than the current master does, it can preempt the master and become the master itself, unless configured not to do so. In preemption, the backup assumes the role of master and begins to send its own advertisements. The current master sees that the backup has higher priority and will stop functioning as the master. A backup router can stop receiving advertisements for one of two reasons—the master can be down, or all communications links between the master and the backup can be down. If the master has failed, it is clearly desirable for the backup (or one of the backups, if there is more than one) to become the master. NOTE – If the master is healthy but communication between the master and the backup 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. Chapter 11: High Availability 212777-A, February 2002 n 251 Web OS 10.0 Application Guide Active-Standby Failover The previous text described the use of a group of VRRP routers to form a single virtual interface router. It implements a traditional hot-standby configuration in which the backup router only functions when the active router has failed. VRRP can also be used to implement activestandby configurations. In an active-standby configuration, both switches support active traffic, but are configured so that they do not simultaneously support the same service. In the example shown in Figure 11-2, Web switch 1 is the master for the virtual interface router with VRID = 1, and its backup for the virtual interface router with VRID = 2. Web 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. VRID = 1 Router #1 = Master Active VRID = 2 Router #1 = Backup Standby Router Web Switch 1 Host #1 Default Gateway 205.178.13.226 Internet Web Switch 2 Router VRID = 1 Router #2 = Backup Standby Host #2 Default Gateway 205.178.13.240 VRID = 2 Router #2 = Master Active Figure 11-2 Example 2: VRRP Router Table 11-1 Active Standby Configuration VRID = 1 VRID = 2 Web Switch 1 Router #1 = Master Active VR IP address = 205.178.13.226 MAC address = 00.00.SE.00.01.01 Priority = 255 IP interface = 205.178.13.226 Router #1 = Backup Standby VR IP address = 205.178.13.240 MAC address = 00.00.SE.00.01.02 Priority = 100 IP interface = 205.178.13.239 Web Switch 2 Router #2 = Backup Standby VR IP address = 205.178.13.226 MAC address = 00.00.SE.00.01.01 Priority = 100 IP interface = 205.178.13.225 Router #1 = Master Active VR IP address = 205.178.13.240 MAC address = 00.00.SE.00.01.02 Priority = 255 IP interface = 205.178.13.240 252 n Chapter 11: High Availability 212777-A, February 2002 Web OS 10.0 Application Guide Failover Methods With service availability becoming a major concern on the Internet, service providers are increasingly deploying Internet traffic control devices, such as Web switches, in redundant configurations. Traditionally, these configurations have been hot-standby configurations, where one switch is active and the other is in a standby mode. A non-VRRP hot-standby configuration is shown in the figure below: Intranet Clients Primary Web Switch IP: 200.200.200.100 Active Links Intranet Servers A B Inter-switch Link Client Switches Secondary Web Switch IP: 200.200.200.101 Backup Links NFS Server Figure 11-3 A Non-VRRP, Hot-Standby Configuration While hot-standby configurations increase site availability by removing single points-of-failure, service providers increasingly view them as an inefficient use of network resources because one functional Web switch sits by idly until a failure calls it into action. Service providers now demand that vendors’ equipment support redundant configurations where all devices can process traffic when they are healthy, increasing site throughput and decreasing user response times when no device has failed. Web OS high availability configurations are based on VRRP. The Web OS implementation of VRRP includes proprietary extensions to accommodate Layer 4 though Layer 7 Web switching features. The Web OS implementation of VRRP supports three modes of high availability: n Active-Standby n Active-Active n Hot-Standby The first mode, active-standby, is based on standard VRRP, as defined in RFC 2338. The second and third modes, active-active and hot-standby, are based on proprietary Web OS extensions to VRRP. Each mode is described in detail in the following sections. Chapter 11: High Availability 212777-A, February 2002 n 253 Web OS 10.0 Application Guide Active-Standby Redundancy In an active-standby configuration, shown in Figure 11-4, two Web switches are used. Both switches support active traffic but are configured so that they do not simultaneously support the same service. Each switch is active for its own set of services, such as IP routing interfaces or load-balancing virtual server IP addresses, and acts as a standby for other services on the other switch. If either switch fails, the remaining switch takes over processing for all services. The backup switch may forward Layer 2 and Layer 3 traffic, as appropriate. NOTE – In an active-standby configuration, the same service cannot be active simultaneously on both switches. Router Standby VIP 1 VIP: 205.178.13.226 Active VIP 2 VIP: 205.178.13.240 Standby VIP 3 VIP: 205.178.13.110 Active Internet Active Router Active VIP 1 VIP: 205.178.13.226 Standby VIP 2 VIP: 205.178.13.240 Active VIP 3 VIP: 205.178.13.110 Figure 11-4 Active-Standby Redundancy 254 n Chapter 11: High Availability 212777-A, February 2002 Web OS 10.0 Application Guide Active-Active Redundancy In an active-active configuration, two Web switches provide redundancy for each other, with both active at the same time for the same services. Web OS has extended VRRP to include virtual servers, allowing full active/active redundancy between its Layer 4 switches. In an active-active configuration, shown in Figure 11-5, both switches can process traffic for the same service at the same time; both switches can be active simultaneously for a given IP routing interface or load-balancing virtual server (VIP). Router Active VIP 1 VIP: 205.178.13.226 Active VIP 2 VIP: 205.178.13.240 Active VIP 3 VIP: 205.178.13.110 Active Internet Active Router Active VIP 1 VIP: 205.178.13.226 Active VIP 2 VIP: 205.178.13.240 Active VIP 3 VIP: 205.178.13.110 Figure 11-5 Active-Active Redundancy In the example above, one switch is still the master router. However, traffic going through the backup router (associated with the same virtual router on the switch) that is addressed to the master router will be intercepted and processed by the backup router. Chapter 11: High Availability 212777-A, February 2002 n 255 Web OS 10.0 Application Guide 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. To provide as much flexibility as possible, the old hot-standby approach has been modified to eliminate the problems previously associated with it and is now based on VRRP. 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 traffic as appropriate. There are three components to the VRRP-based, hot-standby model: the virtual router group, additional Layer 4 port states, and configuration synchronization options. The hot-standby model is shown in Figure 11-6. Router Active VIP 1 VIP: 205.178.13.226 Active VIP 2 VIP: 205.178.13.240 Active VIP 3 VIP: 205.178.13.110 Active Internet Hot Standby Router Standby VIP 1 VIP: 205.178.13.226 Standby VIP 2 VIP: 205.178.13.240 Standby VIP 3 VIP: 205.178.13.110 Figure 11-6 Hot-Standby Redundancy 256 n Chapter 11: High Availability 212777-A, February 2002 Web OS 10.0 Application Guide Virtual Router Group The virtual router group ties all of the virtual routers together as a single entity and is central to the hot-standby configuration. All virtual routers on a given switch must all be either master or backup. They cannot failover individually, only as a group. Once hot-standby is globally enabled, the virtual router group must be enabled. The virtual router group aggregates all of the virtual routers as a single entity. If the virtual router group is master on one switch, it means the switch is master; otherwise, the switch is backup. However, 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. VRRP actually contains support for virtual router groups. Each advertisement is not limited to a single virtual router IP address and can include up to 256 addresses. This means that all virtual routers are advertised in the same packet, conserving processing and buffering resources. However, the advertisements are also used to help bridges learn the virtual router MAC address. Since all of the virtual routers can have different virtual router identifiers (VRIDs), you must rotate the MAC source address of the advertisement to ensure that the bridges learn all of the virtual router MAC addresses. Hot-Standby and Inter-Switch Port States The second part of the solution involves introducing two additional Layer 4 port states, hotstandby and inter-switch: n Links that attach to the standby switch must be configured as hot standby using /cfg/slb/port x/hotstan. n Links that are used by VRRP to deliver updates are configured as intersw, or interswitch links (not to be confused with Cisco’s ISL). The command to configure one or more ports as interswitch links is /cfg/slb/port /intersw. NOTE – A port cannot be configured to support both hot-standby and interswitch link. The hot-standby switch listens to the master’s VRRP updates. After an interval period has expired without receiving a update, the backup switch will take over. The forwarding states of hot-standby ports are controlled much like the forwarding states of the old hot-standby approach. Enabling hot-standby on a switch port allows the hot-standby algorithm to control the forwarding state of the port. If a switch is master, the forwarding states of the hot-standby ports are enabled. If a switch is backup, the hot-standby ports are blocked from forwarding or receiving traffic. Chapter 11: High Availability 212777-A, February 2002 n 257 Web OS 10.0 Application Guide When the hotstan option (/cfg/slb/port x/hotstan) is enabled and all hot-standby ports have link, the virtual router group's priority is automatically incremented by 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 affect when all hot-standby ports on a switch have link. The default virtual routers tracking value is 2 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 hotstandby port loses link, the entire switch must become master to eliminate loss of connectivity. The forwarding states of non-hot-standby ports are not controlled via the hot-standby algorithm, allowing the additional ports on the switches to provide added port density. The client ports on both switches should be able to process or forward traffic to the master switch. The inter-switch port state is only a place holder. Its presence forces the user to configure a 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. Synchronizing Configurations The final piece in configuring a high-availability solution includes the addition of synchronization 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. NOTE – When using both VRRP and GSLB, you must change the /cfg/sys/wport (Browser-Based Interface port) value of the target switch (the switch that is being synchronized to) to a port other than port 80 before VRRP synchronization begins. For more information on synchronizing configurations between two switches, see “Synchronizing Configurations” on page 282. 258 n Chapter 11: High Availability 212777-A, February 2002 Web OS 10.0 Application Guide Web OS Extensions to VRRP This section describes the following VRRP enhancements that are implemented in Web OS: n Virtual Server Routers n Sharing/Active-Active Failover n Tracking VRRP Router Priority Virtual Server Routers Web OS supports virtual server routers, which extend the benefits of VRRP to virtual server IP addresses that are used to perform SLB. Virtual server routers operate for virtual server IP addresses in much the same manner as Virtual Interface Routers operate for IP interfaces. A master is negotiated via a bidding process, during which information about each VRRP router’s priority is exchanged. Only the master can process packets that are destined for the virtual server IP address and respond to ARP requests. One difference between virtual server routers and virtual interface routers is that a virtual server router cannot be an IP address owner. All virtual server routers are renters. All virtual routers, whether virtual server routers or virtual interface routers, operate independently of one another; that is, their priority assignments, advertisements, and master negotiations are separate. For example, when you configure a VRRP router’s priority in a virtual server router, you are not affecting that VRRP router’s priority in any virtual interface router or any other virtual server router of which it is a part. However, because of the requirement that MAC addresses be unique on a LAN, VRIDs must be unique among all virtual routers, whether virtual interface routers or virtual server routers. Chapter 11: High Availability 212777-A, February 2002 n 259 Web OS 10.0 Application Guide Sharing/Active-Active Failover Web OS supports sharing of interfaces at both Layer 3 and Layer 4, as shown in Figure 11-7. With sharing, an IP interface or a VIP address can be active simultaneously on multiple switches, enabling active-active operation as shown in Table 11-2. Master-Active VR 1 Backup-Active VR 2 Master-Active VR 3 Router Web Switch 1 Internet Web Switch 2 Router Backup-Active VR 1 Master-Active VR 2 Backup-Active VR 3 Figure 11-7 Active-Active High Availability Table 11-2 Sharing Active-Active Failover Web Switch 1 Master-Active VR 1 VRID 2 VIP: 205.178.13.226 MAC address 00-00-5E-OO-01-02 Backup-Active VR 2 VRID 4 VIP: 205.178.13.240 MAC address 00-00-5E-OO-01-04 Master-Active VR 3 VRID 6 VIP: 205.178.13.110 MAC address 00-00-5E-OO-01-06 Web Switch 2 Backup-Active VR 1 VRID 2 VIP: 205.178.13.226 MAC address 00-00-5E-OO-01-02 Master-Active VR 2 VRID 4 VIP: 205.178.13.240 MAC address 00-00-5E-OO-01-04 Backup-Active VR 3 VRID 6 VIP: 205.178.13.110 MAC address 00-00-5E-OO-01-06 When sharing is used, incoming packets are processed by the switch on which they enter the virtual router. The ingress switch is determined by external factors, such as routing and Spanning Tree configuration. NOTE – Sharing cannot be used in configurations where incoming packets have more than one entry point into the virtual router—for example, where a hub is used to connect the switches. 260 n Chapter 11: High Availability 212777-A, February 2002 Web OS 10.0 Application Guide When sharing is enabled, the master election process still occurs. Although the process does not affect which switch processes packets that must be routed or that are destined for the virtual server IP address, it does determine which switch sends advertisements and responds to ARP requests sent to the virtual router’s IP address. Web OS strongly recommends that sharing, rather than active-standby configurations, be used whenever possible. Sharing offers both better performance and fewer service interruptions in the face of fault conditions than active-standby configurations. Tracking VRRP Router Priority Web 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. Web OS can track the attributes listed in Table 11-3: Table 11-3 VRRP Tracking Parameters Parameter Description Number of virtual routers in master mode on the switch /cfg/vrrp/track/vrs 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. Number of IP interfaces active on the switch /cfg/vrrp/track/ifs 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 router’s priority in both virtual interface routers and virtual server routers. Number of active ports on the same VLAN Helps elect the virtual routers with the most available /cfg/vrrp/track/ports ports as the master. This parameter influences the VRRP router’s priority in both virtual interface routers and virtual server routers. Chapter 11: High Availability 212777-A, February 2002 n 261 Web OS 10.0 Application Guide Table 11-3 VRRP Tracking Parameters Parameter Description Number of physical switch ports that have active Layer 4 processing on the switch /cfg/vrrp/track/l4pts Helps elect the main Layer 4 switch as the master. This parameter influences the VRRP router's priority in both virtual interface routers and virtual server routers. Number of healthy real servers behind the virtual server IP address that is the same as the IP address of the virtual server router on the switch /cfg/vrrp/track/reals Helps elect the switch with the largest server pool as the master, increasing Layer 4 efficiency. This parameter influences the VRRP router's priority in virtual server routers only. In networks where the Hot Standby Router Protocol (HSRP) is used for establishing router failover, the number of Layer 4 client-only ports that receive HSRP advertisements /cfg/vrrp/track/hsrp Helps elect the switch closest to the master HSRP router as the master, optimizing routing efficiency. This parameter influences the VRRP router's priority in both virtual interface routers and virtual server routers. Each tracked parameter has a user-configurable weight associated with it. 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 “Configuring the Switch for Tracking” on page 280 for an example on how to configure the switch for tracking VRRP priority. 262 n Chapter 11: High Availability 212777-A, February 2002 Web OS 10.0 Application Guide High Availability Configurations Alteon Web switches offer flexibility in implementing redundant configurations. This section discusses a few of the more useful and easily deployed configurations: n n n n “Active-Standby Virtual Server Router Configuration” on page 263 “Active-Active VIR and VSR Configuration” on page 265 “Active/Active Server Load Balancing Configuration” on page 267 “VRRP-Based Hot-Standby Configuration” on page 275 Active-Standby Virtual Server Router Configuration Figure 11-8 shows an example configuration where two Alteon Web switches are used as VRRP routers in an active-standby configuration, implementing a virtual server router. Activestandby redundancy should be used in configurations that cannot support sharing, that is, configurations where incoming packets will be seen by more than one switch, such as instances where a hub is used to connect the switches. In this configuration, when both switches are healthy, only the master responds to packets sent to the virtual server IP address. Server 1 RIP 1: 205.178.13.101 RIP 2: 205.178.13.105 Master-Active VRID 2 VIP: 205.178.13.226 MAC address 00-00-5E-00-01-02 Router Web Switch 1 Server 2 RIP 1: 205.178.13.102 RIP 2: 205.178.13.106 Internet Server 3 RIP 1: 205.178.13.103 RIP 2: 205.178.13.107 Web Switch 2 Router Backup-Standby VRID 2 VIP: 205.178.13.226 MAC address 00-00-5E-00-01-02 Server 4 RIP 1: 205.178.13.104 RIP 2: 205.178.13.108 Figure 11-8 Active-Standby High-Availability Configuration Although this example shows only two switches, there is no limit on the number of switches 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. Chapter 11: High Availability 212777-A, February 2002 n 263 Web OS 10.0 Application Guide 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 should use the virtual server IP address described in Step 4. 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 Web switch 1. For the purposes of this example, assume that Web switch 1 in Figure 11-8 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 = 205.178.13.101, RIP = 205.178.13.102, RIP = 205.178.13.103, and RIP = 205.178.13.104. 4. Configure the VRRP parameters on Web switch 1. This configuration includes VRID = 2, VIP = 205.178.13.226 and the priority. Enable tracking and set the parameters appropriately (refer to “Configuring the Switch for Tracking” on page 280). Make sure to disable sharing. 5. Synchronize the SLB and VRRP configurations by synchronizing the configuration from Web switch 1 to Web switch 2. Use the /oper/slb/synch command (see “Synchronizing Configurations” on page 282). 6. Change the real servers in the Web switch 2 configuration to RIP = 205.178.13.105, RIP = 205.178.13.106, RIP =205.178.13.107, and RIP = 205.178.13.108. Adjust Web switch 2’s priority (see “Configuring the Switch for Tracking” on page 280). In this example, with Web switch 1 as the master, if a link between Web switch 1 and a server fails, the server will fail health checks and be taken out of the load-balancing algorithm. If tracking is enabled and is configured to take into account the number of healthy real servers for the Virtual Router's VIP address, Web switch 1’s priority will be reduced. If it is reduced to a value lower than Web switch 2’s priority, then Web switch 2 will assume the role of master. In this case, all active connections serviced by Web switch 1’s virtual server IP address are severed. If the link between Web switch 1 and its Internet router fails, the protocol used to distribute traffic between the routers, for example, Open Shortest Path First (OSPF), will reroute traffic to the other router. Web switch 2 (backup) will act as a Layer 2/3 switch and forward all traffic destined to the virtual server IP address to Web switch 1. If the entire Web switch 1 (master) fails, the protocol used to distribute traffic between the routers, such as OSPF, will reroute traffic to Web switch 2. Web switch 2 (backup) detects that the master has failed because it will stop receiving advertisements. The backup then assumes the master's responsibility of responding to ARP requests and issuing advertisements. 264 n Chapter 11: High Availability 212777-A, February 2002 Web OS 10.0 Application Guide Active-Active VIR and VSR Configuration Figure 11-9 two Alteon Web switches are used as VRRP routers in an active-active configuration implementing a virtual server router. As noted earlier, this is the preferred redundant configuration. Server 1 RIP 1: 205.178.13.101 Master-Active VRID 2 VIP: 205.178.13.226 MAC address 00-00-5E-00-01-02 Server 2 RIP 1: 205.178.13.102 Router Web Switch 1 Internet Web Switch 2 Router Backup-Active VRID 2 VIP: 205.178.13.226 MAC address 00-00-5E-00-01-02 Server 3 RIP 1: 205.178.13.103 Server 4 RIP 1: 205.178.13.104 Figure 11-9 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 configuration 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. 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. Chapter 11: High Availability 212777-A, February 2002 n 265 Web OS 10.0 Application Guide 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 4. 2. Define all filters required for your network configuration. Filters may be configured on one switch and synchronized with the settings on the other switch (see Step 5, below). 3. Configure all required SLB parameters on one of the switches. For the purposes of this example, assume that Web switch 1 (see Figure 11-9 on page 265) is configured in this step. Required Layer 4 parameters include a VIP = 205.178.13.226 and one real server group with two real servers, RIP = 205.178.13.101 and RIP = 205.178.13.102. RIP = 205.178.13.103 should be configured as a backup server to RIP = 205.178.13.101. RIP = 205.178.13.104 should be configured as a backup server to RIP = 205.178.13.102. NOTE – In this configuration, each server’s backup is attached to the other switch. This ensures that operation will continue if all of the servers attached to a switch fail. 4. Configure the VRRP parameters on the switch. Configure VRID = 2, VIP address = 205.178.13.226, and priority. Be sure to enable sharing. 5. Synchronize the SLB and VRRP configurations by pushing the configuration from Web switch 1 to Web switch 2. Use the /oper/slb/sync command. 6. Reverse the roles of the real servers and their backups in Web switch 2’s configuration. Configure RIP = 205.178.13.103 and RIP= 205.178.13.104 as the real servers Configure RIP = 205.178.13.101 and RIP = 205.178.13.102 as their backups, respectively. 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 virtual server router on one switch, that switch will process all incoming connections. If an entire master switch fails, the backup will detect this failure because it will stop receiving advertisements. The backup will assume the 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. 266 n Chapter 11: High Availability 212777-A, February 2002 Web OS 10.0 Application Guide 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 balanced via a different virtual server. You could load balance all of these services on one VIP, but in this example, four distinct virtual servers are used to illustrate the 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 minutes to complete. You can use either the Web OS Browser-Based Interface (BBI) or the Command Line Interface (CLI) for configuration. Task 1: Background Configuration 1. Define the IP interfaces. The switch will need an IP interface for each subnet to which it will be connected so it can communicate with devices attached to it. Each interface will need to be placed in the appropriate VLAN. In our example, Interfaces 1, 2, 3, and 4 will be in VLAN 2 and Interface 5 will be in VLAN 1. NOTE – On Alteon Web switches, you may configure more than one subnet per VLAN. To configure the IP interfaces for this example, enter the following commands from the CLI: >> >> >> >> Main# /cfg/ip/if IP Interface 1 # IP Interface 1 # IP Interface 1 # 1 addr 10.10.10.10 vlan 2 ena (Select IP interface 1) (Assign IP address for the interface) (Assign VLAN for the interface) (Enable IP interface 1) Repeat the commands for each interface listed below: n IF 2 20.10.10.10 n IF 3 30.10.10.10 n IF 4 40.10.10.10 n IF 5 200.1.1.10 Chapter 11: High Availability 212777-A, February 2002 n 267 Web OS 10.0 Application Guide 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 downstream switches, toward the servers). >> Main# /cfg/vlan >> vlan 1 # add >> vlan 1 # ena (Select VLAN 1) (Add a port to the VLAN membership) (Enable VLAN 1) Repeat this command for the second VLAN. 3. n VLAN 1 - IF 5—physical ports connected to upstream switches. n VLAN 2 - IFs 1,2,3,4—physical ports connected to downstream switches. Disable Spanning Tree. >> Main# /cfg/stp 1 >> Main# /cfg/stp/off >> Main# /cfg/stp/apply 4. (Select the STP Group number) (Disable STP) (Make your changes active) Enable IP forwarding. IP forwarding is enabled by default. Make sure IP forwarding is enabled if the virtual server IP addresses and real server IP addresses are on different subnets, or if the switch is connected to different subnets and those subnets need to communicate through the switch. If you are in doubt as to whether or not to enable IP forwarding, enable it. In this example, the virtual server IP addresses and real server IP addresses are on different subnets, so enable this feature using the following command: >> Main# /cfg/ip/frwd/on 268 n (Enable IP forwarding) Chapter 11: High Availability 212777-A, February 2002 Web OS 10.0 Application Guide 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: >> Main# /cfg/slb/real 1 >> Real server 1 # rip 10.10.10.5/24 >> Real server 1 # ena (Server A is real server 1) (Assign Server A IP address) (Enable real server 1) Repeat this sequence of commands for the following real servers: 2. n RIP 2 10.10.10.6/24 n RIP 3 20.10.10.5/24 n RIP 4 20.10.10.6/24 n RIP 5 30.10.10.5/24 n RIP 6 30.10.10.6/24 n RIP 7 200.1.1.5/24 n RIP 8 200.1.1.6/24 Define the real server groups, adding the appropriate real servers. This combines the three real servers into one service group: >> Real server 8 # /cfg/slb/group 1 >> Real server group 1# add 1 >> Real server group 1# add 2 (Select real server group 1) (Add real server 1 to group 1) (Add real server 2 to group 1) Repeat this sequence of commands for the following real server groups: n Group 2—Add RIP 3 and 4 n Group 3—Add RIP 5 and 6 n Group 4—Add RIP 7 and 8 Chapter 11: High Availability 212777-A, February 2002 n 269 Web OS 10.0 Application Guide 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 number. >> >> >> >> >> 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) Virtual server 1 # ena (Enable the virtual server) Repeat this sequence of commands for the following virtual servers: 4. n VIP 2 200.200.200.101 will load balance HTTPS (Port 443) to Group 2 n VIP 3 200.200.200.102 will load balance POP/SMTP (Ports 110/25) to Group 3 n VIP 4 200.200.200.104 will load balance FTP (Ports 20/21) to Group 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: n The ports connected to the upstream switches (the ones connected to the routers) will need to be in the client port state. n The ports connected to the downstream switches (the ones providing fan out for the servers) will need to be in the server port state. Configure the ports, using the following sequence of commands: >> >> >> >> 270 n Virtual server 4# /cfg/slb/port 1 SLB port A1 # client ena SLB port A1 # ../port 2 SLB port A2 # server ena (Select physical switch port 1) (Enable client processing on port 1) (Select physical switch port 2) (Enable server processing on port 2) Chapter 11: High Availability 212777-A, February 2002 Web OS 10.0 Application Guide 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: >> >> >> >> >> Virtual Virtual Virtual Virtual Virtual server router router router router 4 2 2 2 2 # /cfg/vrrp/vr 2 vrid 2 addr 200.200.200.100 if 5 ena (Select virtual router 2) (Set virtual router ID) (Assign virtual router IP address) (Assign virtual router interface) (Enable virtual router 2) Repeat this sequence of commands for the following virtual routers: 2. n VR 4 - VRID 4 - IF 5 (associate with IP interface #5)—Address 200.200.200.101 n VR 6 - VRID 6 - IF 5 (associate with IP interface #5)—Address 200.200.200.103 n VR 8 - VRID 8 - IF 5 (associate with IP interface #5)—Address 200.200.200.104 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. n VR 1 - VRID 1 - IF 1 (associate with IP interface 1)—Address 10.10.10.1 n VR 3 - VRID 3 - IF 2 (associate with IP interface 2)—Address 20.10.10.1 n VR 5 - VRID 5 - IF 3 (associate with IP interface 3)—Address 30.10.10.1 n VR 7 - VRID 7 - IF 4 (associate with IP interface 4)—Address 40.10.10.1 Chapter 11: High Availability 212777-A, February 2002 n 271 Web OS 10.0 Application Guide 3. Set the renter priority for each virtual router. Since you want Switch 1 to be the master router, you need to bump the default virtual router priorities (which are 100 to 101 on virtual routers 1-4) to force switch 1 to be the master for these virtual routers. Use the following sequence of commands: >> Virtual server 4 # /cfg/vrrp/vr 1 >> Virtual router 1 prio 101 (Select virtual router 1) (Set virtual router priority) Apply this sequence of commands to the following virtual routers, assigning each a priority of 101: 4. n VR 2 - Priority 101 n VR 3 - Priority 101 n VR 4 - Priority 101 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: >> Virtual server 4# /cfg/vrrp/vr 1/track l4pts This command sets the priority tracking parameter for virtual router 1, electing the virtual router with the most available ports as the master router. Repeat this command for the following virtual routers: n VR 2 - Track l4pts VR 6 - Track l4pts n VR 3 - Track l4pts VR 7 - Track l4pts n VR 4 - Track l4pts VR 8 - Track l4pts Switch 1 configuration is complete. 272 n Chapter 11: High Availability 212777-A, February 2002 Web OS 10.0 Application Guide Task 4: Configuring Switch 2 Use the following procedure to dump the configuration script (text dump) out of Switch 1: n 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. (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. n Using HyperTerminal (a) Only the Baud Rate and Flow Control options need to be changed from the default settings. (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: /cfg/dump A script will be dumped out. (d) Stop logging your session (transfer/capture text/stop). Modify the script as follows: 1. 2. Open the text file that you just created and change the following: n Delete anything above “Script Start.” n Delete the two lines directly below “Script Start.” These two lines identify the switch from which the dump was taken and the date and time. If these two lines are left in, it will confuse Web switch 2 when you dump in the file. n Change the last octet in all the IP interfaces from .10 to .11. Find this in line: /cfg/ip/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. Change the virtual router priorities. Virtual routers 1–4 need to have their priority set to 100 from 101, and virtual routers 5-7 need to have their priorities set to 101 from 100. You can find this in line /cfg/vrrp/vr 1/vrid 1/if 1/prio 101. Chapter 11: High Availability 212777-A, February 2002 n 273 Web OS 10.0 Application Guide 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: >> Main# /boot/conf factory/reset You can tell if the switch is at factory default when you log on because the switch will prompt you if you want to use the step-by-step configuration process. When it does, respond: “No.” 5. 274 n In HyperTerminal, go to transfer/send text file and send the Switch 2 text file. The configuration will dump into the switch. Simply type apply, then save. When you can type characters in the terminal session again, reboot the switch (/boot/reset). Chapter 11: High Availability 212777-A, February 2002 Web OS 10.0 Application Guide VRRP-Based 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 11-10 shows a classic network topology, designed with redundancy in mind. This topology contains bridging loops that would require the use of STP. In the typical network, STP failover time is 45-50 seconds, much longer than the typical failover rate using VRRP only. NOTE – To use hot-standby redundancy, peer switches must have an equal number of ports. Clients Active Side Standby Side Hub 7 7 CH CH Interswitch link 3 3 SH 1 1 SH Hub Legend 1. L4 ports are configured as Hot-Standby. 2. Crosslink is configured as Interswitch link. Servers Figure 11-10 Hot-Standby Configuration NOTE – In complex networks, STP convergence time can be much higher than 45-50 seconds. If VRRP was used in this configuration, it would require STP. An important factor to consider is that the switch would be affected by the slower failover time of STP even if VRRP were in use. While VRRP can be used without STP in this scenario, doing so would involve a more complex network configuration, requiring multiple subnets and/or VLANs and enabling IP forwarding to route between them. Chapter 11: High Availability 212777-A, February 2002 n 275 Web OS 10.0 Application Guide By reducing complexity to a single subnet and not requiring routing (L3), hot-standby can be used. The key to hot-standby is that the interswitch link (the link between switches), does NOT participate in STP, so there are no loops in the topology (see Figure 11-10). STP does not need to be enabled, and the switch will have failover times similar to what would be the case with VRRP. Configuration Procedure Configuration takes place after configuring SLB and VRRP with STP enabled: 1. From the SLB menu, enable a hot-standby link on the Layer 4 ports; then enable interswitch link on the crosslink. >> >> >> >> >> >> >> >> 2. Main# /cfg/slb/port 1 SLB Port 1# server ena SLB Port 1# hotstan ena SLB Port 1# ../port 3 SLB Port 3# intersw ena SLB Port 3# ../port 7 SLB Port 7# client ena SLB Port 7# hotstan ena From the VRRP menu, enable VRRP group mode; then enable hot-standby. >> Main# /cfg/vrrp/on >> VRRP# hotstan ena >> VRRP# group ena 3. (Select port 1) (Enable the server) (Enable hot standby) (Select port 3) (Enable inter-switch processing) (Select port 7) (Enable the client) (Enable hot standby) (Enable VRRP) (Enable hot standby) (Enable VR group) Sync the VRRP, SLB, and filter settings to the other switch (same ports). >> Main# /oper/slb/sync NOTE – Switches peering with each other must have an equal number of ports. 4. Turn off STP after verifying that the network is stable. >> Main# /cfg/stp 1/off >> Spanning Tree Group 1# save >> Main# /boot/reset (Disable STP group) (Enable hot standby) (Reset the switch) NOTE – You must reboot the switch for the hot-standby configuration to take effect. 276 n Chapter 11: High Availability 212777-A, February 2002 Web OS 10.0 Application Guide Virtual Router Deployment Considerations Review the following issues described in this section to prevent network problems when deploying virtual routers: n Mixing Active-Standby and Active-Active Virtual Routers n Synchronizing Active/Active Failover n Eliminating Loops with STP and VLANs n Assigning VRRP Virtual Router ID n Configuring the Switch for Tracking n Synchronizing Configurations Mixing Active-Standby and Active-Active Virtual Routers If the network environment can support sharing, enable it for all virtual routers in the LAN. If not, use active-standby for all virtual routers. Do not mix active-active and active-standby virtual routers in a LAN. Mixed configurations have not been tested, may result in unexpected operational characteristics, and, therefore, are not recommended. Synchronizing Active/Active Failover The hot-standby failover required the primary and secondary switches to have identical configurations and port topology. With VRRP and active/active failover, this is optional. 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 command: /oper/slb/synch The sync command copies the following settings to the switch at the specified IP interface address: n VRRP settings n SLB settings (including port settings) n Filter settings (including filter port settings) n 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. For more information on synchronizing configurations between two switches, see “Synchronizing Configurations” on page 282. Chapter 11: High Availability 212777-A, February 2002 n 277 Web OS 10.0 Application Guide 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 11-11, active-active configurations can introduce loops into complex LAN topologies. Server Router Web Switch Bridging Loop Internet Router Web Switch Server Figure 11-11 Loops in Active-Active Configuration 278 n Chapter 11: High Availability 212777-A, February 2002 Web OS 10.0 Application Guide 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 11-12. In this example, a number of loops are wired into the topology. STP resolves loops by blocking ports where looping is detected. Routers Alteon Web Switches Switches Servers Internet Figure 11-12 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 11-13: Routers Alteon Web Switches Switches Servers VLAN 1 is for switch-to-switch and external routing Internet VLAN 2 groups the first subswitch with the Alteon Web Switches VLAN 3 groups the second sub- switch with the Alteon Web switches Figure 11-13 Using VLANs to Create Non-Looping Topologies This topology allows STP to be disabled. On the Alteon Web switches, IP routing allows traffic to cross VLAN boundaries. The servers use the Alteon Web 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). Chapter 11: High Availability 212777-A, February 2002 n 279 Web OS 10.0 Application Guide 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/vrrp/vr #/vrid) must be assigned. The virtual router ID may be configured as any number between 1 and 255. Configuring the Switch for Tracking Tracking configuration largely depends on user preferences and network environment. Consider the configuration shown in Figure 11-8 on page 263. Assume that the user wants the following behavior on the network: n Web switch 1 is the master router upon initialization. n If Web switch 1 is the master and it has one active server fewer than Web switch 2, it remains the master. n The user wants this behavior because running one server down is less disruptive than bringing a new master online and severing all active connections in the process. n If Web switch 1 is the master and it has two or more active servers fewer than Web switch 2, then Web switch 2 becomes the master. n If Web switch 2 is the master, it remains the master even if servers are restored on Web switch 1 such that it has one fewer or an equal number of servers. n If Web switch 2 is the master and it has one active server fewer than Web switch 1, then Web switch 1 becomes the master. The user can implement this behavior by configuring the switch for tracking as follows: 1. Set the priority for Web switch 1 to the default value of 100. 2. Set the priority for Web 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 that is the same as the IP address of the virtual server router on the switch and set the value = 6. Initially, Web switch 1 (Figure 11-8) will have a priority of 100 (base value) + 5 (since it will initially be the master) + 24 (4 active real servers x 6 per real server) = 129. Web switch 2 will have a priority of 96 (base value) + 24 (4 active real servers X 6 per real server) = 120. 280 n Chapter 11: High Availability 212777-A, February 2002 Web OS 10.0 Application Guide If one server attached to Web switch 1 fails, then Web switch 1’s priority will be reduced by 6 to 123. Since 123 is greater than 120 (Web switch 2’s priority), Web switch 1 will remain the master. If a second server attached to Web switch 1 fails, then Web switch 1’s priority will be reduced by 6 more to 117. Since 117 is less than 120 (Web switch 2’s priority), then Web switch 2 will become the Master. At this point, Web switch 1’s priority will fall by 5 more and Web switch 2's will rise by 5 because the switches are tracking how many Masters they are running. So, Web switch 1's priority will settle out at 112 and Web switch 2's priority at 125. When both servers are restored to Web switch 1, that switch's priority will rise by 12 (2 healthy real servers X 6 per healthy server) to 124. Since 124 is less than 125, Web switch 2 will remain the master. If, at this point, a server fails on Web switch 2, its priority will fall by 6 to 119. Since 119 is less than 124, Web switch 1 will become the Master. Its priority will settle out at 129 (since it's now the master) while Web switch 2’s priority will drop by 5 more to 114. As you can see from this example, the user's goals were met by the configured tracking parameters. NOTE – There is no shortcut to setting tracking parameters. The goals must first be set and the outcomes of various configurations and scenarios analyzed to find settings that meet the goals. Chapter 11: High Availability 212777-A, February 2002 n 281 Web OS 10.0 Application Guide Synchronizing Configurations As noted above, 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 configurations, 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 configured on each switch. Switches being synchronized must use the same administrator password. 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 Config Synchronization # peer 1 Peer Switch 1 # addr Peer Switch 1 # enable (Select the synchronization menu) (Select a peer) (Assign switch 2 IP address) (Enable peer switch) Similarly, from switch #2, configure switch # 1 as a peer and specify its IP address as follows: >> >> >> >> Main # /cfg/slb/sync Config Synchronization # peer 2 Peer Switch 2 # addr Peer Switch 2 # enable (Select the synchronization menu) (Select a peer) (Assign switch 1 IP address) (Enable peer switch) 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 command is used, it is highly recommended that the hardware configurations and network connections of all switches in the virtual router be identical; that is, each switch should be the same model, have the same line cards in the same slots (if modular) and have the same ports connected to the same external network devices. Otherwise, unexpected results may occur when the /oper/slb/synch command attempts to configure a non-existent port or applies an inappropriate configuration to a port. 282 n Chapter 11: High Availability 212777-A, February 2002 Web OS 10.0 Application Guide Stateful Failover of Layer 4 and Layer 7 Persistent Sessions Web OS provides stateful failover of content-intelligent persistent session state and Layer 7 persistent session state. This includes the following: n SSL session state n HTTP cookie state n Layer 4 persistent n FTP session state Providing stateful failover enables network administrators to mirror their Layer 7 and Layer 4 persistent transactional state on the peer switch. NOTE – Stateful failover does not synchronize all sessions, except persistent sessions. Make sure Direct Access Mode (DAM) is enabled when you configure stateful failover for Layer 7 persistency (for example: SSL session ID persistence-based server load balancing, URL and cookie-based server load balancing). To provide stateful failover, the state of the connection and session table must be shared between the switches in high-availability configurations. With Virtual Matrix Architecture (VMA) enabled, all URL and cookie-parsing information is stored in the session table on port 9. Sharing this information between switches is necessary to ensure the persistent session goes back to the same server. NOTE – Stateful failover is only supported in active-standby mode with VMA enabled. Chapter 11: High Availability 212777-A, February 2002 n 283 Web OS 10.0 Application Guide 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 11-14. 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 (Switch 2) becomes active. 2. The incoming request is redirected to Switch 2. 3. When the user clicks Submit again, the request is forwarded to the correct server. Even though Switch 1 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 Switch 2. Clients Servers Web Switch 1 Failed Internet Layer 2 Switch Router IP: A Traffic is redirected to Switch 2 Web Switch 2 Active IP: B Figure 11-14 Stateful Failover Example when the Master Switch Fails 284 n Chapter 11: High Availability 212777-A, February 2002 Web OS 10.0 Application Guide Stateful Failover Configuration Example After the VRRP setup, perform the following additional steps to enable stateful failover on the switches. On the Master Switch 1. Enable stateful failover. >> # /cfg/slb/sync/state ena 2. Set the update interval. >> # /cfg/slb/sync/update 10 (The default is 30) On the Backup Switch 1. Turn on stateful failover. >> # /cfg/slb/sync/state ena 2. Set the update interval. >> # /cfg/slb/sync/update 10 (The default is 30) NOTE – The update does not have to be the same for both switches. Stateful failover supports up to two peer switches. Repeat the steps mentioned above to enable stateful failover on all the peer switches. Chapter 11: High Availability 212777-A, February 2002 n 285 Web OS 10.0 Application Guide 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/vrrp command. If the switch is a master: >> # /info/vrrp VRRP information: 1: vrid 1, 172.21.16.187, server 3: vrid 3, 192.168.1.30, 5: vrid 5, 172.21.16.10, (View VRRP Information) if 4, renter, prio 109, master, if if 2, renter, prio 109, master 4, renter, prio 109, master If the switch is a backup: >> # /info/vrrp VRRP information: 1: vrid 1, 172.21.16.187, server 3: vrid 3, 192.168.1.30, 5: vrid 5, 172.21.16.10, 286 n (View VRRP Information) if 1, renter, prio 104, backup, if if 3, renter, prio 104, backup 1, renter, prio 104, backup Chapter 11: High Availability 212777-A, February 2002 Part 3: Advanced Web Switching Web 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 Web switching applications: n Global Server Load Balancing n Firewall Load Balancing n Virtual Private Network Load Balancing n Content Intelligent Switching n Persistence n Bandwidth Management 287 212777-A, February 2002 Web OS 10.0 Application Guide 288 n Advanced Web Switching 212777-A, February 2002 CHAPTER 12 Global Server Load Balancing This chapter provides information for configuring Global Server Load Balancing (GSLB) across multiple geographic sites. The following topics are covered: n “GSLB Overview” on page 290 n “Configuring GSLB” on page 293 n “IP Proxy for Non-HTTP Redirects” on page 304 n “Verifying GSLB Operation” on page 308 n “Configuring Client Site Preferences” on page 308 n “Using Border Gateway Protocol for GSLB” on page 312 289 212777-A, February 2002 Web OS 10.0 Application Guide GSLB Overview GSLB allows balancing server traffic load across multiple physical sites. The Alteon GSLB implementation takes into account an individual site’s health, response time, and geographic location to smoothly integrate the resources of the dispersed server sites for complete global performance. Benefits GSLB meets the following demands for distributed network services: n 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. n There is no latency during client connection set up. Instant site hand-off decisions can be made by any distributed switch. n The best performing sites receive a majority of traffic over a given period of time but are not overwhelmed. n Switches at different sites regularly exchange information through the Distributed Site State Protocol (DSSP), and can trigger exchanges when any site’s health status changes. This ensures that each active site has valid state knowledge and statistics. n GSLB implementation takes geography as well as network topology into account. n Creative control is given to the network administrator or Webmaster to build and control content by user, location, target application, and more. n GSLB is easy to deploy, manage, and scale. Switch configuration is straightforward. There are no complex system topologies involving routers, protocols, and so forth. n Flexible design options are provided. n All IP protocols are supported. Compatibility with Other Web OS Features 290 n n URL-based server load balancing is compatible with GSLB. n Cookie-based persistence is compatible with GSLB: cookie rewrite and cookie insert modes. Chapter 12: Global Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide How GSLB Works GSLB is based on the Domain Name System (DNS) and proximity by source IP address. In the example in Figure 12-1, a client is using a browser to view the Web site for the Foo Corporation at “www.foocorp.com.” The Foo Corporation has two Web sites: one in California, and one in Denver, each with identical content and available services. Both Web sites have an Alteon Web switch configured for GSLB. These switches are also configured as the Authoritative Name Servers for “www.foocorp.com.” Client Site DNS Request DNS Foo Corp. California 1 5 HTTP Request Foo Corp. Denver 2 DNS DNS 3 Best Service! Web Switch Web Switch Internet 4 Switches regularly exchange performance information Web Servers Web Servers DNS response lists best site's IP address first Figure 12-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.foocorp.com” IP address from the local DNS. 2. Client’s 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 requested IP address information on hand or the request reaches one of the Foo Corporation’s DNS servers. 3. The Foo Corporation’s California DNS has been configured to use the local Web switch with GSLB software as the authoritative name server for “www.foocorp.com.” Chapter 12: Global Server Load Balancing 212777-A, February 2002 n 291 Web OS 10.0 Application Guide 4. The California Web switch responds to the DNS request, listing the IP address with the current best service. Each switch with GSLB software is capable of responding to the client’s name resolution request. Since each switch regularly checks and communicates health and performance information with its peers, either switch can determine which site(s) are best able to serve the client’s Web access needs. It can respond with a list of IP addresses for the Foo Corporation’s distributed sites, which are prioritized by performance, geography, and other criteria. In this case, the California Web switch knows that Foo Corp. Denver currently provides better service, and lists Foo Corp. Denver’s virtual server IP address first when responding to the DNS request. 5. The client connects to Foo Corp. Denver for the best service. The client’s Web browser will use the IP address information obtained from the DNS request to open a connection to the best available site. The IP addresses represent virtual servers at any site, which are locally load balanced according to regular SLB configuration. If the site serving the client HTTP content suddenly experiences a failure (no healthy real servers) 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 client-side configuration. 292 n Chapter 12: Global Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Configuring GSLB Configuring GSLB is simply an extension of the configuration procedure for SLB. The process is summarized as follows: n Use the administrator login to connect to the switch you want to configure. n Activate SLB and GSLB software keys. See the Web OS Command Reference for details. n Configure the switch at each site with basic attributes. o Configure the switch IP interface. o Configure the default gateways. n 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 local DNS server to recognize the switch as the authoritative DNS server for the hosted services. n Configure the switch at each site for local SLB. o Define each local real server. o Group local real servers into real server groups. o Define the local virtual server with its IP address, services, and real server groups. o Define the switch port states. o Enable SLB. n Finally, configure each switch so that it recognizes its remote peers. o Configure a remote real server entry on each switch for each remote service. o Add the remote real server entry to an appropriate real server group. o Enable GSLB. Chapter 12: Global Server Load Balancing 212777-A, February 2002 n 293 Web OS 10.0 Application Guide Example GSLB Topology Consider the following example network: California Site Denver Site 200.200.200.X Network 174.14.70.X Network DNS Server: 200.200.200.102 A DNS Server: 174.14.70.102 Web Switch B Web Servers: 200.200.200.2 200.200.200.3 C Internet IP Interface: 200.200.200.100 Virtual Server: 200.200.200.1 D Web Switch Default Gateway: 200.200.200.101 Default Gateway: 174.14.70.101 IP Interface: 174.14.70.100 Virtual Server: 174.14.70.1 Web Servers: 174.14.70.2 174.14.70.3 Figure 12-2 GSLB Topology Example In the following examples, many of the options are left to their default values. See “Additional Server Load Balancing Options” on page 128 for more options. GSLB Requirements The following is required prior to configuration: n You must be connected to the switch Command Line Interface (CLI) as the administrator. n Both of the following optional software keys must be activated: o SLB o GSLB NOTE – For details about any of the processes or menu commands described in this example, see the Web OS Command Reference. 294 n Chapter 12: Global Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Task 1: Configure the Basics at the California Site 1. If the Browser-Based Interface (BBI) is to be used for managing the California switch, change its service port. GSLB uses service port 80 on the IP interface for DSSP updates. By default, the Web 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/http command in Chapter 7 of the Web OS Command Reference), configure it to use a different port. For example, enter the following command to change the BBI port to 8080: (Select the System menu) (Set service port 8080 for BBI) >> # /cfg/sys >> System# wport 8080 2. On the California switch, define an IP interface. The switch IP interface responds when asked to resolve client DNS requests. The IP interface must have an IP route to the local real servers. The switch uses this path to determine if the real servers can be reached via TCP/IP. To configure an IP interface for this example, enter these commands from the CLI: >> System# /cfg/ip/if 1 >> IP Interface 1# addr 200.200.200.100 >> IP Interface 1# ena (Select IP interface 1) (Assign IP address for the interface) (Enable IP interface 1) NOTE – 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. On the California switch, define the default gateway. The router at the edge of the site acts as the default gateway to the Internet. To configure the default gateway for this example, enter these commands from the CLI: >> IP Interface 1# ../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) 4. Configure the local DNS server to recognize the local GSLB switch as the authoritative name server for the hosted services. Determine the domain name that will be distributed to both sites and the host name for each distributed service. In this example, the California DNS server is configured to recognize 200.200.200.100 (the IP interface of the California GSLB switch) as the authoritative name server for “www.foocorp.com.” Chapter 12: Global Server Load Balancing 212777-A, February 2002 n 295 Web OS 10.0 Application Guide Task 2: Configure the California Switch for Standard SLB 1. Assign an IP address to each of the real servers in the local California server pool. The real servers in any real server group must have an IP route to the switch that will perform the SLB functions. This is most easily accomplished by placing the switches and servers on the same IP subnet, although advanced routing techniques can be used as long as they do not violate the topology rules outlined in “Network Topology Requirements” on page 122. For this example, the host real servers have IP addresses on the same IP subnet: Table 12-1 GSLB Example: California Real Server IP Addresses 2. Real Server IP address Server A 200.200.200.2 Server B 200.200.200.3 On the California switch, 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. Default gateway 1# /cfg/slb/real 1 Real server 1# rip 200.200.200.2 Real server 1# ena Real server 1# ../real 2 Real server 2# rip 200.200.200.3 Real server 2# ena (Server A is real server 1) (Assign IP address to server A) (Enable real server 1) (Server B is real server 2) (Assign IP address to server B) (Enable real server 2) On the California switch, define a real server group. Combine the real servers into one service group and set the necessary health checking parameters. In this example, HTTP health checking is used to ensure that Web content is being served. If the index.html file is not accessible on a real server during health checks, the real server will be marked as down. >> >> >> >> >> 296 n Real Real Real Real Real server server server server server 2# ../group 1 (Select real server group 1) group 1# add 1 (Add real server 1 to group 1) group 1# add 2 (Add real server 2 to group 1) group 1# health http (Use HTTP for health checks) group 1# content index.html (Set URL content for health checks) Chapter 12: Global Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide 4. On the California switch, define a virtual server. All client requests will be addressed to a virtual server IP address defined on the switch. Clients acquire the virtual server IP address through normal DNS resolution. HTTP uses wellknown 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: >> >> >> >> >> Real server group 1# ../virt 1 Virtual server 1# vip 200.200.200.1 Virtual Server 1# service 80 Virtual server 1 http Service# group 1 Virtual server 1 http Service# ../ena (Select virtual server 1) (Assign a virtual server IP address) (Associate virtual port to real group) (Enable virtual server) NOTE – This configuration is not limited to HTTP services. For a list of other well-known TCP/IP services and ports, see Table 6-3 on page 128. 5. On the California switch, define the type of Layer 4 traffic processing each port must support. In this example, the following ports are being used on the Web switch: Table 12-2 GSLB Example: California Alteon 180 Port Usage Port Host Layer 4 Processing 1 Server A Server 2 Server B Server 6 Default Gateway Router. This connects the switch to the Internet where all client requests originate. Client The ports are configured as follows: >> >> >> >> >> >> 6. Virtual server 1# /cfg/slb/port 1 SLB port 1# server ena SLB port 1# ../port 2 SLB port 2# server ena SLB port 2# ../port 6 SLB port 6# client ena (Select physical switch port 1) (Enable server processing on port 1) (Select physical switch port 2) (Enable server processing on port 2) (Select physical switch port 6) (Enable client processing on port 6) On the California switch, enable SLB. >> SLB port 6# /cfg/slb >> Layer 4# on (Select the SLB Menu) (Turn SLB on) Chapter 12: Global Server Load Balancing 212777-A, February 2002 n 297 Web OS 10.0 Application Guide Task 3: Configure the California Site for GSLB 1. On the California switch, define each remote site. When you start configuring at the California site, California is local and Denver is remote. Add and enable the remote switch’s IP address interface. In this example, there is only one remote site: Denver, with an IP interface address of 174.14.70.100. The following commands are used: >> Layer 4# gslb/site 1 >> Remote site 1# prima 174.14.70.100 >> Remote site 1# ena (Select remote site 1) (Define remote interface) (Enable remote site 1) Each additional remote site would be configured in the same manner. You can enable up to 64 remote sites with a total aggregate of 2048 service/site combinations. 2. On the California switch, assign each remote distributed service to a local virtual server. Configure the local California site to recognize the services offered at the remote Denver site. To do this, configure one real server entry on the California 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 California 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. 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. For example: >> >> >> >> >> >> >> Remote site Real server Real server Real server Real server Real server Real server 1# /cfg/slb/real 3 3# rip 174.14.70.1 3# remote enable 3# inter 60 3# ena 3# ../group 1 group 1# add 3 (Create an entry for real server 3) (Set remote virtual server IP address) (Define the real server as remote) (Set a high health check interval) (Enable the real server entry) (Select appropriate real server group) (Add real server 3 to the group 1) NOTE – Take care to note where each configured value originates or this step can result in improper configuration. 298 n Chapter 12: Global Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide 3. On the California switch, define the domain name and host name for each service hosted on each virtual server. In this example, the domain name for the Foo Corporation is “foocorp.com,” and the host name for the only service (HTTP) is “www.” These values are configured as follows: >> Real server group 1# ../virt 1 (Select virtual server 1) >> Virtual server 1# dname foocorp.com (Define domain name) >> Virtual server 1# service 80/hname www (Define HTTP host name) To define other services (such as FTP), make additional hostname entries. 4. On the California switch, turn on GSLB. >> Virtual server 1# ../gslb >> Global SLB# on 5. (Select the GSLB Menu) (Activate GSLB for the switch) Apply and verify the configuration. >> Global SLB# apply >> Global SLB# cur >> Global SLB# /cfg/slb/cur (Make your changes active) (View current GSLB settings) (View current SLB settings) Examine the resulting information. If any settings are incorrect, make and apply any appropriate changes, and then check again. 6. Save your new configuration changes. >> Layer 4# save (Save for restore after reboot) Task 4: Configure the Basics at the Denver Site Following the same procedure described for California (see “Example GSLB Topology” on page 294), configure the Denver site as follows: 1. If the Web OS BBI is to be used for managing the Denver switch, change its service port. >> # /cfg/sys >> System# wport 8080 (Select the System menu) (Set service port 8080 for BBI) Chapter 12: Global Server Load Balancing 212777-A, February 2002 n 299 Web OS 10.0 Application Guide 2. On the Denver switch, define an IP interface. >> # /cfg/ip/if 1 >> IP Interface 1# addr 174.14.70.100 >> IP Interface 1# ena 3. On the Denver switch, define the default gateway. >> IP Interface 1# ../gw 1 >> Default gateway 1# addr 174.14.70.101 >> Default gateway 1# ena 4. (Select IP interface 1) (Assign IP address for the interface) (Enable IP interface 1) (Select default gateway 1) (Assign IP address for the gateway) (Enable default gateway 1) Configure the local DNS server to recognize the local GSLB switch as the authoritative name server for the hosted services. The Denver DNS server is configured to recognize 174.14.70.100 (the IP interface of the Denver GSLB switch) as the authoritative name server for “www.foocorp.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. Table 12-3 Denver Real Server IP Addresses 2. Real Server IP address Server C 179.14.70.2 Server D 179.14.70.2 On the Denver switch, define each local real server. >> >> >> >> >> >> 300 n Default gateway 1# /cfg/slb/real 1 Real server 1# rip 179.14.70.2 Real server 1# ena Real server 1# ../real 2 Real server 2# rip 179.14.70.3 Real server 2# ena (Server C is real server 1) (Assign IP address for Server C) (Enable real server 1) (Server D is real server 2) (Assign IP address for Server D) (Enable real server 2) Chapter 12: Global Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide 3. On the Denver switch, define a real server group. >> >> >> >> >> 4. Real Real Real Real Real 2# ../group 1 (Select real server group 1) group 1# add 1 (Add real server 1 to group 1) group 1# add 2 (Add real server 2 to group 1) group 1# health http (Use HTTP for health checks) group 1# content index.html (Set URL content for health checks) On the Denver switch, define a virtual server. >> >> >> >> >> 5. server server server server server Real server group 1# ../virt 1 Virtual server 1# vip 179.14.70.1 Virtual server 1# service http Virtual server 1 http service# group 1 Virtual server 1 http service# ../ena (Select virtual server 1) (Assign IP address) (Select the HTTP service menu) (Associate virtual port to real group) (Enable the virtual server) On the Denver switch, define the type of Layer 4 processing each port must support. In this example, the following ports are being used on the Alteon 180 Web switch: Table 12-4 Web Host Example: Alteon 180 Port Usage Port Host Layer 4 Processing 3 Server C Server 4 Server D Server 5 Default Gateway Router. This connects the switch to the Internet where all client requests originate. Client The ports are configured as follows: >> >> >> >> >> >> 6. Virtual server 1# /cfg/slb/port 3 SLB port 3# server ena SLB port 3# ../port 4 SLB port 4# server ena SLB port 4# ../port 5 SLB port 5# client ena (Select physical switch port 3) (Enable server processing on port 3) (Select physical switch port 4) (Enable server processing on port 4) (Select physical switch port 5) (Enable client processing on port 5) On the Denver switch, enable SLB. >> SLB port 5# /cfg/slb >> Layer 4# on (Select the SLB Menu) (Turn SLB on) Chapter 12: Global Server Load Balancing 212777-A, February 2002 n 301 Web OS 10.0 Application Guide Task 6: Configure the Denver Site for GSLB Following the same procedure described for California (see “Task 3: Configure the California Site for GSLB” on page 298), configure the Denver site as follows: 1. On the Denver switch, define each remote site. When you start configuring at the Denver site, Denver is local and California is remote. Add and enable the remote switch’s IP address interface. In this example, there is only one remote site: California, with an IP interface address of 200.200.200.100. The following commands are used: >> Layer 4# gslb/site 1 >> Remote site 1# prima 200.200.200.100 >> Remote site 1# ena (Select remote site 1) (Define remote IP interface address) (Enable remote site 1) Each additional remote site would be configured in the same manner. You can enable up to 64 remote sites with a total aggregate of 2048 service/site combinations. 2. 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 California 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 (California) 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 interface address on the remote switch. Also, the remote parameter is enabled, and the real server entry is added to the real server group under the local virtual server for the intended service. Finally, since the real server health checks are headed across the Internet, the health-checking interval should be increased to 30 or 60 seconds to avoid generating excess traffic. 302 n Chapter 12: Global Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide For example: >> >> >> >> >> >> >> Remote site Real server Real server Real server Real server Real server Real server 1# /cfg/slb/real 3 3# rip 200.200.200.1 3# remote enable 3# inter 60 3# ena 3# ../group 1 group 1# add 3 (Create an entry for real server 3) (Set remote virtual server IP address) (Define the real server as remote) (Set a high health check interval) (Enable the real server entry) (Select appropriate. real server group) (Add real server 3 to group 1) NOTE – Take care to note where each configured value originates or this step can result in improper configuration. 3. 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 California switch: the domain name is “foocorp.com,” and the host name for the HTTP service is “www.” These values are configured as follows: >> >> >> >> 4. Real server group 1# ../virt 1 Virtual server 1# dname foocorp.com Virtual server 1# service 80 Virtual server 1 http# hname www (Select virtual server 1) (Define domain name) (Select HTTP for virtual server) (Define HTTP hostname) On the Denver switch, turn on GSLB. >> Virtual server 1 http# /cfg/slb/gslb/on (Activate GSLB for the switch) 5. Apply and verify the configuration. >> Global SLB# apply >> Global SLB# cur >> Global SLB# /cfg/slb/cur (Make your changes active) (View current GSLB settings) (View current SLB settings) Examine the resulting information. If any settings are incorrect, make and apply any appropriate changes, and then check again. 6. Save your new configuration changes. >> Layer 4# save (Save for restore after reboot) Chapter 12: Global Server Load Balancing 212777-A, February 2002 n 303 Web OS 10.0 Application Guide IP Proxy 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. This is because the HTTP protocol has a built-in redirection function that allows requests to be redirected to an alternate site. 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 Web switches. Figure 12-3 illustrates the packet-flow of HTTP and non-HTTP redirects in a GSLB environment. Client Site HTTP Applications Non HTTP Applications DNS DNS Request Site 1 Site 2 DNS Web Switch 1a 1b 2b 2a Internet Web Servers Web Switch DNS Proxy IP address is configured on Client port for non-HTTP applications. Web Servers Figure 12-3 HTTP and Non-HTTP Redirects 304 n Chapter 12: Global Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Table 12-5 explains the packet -flow process in detail. In this example, the initial DNS request from the client reaches Site 2, but Site 2 has no available services. Table 12-5 HTTP Versus Non-HTTP Redirects HTTP application (built-in redirection) Site 2 Web switch Site 1 Web switch 1a. Client DNS request reaches Site 2. Resources are unavailable at Site 2. Site 2 sends a response to Client with Site 1’s virtual server IP address. 1b. Client resends request to Site 1. Resources are available at Site 1. Site 1 completes TCP three-way handshake with client. Non-HTTP application 2a. Client DNS request reaches Site 2. (no redirection) Resources are unavailable at Site 2. Site 2 sends a request to Site 1 with Site 2’s proxy IP address as the source IP address and the virtual server IP address of Site 1 as the destination IP address. 2b. Site 1 processes the client proxy IP request. Resources are available at Site 1. Site 1 returns request to proxy IP port on Site 2. Site 2 completes the three-way handshake with Client. How IP Proxy Works Figure 12-4 shows examples of two GSLB sites deployed in California and Denver. The applications being load balanced are HTTP and POP3. Any request that cannot be serviced locally is sent to the peer site. HTTP requests are sent to the peer site using HTTP Redirect. Any other application request will be sent to the peer site using the IP proxy feature. California Site #1 200.200.200.X Network Proxy Disabled For Local Real Servers A Web Switch B Denver: Site #2 174.14.70.X Network Service requests are always served by local real servers if available. Proxy IP Address 200.200.200.4 Proxy IP Address 174.14.70.4 Proxy Disabled For Local Real Servers D Web Switch C Internet HTTP/POP3 Local Servers 200.200.200.2 200.200.200.3 Remote Server 174.14.70.1 Virtual Server HTTP/POP3 Local Servers 174.14.70.1 174.14.70.2 174.14.70.3 Proxy Enabled For Remote Server Proxy Enabled For Remote Server Remote Server 200.200.200.1 If local real servers cannot service the request, the remote server is used via proxy. Virtual Server 200.200.200.1 Figure 12-4 POP3 Request Fulfilled via IP Proxy Chapter 12: Global Server Load Balancing 212777-A, February 2002 n 305 Web OS 10.0 Application Guide The following procedure explains the three-way handshake between the two sites and the client for a non-HTTP application (POP3). When POP3 processes at Site 1 terminate because of operator error, the following events occur to allow POP3 requests to be fulfilled: 1. A user POP3 TCP SYN request is received by the virtual server at Site 1. The switch at that site determines that there are no local resources to handle the request. 2. The Site 1 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 2 as the destination IP address. 3. The switch at Site 2 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 2, the switch and the real servers exchange information. The TCP SYN ACK from Site 2’s local real server is sent back to the IP address specified by the proxy IP address. 5. The Site 2 switch sends the TCP SYN ACK frame to Site 1, with Site 2’s virtual server IP address as the source IP address, and Site 1’s proxy IP address as the destination IP address. 6. The switch at Site 1 receives the frame and translates it, using Site 1’s virtual server IP address as the source IP address and the client’s IP address as the destination IP address. This cycle continues for the remaining frames to transmit all the client’s mail, until a FIN frame is received. 306 n Chapter 12: Global Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Configuring Proxy IP Addresses Refer to the example starting on page 294 and Figure 12-4, the switch at Site 1 in California is configured with switch port 6 connecting to the default gateway and real server 3 represents the remote server in Denver. The following commands are used at Site 1 in California to configure the proxy IP address for the remote server in Denver: NOTE – If any port is configured with a proxy IP address, then all ports (except port 9) must be configured with a unique proxy IP address prior to enabling Virtual Matrix Architecture (VMA). Once they are configured, proxy IP addresses not in use can be disabled. >> >> >> >> >> >> >> >> # /cfg/slb/port 6 SLB port 6# pip 200.200.200.4 SLB port 6# proxy enable SLB port 6 ../real 1/proxy disable Real server 1# ../real 2/proxy disable Real server 2# ../real 3/proxy enable Real server 3# apply Real server 3# save (Select port to default gateway) (Set unique proxy IP address) (Enable proxy for switch port 6) (Disable local real server proxy) (Disable proxy for local server) (Enable proxy for remote server) (Apply configuration changes) (Save configuration changes) If you want to configure proxy IP addresses on Site 2, the following commands are issued on the Denver switch: >> >> >> >> >> >> >> >> # /cfg/slb/port 5 SLB port 5# pip 174.14.17.4 SLB port 5# proxy enable SLB port 5# ../real 1/proxy disable Real server 1# ../real 2/proxy disable Real server 2# ../real 3/proxy enable Real server 3# apply Real server 3# save (Select port to default gateway) (Set unique proxy IP address) (Enable proxy for switch port 5) (Disable local real server proxy) (Disable local real server proxy) (Enable proxy for remote server) (Apply configuration changes) (Save configuration changes) Chapter 12: Global Server Load Balancing 212777-A, February 2002 n 307 Web OS 10.0 Application Guide Verifying GSLB Operation n Use your browser to request the configured service (www.foocorp.com in the previous example). n Examine the /info/slb information on each switch. n Check to see that all SLB parameters are working according to expectation. If necessary, make any appropriate configuration changes and then check the information again. n Examine the following statistics on each switch: o /stats/slb/gslb/virt o /stats/slb/gslb/group o /stats/slb/maint Configuring Client Site Preferences Internet Assigned Numbers Authority (IANA), the central coordinator for the assignment of unique parameter values for Internet protocols, does not provide sufficient geographic separation of client proximity information. As a result, large ISP partners cannot use their own geographic data to determine GSLB site selection based on client location. However, using static “client-to-site” mapping in Web OS software, you can configure client proximity tables to select GSLB sites based on client location. The use of a static client/site database allows you to customize the client environment. The proximity database is limited to 128 entries. The GSLB client proximity table is supported for HTTP protocol. 308 n Chapter 12: Global Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Figure 12-5 illustrates GSLB proximity tables. The client sends a request to the DNS server, which is forwarded to the master switch. The master switch looks through its proximity table and returns the request to the DNS server with the virtual server IP address of the preferred site. The DNS server sends a new request through the Internet and connects the client to the preferred site. 4.CLIENT REQUEST FORWARDED TO NEAREST LOCATION DATABASE FIELDS 3.MASTER SWIT CH LOOKS AT DATABASE AND RESPONDS 1. CLIENT SENDS REQUEST TO LOCAL DNS SERVER 2. DNS REQUEST SENT TO MASTER SWIT CH Figure 12-5 GSLB Proximity Tables: How They Work The following example illustrated in Figure 12-6 on page 310 shows how to add entries into a GSLB proximity table. Two client networks, A and B, are configured in the proximity table on the master switch at Site 4. Client A with a subnet address of 205.178.13.0 is configured with static entries for preferred Sites 1 and 3. Client B, with a subnet address of 204.165.0.0, is configured with static entries for preferred Sites 2 and 4. Chapter 12: Global Server Load Balancing 212777-A, February 2002 n 309 Web OS 10.0 Application Guide 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 Web switch at Site 4 looks up its proximity table and finds Client A prefers to connect to Sites 1 or 3. Similarly, Client B’s requests are always forwarded to Sites 2 or 4. Client Site A Client Site B 205.178.13.0 Prefers Sites 1 and 3 204.165.0.0 Prefers Sites 2 and 4 DNS Request 1. Client sites A and B send requests to their DNS servers which are forwarded to the master switch at Site 4. 2. The master switch looks through its proximity table and responds to the DNS request by providing the virtual IP address of the preferred site. DNS Request 3. The client sends out a new request and connects to the preferred site. Site 1 Site 4 DNS Web Servers Web Switch IF: 1.1.1.1 / 24 VIP: 1.1.1.100 DNS Web Switch IF: 4.4.4.4 / 24 VIP: 4.4.4.100 Internet Site 2 Site 3 DNS Web Servers Web Switch IF: 2.2.2.2 / 24 VIP: 2.2.2.100 Web Servers Master switch returns Client's request with the VIP of the preferred site DNS Web Switch IF: 3.3.3.3 / 16 Web VIP: 3.3.3.100 Servers Figure 12-6 Configuring Client Proximity Table You can add static entries in the proximity table for up to 128 client networks. NOTE – Web OS allows you to configure a single domain only and for each client subnet you can configure up to two preferred sites. The Web switch forwards the client request based on the minimum available sessions and response time between the two preferred sites. 310 n Chapter 12: Global Server Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Use the following commands to configure a proximity table on the Web switch at Site 4: >> >> >> >> >> >> >> >> >> >> >> >> # # # # # # # # # # # # /cfg/slb/gslb/lookup/lookups ena dname nortelnetworks.com network 1 sip 205.178.13.0 mask 255.255.255.0 vip1 vip2 ../network 2 sip 204.165.0.0 mask 255.255.0.0 vip1 vip2 (Enable the lookup or proximity table) (Select the domain name) (Select Client A subnet) (Assign source address for Client A) (Assign the mask for Client A) (Select preferred Site 3) (Select preferred Site 1) (Select Client B subnet) (Assign source address for Client B) (Assign the mask for Client B) (Select preferred Site 4) (Select preferred Site 2) NOTE – For each client subnet, add only one static entry. Using this configuration, the DNS request “nortelnetworks.com” from 205.178.13.0 will get a DNS response with only the virtual server IP address of Site 1, if Site 1 has less load than Site 3. Chapter 12: Global Server Load Balancing 212777-A, February 2002 n 311 Web OS 10.0 Application Guide Using Border Gateway Protocol for GSLB Border Gateway Protocol (BGP)-based GSLB utilizes the Internet’s routing protocols to localize content delivery to the most efficient and consistent site. It does so by using a shared IP block that co-exists in each Internet Service Provider’s (ISP’s) network and is then advertised, using BGP, throughout the Internet. Because of the way IP routing works, BGP-based GSLB allows for the routing protocols to route DNS requests to the closest location, which then returns IP addresses of that particular site, locking in the requests to that site. In effect, the Internet is making the decision of the best location for you, avoiding the need for advanced GSLB. Some corporations use more than one ISP as a way to increase the reliability and bandwidth of their Internet connection. Enterprises with more than one ISP are referred to as being multihomed. 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 providers and have one DNS server that has the IP address 1.1.1.1. In this case, all requests can be received via any given feed but are funneled to the same server on the local network. In BGPbased 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 Web 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/local ena) 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 Gateway Protocol (BGP)” on page 36. 312 n Chapter 12: Global Server Load Balancing 212777-A, February 2002 CHAPTER 13 Firewall Load Balancing Firewall Load Balancing (FWLB) with Alteon Web switches allows multiple active firewalls to operate in parallel. Parallel operation allows users to maximize firewall productivity, scale firewall performance without forklift upgrades, and eliminate the firewall as a single point-offailure. This chapter presents the following material: n “Firewall Overview” on page 314 An overview of firewalls and the various FWLB solutions supported by Alteon Web switches. n “Basic FWLB” on page 316 Explanation and example configuration for FWLB in simple networks, using two parallel firewalls and two Web switches. The basic FWLB method combines redirection filters and static routing for FWLB. n “Four-Subnet FWLB” on page 326 Explanation and example configuration for FWLB in a large-scale, high-availability network with redundant firewalls and Web switches. This method combines redirection filters, static routing, and Virtual Router Redundancy Protocol (VRRP). n “Advanced FWLB Concepts” on page 346 o “Free-Metric FWLB” on page 346. Using other load balancing metrics (besides hash) by enabling the Return to Sender (RTS) option. o “Adding a Demilitarized Zone (DMZ)” on page 349. Adding a DMZ for servers that attach to the Web switch between the Internet and the firewalls. o “Firewall Health Checks” on page 351. Methods for fine-tuning the health checks performed for FWLB. 313 212777-A, February 2002 Web OS 10.0 Application Guide Firewall Overview Firewall devices have become indispensable for protecting network resources from unauthorized access. Prior to FWLB, however, firewalls could become critical bottlenecks or single points-of-failure for your network. As an example, consider the following network: "Dirty" Public Network Firewall "Clean" Private Network Private Network Internet DMZ Figure 13-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 network 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 single point-of-failure device. If it goes out of service, external clients can no longer reach your services and internal clients can no longer reach the Internet. Sometimes, a Demilitarized Zone (DMZ) is attached to the 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 Web switches provides a variety of options that enhance firewall performance and resolve typical firewall problems. 314 n Chapter 13: Firewall Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Alteon Web switches support the following methods of FWLB: n Basic FWLB for simple networks This method uses a combination of static routes and redirection filters and is usually employed in smaller networks. A Web 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 316. n 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 Redundancy Protocol (VRRP) to the configuration. Just as with the basic method, four-subnet FWLB uses the hash metric to distribute firewall traffic and maintain persistence. For more information, see “Four-Subnet FWLB” on page 326. Each method is described in more detail in the following sections. Chapter 13: Firewall Load Balancing 212777-A, February 2002 n 315 Web OS 10.0 Application Guide 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 13-2 shows a basic FWLB topology: "Dirty" Side of Network "Clean" Side of Network Internal Network Internet Web Switch Web Switch Firewalls Figure 13-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 Web switches: one on the dirty side of the firewalls and one on the clean side. A redirection filter on the dirty-side Web switch splits incoming client traffic into multiple streams. Each stream is routed through a different firewall. The valid client traffic in each stream is forwarded to a virtual server on the clean-side Web switch. The clean-side Web switch uses Server Load Balancing (SLB) settings to select a real server on the internal network for each incoming request. The same process is used for outbound server responses; a redirection filter on the clean-side Web 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 346), the distribution of traffic within each stream is normally based on a mathematical hash of the IP source and destination addresses. This ensures that each client request and its related responses will use the same firewall (a feature known as persistence) and that the streams will be roughly equal in traffic load. Although basic firewall load-balancing techniques can support more firewalls as well as multiple 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 326). 316 n Chapter 13: Firewall Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Basic FWLB Implementation In this example, traffic is load balanced among the available firewalls. "Dirty" Side Web Switch Client 1 10 3 Internet 2 Firewalls 4 9 "Clean" Side Servers Web Switch 5 8 7 6 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 Figure 13-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 Web switch. 2. A redirection filter balances incoming requests among different IP addresses. When the client request arrives at the dirty-side Web 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 Web 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 Web switch using the first firewall 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 firewall, 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. Chapter 13: Firewall Load Balancing 212777-A, February 2002 n 317 Web OS 10.0 Application Guide 4. The firewalls decide if they should allow the packets and, if so, forwards them to a virtual server on the clean-side Web 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 Web switch performs normal SLB functions. Packets forwarded from the firewalls are sent to the original destination address, that is, the virtual server on the clean-side Web 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 Web switch balance responses among different IP addresses. Redirection filters are needed on all ports on the clean-side Web 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 Web 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 Web 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 Web switches intelligently maintain state information, all traffic between specific IP source/destination addresses flows through the same firewall, maintaining session persistence. NOTE – If Network Address Translation (NAT) software is used on the firewalls, FWLB session persistence requires the RTS option to be enabled on the Web switch (see “Free-Metric FWLB” on page 346). 9. The firewall decides if it should allow the packet and, if so, forwards it to the dirty-side Web 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 Web switch and out to the Internet. 10. The client receives the server response. 318 n Chapter 13: Firewall Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide 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 Web switches (one on each side of the firewalls) as shown in Figure 13-4. "Dirty" Side Web Switch 1 IF1: 192.16.12.1 Internet "Clean" Side Firewall 1 Clean Side: Dirty Side: 10.1.3.10 10.1.1.10 2 1 Firewall 2 3 IF2: 10.1.1.1 IF3: 10.1.2.1 Dirty Side: 10.1.2.10 Clean Side: 10.1.4.10 Web Switch 2 IF1: 20.1.1.1 Virtual Server: 20.1.1.10 2 4 3 5 Servers 20.1.1.2 IF2: 10.1.3.1 IF3: 10.1.4.1 20.1.1.3 Figure 13-4 Basic FWLB Example Network Configure the Dirty-Side Web 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. 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. >> >> >> >> >> >> >> >> >> >> >> >> # /cfg/ip/if IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface 1 1# 1# 1# 1# 2# 2# 2# 2# 3# 3# 3# addr 192.16.12.1 mask 255.255.255.0 ena ../if 2 addr 10.1.1.1 mask 255.255.255.0 ena ../if 3 addr 10.1.2.1 mask 255.255.255.0 ena (Select IP interface 1) (Set address for switch management) (Set subnet mask for interface 1) (Enable IP interface 1) (Select IP interface 2) (Set the IP address for interface 2) (Set subnet mask for interface 2) (Enable IP interface 2) (Select IP interface 3) (Set the IP address for interface 3) (Set subnet mask for interface 3) (Enable IP interface 3) Chapter 13: Firewall Load Balancing 212777-A, February 2002 n 319 Web OS 10.0 Application Guide 3. Configure the clean-side IP interface as if they were real servers on the dirty side. Later in this procedure, you’ll configure one clean-side IP interface on a different subnet for each firewall path being load balanced. On the dirty-side Web switch, create two real servers using the IP address of each clean-side IP interface used for FWLB. >> >> >> >> >> >> IP Interface 3# /cfg/slb/real 1 Real server 1# rip 10.1.3.1 Real server 1# ena Real server 1# ../real 2 Real server 2# rip 10.1.4.1 Real server 2# ena (Select real server 1) (Assign clean-side IF 2 address) (Enable real server 1) (Select real server 2) (Assign clean-side IF 3 address) (Enable real server 1) NOTE – Each of the four interfaces used for FWLB (two on each Web switch) in this example must be configured for a different IP subnet. 4. Place the IP interface real servers into a real server group. >> Real server 2# /cfg/slb/group 1 >> Real server group 1# add 1 >> Real server group 1# add 2 5. Set the health check type for the real server group to ICMP. >> Real server group 1# health icmp 6. (Select real server group 1) (Add real server 1 to group 1) (Add real server 2 to group 1) (Select ICMP as health check type) Set the load-balancing metric for the real server group to hash. >> Real server group 1# metric hash (Select SLB hash metric for group 1) 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 maintained for their duration. NOTE – Other load balancing metrics such as leastconns, roundrobin, minmiss, response, and bandwidth can be used when enabling the Return to Sender (RTS) option. For more information, see “Free-Metric FWLB” on page 346. 7. Enable SLB on the switch. >> Real server group 1# /cfg/slb/on 320 n Chapter 13: Firewall Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide 8. Create a filter to allow local subnet traffic on the dirty side of the firewalls to reach the firewall interfaces. >> >> >> >> >> 9. Layer 4# /cfg/slb/filt 10 Filter 10# sip any Filter 10# dip 192.16.12.0 Filter 10# action allow Filter 10# ena (Select filter 10) (From any source IP address) (To this destination IP address) (Allow frames with this DIP address) (Enable filter) 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 Web switch. >> >> >> >> >> >> >> Filter Filter Filter Filter Filter Filter Filter 10# 15# 15# 15# 15# 15# 15# ../filt 15 sip any dip any proto any action redir group 1 ena (Select filter 15) (From any source IP address) (To any destination IP address) (For any protocol) (Perform redirection) (To real server group 1) (Enable the filter) 10. Add filters to the ingress port. >> >> >> >> Filter 15# ../port 1 SLB Port 1# add 10 SLB Port 1# add 15 SLB Port 1# filt ena (Select the ingress port) (Add the filter to the ingress port) (Add the filter to the ingress port) (Enable filtering on the port) 11. 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. >> SLB Port 5# /cfg/ip/route >> IP Static Route# add 10.1.3.1 255.255.255.255 10.1.1.10 >> IP Static Route# add 10.1.4.1 255.255.255.255 10.1.2.10 12. Apply and save the configuration changes. >> # apply >> # save Chapter 13: Firewall Load Balancing 212777-A, February 2002 n 321 Web OS 10.0 Application Guide Configure the Clean-Side Web 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. # /cfg/ip/if IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface 1 1# 1# 1# 1# 2# 2# 2# 2# 3# 3# 3# addr 20.1.1.1 mask 255.255.255.0 ena ../if 2 addr 10.1.3.1 mask 255.255.255.0 ena ../if 3 addr 10.1.4.1 mask 255.255.255.0 ena (Select IP interface 1) (Set the IP address for interface 1) (Set subnet mask for interface 1) (Enable IP interface 1) (Select IP interface 2) (Set the IP address for interface 2) (Set subnet mask for interface 2) (Enable IP interface 2) (Select IP interface 3) (Set the IP address for interface 3) (Set subnet mask for interface 3) (Enable IP interface 3) 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 firewall path being load balanced. Create two real servers on the clean-side switch, using the IP address of each dirty-side IP interface. >> >> >> >> >> >> IP Interface 5# /cfg/slb/real 1 Real server 1# rip 10.1.1.1 Real server 1# ena Real server 1# ../real 2 Real server 2# rip 10.1.2.1 Real server 2# ena (Select real server 1) (Assign dirty-side IF 1 address) (Enable real server 1) (Select real server 2) (Assign dirty-side IF 2 address) (Enable real server 2) NOTE – Each of the four IP interfaces (two on each Web switch) in this example must be configured for a different IP subnet. 3. Place the real servers into a real server group. >> Real server 2# ../group 1 >> Real server group 1# add 1 >> Real server group 1# add 2 322 n (Select real server group 1) (Select real server 1 to group 1) (Select real server 2 to group 1) Chapter 13: Firewall Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide 4. Set the health check type for the real server group to ICMP. >> Real server group 1# health icmp 5. (Select ICMP as health check type) Set the load-balancing metric for the real server group to hash. >> Real server group 1# metric hash (Select SLB hash metric for group 1) NOTE – The clean-side Web switch must use the same metric as defined on the dirty side. 6. Enable server load balancing on the switch. >> Real server group 1# /cfg/slb/on 7. Configure ports 2 and 3, which are connected to the clean-side of the firewalls, for client processing. >> >> >> >> 8. Real server SLB port 2# SLB port 3# SLB port 3# group 1# ../port 2/client ena(Enable client processing on port 2) ../port 3/client ena (Enable client processing on port 3) apply (Apply the configuration) save (Save the configuration) Configure the virtual server that will load balance the real servers. >> SLB port 3# ../virt 100 >> Virtual Server 100# vip 20.1.1.10 >> Virtual Server 100# ena 9. (Configure virtual server 100) (Assign virtual server 100 IP address) (Enable the virtual server) Configure the real servers to which traffic will be load-balanced. These are the real servers on the network. >> >> >> >> >> Real Real Real Real Real server server server server server group 1# /cfg/slb/real/2 2 # rip 20.1.1.2 2 # ena 2 # ../real 3 3 # rip 20.1.1.3 (Select real server 2) (Assign real server 2 IP address) (Enable real server 2) (Select real server 3) (Assign real server 3 IP address) Chapter 13: Firewall Load Balancing 212777-A, February 2002 n 323 Web OS 10.0 Application Guide 10. Place the real servers into a real server group. >> Real server 3# ../group 200 >> Real server group 200# add 2 >> Real server group 200# add 3 (Select real server group 1) (Select real server 2 to group 200) (Select real server 3 to group 200) 11. Configure ports 4 and 5, which are connected to the real servers, for server processing. >> Real server group 200# ../port 4/server ena >> SLB port 4# ../port 5/server ena 12. Enable server load balancing on the switch. >> Real server group 1# /cfg/slb/on 13. Create a filter to prevent server-to-server traffic from being redirected. >> >> >> >> >> >> >> Layer 4# /cfg/slb/filt 10 Filter 10# sip any Filter 10# dip 20.1.1.0 Filter 10# dmask 255.255.255.0 Filter 10# proto any Filter 10# action allow Filter 10# ena (Select filter 10) (From any source IP address) (To base IP address for IF 5) (For the range of addresses) (For any protocol) (Allow traffic) (Enable the filter) 14. Create the redirection 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. >> >> >> >> >> >> >> 324 n Filter Filter Filter Filter Filter Filter Filter 10# 15# 15# 15# 15# 15# 15# ../filt 15 sip any dip any proto any action redir group 1 ena (Select filter 15) (From any source IP address) (To any destination IP address) (For any protocol) (Perform redirection) (To real server group 1) (Enable the filter) Chapter 13: Firewall Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide 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 Web switch. Ingress ports are any that attach to real servers or internal clients on the clean-side of the network. In this case, two real servers are attached to the clean-side Web switch on port 4 and port 5. >> >> >> >> >> >> >> >> Filter 15# ../port 4 SLB Port 4# add 10 SLB Port 4# add 15 SLB Port 4# filt ena SLB Port 4# ../port 5 SLB Port 5# add 10 SLB Port 5# add 15 SLB Port 5# filt ena (Select ingress port 4) (Add the filter to the ingress port) (Add the filter to the ingress port) (Enable filtering on the port) (Select ingress port 5) (Add the filter to the ingress port) (Add the filter to the ingress port) (Enable filtering on the port) 16. 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. >> SLB Port 5# /cfg/ip/route >> IP Static Route# add 10.1.1.1 255.255.255.255 10.1.3.10 >> IP Static Route# add 10.1.2.1 255.255.255.255 10.1.4.10 NOTE – Configuring static routes for FWLB does not require IP forwarding to be turned on. 17. Apply and save the configuration changes. >> # apply >> # save Chapter 13: Firewall Load Balancing 212777-A, February 2002 n 325 Web OS 10.0 Application Guide Four-Subnet FWLB The four-subnet FWLB method is often deployed in large networks that require high-availability solutions. This method uses filtering, static routing, and Virtual Router Redundancy Protocol (VRRP) to provide parallel firewall operation between redundant Web switches. Figure 13-5 shows one possible network topology using the four-subnet method: Dirty Side Subnet 1 Clean Side Subnet 2 Subnet 3 Primary Subnet 4 Primary Internet Routers Simple Switches Secondary Web Switch Firewalls Secondary Web Switch Simple Switches Servers Figure 13-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. Normally the interswitch link between the primary and secondary Web switches is configured on port 9 of the Web switch. However, the interswitch links may trunked together with multiple ports for additional protection from failure. NOTE – Other topologies that use internal hubs, or diagonal cross-connections between the Web 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 Web OS FWLB white papers, but are not within the scope of this manual. 326 n Chapter 13: Firewall Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide As shown in Figure 13-5, the network is divided into four sections: n Subnet 1 includes all equipment between the exterior routers and dirty-side Web switches. n Subnet 2 includes the dirty-side Web switches with their interswitch link, and dirty-side firewall interfaces. n Subnet 3 includes the clean-side firewall interfaces, and clean-side Web switches with their interswitch link. n Subnet 4 includes all equipment between the clean-side Web switches and their servers. In this network, external traffic arrives through both routers. Since VRRP is enabled, one of the dirty-side Web switches acts as primary and receives all traffic. The dirty-side primary Web switch performs FWLB in a fashion similar to basic FWLB: a redirection filter splits traffic into multiple streams which are routed through the available firewalls to the primary clean-side Web 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 configuring an additional Return to Sender (RTS) option (see “Free-Metric FWLB” on page 346). Four-Subnet FWLB Implementation In this example, traffic between the redundant Web switches is load balanced among the available firewalls. Dirty Side Subnet 1 Subnet 2 Subnet 3 Primary Clean Side Subnet 4 Primary 3 2 1 Internet Routers Simple Switches Secondary Web Switch Firewalls Secondary Web Switch Simple Switches Servers 1. VRRP forces incoming traffic to converge on primary dirty-side Web switch 2. Firewall load balancing occurs between primary Web switches 3. Primary clean-side Web switch performs standard SLB Figure 13-6 Four-Subnet FWLB Process Chapter 13: Firewall Load Balancing 212777-A, February 2002 n 327 Web OS 10.0 Application Guide 1. Incoming traffic converges on the primary dirty-side Web switch. External traffic arrives through redundant routers. A set of interconnected switches ensures that both routers have a path to each dirty-side Web switch. VRRP is configured on each dirty-side Web switch so that one acts as the primary routing switch. If the primary fails, the secondary takes over. 2. FWLB is performed between primary Web switches. Just as with basic FWLB, filters on the ingress ports of the dirty-side Web switch redirect 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 Web switch through a different firewall. Although other load balancing metrics can be used in some configurations (see “Free-Metric FWLB” on page 346), 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. 3. The primary clean-side Web switch forwards the traffic to its destination. Once traffic arrives at the primary clean-side Web switch, it is forwarded to its destination. In this example, the Web 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 Web switch splits the traffic, and static routes forward each response stream back through the same firewall that forwarded the original request. 328 n Chapter 13: Firewall Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Configuring Four-Subnet FWLB An example network for four-subnet FWLB is illustrated in Figure 13-7. While other complex topologies are possible, this example assumes a high-availability network using block (rather than diagonal) interconnections between switches. Dirty Side Subnet 1 (VLAN 1): 195.1.1.0/24 Clean Side Subnet 2 (VLAN 2): 10.10.2.0/24 Web Switch #1 IF1: 195.1.1.10 IF2: 10.10.2.1 IF3: 10.10.2.2/32 Subnet 3 (VLAN 3): 10.10.3.0/24 Web Switch #3 IF1: 10.10.4.10 IF2: 10.10.3.1 IF3: 10.10.3.2/32 VIP: 10.10.4.100 Firewall #1 Dirty: 10.10.2.3 Clean: 10.10.3.3 Router 195.1.1.1 1 Internet Subnet 4 (VLAN 4): 10.10.4.0/24 2 3 4 10.10.4.20 9 9 VIR VIR 195.1.1.9 10.10.2.9 VIR VIR 10.10.3.9 10.10.4.9 9 9 10.10.4.21 1 2 3 4 Router 195.1.1.2 Web Switch #2 IF1: 195.1.1.11 IF2: 10.10.2.11 IF3: 10.10.2.12/32 Firewall #2 Dirty: 10.10.2.4 Clean: 10.10.3.4 Web Switch #4 IF1: 10.10.4.11 IF2: 10.10.3.11 IF3: 10.10.3.12/32 VIP: 10.10.4.100 10.10.4.22 Figure 13-7 Four-Subnet FWLB Example Network NOTE – The port designations of both dirty-side Web switches are identical, as are the port designations of both clean-side Web switches. This simplifies configuration by allowing you to synchronize each primary Web switch’s configuration with the secondary. Four-subnet FWLB configuration is summarized as follows: n Configure routers and firewalls and test them for proper operation. n Configure VLANs, IP interfaces, and static routes on all Web switches and test them. n Configure secondary web switches with VRRP support settings. n Configure FWLB groups and redirection filters on the primary dirty-side Web switch. n Configure and synchronize VRRP on the primary dirty-side Web switch. n Configure FWLB and SLB groups, and add FWLB redirection filters on the primary clean-side Web switch. n Configure VRRP on the primary clean-side Web switch and synchronize the secondary. These steps are explained in detail in the following sections. Chapter 13: Firewall Load Balancing 212777-A, February 2002 n 329 Web OS 10.0 Application Guide 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 Web 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 Web switch Virtual Interface Router (VIR), which is in the same subnet as the routers: Route Added: 10.10.4.100 (to clean-side virtual server) via 195.1.1.9 (Subnet 1 VIR) Configure the Firewalls Before you configure the Web switches, the firewalls must be properly configured. For incoming traffic, each firewall must be configured with a static route to the clean-side virtual server, using the VIR in its clean-side subnet as the next hop. For outbound traffic, each firewall must use the VIR in its dirty-side subnet as the default gateway. In this example, the firewalls are configured with the following IP addresses: Table 2 Four-Subnet Firewall IP Address Configuration Item Address Firewall 1 Dirty-side IP interface Clean-side IP interface Default 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) 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. 330 n Chapter 13: Firewall Load Balancing 212777-A, February 2002 Web OS 10.0 Application Guide Configure Connectivity for the Primary Dirty-Side Web Switch 1. Configure VLANs on the primary dirty-side Web switch. Two VLANs are required. VLAN 1 includes port 1, for the Internet connection. VLAN 2 includes port 2, for the firewall connection, and port 9, for the interswitch connection. >> >> >> >> # # # # /cfg/vlan 2 add 2 add 9 ena (Port 2 connects to the firewall) (Port 9 is the inter-switch connection) NOTE – Port 1 is part of VLAN 1 by default and does not require manual configuration. 2. Configure IP interfaces on the primary dirty-side Web switch. Three IP interfaces (IF’s) are used. IF 1 is on placed on Subnet 1. IF 2 will be used for routing traffic through the top firewall. IF 3 will be used for routing traffic through the lower firewall. To avoid confusion, IF 2 and IF 3 will be used in the same way on all Web switches. >> >> >> >> >> >> >> >> >> >> >> >> >> >> # # # # # # # # # # # # # # /cfg/ip/if 1 mask 255.255.255.0 addr 195.1.1.10 ena ../if 2 mask 255.255.255.0 addr 10.10.2.1 vlan 2 ena ../if 3 mask 255.255.255.255 addr 10.10.2.2 vlan 2 ena NOTE – By configuring the IP interface mask prior to the IP address, the broadcast address is automatically calculated. Also, only the first IP interface in a given subnet is given the full subnet range mask. Subsequent IP interfaces (such as IF 3) are given individual masks. 3. Turn Spanning Tree Protocol (STP) off for the primary dirty-side Web switch. >> # /cfg/stp/off Chapter 13: Firewall Load Balancing 212777-A, February 2002 n 331 Web OS 10.0 Application Guide 4. Configure static routes on the primary dirty-side Web switch. Four static routes are required: n To primary clean-side IF 2 via Firewall 1 using dirty-side IF 2 n To primary clean-side IF 3 via Firewall 2 using dirty-side IF 3 n To secondary clean-side IF 2 via Firewall 1 using dirty-side IF 2 n To secondary clean-side IF 3 via Firewall 2 using dirty-side IF 3 NOTE – Remember, IF 2 is being used on all Web switches whenever routing through the top firewall, and IF 3 is being used on all Web switches whenever routing through the lower firewall. The static route add command uses the following format: add
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.3 Linearized : Yes Encryption : Standard V1.2 (40-bit) User Access : Print, Copy, Annotate, Fill forms, Extract, Assemble, Print high-res Producer : Acrobat Distiller 4.05 for Windows Title : Web OS 10.0 Application Guide Modify Date : 2002:02:01 19:08:47-08:00 Create Date : 2002:02:01 14:52:07 Creator : FrameMaker 6.0 Author : Nortel Networks Page Count : 482 Page Mode : UseOutlinesEXIF Metadata provided by EXIF.tools