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.
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.
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 Agen
Web OS 10.
Web OS 10.
Web OS 10.
Web OS 10.
Web OS 10.
Web OS 10.
Web OS 10.
Web OS 10.
Web OS 10.
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 Im
Web OS 10.
Web OS 10.
Web OS 10.
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: Rea
Web OS 10.
New Features The following table lists the new features in Web OS 10.
Web OS 10.
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.
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.
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.
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.
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.
Web OS 10.
CHAPTER 1 Basic IP Routing This chapter provides configuration background and examples for using the Alteon Web switch to perform IP routing functions.
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.
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.
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.
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.
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 ..
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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).
Web OS 10.
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.
Web OS 10.
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.
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.
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.
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.
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.
Web OS 10.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Web OS 10.0 Application Guide Port Trunking Example In the example below, three ports will be trunked between two Alteon Web switches.
Web OS 10.0 Application Guide 3. Repeat the process on Web switch 2.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 # ..
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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 # ..
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.
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 # ..
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 # ..
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.
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.
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).
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.
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.
Web OS 10.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
Web OS 10.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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# ..
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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 ..
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.
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.
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.
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.
Web OS 10.
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.
Web OS 10.
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.
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.
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 ..
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
Web OS 10.
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.
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.
Web OS 10.
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.
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.
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.
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.
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.
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.
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.
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.
Web OS 10.0 Application Guide In Figure 7-5, the default filter 224 configured for Any is applied for all other connection requests.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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# ..
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.
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.
Web OS 10.0 Application Guide 3. Configure an RTSP redirection filter to cache data and balance the load among the cache servers. >> >> >> >> >> >> >> >> 4.
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.
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.
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.
Web OS 10.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Web OS 10.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Web OS 10.0 Application Guide High Availability Configurations Alteon Web switches offer flexibility in implementing redundant configurations.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Web OS 10.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Web OS 10.
CHAPTER 12 Global Server Load Balancing This chapter provides information for configuring Global Server Load Balancing (GSLB) across multiple geographic sites.
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.
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.
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.
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.
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.
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.
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.
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# ..
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.
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.
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.
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# ..
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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# ..
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.
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.
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.
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.
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# ..
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.
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.
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.
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.
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.
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.
Web OS 10.0 Application Guide 4. Configure static routes on the primary dirty-side Web switch.
Web OS 10.0 Application Guide Configure Connectivity for the Secondary Dirty-Side Web Switch Except for the IP interfaces, this configuration is identical to the primary dirty-side Web switch. 1. Configure VLANs on the secondary dirty-side Web switch. >> >> >> >> 2. /cfg/vlan 2 add 2 add 9 ena Configure IP interfaces on the secondary dirty-side Web switch. >> >> >> >> >> >> >> >> >> >> >> >> >> >> 3. # # # # # # # # # # # # # # # # # # /cfg/ip/if 1 mask 255.255.255.0 addr 195.1.1.11 ena ..
Web OS 10.0 Application Guide Configure Connectivity for the Primary Clean-Side Web Switch 1. Configure VLANs on the primary clean-side Web switch. Two VLANs are required. VLAN 3 includes the firewall port and interswitch connection port. VLAN 4 includes the port that attaches to the real servers. >> >> >> >> >> >> >> 2. /cfg/vlan 3 add 3 add 9 ena ../vlan 4 add 4 ena Configure IP interfaces on the primary clean-side Web switch. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 3.
Web OS 10.0 Application Guide 4. Configure static routes on the primary clean-side Web switch. Four static routes are needed: n To primary dirty-side IF 2 via Firewall 1 using clean-side IF 2 n To primary dirty-side IF 3 via Firewall 2 using clean-side IF 3 n To secondary dirty-side IF 2 via Firewall 1 using clean-side IF 2 n To secondary dirty-side IF 3 via Firewall 2 using clean-side IF 3 Again, the static route add command uses the following format: add
Web OS 10.0 Application Guide 2. Configure IP interfaces on the secondary clean-side Web switch. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 3. # # # # # # # # # # # # # # # /cfg/ip/if 1 mask 255.255.255.0 addr 10.10.4.11 vlan 4 ena ../if 2 mask 255.255.255.0 addr 10.10.3.11 vlan 3 ena ../if 3 mask 255.255.255.255 addr 10.10.3.12 vlan 3 ena Turn STP off for the secondary clean-side Web switch. >> # /cfg/stp/off 4. Configure static routes on the secondary clean-side Web switch. >> >> >> >> >> 5.
Web OS 10.0 Application Guide Verify Proper Connectivity To verify proper configuration up to this point, use the ping option to test network connectivity. At each Web switch, you should receive a valid response when pinging the destination addresses established in the static routes. For example, on the secondary clean-side Web switch, the following commands should receive a valid response: >> # ping Response; >> # ping Response; >> # ping Response; >> # ping Response; 10.10.2.1 10.10.2.
Web OS 10.0 Application Guide Complete the Configuration of the Primary Dirty-Side Web Switch 1. Create an FWLB real server group on the primary dirty-side Web switch. A real server group is used as the target for the FWLB redirection filter. Each IP address that is assigned to the group represents a path through a different firewall. In this case, since two firewalls are used, two addresses are added to the group.
Web OS 10.0 Application Guide 2. Create the FWLB filters. Three filters are required on the port attaching to the routers: n Filter 10 prevents local traffic from being redirected. n Filter 20 prevents VRRP traffic (and other multicast traffic on the reserved 224.0.0.0/24 network) from being redirected. n Filter 224 redirects the remaining traffic to the firewall group. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> # # # # # # # # # # # # # # # # # /cfg/slb/filt 10 dip 195.1.1.0 dmask 255.
Web OS 10.0 Application Guide 3. Configure VRRP on the primary dirty-side Web switch. VRRP in this example requires two virtual routers–one for the subnet attached to the routers, and one for the subnet attached to the firewalls. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 4. /cfg/vrrp on vr 1 vrid 1 addr 195.1.1.9 if 1 prio 101 share dis ena track ifs ena ports ena /cfg/vrrp/vr 2 vrid 2 addr 10.10.2.
Web OS 10.0 Application Guide Complete the Configuration of the Primary Clean-Side Web Switch 1. Create an FWLB real server group on the primary clean-side Web switch. A real server group is used as the target for the FWLB redirection filter. Each IP address assigned to the group represents a return path through a different firewall. In this case, since two firewalls are used, two addresses are added to the group.
Web OS 10.0 Application Guide 2. Create an SLB real server group on the primary clean-side Web switch, to which traffic will be load-balanced. The external clients intend to connect to HTTP services at a publicly advertised IP address. The servers on this network are load balanced by a virtual server on the clean-side Web switch. SLB options are configured as follows: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> # # # # # # # # # # # # # # # /cfg/slb real 20 rip 10.10.4.20 ena ../real 21 rip 10.10.4.
Web OS 10.0 Application Guide 3. Create the FWLB filters on the primary clean-side Web switch. Three filters are required on the port attaching to the real servers: n Filter 10 prevents local traffic from being redirected. n Filter 20 prevents VRRP traffic from being redirected. n Filter 224 redirects the remaining traffic to the firewall group. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> # # # # # # # # # # # # # # # # # /cfg/slb/filt 10 dip 10.10.4.0 dmask 255.255.255.0 ena ..
Web OS 10.0 Application Guide 4. Configure VRRP on the primary clean-side Web switch. VRRP in this example requires two virtual routers to be configured–one for the subnet attached to the real servers, and one for the subnet attached to the firewalls. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> # # # # # # # # # # # # # # # # # # # # # # /cfg/vrrp on vr 1 vrid 3 addr 10.10.4.9 if 1 prio 100 share dis ena track ifs ena ports ena /cfg/vrrp/vr 2 vrid 4 addr 10.10.3.
Web OS 10.0 Application Guide 5. Configure the peer on the primary clean-side Web switch. >> >> >> >> >> 6. # # # # # /cfg/slb/sync prios d peer 1 ena addr 10.10.4.11 Apply and save your configuration changes. >> # apply >> # save 7. Synchronize primary and secondary dirty-side Web switches.
Web OS 10.0 Application Guide Advanced FWLB Concepts Free-Metric FWLB Free-metric FWLB allows to you use load-balancing metrics other than hash, such as leastconns, roundrobin, minmiss, response, and bandwidth for more versatile FWLB. The free-metric method uses the Return to Sender (RTS) option. RTS can be used with basic FWLB or four-subnet FWLB networks. Free-Metric with Basic FWLB For this example, review the basic FWLB example network. "Dirty" Side Web Switch 1 IF1: 192.16.12.
Web OS 10.0 Application Guide 3. On the dirty-side Web switch, set the FWLB metric. >> # ../group 1 >> # metric Any of the following load-balancing metrics can be used: hash, leastconns, roundrobin, minmiss, response, and bandwidth. See “Metrics for Real Server Groups” on page 131 for details on using each metric. NOTE – Some metrics allow other options (such as weights) to be configured. Free-Metric with Four-Subnet FWLB For this example, review the four-subnet example network.
Web OS 10.0 Application Guide To use free-metric FWLB in this network, the following configuration changes are necessary. 1. On the clean-side Web switches, enable RTS on the ports attached to the firewalls (port 3) and on the interswitch port (port 9). On both clean-side switches: >> # /cfg/slb/port 3/rts enable >> # ../port 9/rts enable 2. On the clean-side Web switches, remove the redirection filter from the ports attached to the real servers (ports 4), but make sure filter processing is enabled.
Web OS 10.0 Application Guide Adding a Demilitarized Zone (DMZ) Implementing a DMZ in conjunction with firewall load balancing enables the Web switch to do the traffic filtering, off-loading this task from the firewall. A DMZ is created by configuring FWLB with another real server group and a redirection filter towards the DMZ subnets. The DMZ servers can be connected to the Web switch on the dirty side of the firewall. A typical firewall load balancing configuration with a DMZ is shown in Figure 13-10.
Web OS 10.0 Application Guide You could add the filters required for the DMZ (to each Web switch) as follows: 1. On the dirty-side Web switch, create the filter to allow HTTP traffic to reach the DMZ Web servers. In this example, the DMZ Web servers use IP addresses 205.178.29.0/24. >> >> >> >> >> >> >> >> >> 2. # /cfg/slb/filt 80 Filter 80# sip any Filter 80# dip 205.178.29.0 Filter 80# dmask 255.255.255.
Web OS 10.0 Application Guide Firewall Health Checks Basic FWLB health checking is automatic. No special configuration is necessary unless you wish to tune the health checking parameters. See Chapter 10, “Health Checking” for details. Firewall Service Monitoring To maintain high availability, Web switches monitor firewall health status and send packets only to healthy firewalls. There are two methods of firewall service monitoring: ICMP and HTTP.
Web OS 10.0 Application Guide Using HTTP Health Checks For those firewalls that do not permit ICMP pings to pass through, Web switches can be configured to perform HTTP health checks, as described below. 1. Set the health check type to HTTP instead of ICMP. >> # /cfg/slb/group 1/health http 2.
CHAPTER 14 Virtual Private Network Load Balancing The VPN (Virtual Private Network) load balancing feature in Web OS 10.0 allows the switch to load balance simultaneously up to 255 VPN devices. The switch records from which VPN server a session was initiated and ensures that the traffic returns back to the same VPN server from which the session started.
Web OS 10.0 Application Guide Overview Virtual Private Networks A VPN is a connection that has the appearance and advantages of a dedicated link, but it occurs over a shared network. Using a technique called tunneling, data packets are transmitted across a routed network, such as the Internet, in a private tunnel that simulates a point-to-point connection. This approach enables network traffic from many sources to travel via separate tunnels across the infrastructure.
Web OS 10.0 Application Guide Figure 14-1 Basic Network Frame Flow and Operation The basic steps that occur at the switches when a request arrives from the Internet are described below: 1. The user prepares to send traffic to the destination server. 2. The VPN client software encrypts the packet and sends it to the cluster IP address of the VPN devices. 3. Switch 1 (SW1) makes an entry in the session table and forwards the packet to VPN device 1.
Web OS 10.0 Application Guide VPN Load-Balancing Configuration Requirements n Configure the switch with firewall load balancing. For more information, see “Firewall Load Balancing” on page 313. n Enable the Return to Sender (RTS) feature on the ports attached to the VPN devices, using the following command: >> # /cfg/slb/port /rts ena VPN Load-Balancing Configuration Example The following example uses Alteon Web switches for VPN load balancing.
Web OS 10.0 Application Guide Configure the First Clean-Side Switch (CA) 1. Turn off BOOTP. >> # /cfg/sys/bootp dis 2. Define and enable VLAN 2 for ports 7, and 8. >> # /cfg/vlan 2/ena/def 7 8 3. Turn off Spanning Tree Protocol (STP). >> # /cfg/stp/off 4. Define the clean-side IP interfaces. Create one clean-side IP interface on a different subnet for each VPN device being load balanced. 5. >> >> >> >> # /cfg/ip/if IP Interface IP Interface IP Interface 1/ena 1# mask 255.255.255.0 1# addr 30.0.
Web OS 10.0 Application Guide One static route is required for each VPN device being load balanced. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 6. n add 10.0.0.10 255.255.255.255 20.0.0.101 2 add 10.0.0.11 255.255.255.255 20.0.0.102 3 add 10.0.0.20 255.255.255.255 20.0.0.101 2 add 10.0.0.21 255.255.255.255 20.0.0.
Web OS 10.0 Application Guide 7. Enable Server Load Balancing (SLB) on the first clean switch. >> # /cfg/slb/on 8. Configure real servers for health checking VPN devices. >> >> >> >> >> >> >> >> 9. # /cfg/slb/real Real server 1 # Real server 1 # Real server 2 # Real server 2 # Real server 3 # Real server 3 # Real server 4 # 1/ena rip 10.0.0.10 ../real 2/ena rip 10.0.0.11 ../real 3/ena rip 10.0.0.20 ../real 4/ena rip 10.0.0.
Web OS 10.0 Application Guide Configure the Second Clean-Side Switch (CB) 1. Turn off bootp. >> # /cfg/sys/bootp dis 2. Define and enable VLAN 2 for ports 7 and 8. >> # /cfg/vlan 2/ena/def 7 8 3. Turn off Spanning Tree Protocol. >> # /cfg/stp/off 4. Define the clean-side IP interfaces. Create one clean-side IP interface on a different subnet for each VPN device being load balanced. >> # /cfg/ip/if 1/ena/mask 255.255.255.0/addr 30.0.0.11 >> # /cfg/ip/if 2/ena/mask 255.255.255.0/addr 20.0.0.
Web OS 10.0 Application Guide 6. Configure Virtual Router Redundancy Protocol (VRRP) for virtual routers 1 and 2. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 7. # /cfg/vrrp/on Virtual Router Redundancy Protocol# vr 1 VRRP Virtual Router 1# ena VRRP Virtual Router 1# vrid 1 VRRP Virtual Router 1# if 1 VRRP Virtual Router 1# addr 30.0.0.
Web OS 10.0 Application Guide 11. Enable filter processing on the server ports so that the response from the real server will be looked up in VPN session table. >> SLB port 8# ../port 1/filter ena 12. Apply and save the configuration, and reboot the switch. >> SLB port 8# apply >> SLB port 8# save >> SLB port 8# /boot/reset Configure the First Dirty-Side WebSwitch (DA) 1. Turn off BOOTP. >> # /cfg/sys/bootp dis 2. Define and enable VLAN 2 for ports 7 and 8. >> # /cfg/vlan 2/ena/def 7 8 3.
Web OS 10.0 Application Guide 6. Configure VRRP for virtual routers 1 and 2. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 7. # /cfg/vrrp/on Virtual Router Redundancy Protocol# /cfg/vrrp/vr 1 VRRP Virtual Router 1# ena VRRP Virtual Router 1# vrid 1 VRRP Virtual Router 1# if 1 VRRP Virtual Router 1# prio 101 VRRP Virtual Router 1# addr 192.168.10.
Web OS 10.0 Application Guide 10. Configure the filters to allow local subnet traffic on the dirty side of the VPN device to reach the VPN device interfaces. >> >> >> >> >> >> >> >> >> >> # # # # # # # # # # ../filt 100 ena sip any dip 192.168.10.0/dmask 255.255.255.0 action allow ../filt 110 ena sip any dip 224.0.0.0/dmask 255.0.0.0 action allow 11. Create a filter to allow the management firewall (Policy Server) to reach the VPN firewall. >> >> >> >> >> # # # # # ../filt 120 ena sip 192.168.10.
Web OS 10.0 Application Guide Configure the Second Dirty-Side WebSwitch (DB) 1. Turn off BOOTP. >> # /cfg/sys/bootp dis 2. Define and enable VLAN 2 for ports 7 and 8. >> # /cfg/vlan 2/ena/def 7 8 3. Turn off STP. >> # /cfg/stp/off 4. Configure IP interfaces 1, 2, and 3. >> # /cfg/ip/if 1/ena/mask 255.255.255.0/addr 192.168.10.11 >> # /cfg/ip/if 2/ena/mask 255.255.255.0/addr 10.0.0.20/vl 2 >> # /cfg/ip/if 3/ena/mask 255.255.255.255/addr 10.0.0.21/vl 2 5.
Web OS 10.0 Application Guide 6. Configure VRRP for virtual routers 1 and 2. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 7. # # # # # # # # # # # # # # # # # # # /cfg/vrrp/on /cfg/vrrp/vr 1 ena vrid 1 if 1 addr 192.168.10.50 share dis track vrs ena ports ena /cfg/vrrp/vr 2 ena vrid 2 if 2 addr 10.0.0.1 share dis track vrs ena ports ena Enable SLB. >> # /cfg/slb/on 8. Configure real servers for health checking VPN devices. >> >> >> >> 9.
Web OS 10.0 Application Guide 10. Configure the filters to allow local subnet traffic on the dirty side of the VPN device to reach the VPN device interfaces. >> >> >> >> >> >> >> >> # # # # # # # # /cfg/slb/filt 100 ena sip any dip 192.168.10.0/dmask 255.255.255.0 ../filt 110 ena sip any dip 224.0.0.0/dmask 255.0.0.0 11. Create the redirection filter and enable firewall load balancing. This filter will redirect inbound traffic, among the defined real servers in the group.
Web OS 10.0 Application Guide Test Configurations and General Topology The switches should be able to health check each other, and all switches should see four real servers up. (Rules on the VPN devices permit this—see Figure 14-3 on page 368.) Figure 14-3 Checkpoint Rules for Both VPN Devices as Seen in the Policy Editor 1. Disconnect the cables (cause failures) to change the available servers that are up. >> # /info/slb/dump (Verify which servers are up) This should change the VRRP preferences.
Web OS 10.0 Application Guide Test the VPN 1. Launch the SecuRemote client on the dirty side of the network. 2. Add a new site. 3. Enter the policy server IP address: 192.168.10.120. You have the option of adding a nickname. 4. Launch a browser (such as Netscape or Internet Explorer) and go to http://30.0.0.100 5. You will be asked to authenticate yourself. 6. Enter vpnuser for user name and alteon for the password.
Web OS 10.0 Application Guide 7. You will see a message verifying that you were authenticated. 8. Browse to the Web site. If there are other services running on other servers in the internal network, you should also be able to reach those services. All of this traffic is traveling over the VPN and is being decrypted at the VPN device. You can verify which VPN device is being used by looking at the Log Viewer. You should also be able to see the client authentication as well as the decrypted traffic.
CHAPTER 15 Content Intelligent Switching This chapter discusses advanced load balancing solutions utilizing Layer 7 content switching.
Web OS 10.0 Application Guide Overview Alteon Web switches performs content intelligent switching by processing numerous tasks for each incoming session, including connection setup, traffic parsing, applying server selection algorithms, splicing connections and translating session addresses, metering and controlling server bandwidth usage, processing traffic filters, collecting statistics, and so on. Figure 15-1 illustrates the process of content intelligent switching in the Web switch. 2.
Web OS 10.0 Application Guide Parsing Content Examining session content places heavier demands upon the Web switch than examining TCP/IP headers for the following reasons: n Content is non-deterministic. Content identifiers such as URLs and cookies can be of varying lengths and can appear at unpredictable locations within a request. Scanning session traffic for a specific string is far more processor-intensive than looking at a known location in a session for a specific number of bytes.
Web OS 10.0 Application Guide HTTP Header Inspection Content intelligent switching is performed by inspecting HTTP headers. HTTP headers include additional information about requests and responses. The HTTP 1.1 specification defines a total of 46 headers. For Web Cache Redirection, at any given time one HTTP header is supported globally for the entire switch. HTTP headers can be general, request, response, or entity headers. General headers may exist in both requests and responses.
Web OS 10.0 Application Guide Content Intelligent Server Load Balancing Web OS allows you to load balance HTTP requests based on different HTTP header information, such as “Cookie:” header for persistent load balancing, “Host:” header for virtual hosting, or “User-Agent” for browser-smart load balancing.
Web OS 10.0 Application Guide String matching for: images /product .gif .jpg GET/www.foo.com/images/abc.gif 2 GET/www.foo.com/event/reg.bin 1 GET/www.foo.com/product/abc.html 4 Alteon Web Switch 3 5 6 In groups with multiple servers, traffic is distributed within the group via standard SLB metric or URL hashing String matching for: /product .cgi .bin .exe String matching for: /product .
Web OS 10.0 Application Guide 2. Define the string(s) to be used for URL load balancing. >> # /cfg/slb/layer7/slb/add|rem n add: Add string or a path. n rem: Remove string or a path. A default string “any” indicates that the particular server can handle all URL or Web-cache requests.
Web OS 10.0 Application Guide 3. Apply and save your configuration changes. 4. Identify the defined string IDs. >> # /cfg/slb/layer7/slb/cur For easy configuration and identification, each defined string has an ID attached, as shown in the following example: Number of entries: six ID SLB String 1 any 2 .gif 3 /sales 4 /xitami 5 /manual 6 .jpg 5. Configure one or more real servers to support URL-based load balancing. 6.
Web OS 10.0 Application Guide 7. Enable SLB on the switch. (Turn SLB on) >> # /cfg/slb/on 8. Enable DAM on the switch or configure a proxy IP address on the client port. n To turn on DAM: >> # /cfg/slb/adv/direct ena n To turn off DAM and configure a proxy IP address on the client port: >> # /cfg/slb/direct dis >> # port 2/pip 12.12.12.
Web OS 10.0 Application Guide Virtual Hosting Web OS allows individuals and companies to have a presence on the Internet in the form of a dedicated Web site address. For example, you can have a “www.site-a.com” and “www.siteb.com” instead of “www.hostsite.com/site-a” and “www.hostsite.com/site-b.” Service providers, on the other hand, do not want to deplete the pool of unique IP addresses by dedicating an individual IP address for each home page they host. By supporting an extension in HTTP 1.
Web OS 10.0 Application Guide Virtual Hosting Configuration Overview The sequence of events for configuring virtual hosting based on HTTP Host: headers is described below: 1. The network administrator defines a domain name as part of the 128 supported URL strings. Both domain names “www.company-a.com” and “www.company-b.com” resolve to the same IP address. In this example, the IP address is for a virtual server on the switch. 2. “www.company-a.com” and “www.company-b.com” are defined as URL strings. 3.
Web OS 10.0 Application Guide Configuring the “Host” Header for Virtual Hosting To support virtual hosting, configure the switch for Host header-based load balancing with the following procedure: 1. Before you can configure header-based server load balancing, ensure that the switch has already been configured for basic SLB with the following tasks: n Assign an IP address to each of the real servers in the server pool. n Define an IP interface on the switch. n Define each real server.
Web OS 10.0 Application Guide Cookie-Based Preferential Load Balancing Cookies can be used to provide preferential services for customers, ensuring that certain users are offered better access to resources than other users when site resources are scarce. For example, a Web server could authenticate a user via a password and then set cookies to identify them as “Gold,” “Silver,” or “Bronze” customers.
Web OS 10.0 Application Guide Configuring Cookie-Based Preferential Load Balancing To configure cookie-based preferential load balancing, perform the following procedure. 1. Before you can configure header-based load balancing, ensure that the switch has already been configured for basic SLB with the following tasks: n Assign an IP address to each of the real servers in the server pool. n Define an IP interface on the switch. n Define each real server. n Assign servers to real server groups.
Web OS 10.0 Application Guide Example: n Real Server 1: “Gold” handles gold requests. n Real Server 2: “Silver” handles silver request. n Real Server 3: “Bronze” handles bronze request. n Real Server 4: “any” handles any request that does not have a cookie or matching cookie. With servers defined to handle the requests listed above, here is what happens: 4. n Request 1 comes in with no cookie; it is forwarded to Real Server 4 to get cookie assigned.
Web OS 10.0 Application Guide Browser-Smart Load Balancing HTTP requests can be directed to different servers based on browser type by inspecting the “User-Agent” header. For example, GET /products/180/ HTTP/1.0 User-agent: Mozilla/3.0 Accept: text/html, image/gif, image/jpeg To allow the switch to perform browser-smart load balancing, perform the following procedure. 1. 2.
Web OS 10.0 Application Guide URL Hashing for Server Load Balancing By default, hashing algorithms use the IP source address and/or IP destination address (depending on the application area) to determine content location. The default hashing algorithm for SLB is the IP source address. By enabling URL hashing, requests going to the same page of an origin server are redirected to the same real server or cache server.
Web OS 10.0 Application Guide To configure URL hashing, perform the following procedure: 1. Before you can configure URL hashing, ensure that the switch has already been configured for basic SLB with the following tasks: n Assign an IP address to each of the real servers in the server pool. n Define an IP interface on the switch. n Define each real server. n Assign servers to real server groups. n Define virtual servers and services. n Configure load-balancing algorithm for hash or minmiss.
Web OS 10.0 Application Guide Header Hash Load Balancing Web OS allows you to hash on any selected HTTP header. To configure the Web switch for load balancing based on header hash, perform the following procedure: 1. Ensure that the switch has already been configured for basic SLB: n Assign an IP address to each of the real servers in the server pool. n Define an IP interface on the switch. n Define each real server. n Assign servers to real server groups. n Define virtual servers and services.
Web OS 10.0 Application Guide DNS Load Balancing The Internet name registry has become so large that a single server cannot keep track of all the entries. This is resolved by splitting the registry and saving it on different servers. If you have large DNS server farms, Web OS allows you to load balance traffic based on DNS names. To load balance DNS names, the host name is extracted from the query, processed by the regular expressions engine, and the request is sent to the appropriate real server.
Web OS 10.0 Application Guide To configure the switch for DNS load balancing, perform the following procedure: 1. Before you can configure DNS load balancing, ensure that the switch has already been configured for basic SLB with the following tasks: n Assign an IP address to each of the real servers in the server pool. n Define an IP interface on the switch. n Define each real server (DNS server address). n Assign servers to real server groups. n Define virtual servers and services.
Web OS 10.0 Application Guide Number of entries: five ID 7. SLB String 1 any, cont 1024 2 www.[abcdefg]*.com, cont 1024 3 www.[hijklm]*.com, cont 1024 4 www.[nopqrst]*.com, cont 1024 5 www.[uvwxyz]*.
Web OS 10.0 Application Guide To configure RTSP load balancing using pattern matching, follow this procedure: 1. Add the URL string. >> # /cfg/slb/layer7/slb/add (Add URL string ID, for example, g2video.rm) n You can remove the URL string by performing the following: >> # /cfg/slb/layer7/slb >> Server Load Balance Resource# rem (Remove URL string ID: g2video.
Web OS 10.0 Application Guide Content Intelligent Web Cache Redirection Web OS allows you to redirect Web cache requests based on different HTTP header information, such as “Host:” header or “User-Agent” for browser-smart load balancing. For more information on layer 4 Web cache redirection, see Chapter 8, “Application Redirection.
Web OS 10.0 Application Guide URL-Based Web Cache Redirection URL parsing for Web Cache Redirection operates in a manner similar to URL-based server load balancing except that in WCR a virtual server on the switch is the target of all IP/HTTP requests. For information on URL-based server load balancing, see “URL-Based Server Load Balancing” on page 375.
Web OS 10.0 Application Guide The switch is preconfigured with a list of 13 noncacheable items that you can add to, delete, or modify. These items are either known dynamic content file extensions or dynamic URL parameters, as described below: n Dynamic content files: o o o o o o o n Common gateway interface files (.cgi) cold fusion files (.cfm), ASP files (.asp) BIN directory CGI-BIN directory SHTML (scripted html) Microsoft HTML extension files (.htx) executable files (.
Web OS 10.0 Application Guide Network Address Translation Options URL-based WCR supports three types of Network Address Translation (NAT): No NAT, Half NAT, and Full NAT. n No NAT In this NAT method, the traffic is redirected to the Web cache with the destination MAC address replaced by the MAC address of the cache. The destination IP address remains unchanged, and no modifications are made to the IP address or the MAC address of the source or origin server.
Web OS 10.0 Application Guide 3. Configure the parameters and file extensions that bypass WCR. The switch is preconfigured with a list of 13 noncacheable items: n Dynamic content files: Common gateway interface files (.cgi), cold fusion files (.cfm), ASP files (.asp), BIN directory, CGI-BIN directory, SHTML (scripted html), Microsoft HTML extension files (.htx), executable files(.exe) n Dynamic URL parameters: +, !, %, =, & a) Add or remove expressions that should not be cacheable.
Web OS 10.0 Application Guide 4. Define the string(s) to be used for Web cache SLB. Refer to the parameters listed below: >> # /cfg/slb/layer7/slb/add|rem n n add: Add a string or a path. rem: Remove string or a path. A default string “any” indicates that the particular server can handle all URL or Web-cache requests.
Web OS 10.0 Application Guide 5. Apply and save your configuration changes. 6. Identify the defined string IDs. >> # /cfg/slb/layer7/slb/cur For easy configuration and identification, each defined string has an ID attached, as shown in the following example: Number of entries: six 7. ID SLB String 1 any 2 .gif 3 /sales 4 /xitami 5 /manual 6 .jpg Configure the real server(s) to support WCR.
Web OS 10.0 Application Guide 9. Configure a filter to support basic WCR.
Web OS 10.0 Application Guide 12. Create a default filter for noncached traffic on the switch.
Web OS 10.0 Application Guide HTTP Header-Based Web Cache Redirection To configure the switch for WCR based on the “Host:” header, use the following procedure: 1. Configure basic SLB. Before you can configure header-based cache redirection, ensure that the switch has already been configured for basic SLB (see “Server Load Balancing” on page 117)with the following tasks: n n n n n 2. Assign an IP address to each of the real servers in the server pool. Define an IP interface on the switch.
Web OS 10.0 Application Guide 7. Configure the real server(s) to handle the appropriate load balance string(s). Add the defined string IDs to the real servers: >> # /cfg/slb/real 2/layer7/addlb where ID is the identification number of the defined string. NOTE – If you don’t add a defined string (or add ID=1), the server will handle any request. 8.
Web OS 10.0 Application Guide Browser-Based Web Cache Redirection Browser-based Web cache redirection uses the User-agent: header. To configure browserbased WCR, perform the following procedure. 1. Before you can configure header-based WCR, ensure that the switch is already configured for basic SLB with the following tasks: n n n n n 2. Assign an IP address to each of the real servers in the server pool. Define an IP interface on the switch. Define each real server. Assign servers to real server groups.
Web OS 10.0 Application Guide 7. Add the defined string IDs to configure the real server(s) to handle the appropriate load balance string(s). >> # /cfg/slb/real 2/layer7/addlb where ID is the identification number of the defined string. NOTE – If you don’t add a defined string (or add the ID 1), the server will handle any request.
Web OS 10.0 Application Guide 2. Turn on URL parsing for the filter. >> # /cfg/slb/filt 1/adv/urlp ena 3. Enable hash to direct a cacheable URL request to a specific cache server. By default, the host header field is used to calculate the hash key and URL hashing is disabled. n hash ena: Enables hashing based on the URL and the host header if it is present. Specify the length of the URL to hash into the cache server.
Web OS 10.0 Application Guide http://www.nortelnetworks.com Cache server farm 1 Clients 2 3 1 2 Internet Alteon Web Switch 3 Figure 15-6 URL Hashing for WCR Example 2: Hashing on the Host Header Field Only In this example, URL hashing is disabled. If you use the Host header field to calculate the hash key, the same URL request goes to the same cache server: n Client 1 request http://www.nortelnetworks.com is directed to cache server 1. n Client 2 request http://www.nortelnetworks.
Web OS 10.0 Application Guide Layer 7 RTSP Streaming Cache Redirection This section explains Layer 7 support for RTSP Streaming Cache Redirection. For conceptual information on RTSP Streaming Cache Redirection, see “RTSP Web Cache Redirection” on page 211. For detailed information on two prominent commercial RTSP servers—Real Player and QuickTime—see “Real Time Streaming Protocol SLB” on page 155. To configure RTSP for Streaming Cache Redirection, follow this procedure: 1.
Web OS 10.0 Application Guide Exclusionary String Matching for Real Servers URL-based SLB and WCR can match or exclude up to 128 strings. Examples of strings are as follows: n n “/product,” matches URLs that starts with /product. “product,” matches URLs that have the string “product” anywhere in the URL. You can assign one or more strings to each real server. When more than one URL string is assigned to a real server, requests matching any string are redirected to that real server.
Web OS 10.0 Application Guide For information on how to configure your network for server load balancing, see Chapter 6, “Server Load Balancing.” 2. Add the load balancing strings (for example test, /images, and /product) to the real server. >> # /cfg/slb/layer7/slb/add test >> Server Loadbalance Resource# add “/images” >> Server Loadbalance Resource# add “/product” 3. Apply and save the configuration. 4. Identify the IDs of the defined strings.
Web OS 10.0 Application Guide Regular Expression Matching Regular expressions are used to describe patterns for string matching. They enable you to match the exact string, such as URLs, host names, or IP addresses. It is a powerful and effective way to express complex rules for Layer 7 string matching. Both Layer 7 HTTP SLB and Web Cache Redirection can use regular expressions as a resource.
Web OS 10.0 Application Guide n Size of the regular expression structure after compilation cannot exceed 43 bytes for load balancing strings and 23 bytes for Web Cache Redirection. The size of regular expression after compilation varies, based on regular expression characters used in the user input string. n Use “/” at the beginning of the regular expression. Otherwise a regular expression will have “*” prefixed to it automatically. For example, “html/*\.htm” appears as “*html/*\.htm”.
Web OS 10.0 Application Guide Content Precedence Lookup The Layer 7 Precedence Lookup feature in Web OS allows you to give precedence to one Layer 7 parameter over another and selectively decide which parameter should be analyzed first. The Content Precedence Lookup feature allows you to combine up to two Layer 7 load balancing mechanisms. You can specify which types of Layer 7 content to examine, the order in which they are examined, and a logical operator (and/or) for their evaluation.
Web OS 10.0 Application Guide Requirements n Enable Direct Access Mode (DAM), or configure proxy IP address if DAM is disabled. n Enable delayed binding. Using the or and and Operators Figure 15-7 shows a network with real servers 1 and 3 configured for URL SLB and real servers 2 and 3 configured for HTTP Host SLB. Real Servers 1 URL: "/gold" 2 Host: "www.host.net" 3 Host: "www.host.
Web OS 10.0 Application Guide Assigning Multiple Strings Figure 15-8 shows an example of a company providing content for two large customers: Customers A and B. Customer A uses www.a.com as their domain name, and Customer B uses www.b.com. The company has a limited number of public IP addresses and wishes to assign them on a very conservative basis. As a result, the company implements virtual hosting by advertising a single virtual server IP address that includes both customers’ Web sites.
Web OS 10.0 Application Guide When a client request is received with www.a.com in the Host Header and .jpg in the URL, the request will be load balanced between Server 1 and Server 2. To accomplish this configuration, you must assign multiple strings (a Host Header string and a URL string) for each real server. Layer 7 Deny Filter Web OS allows you to secure your switch from virus attacks by configuring the switch with a list of potential offending string patterns (HTTP URL request).
Web OS 10.0 Application Guide Configuring a Layer 7 Deny Filter 1. Before you can configure Layer 7 deny filter, ensure that the switch has already been configured for basic switch functions: n Assign an IP address to each of the real servers in the server pool. n Define an IP interface on the switch. For information on how to configure your network for the above tasks, see Chapter 6, “Server Load Balancing.” 2. Define the virus string patterns or offending HTTP URL request to be blocked.
Web OS 10.0 Application Guide 7. Enable the Layer 7 deny option. (Select the Layer 7 deny menu) (Enable Layer 7 deny filter) >> Filter 1 Advanced# l7deny >> Filter 1 Advanced L7deny# ena 8. Assign the URL string ID from Step 4 to the filter. >> >> >> >> 9.
Web OS 10.
CHAPTER 16 Persistence The Web OS persistence feature ensures that all connections from a specific client session reach the same real server, even when Server Load Balancing (SLB) is used. The following topics are addressed in this chapter: n “Overview of Persistence” on page 422. This section gives an overview of persistence and the different types of persistence methods implemented in Web OS. n “Cookie-Based Persistence” on page 424.
Web OS 10.0 Application Guide Overview of Persistence In a typical SLB environment, traffic comes from various client networks across the Internet to the virtual server IP address on the Web switch. The switch then load balances this traffic among the available real servers. In any authenticated Web-based application, it is necessary to provide a persistent connection between a client and the Web server to which it is connected.
Web OS 10.0 Application Guide Using Cookies Cookies are strings passed via HTTP from servers to browsers. Based on the mode of operation, cookies are inserted by either the Web switch or the server. After a client receives a cookie, a server can poll that cookie with a GET command, which allows the querying server to positively identify the client as the one that received the cookie earlier.
Web OS 10.0 Application Guide Cookie-Based Persistence Cookies are a mechanism for maintaining state between clients and servers. When the server receives a client request, the server issues a cookie, or token, to the client, which the client then sends to the server on all subsequent requests. Using cookies, the server does not require authentication, the client IP address, or any other time-consuming mechanism to determine that the user is the same user that sent the original request.
Web OS 10.0 Application Guide The following topics discussing cookie-based persistence are detailed in this section: n “Permanent and Temporary Cookies” on page 425 n “Cookie Formats” on page 425 n “Cookie Properties” on page 426 n “Client Browsers that Do Not Accept Cookies” on page 426 n “Cookie Modes of Operation” on page 427 n “Configuring Cookie-Based Persistence” on page 430 Permanent and Temporary Cookies Cookies can either be permanent or temporary.
Web OS 10.0 Application Guide Cookie Properties Cookies are configured on the Web switch by defining the following properties: n Cookie names of up to 20 bytes n The offset of the cookie value within the cookie string For security, the real cookie value can be embedded somewhere within a longer string. The offset directs the Web switch to the starting point of the real cookie value within the longer cookie string.
Web OS 10.0 Application Guide Cookie Modes of Operation Web OS supports the following modes of operation for cookie-based session persistence: insert, passive, and rewrite mode.
Web OS 10.0 Application Guide Passive Cookie Mode In Passive Cookie mode, when the client first makes a request, the switch selects the server based on the load-balancing metric. The real server embeds a cookie in its response to the client. The switch records the cookie value and matches it in subsequent requests from the same client. NOTE – The passive cookie mode is recommended for temporary cookies. However, you can use this mode for permanent cookies if the server is embedding an IP address.
Web OS 10.0 Application Guide Rewrite Cookie Mode In rewrite cookie mode, the Web switch generates the cookie value on behalf of the server, eliminating the need for the server to generate cookies for each client. Instead, the server is configured to return a special persistence cookie which the switch is configured to recognize. The switch then intercepts this persistence cookie and rewrites the value to include server-specific information before sending it on to the client.
Web OS 10.0 Application Guide Configuring Cookie-Based Persistence 1. Before you can configure cookie-based persistence, you need to configure the switch for basic SLB. This includes the following tasks: n Assign an IP address to each of the real servers in the server pool. n Define an IP interface on the switch. n Configure each real server with its IP address, name, weight, and so forth. n Assign servers to real server groups. n Define virtual servers and services.
Web OS 10.0 Application Guide 4. Select the appropriate load-balancing metric for the real server group. >> # /cfg/slb/group 2/metric hash (Select hash as server group metric) n If embedding an IP address in the cookie, select roundrobin or leastconns as the metric. n If you are not embedding the IP address in the cookie, select hash as the metric in conjunction with a cookie assignment server.
Web OS 10.0 Application Guide n Set multiple response count This parameter is set for passive mode only. Typically, the Web switch searches the first HTTP response packet from the server and, if a persistence cookie is found, sets up a persistent connection between the server and the client. While this approach works for most servers, some customers with complex server configurations might send the persistence cookie a few responses later.
Web OS 10.0 Application Guide Example 1: Setting the Cookie Location In this example, the client request has two different cookies labeled “UID.” One exists in the HTTP header and the other appears in the URI: GET /product/switch/UID=12345678;ck=1234... Host: www.alteonwebsystems.com Cookie: UID=87654321 n Look for the cookie in the HTTP header >> # /cfg/slb/virt 1/service 80/pbind cookie passive UID 1 8 dis The last parameter in this command answers the “Look for cookie in URI?” prompt.
Web OS 10.0 Application Guide Example 2: Parsing the Cookie This example shows three configurations where the switch uses the hashing key or wild cards to determine which part of the cookie value should be used for determining the real server. For example, the value of the cookie is defined as follows: Cookie: sid=0123456789abcdef; name1=value1;...
Web OS 10.0 Application Guide Example 4: Using Rewrite Cookie Mode n Rewrite server cookie with the encrypted real server IP address: In cookie rewrite mode, if the cookie length parameter is configured to be eight bytes, the switch will rewrite the placeholder cookie value with the encrypted real server IP address.
Web OS 10.0 Application Guide Server-Side Multi-Response Cookie Search Cookie-based persistence requires the switch to search the HTTP response packet from the server and, if a persistence cookie is found, sets up a persistence connection between the server and the client. The Alteon switch looks through the first HTTP response from the server. While this approach works for most servers, some customers with complex server configurations might send the persistence cookie a few responses later.
Web OS 10.0 Application Guide SSL Session ID-Based Persistence SSL is a set of protocols built on top of TCP/IP that allows an application server and client to communicate over an encrypted HTTP session, providing authentication, non-repudiation, and security. The SSL protocol handshake is performed using clear (unencrypted) text. The content data is then encrypted (using an algorithm exchanged during the handshake) prior to being transmitted.
Web OS 10.0 Application Guide Figure 16-5 illustrates persistence based on SSL session ID as follows: 1. An SSL Hello handshake occurs between Client 1 and Server 1 via the Web switch. 2. An SSL session ID is assigned to Client 1 by Server 1. 3. The Web switch records the SSL session ID. 4. The Web switch selects a real server based on the existing SLB settings. As a result, subsequent connections from Client 1 with the same SSL session ID are directed to Server 1.
Web OS 10.0 Application Guide Configuring SSL Session ID-Based Persistence To configure session ID-based persistence for a real server, perform the following steps: 1. Configure real servers and services for basic SLB, as indicated below: n Define each real server and assign an IP address to each real server in the server pool. n Define a real server group and set up health checks for the group.
Web OS 10.
CHAPTER 17 Bandwidth Management Bandwidth Management (BWM) enables Web site managers to allocate a certain portion of the available bandwidth for specific users or applications. It allows companies to guarantee that critical business traffic, such as e-commerce transactions, receive higher priority versus noncritical traffic. Traffic classification can be based on user or application information. BWM policies can be configured to set lower and upper bounds on the bandwidth allocation.
Web OS 10.0 Application Guide Overview To manage bandwidth, create one or more bandwidth management contracts. The switch uses these contracts to limit individual traffic flows. 2. Administrator configures bandwidth policy and contract 3. Classification is done on ingress port of switch Web Switch Internet 1. Client buys a contract (for example, a VIP address) 4. Bandwidth management done on egress port of switch. Can optionally set TOS values to reflect usage rate 5.
Web OS 10.0 Application Guide n When Virtual Matrix Architecture (VMA) is not enabled, bandwidth classification is done on the ingress side of the switch (at the ingress port or designated port) and can be based on the following: source port, VLAN, filters, Virtual Internet Protocol (VIP) address, service on the Virtual server, URL, and so on.
Web OS 10.0 Application Guide Bandwidth Policies Bandwidth policies are bandwidth limitations defined for any set of frames, specifying the guaranteed bandwidth rates. A bandwidth policy is often based on a rate structure whereby a Web host or co-location provider could charge a customer for bandwidth utilization. There are three rates that are configured: a Committed Information Rate (CIR)/Reserved Limit, a Soft Limit, and a Hard Limit, as described below. A queue depth is also associated with a policy.
Web OS 10.0 Application Guide Rate Limits A bandwidth policy specifies three limits, listed and described in Table 17-1: Table 17-1 Bandwidth Rate Limits Rate Limit Description Committed Information Rate (CIR) or Reserved Limit This is a rate that a bandwidth classification is always guaranteed. In configuring BWM contracts, ensure that the sum of all committed information rates never exceeds the link speeds associated with ports on which the traffic is transmitted.
Web OS 10.0 Application Guide Data Pacing The mechanism used to keep the individual traffic flows under control is called data pacing. It is based on the concept of a virtual clock and theoretical departure times (TDT). The actual calculation of the TDT is based initially on the soft limit rate. The soft limit can be thought of as a target limit for the ISP’s customer.
Web OS 10.0 Application Guide Classification Criteria The frames associated with a particular BWM contract are specified, using the parameters listed below. All of these classifications are aimed at limiting the traffic outbound from the server farm for bandwidth measurement and control. Server Output Bandwidth Control n Physical Port - All frames are from a specified physical port. n VLAN - All frames are from a specified VLAN.
Web OS 10.0 Application Guide Combinations Combinations of classifications are limited to grouping items together into a contract. For example, if you wanted to have three different virtual servers associated with a contract, you would specify the same contract index on each of the three virtual server IP addresses. You can also combine filters in this manner.
Web OS 10.0 Application Guide Frame Discard When packets in a contract queue have not yet been sent and the buffer size set for the queue is full, any new frames attempting to be placed in the queue will be discarded. URL-Based Bandwidth Management URL-based BWM allows the network administrator or Web site manager to control bandwidth based on URLs, HTTP headers, or cookies.
Web OS 10.
Web OS 10.0 Application Guide HTTP Header-Based Bandwidth Management HTTP header-based BWM allows Web site managers to allocate bandwidth based on header value. Thus, they can allocate bandwidth based on browser type, cookie value, and so forth. Cookie-Based Bandwidth Management Cookie-based BWM enables Web site managers to prevent network abuse by bandwidth-hogging users. Using this feature, bandwidth can be allocated by type of user or other user-specific information available in the cookie.
Web OS 10.0 Application Guide Bandwidth Statistics and History Statistics are maintained in order to allow Web switch owners to bill for bandwidth usage. Statistics for frequency and count are configurable. Statistics are kept in the individual Switch Processors (SP) and then collected every second by the MP (Management Processor). The MP then combines the statistics, as statistics for some classifications may be spread across multiple SPs.
Web OS 10.0 Application Guide Packet Coloring (TOS bits) for Burst Limit Whenever the soft limit is exceeded, optional packet coloring can be done to allow downstream routers to use diff-serv mechanisms (that is, writing the Type-Of-Service (TOS) byte of the IP header) to delay or discard these out-of-profile frames. Frames that are not out-of -profile are marked with a different, higher priority value.
Web OS 10.0 Application Guide Configuring Bandwidth Management The following procedure provides general instructions for configuring BWM on the switch. Specific configuration examples begin on page 457. 1. Configure the switch as you normally would for SLB. Configuration includes the following tasks: n Assign an IP address to each of the real servers in the server pool. n Define an IP interface on the switch. n Define each real server. n Define a real server group. n Define a virtual server.
Web OS 10.0 Application Guide 5. (Optional) Set the TOS byte value, between 0-255, for the policy underlimit and overlimit. There are two parameters for specifying the TOS bits: underlimit (utos) and overlimit (otos). These TOS values are used to overwrite the TOS values of IP packets if the traffic for a contract is under or over the soft limit, respectively. These values only have significance to a contract if TOS overwrite is enabled in the Bandwidth Management Contract Menu (cfg/bwm/cont x/wtos ena.
Web OS 10.0 Application Guide 9. (Optional) Enable TOS overwriting for the BWM contract. >> BWM Contract 1# wtos ena (Enables overwriting for contract) 10. Set the bandwidth policy for this contract. Each bandwidth management contract must be assigned a bandwidth policy. >> BWM Contract 1# pol 1 (Assign policy 1 to BWM contract 1) 11. Enable the BWM contract. >> BWM Contract 1# ena (Enables this BWM contract) 12. Classify the frames for this contract and assign the BWM contract to the filter.
Web OS 10.
Web OS 10.0 Application Guide 3. On the switch, select a BWM contract and name the contract. Each contract must have a unique number from 1 to 256. >> Policy 1# /cfg/bwm/cont 1 >> BWM Contract 1# name dial-up 4. (Select BWM contract 1) (Assign contract name “dial-up”) Set the bandwidth policy for this contract. Each BWM contract must be assigned a bandwidth policy. >> BWM Contract 1# pol 1 5. Enable this BWM contract. >> BWM Contract 1# ena 6.
Web OS 10.0 Application Guide 11. Assign the BWM contracts to different switch ports. Physical switch ports are used to classify which frames are managed by each contract—that is, one BWM contract will be applied to all frames from a specific port. The second contract will be applied to all frames from another specified port. >> BWM Contract 2# /cfg/port 1/cont 1 >> Port 1# ../port 2/cont 2 (Assign contract 1 to port 1) (Assign contract 2 to port 2) 12. On the switch, apply and verify the configuration.
Web OS 10.0 Application Guide Preferential Services Examples BWM can be used to provide preferential treatment to certain traffic, based on source IP blocks, applications, URL paths, or cookies. You may find it useful to configure higher policy rate limits for specific sites, for example, those used for e-commerce. Web Site Preference Example In the following example, there are two Web sites, “A.com” and “B.com.” BWM is configured to give preference to traffic sent to Web site “B.com:” 1.
Web OS 10.0 Application Guide 5. Set the bandwidth policy for this contract. Each BWM contract must be assigned a bandwidth policy. (Assign policy 1 to BWM contract 1) >> BWM Contract 1# pol 1 6. Enable this BWM contract. (Enables this BWM contract) >> BWM Contract 1# ena 7. Select the second bandwidth policy. >> BWM Contract 1# /cfg/bwm/policy 2 8. Set the hard, soft, and reserved rate limits for this policy, in Mbps.
Web OS 10.0 Application Guide 12. Create a virtual server that will be used to classify the frames for contract 1 and assign the Virtual server IP address for this server. Then, assign the BWM contract to the virtual server. Repeat this procedure for a second virtual server. NOTE – This classification applies to the services within the virtual server and not to the virtual server itself. The classification policy for these BWM contracts is based on a virtual server.
Web OS 10.0 Application Guide URL-Based Bandwidth Management Example In this example, you will assign bandwidth based on URL paths. For URL-based server load balancing, a user has to first define strings to monitor. Each of these strings is attached to real servers, and any URL with the string is load balanced across the assigned servers. NOTE – The complete procedure to configure URL-based SLB is described in Chapter 7, “Content Intelligent Switching” of the Web OS Application Guide.
Web OS 10.0 Application Guide 3. Configure a real server to handle the URL request. To add a defined string: >> # /cfg/slb/real 2/layer7/addlb where URL path ID is the identification number of the defined string as displayed when you enter the cur command. Example: /cfg/slb/real 2/layer7/addlb 3 4. Either enable Direct Access Mode (DAM) on the switch or configure a proxy IP address on the client port.
Web OS 10.0 Application Guide 5. Turn on URL-based server load balancing on the virtual server. Configure everything under the virtual server as in Configuration Example 1. >> # /cfg/slb/virt 1/service 80/httpslb enable urlslb If the same string is used by more than one service, and you want to allocate a certain percentage of bandwidth to this URL string for this service on the virtual server, then define a rule using the urlcont command.
Web OS 10.0 Application Guide 2. Allocate bandwidth for each string. To do this, assign a BWM contract to each defined string. >> # /cfg/slb/layer7/lb/cont 3. Configure a real server to handle the cookie. To add a defined string: >> # /cfg/slb/real 2/layer7/addlb where URL path ID is the identification number of the defined string. Example: >> # /cfg/slb/real 2/layer7/addlb 3 4.
Web OS 10.0 Application Guide Scenario 2: In this scenario, the Web site has multiple virtual server IP addresses, and the same user classification or multiple sites use the same string name. In this scenario, there are two Virtual IP (VIP) addresses: 172.17.1.1 and 172.17.1.2. Both the virtual servers and sites have first class and business class customers, with different bandwidth allocations, as shown in Figure 17-7 on page 467.
Web OS 10.0 Application Guide Security Management Example BWM can be used to prevent Denial of Service (DoS) attacks by a flooding of “necessary evil” packets and limiting the rate of TCP SYN, ping, other disruptive packets, and alerting/logging the network manager when soft limits are exceeded. In the following example, a filter is configured to match ping packets, and BWM is configured to prevent DoS attacks by limiting the bandwidth policy rate of those packets: 1.
Web OS 10.0 Application Guide 6. Set the bandwidth policy for the contract. Each BWM contract must be assigned a bandwidth policy. (Assign policy 1 to BWM contract 1) >> BWM Contract 1# pol 1 7. Enable the BWM contract. (Enables this BWM contract) >> BWM Contract 1# ena 8. Create a filter that will be used to classify the frames for this contract and assign the BWM contract to the filter. The classification policy for this BWM contract is based on a filter configured to match ICMP traffic.
Web OS 10.
Glossary DIP (Destination IP Address) The destination IP address of a frame. Dport (Destination Port) The destination port (application socket: for example, http-80/https-443/DNS-53) NAT (Network Address Translation) Any time an IP address is changed from one source IP or destination IP address to another address, network address translation can be said to have taken place. In general, half NAT is when the destination IP or source IP address is changed from one address to another.
Web OS 10.0 Application Guide 472 SIP (Source IP Address) The source IP address of a frame. SPort (Source Port) The source port (application socket: for example, HTTP-80/HTTPS-443/DNS-53). Tracking In VRRP, a method to increase the priority of a virtual router and thus master designation (with preemption enabled). Tracking can be very valuable in an active/active configuration.
Web OS 10.0 Application Guide VRRP (Virtual Router Redundancy Protocol) A protocol that acts very similarly to Cisco’s proprietary HSRP address sharing protocol. The reason for both of these protocols is so devices have a next hop or default gateway that is always available. Two or more devices sharing an IP interface are either advertising or listening for advertisements. These advertisements are sent via a broadcast message to an address such as 224.0.0.18.
Web OS 10.
Index Symbols B [ ]....................................................................... 23 backup servers ................................................... 135 bandwidth management ...........................449 to 450 burst limit................................................... 453 classification policies ................................... 447 configuration, general .......................454 to 456 configuration, preferential service ................. 460 configuration, security ...............
Web OS 10.0 Application Guide configuring cookie-based persistence ..............................430 FTP Server Load Balancing ..................150, 151 multi-response cookie search.........................436 stateful failover ...........................................285 contacting us........................................................24 content intelligent server load balancing ...................................375 Web cache redirection ..................................394 cookie active ........
Web OS 10.0 Application Guide G gateway. See default gateway. Gigabit adapters jumbo frames ............................................... 63 Global SLB configuration tutorial ........................ 294 to 303 Distributed Site State Protocol .............. 290, 295 DNS resolution (diagram) ............................ 291 domain name configuration .......................... 299 health check interval ................................... 298 hostname configuration ...............................
Web OS 10.0 Application Guide IP routing ..........................................................123 cross-subnet example .....................................28 default gateway configuration ...................32, 61 IP interface configuration ...................31, 34, 60 IP subnets .....................................................29 network diagram............................................29 routing between VLANs .................................64 subnet configuration example ..................
Web OS 10.0 Application Guide N name servers, Global SLB configuration example. 291 Network Address Translation (NAT) ................... 208 configuration example ...................... 191 to 193 filter example ............................................. 194 proxy ........................................................ 194 static example............................................. 191 network performance statistics, with use of proxy addresses ............ 136 New ....................................
Web OS 10.0 Application Guide real servers ........................................................122 backup/overflow servers ...............................135 configuration example ..................................296 connection timeouts .....................................134 health checks ..............................................231 maximum connections .................................134 SLB configuration example ..........................125 weights............................................
Web OS 10.0 Application Guide service ports .............................................. 128, 171 setting multiple response count ........................... 432 shared services .................................................. 118 SIP (source IP address for filtering) ..................... 178 smask source mask for filtering .............................. 178 SMTP .............................................................. 304 SNMP ................................................................
Web OS 10.0 Application Guide VLANs broadcast domains .......................33, 43, 45, 48 default PVID.................................................44 example showing multiple VLANs ..................46 filtering ......................................................174 gateway, default ............................................58 ID numbers ...................................................44 IP interface configuration ...............................34 IP interfaces ...............................
