BLADE OS™ Application Guide HP GbE2c Ethernet Blade Switch for c-Class BladeSystem Version 5.1 Advanced Functionality Software Part Number: BMD00113, September 2009 2350 Mission College Blvd. Suite 600 Santa Clara, CA 95054 www.bladenetwork.
BLADE OS 5.1 Application Guide Copyright © 2009 BLADE Network Technologies, Inc., 2350 Mission College Blvd., Suite 600, Santa Clara, California, 95054, USA. All rights reserved. Part Number: BMD00113. 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 BLADE Network Technologies, Inc.
Contents Preface 17 Who Should Use This Guide 17 What You’ll Find in This Guide 17 Additional References 19 Typographic Conventions 20 Part 1: Basic Switching 21 Chapter 1: Accessing the Switch 23 The Management Network 24 Local Management Using the Console Port 25 The Command Line Interface 25 Remote Management Access 26 Configuring an IP Interface 26 Using Telnet 27 Using Secure Shell 27 Using the Browser-Based Interface 27 Configuring BBI Access via HTTP 27 Configuring
BLADE OS 5.
BLADE OS 5.
BLADE OS 5.
BLADE OS 5.
BLADE OS 5.
BLADE OS 5.
BLADE OS 5.
BLADE OS 5.
BLADE OS 5.
Figures Chapter 1: Accessing the Switch Figure 1: BOOTP Relay Agent Configuration 38 Figure 2: DHCP Relay Agent Configuration 40 Chapter 2: Ports and Trunking Figure 3: Port Trunk Group 67 Figure 4: Port Trunk Group Configuration Example 70 Chapter 3: Port-Based Network Access Control Figure 5: Authenticating a Port Using EAPoL 79 Chapter 4: VLANs Figure 6: Default VLAN Settings 91 Figure 7: Port-Based VLAN Assignment 92 Figure 8: 802.
BLADE OS 5.
Tables Preface Table 1: Typographic Conventions 20 Chapter 1: Accessing the Switch Table 2: Default User Access Levels 30 Table 3: Proprietary Attributes for RADIUS 46 Table 4: Default TACACS+ Authorization Levels 48 Table 5: Alternate TACACS+ Authorization Levels 48 Table 6: User Access Levels 60 Chapter 2: Ports and Trunking Table 7: Ethernet Switch Port Names 66 Table 8: Actor vs.
BLADE OS 5.
Preface The BLADE OS 5.1 Application Guide describes how to configure and use the BLADE OS 5.1 Advanced Functionality Software for the HP GbE2c Ethernet Blade Switch for c-Class BladeSystem. For documentation on installing the switch physically, see the User Guide for your HP GbE2c Ethernet Blade Switch (GbE2c). Who Should Use This Guide This guide is intended for network installers and system administrators engaged in configuring and maintaining a network.
BLADE OS 5.1 Application Guide Chapter 4, “VLANs,” describes how to configure Virtual Local Area Networks (VLANs) for creating separate network segments, including how to use VLAN tagging for devices that use multiple VLANs. This chapter also describes Protocol-based VLANs, Private VLANs, and Generic VLAN Registration Protocol (GVRP). Chapter 5, “Spanning Tree Protocol,” discusses how Spanning Trees configure the network so that the switch uses the most efficient path when multiple paths exist.
BLADE OS 5.1 Application Guide Additional References Additional information about installing and configuring the GbE2c is available in the following guides: HP GbE2c Ethernet Blade Switch User Guide BLADE OS 5.1 Command Reference for the HP GbE2c Ethernet Blade Switch BLADE OS 5.1 ISCLI Reference for the HP GbE2c Ethernet Blade Switch BLADE OS 5.
BLADE OS 5.1 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 prompts. Main# AaBbCc123 This bold type appears in command examples. It Main# sys shows text that must be typed in exactly as shown.
Part 1: Basic Switching This section discusses basic switching functions.
BLADE OS 5.
CHAPTER 1 Accessing the Switch The BLADE OS software provides means for accessing, configuring, and viewing information and statistics about the HP GbE2c Ethernet Blade Switch (GbE2c).
BLADE OS 5.1 Application Guide The Management Network The GbE2c is an integral subsystem within the overall BladeSystem. The BladeSystem chassis includes an Onboard Administrator as the central element for overall chassis and control. The GbE2c communicates with the Onboard Administrator through its internal management port (port 19).
BLADE OS 5.1 Application Guide Local Management Using the Console Port Using a null modem cable, you can directly connect to the switch through the console port. A console connection is required in order to configure Telnet or other remote access applications. For more information on establishing console connectivity to the switch, see the HP GbE2c Ethernet Blade Switch User Guide.
BLADE OS 5.1 Application Guide Remote Management Access Configuring an IP Interface An IP interface address must be set on the switch to provide management access to the switch over an IP network. By default, the management interface is set up to request its IP address from a Bootstrap Protocol (BOOTP) server. If you have a BOOTP server on your network, add the Media Access Control (MAC) address of the switch to the BOOTP configuration file located on the BOOTP server.
BLADE OS 5.1 Application Guide Using Telnet By default, Telnet is enabled on the switch. Once you have configured the switch with an IP address and gateway, you can access the switch from any workstation connected to the management network using a Telnet connection. Telnet access provides the same options for user and administrator access as those available through the management module. The switch supports concurrent Telnet sessions.
BLADE OS 5.1 Application Guide Configuring BBI Access via HTTPS The BBI can also be accessed via secure HTTPS connection. By default, BBI access via HTTPS is disabled on the switch. To enable BBI Access via HTTPS, use the following procedure: 1. Enable HTTPS using the following CLI command: >> # /cfg/sys/access/https/access ena 2.
BLADE OS 5.1 Application Guide BBI Summary The BBI is organized at a high level as follows: Context buttons – allow you to select the type of action you wish to perform. The Configuration button provides access to the configuration elements for the entire switch. The Statistics button provides access to the switch statistics and state information. The Dashboard button allows you to display settings and operating status of a variety of switch features.
BLADE OS 5.1 Application Guide User Accounts By default, remote users must log in with a user name and password to access the switch. The default user accounts are listed in Table 2: Table 2 Default User Access Levels Account Password Description and Tasks Performed user user Operators can only effect temporary changes on the switch. These changes are lost when the switch is rebooted/reset. Operators have access to the switch management features used for daily switch operations.
BLADE OS 5.1 Application Guide Using Simple Network Management Protocol BLADE OS provides Simple Network Management Protocol (SNMP) version 1, version 2, and version 3 support for access through any network management software, such as IBM Director or HP-OpenView. SNMP v1.0 To access the SNMP agent on the GbE2c, the read and write community strings on the SNMP manager should be configured to match those on the switch.
BLADE OS 5.1 Application Guide Default Configuration BLADE OS has two SNMP v3 users by default. Both of the following users have access to all the MIBs supported by the switch: username 1: adminmd5/password adminmd5. Authentication used is MD5. username 2: adminsha/password adminsha. Authentication used is SHA.
BLADE OS 5.1 Application Guide View-Based Configurations CLI User Equivalent To configure an SNMP user equivalent to the CLI user, use the following configuration: /c/sys/ssnmp/snmpv3/usm 4 name "usr" /c/sys/ssnmp/snmpv3/access 3 name "usrgrp" rview "usr" wview "usr" nview "usr" /c/sys/ssnmp/snmpv3/group 4 uname usr gname usrgrp /c/sys/ssnmp/snmpv3/view 6 name "usr" tree "1.3.6.1.4.1.1872.2.5.1.2" /c/sys/ssnmp/snmpv3/view 7 name "usr" tree "1.3.6.1.4.1.1872.2.5.1.
BLADE OS 5.1 Application Guide CLI Oper Equivalent To configure an SNMP user equivalent to the CLI oper, use the following configuration /c/sys/ssnmp/snmpv3/usm 5 name "oper" /c/sys/ssnmp/snmpv3/access 4 name "opergrp" rview "oper" wview "oper" nview "oper" /c/sys/ssnmp/snmpv3/group 4 uname oper gname opergrp /c/sys/ssnmp/snmpv3/view 20 name "usr" tree "1.3.6.1.4.1.1872.2.5.1.2" /c/sys/ssnmp/snmpv3/view 21 name "usr" tree "1.3.6.1.4.1.1872.2.5.1.3" /c/sys/ssnmp/snmpv3/view 22 name "usr" tree "1.3.6.1.4.
BLADE OS 5.1 Application Guide In the example below the user will receive the traps sent by the switch. /c/sys/ssnmp/snmpv3/access 10 name "v1trap" model snmpv1 nview "iso" /c/sys/ssnmp/snmpv3/group 10 model snmpv1 uname v1trap gname v1trap (Define access group to view SNMPv1 traps) (Assign user to the access group) 3. Configure an entry in the notify table. /c/sys/ssnmp/snmpv3/notify 10 name v1trap tag v1trap (Assign user to the notify table) 4.
BLADE OS 5.1 Application Guide SNMPv2 Trap Host Configuration The SNMPv2 trap host configuration is similar to the SNMPv1 trap host configuration. Wherever you specify the model, use snmpv2 instead of snmpv1. c/sys/ssnmp/snmpv3/usm 10 name "v2trap" /c/sys/ssnmp/snmpv3/access 10 name "v2trap" model snmpv2 nview "iso" /c/sys/ssnmp/snmpv3/group 10 model snmpv2 uname v2trap gname v2trap /c/sys/ssnmp/snmpv3/notify 10 name v2trap tag v2trap /c/sys/ssnmp/snmpv3/taddr 10 name v2trap addr 47.81.25.
BLADE OS 5.1 Application Guide SNMPv3 Trap Host Configuration To configure a user for SNMPv3 traps, you can choose to send the traps with both privacy and authentication, with authentication only, or without privacy or authentication. This is configured in the access table using the following commands: /cfg/sys/ssnmp/snmpv3/access /level /cfg/sys/ssnmp/snmpv3/tparam Configure the user in the user table accordingly.
BLADE OS 5.1 Application Guide Client IP Address Agents BOOTP Relay Agent BOOTP Relay Agent Overview The GbE2c can function as a Bootstrap Protocol relay agent, enabling the switch to forward a client request for an IP address up to two BOOTP servers with IP addresses that have been configured on the switch. When a switch receives a BOOTP request from a BOOTP client requesting an IP address, the switch acts as a proxy for the client.
BLADE OS 5.
BLADE OS 5.1 Application Guide DHCP Relay Agent Configuration To enable the GbE2c to be the BOOTP forwarder, you need to configure the DHCP/BOOTP server IP addresses on the switch. Generally, you should configure the command on the switch IP interface closest to the client so that the DHCP server knows from which IP subnet the newly allocated IP address should come.
BLADE OS 5.1 Application Guide Securing Access to the Switch 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: Limiting management users to a specific IP address range. Authentication and authorization of remote administrators such as RADIUS and TACACS+.
BLADE OS 5.1 Application Guide Setting Allowable Source IP Address Ranges To limit access to the switch without having to configure filters for each switch port, you can set a source IP address (or range) that will be allowed to connect to the switch IP interface through Telnet, SSH, SNMP, or the switch browser-based interface (BBI). When an IP packet reaches the application switch, the source IP address is checked against the range of addresses defined by the management network and management mask.
BLADE OS 5.1 Application Guide RADIUS Authentication and Authorization BLADE OS supports the RADIUS (Remote Authentication Dial-in User Service) method to authenticate and authorize remote administrators for managing the switch. This method is based on a client/server model. The Remote Access Server (RAS)—the switch—is a client to the back-end database server. A remote user (the remote administrator) interacts only with the RAS, not the back-end server and database.
BLADE OS 5.1 Application Guide Configuring RADIUS on the Switch Use the following procedure to configure Radius authentication on the GbE2c. For more information, see “RADIUS Server Configuration Notes” on page 269. 1. Turn RADIUS authentication on, then configure the Primary and Secondary RADIUS servers. >> Main# /cfg/sys/radius (Select the RADIUS Server menu) >> RADIUS Server# on (Turn RADIUS on) Current status: OFF New status: ON >> RADIUS Server# prisrv 10.10.1.
BLADE OS 5.1 Application Guide RADIUS Authentication Features in BLADE OS BLADE OS supports the following RADIUS authentication features: Supports RADIUS client on the switch, based on the protocol definitions in RFC 2138 and RFC 2866. Allows a RADIUS secret password of up to 32 characters. Supports secondary authentication server so that when the primary authentication server is unreachable, the switch can send client authentication requests to the secondary authentication server.
BLADE OS 5.1 Application Guide RADIUS Attributes for BLADE OS User Privileges If the authentication server successfully authenticates the remote user, the switch verifies the privileges of the remote user and authorizes the appropriate access. The administrator has the option to allow backdoor access through the console port only, or through the console and Telnet, SSH, HTTP, and HTTPS access.
BLADE OS 5.1 Application Guide TACACS+ Authentication BLADE OS supports authentication, authorization, and accounting with networks using the Cisco Systems TACACS+ protocol. The GbE2c functions as the Network Access Server (NAS) by interacting with the remote client and initiating authentication and authorization sessions with the TACACS+ access server. The remote user is defined as someone requiring management access to the GbE2c either through a data or management port.
BLADE OS 5.1 Application Guide Authorization Authorization is the action of determining a user’s privileges on the device, and usually takes place after authentication. The default mapping between TACACS+ authorization levels and BLADE OS management access levels is shown in Table 4. The authorization levels listed in this table must be defined on the TACACS+ server.
BLADE OS 5.1 Application Guide Accounting Accounting is the action of recording a user's activities on the device for the purposes of billing and/or security. It follows the authentication and authorization actions. If the authentication and authorization is not performed via TACACS+, there are no TACACS+ accounting messages sent out. You can use TACACS+ to record and track software logins, configuration changes, and interactive commands.
BLADE OS 5.1 Application Guide The following rules apply to TACACS+ command authorization and logging: Only commands from a Console, Telnet, or SSH connection are sent for authorization and logging. SNMP, BBI, or file-copy commands (for example, TFTP or sync) are not sent. Only leaf-level commands are sent for authorization and logging. For example, /cfg is not sent, but /cfg/sys/tacacs/cauth is sent. The full path of each command is sent for authorization and logging.
BLADE OS 5.1 Application Guide Configuring TACACS+ Authentication on the Switch 1. Turn TACACS+ authentication on, then configure the Primary and Secondary TACACS+ servers. >> Main# /cfg/sys/tacacs+ (Select the TACACS+ Server menu) >> TACACS+ Server# on (Turn TACACS+ on) Current status: OFF New status: ON >> TACACS+ Server# prisrv 10.10.1.1 (Enter primary server IP) Current primary TACACS+ server: 0.0.0.0 New pending primary TACACS+ server: 10.10.1.1 >> TACACS+ Server# secsrv 10.10.1.
BLADE OS 5.1 Application Guide LDAP Authentication and Authorization BLADE OS supports the LDAP (Lightweight Directory Access Protocol) method to authenticate and authorize remote administrators to manage the switch. LDAP is based on a client/server model. The switch acts as a client to the LDAP server. A remote user (the remote administrator) interacts only with the switch, not the back-end server and database.
BLADE OS 5.1 Application Guide Configuring LDAP Authentication on the Switch 1. Turn LDAP authentication on, then configure the Primary and Secondary LDAP servers. >> Main# /cfg/sys/ldap (Select the LDAP Server menu) >> LDAP Server# on (Turn LDAP on) Current status: OFF New status: ON >> LDAP Server# prisrv 10.10.1.1 (Enter primary server IP) Current primary LDAP server: 0.0.0.0 New pending primary LDAP server: 10.10.1.1 >> LDAP Server# secsrv 10.10.1.
BLADE OS 5.1 Application Guide Secure Shell and Secure Copy Secure Shell (SSH) and Secure Copy (SCP) use secure tunnels to encrypt and secure messages between a remote administrator and the switch. Telnet does not provide this level of security. The Telnet method of managing a GbE2c does not provide a secure connection. SSH is a protocol that enables remote administrators to log securely into the GbE2c over a network to execute management commands.
BLADE OS 5.1 Application Guide Configuring SSH/SCP Features on the Switch Before you can use SSH commands, use the following commands to turn on SSH/SCP. SSH and SCP are disabled by default.
BLADE OS 5.1 Application Guide Configuring the SCP Administrator Password To configure the scpadmin (SCP administrator) password, first connect to the switch via the RS-232 management console. For security reasons, the scpadmin password can be configured only when connected directly to the switch console. To configure the password, enter the following CLI command. At factory default settings, the current SCP administrator password is admin.
BLADE OS 5.1 Application Guide To Upload the Configuration to the Switch Syntax: scp @:putcfg Example: >> # scp ad4.cfg scpadmin@205.178.15.157:putcfg To Apply and Save the Configuration The apply and save commands are still needed after the last command, or use the following commands: >> # scp ad4.cfg scpadmin@205.178.15.157:putcfg_apply >> # scp ad4.cfg scpadmin@205.178.15.
BLADE OS 5.1 Application Guide Generating RSA Host and Server Keys for SSH Access To support the SSH server feature, two sets of RSA keys (host and server keys) are required. The host key is 1024 bits and is used to identify the GbE2c. The server key is 768 bits and is used to make it impossible to decipher a captured session by breaking into the GbE2c at a later time.
BLADE OS 5.1 Application Guide SSH/SCP Integration with TACACS+ Authentication SSH/SCP is integrated with TACACS+ authentication. After the TACACS+ server is enabled on the switch, all subsequent SSH authentication requests will be redirected to the specified TACACS+ 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.
BLADE OS 5.1 Application Guide End User Access Control BLADE OS allows an administrator to define end user accounts that permit end users to perform operation tasks via the switch CLI commands. Once end user accounts are configured and enabled, the switch requires username/password authentication. The user types listed in Table 6 can be assigned to individual users: Table 6 User Access Levels User Type Description and Tasks Performed User The User has no direct responsibility for switch management.
BLADE OS 5.1 Application Guide Strong Passwords The administrator can require use of Strong Passwords for users to access the GbE2c. Strong Passwords enhance security because they make password guessing more difficult.
BLADE OS 5.1 Application Guide Defining User Names and Passwords Use the User ID menu to define user names and passwords. >> User ID 1 # name user1 (Assign name to user ID 1) Current user name: New user name: user1 >> User ID 1 # pswd (Assign password to user ID 1) Changing user1 password; validation required: Enter current admin password: Enter new user1 password: Re-enter new user1 password: New user1 password accepted.
BLADE OS 5.1 Application Guide Listing Current Users To displays the defined user accounts and their current log-in status, enter the following command.
BLADE OS 5.
CHAPTER 2 Ports and Trunking The first part of this chapter describes the different types of ports used on the switch. This information is useful in understanding other applications described in this guide, from the context of the embedded switch/server environment. For specific information on how to configure ports for speed, auto-negotiation, and duplex modes, see the port commands in the BLADE OS 5.1 Command Reference for the HP GbE2c Ethernet Blade Switch for c-Class BladeSystem.
BLADE OS 5.1 Application Guide Ports on the Switch The following table describes the Ethernet ports of the switch, including the port name and function. Note – The actual mapping of switch ports to server Network Interface Controllers (NICs) is dependant on the operating system software, the type of server blade, and the enclosure type. For more information, see the HP GbE2c Ethernet Blade Switch User Guide.
BLADE OS 5.1 Application Guide Port Trunk Groups When using port trunk groups between two switches, as shown in Figure 3, you can create a virtual link between the switches, operating with combined throughput levels that depends on how many physical ports are included. Each GbE2c supports up to 12 trunk groups, and each trunk group can contain up to 8 member ports.
BLADE OS 5.1 Application Guide Statistical Load Distribution In a configured trunk group containing more than one port, the load distribution is determined by information embedded within the data frame. For IP traffic, distribution is based on IP addresses.
BLADE OS 5.1 Application Guide Trunk Group Configuration Rules The trunking feature operates according to specific configuration rules. When creating trunks, consider the following rules that determine how a trunk group reacts in any network topology: All trunks must originate from one device, and lead to one destination device. For example, you cannot combine a link from Server 1 and a link from Server 2, into one trunk group. Any physical switch port can belong to only one trunk group.
BLADE OS 5.1 Application Guide Port Trunking Example In this example, the uplink ports and the crosslink ports on each switch are configured into a total of five trunk groups: two on each switch, and one trunk group at the crosslink between the two switches. Note – The actual mapping of switch ports to NIC interfaces is dependant on the operating system software, the type of server blade, and the enclosure type. For more information, see the HP GbE2c Ethernet Blade Switch User Guide.
BLADE OS 5.1 Application Guide The trunk groups are configured as follows: Trunk groups 1 through 4 consist of two uplink ports each, configured to act as a single link to the upstream routers. The trunk groups on each switch are configured so that there is a link to each router for redundancy. Trunk group 5 is configured by default on the crosslink ports 17 and 18, which connect the switches 1 and 2 together.
BLADE OS 5.1 Application Guide 3. Examine the trunking information on each switch using the following command: >> /info/l2/trunk (View trunking information) Information about each port in each configured trunk group will be displayed. Make sure that trunk groups consist of the expected ports and that each port is in the expected state. Configurable Trunk Hash Algorithm The GbE2c allows you to change the parameters for the trunk hash algorithm.
BLADE OS 5.1 Application Guide Link Aggregation Control Protocol LACP Overview Link Aggregation Control Protocol (LACP) is an IEEE 802.3ad standard for grouping several physical ports into one logical port (known as a dynamic trunk group or Link Aggregation group) with any device that supports the standard. Please refer to IEEE 802.3ad-2002 for a full description of the standard. The 802.
BLADE OS 5.1 Application Guide In the configuration shown in Table 8 on page 73, Actor switch ports 20 and 21 aggregate to form an LACP trunk group with Partner switch ports 1 and 2. At the same time, Actor switch ports 22 and 23 form a different LACP trunk group with a different partner. LACP automatically determines which member links can be aggregated and then aggregates them. It provides for the controlled addition and removal of physical links for the link aggregation.
BLADE OS 5.1 Application Guide Configuring LACP Use the following procedure to configure LACP for port 20 and port 21 to participate in link aggregation. 1. Set the LACP mode on port 20. >> # /cfg/l2/lacp/port 20 >> LACP port 20# mode active (Select port 20) (Set port 20 to LACP active mode) 2. Define the admin key on port 20. Only ports with the same admin key can form a LACP trunk group.
BLADE OS 5.
CHAPTER 3 Port-Based Network Access Control Port-Based Network Access control provides a means of authenticating and authorizing devices attached to a LAN port that has point-to-point connection characteristics. It prevents access to ports that fail authentication and authorization. This feature provides security to ports of the HP GbE2c Ethernet Blade Switch (GbE2c) that connect to blade servers.
BLADE OS 5.1 Application Guide Extensible Authentication Protocol over LAN BLADE OS can provide user-level security for its ports using the IEEE 802.1X protocol, which is a more secure alternative to other methods of port-based network access control. Any device attached to an 802.1X-enabled port that fails authentication is prevented access to the network and denied services offered through that port. The 802.
BLADE OS 5.1 Application Guide EAPoL Authentication Process The clients and authenticators communicate using Extensible Authentication Protocol (EAP), which was originally designed to run over PPP, and for which the IEEE 802.1X Standard has defined an encapsulation method over Ethernet frames, called EAP over LAN (EAPOL). Figure 5 shows a typical message exchange initiated by the client. Figure 5 Authenticating a Port Using EAPoL RADIUS Server 802.
BLADE OS 5.1 Application Guide EAPoL Message Exchange During authentication, EAPOL messages are exchanged between the client and the GbE2c authenticator, while RADIUS-EAP messages are exchanged between the GbE2c authenticator and the RADIUS server. Authentication is initiated by one of the following methods: The GbE2c authenticator sends an EAP-Request/Identity packet to the client Client sends an EAPOL-Start frame to the GbE2c authenticator, which responds with an EAP-Request/Identity frame.
BLADE OS 5.1 Application Guide EAPoL Port States The state of the port determines whether the client is granted access to the network, as follows: Unauthorized While in this state the port discards all ingress and egress traffic except EAP packets. Authorized When the client is successfully authenticated, the port transitions to the authorized state allowing all traffic to and from the client to flow normally. Force Unauthorized You can configure this state that denies all access to the port.
BLADE OS 5.1 Application Guide Supported RADIUS Attributes The 802.1X Authenticator relies on external RADIUS servers for authentication with EAP. Table 9 lists the RADIUS attributes that are supported as part of RADIUS-EAP authentication based on the guidelines specified in Annex D of the 802.1X standard and RFC 3580. Table 9 Support for RADIUS Attributes # Attribute Attribute Value 1 User-Name The value of the Type-Data field from the supplicant’s EAP-Response/Identity message.
BLADE OS 5.1 Application Guide Table 9 Support for RADIUS Attributes # Attribute Attribute Value A-R A-A A-C A-R 80 MessageAuthenticator Always present whenever an EAP-Message attribute is also included. Used to integrity-protect a packet. 1 1 1 1 87 NAS-Port-ID Name assigned to the authenticator port, e.g.
BLADE OS 5.1 Application Guide EAPoL Configuration Guidelines When configuring EAPoL, consider the following guidelines: The 802.1X port-based authentication is currently supported only in point-to-point configurations, that is, with a single supplicant connected to an 802.1X-enabled switch port. When 802.1X is enabled, a port has to be in the authorized state before any other Layer 2 feature can be operationally enabled.
BLADE OS 5.1 Application Guide Port-Based Traffic Control Port-based traffic control prevents switch ports from being disrupted by LAN storms. A LAN storm occurs when data packets flood the LAN, which can cause the network to become congested and slow down. Errors in the protocol-stack implementation or in the network configuration can cause a LAN storm.
BLADE OS 5.
CHAPTER 4 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.
BLADE OS 5.1 Application Guide Ports are grouped into broadcast domains by assigning them to the same VLAN. Frames received in one VLAN can only be forwarded within that VLAN, and multicast, broadcast, and unknown unicast frames are flooded only to ports in the same VLAN. The HP GbE2c Ethernet Blade Switch (GbE2c) supports jumbo frames with a Maximum Transmission Unit (MTU) of 9,216 bytes. Within the frame, 18 bytes are reserved for the Ethernet header and CRC trailer.
BLADE OS 5.1 Application Guide The default configuration for the switch sets all ports (except the management port) as untagged members of VLAN 1, and sets the PVID to 1. In the default configuration example, all incoming packets are assigned to VLAN 1 by the default port VLAN identifier (PVID=1).
BLADE OS 5.1 Application Guide VLAN Tagging BLADE OS software supports 802.1Q VLAN tagging, providing standards-based VLAN support for Ethernet systems. Tagging places the VLAN identifier in the frame header of a packet, allowing each port to belong to multiple VLANs. When you add a port to multiple VLANs, you also must enable tagging on that port.
BLADE OS 5.1 Application Guide Figure 6 Default VLAN Settings 802.1Q Switch VLAN 1 Port 1 Port 2 Port 3 Port 4 Port 5 Port 6 Port 7 ...
BLADE OS 5.1 Application Guide Figure 7 Port-Based VLAN Assignment Data SA Port 4 CRC DA Before Port 2 Port 3 Tagged member of VLAN 2 Port 5 Port 1 PVID = 2 Untagged packet 802.1Q Switch Port 6 Port 7 Port 8 Untagged member of VLAN 2 As shown in Figure 8, the untagged packet is marked (tagged) as it leaves the switch through port 5, which is configured as a tagged member of VLAN 2.
BLADE OS 5.1 Application Guide As shown in Figure 10, the tagged packet remains unchanged as it leaves the switch through port 5, which is configured as a tagged member of VLAN 2. However, the tagged packet is stripped (untagged) as it leaves the switch through port 7, which is configured as an untagged member of VLAN 2. Figure 10 802.1Q Tagging (after 802.1Q tag assignment) Port 4 Port 1 Port 2 802.
BLADE OS 5.1 Application Guide VLAN Topologies and Design Considerations By default, all switch ports are configured to the default VLAN 1. This configuration groups all ports into the same broadcast domain. The VLAN has an 802.1Q VLAN ID of 1. VLAN tagging is turned off, because, by default, all ports are members of a single VLAN only. If configuring Spanning Tree Protocol (/cfg/l2/stp), note that each of spanning tree groups 2–128 may contain only one VLAN.
BLADE OS 5.1 Application Guide Multiple VLANs with Tagging Adapters The following example shows only those switch port to server links that must be configured for the example. While not shown, all other server links remain set at their default settings.
BLADE OS 5.1 Application Guide The features of this VLAN are described in the following table: Table 10 Multiple VLANs with Tagging Component Description Switch 1 Switch 1 is configured for VLANS 1, 2, and 3. Port 1 is tagged to accept traffic from VLANs 1 and 2. Ports 17 and 18 are tagged members of a trunk that accepts traffic from VLANs 1 and 3. Port 20 is tagged to accept traffic from VLANs 1, 2, and 3. Port 21 is an untagged member of VLAN 2. Switch 2 Switch 2 is configured for VLANS 1, 3, and 4.
BLADE OS 5.1 Application Guide Configuring Ports and VLANs on Example Switch 1 To configure ports and VLANs on Switch 1, do the following: 1. On Switch 1, enable VLAN tagging on the necessary ports. Main# /cfg/port 1 >> Port 1# tag e (Select port 1: connection to server 1) (Enable tagging) Current VLAN tag support: disabled New VLAN tag support: enabled Port 1 changed to tagged.
BLADE OS 5.1 Application Guide 2. Configure the VLANs and their member ports. Since all ports are by default configured for VLAN 1, configure only those ports that belong to VLAN 2. Crosslink ports 17 and 18 must belong to VLANs 1 and 2.
BLADE OS 5.1 Application Guide Configuring ports and VLANs on Example Switch 2 To configure ports and VLANs on Switch 2, do the following: 1. On Switch 2, enable VLAN tagging on the necessary ports. Port 4 (connection to server 2) remains untagged, so it is not configured below. Main# /cfg/port 2 >> Port 2# tag e Current VLAN tag support: disabled New VLAN tag support: enabled Port 2 changed to tagged.
BLADE OS 5.1 Application Guide 2. Configure the VLANs and their member ports. Since all ports are by default configured for VLAN 1, configure only those ports that belong to other VLANs.
BLADE OS 5.1 Application Guide Protocol-Based VLANs Protocol-based VLANs (PVLANs) allow you to segment network traffic according to the network protocols in use. Traffic for supported network protocols can be confined to a particular port-based VLAN. You can give different priority levels to traffic generated by different network protocols. With PVLAN, the switch classifies incoming packets by Ethernet protocol of the packets, not by the configuration of the ingress port.
BLADE OS 5.1 Application Guide Port-Based vs. Protocol-Based VLANs Each VLAN supports both port-based and protocol-based association, as follows: The default VLAN configuration is port-based. All data ports are members of VLAN 1, with no PVLAN association. When you add ports to a PVLAN, the ports become members of both the port-based VLAN and the PVLAN. For example, if you add port 20 to PVLAN 1 on VLAN 2, the port also becomes a member of VLAN 2.
BLADE OS 5.1 Application Guide PVLAN Configuration Guidelines Consider the following guidelines when you configure protocol-based VLANs: Each port can support up to 16 VLAN protocols. The GbE2c can support up to 16 protocols simultaneously. Each PVLAN must have at least one port assigned before it can be activated. The same port within a port-based VLAN can belong to multiple PVLANs. An untagged port can be a member of multiple PVLANs.
BLADE OS 5.1 Application Guide 3. Add member ports for this PVLAN. >> VLAN 2 Protocol 1# add 1 Port 1 is an UNTAGGED port and its current PVID is 1. Confirm changing PVID from 1 to 2 [y/n]: y Current ports for VLAN 2: empty Current ports for VLAN 1, Protocol 3: empty Pending new ports for VLAN 2: 1 Pending new ports for VLAN 2, Protocol 1: 1 >> VLAN Port 20 Confirm Current Current Pending Pending 2 Protocol 1# add 20 is an UNTAGGED port and its current PVID is 1.
BLADE OS 5.1 Application Guide 6. Verify PVLAN operation.
BLADE OS 5.1 Application Guide Private VLANs Private VLANs provide Layer 2 isolation between the ports within the same broadcast domain. Private VLANs can control traffic within a VLAN domain, and provide port-based security for host servers. Use Private VLANs to partition a VLAN domain into sub-domains. Each sub-domain is comprised of one primary VLAN and one secondary VLAN, as follows: Primary VLAN—carries unidirectional traffic downstream from promiscuous ports.
BLADE OS 5.1 Application Guide Private VLANs Configuration Guidelines The following guidelines apply when configuring Private VLANs: The management VLAN 4095 cannot be a Private VLAN. Management port 19 cannot be a member of a Private VLAN. The default VLAN 1 cannot be a Private VLAN. Protocol-based VLANs cannot be used the same ports as Private VLANs. Protocol-based VLANs must be disabled on ports that use Private VLANs. IGMP Snooping must be disabled on isolated VLANs.
BLADE OS 5.1 Application Guide FDB Static Entries Static entries in the Forwarding Database (FDB) allow the switch to forward packets without flooding ports to perform a lookup. A FDB static entry is a MAC address associated with a specific port and VLAN. The switch supports 128 static entries. Static entries are manually configured, using the following command: /cfg/l2/fdb/static FDB static entries are permanent, so the FDB Aging value does not apply to them.
CHAPTER 5 Spanning Tree Protocol When multiple paths exist on a network, Spanning Tree Protocol (STP) allows the switch to determine the most efficient path.
BLADE OS 5.1 Application Guide The relationship between port, trunk groups, VLANs, and STP Groups is shown in Table 11. Table 11 Ports, Trunk Groups, and VLANs Switch Element Belongs To Port Trunk group, or one or more VLANs Trunk group One or more VLANs VLAN (non-default) One Spanning Tree Group Note – The sequence used by STP for listening, learning, and forwarding or blocking, is lengthy and delays may occur.
BLADE OS 5.1 Application Guide Determining the Path for Forwarding BPDUs When determining which port to use for forwarding and which port to block, the HP GbE2c Ethernet Blade Switch uses information in the BPDU, including each bridge priority ID. A technique based on the “lowest root cost” is then computed to determine the most efficient path for forwarding. Bridge Priority The bridge priority parameter controls which bridge on the network is the STP Group root bridge.
BLADE OS 5.1 Application Guide Spanning Tree Group Configuration Guidelines This section provides important information on configuring Spanning Tree Groups (STGs). Default Spanning Tree configuration In the default configuration, a single STG with the ID of 1 includes all ports on the switch, except management port 19. STG 1 is called the default STG. All other STGs are empty, except management STG 128, and VLANs must be added by the user. You cannot assign ports directly to an STG.
BLADE OS 5.1 Application Guide When creating a VLAN, also consider the following: VLANs must be contained within a single STG; a VLAN cannot span multiple STGs. By confining VLANs within a single STG, you avoid problems with spanning tree blocking ports and causing a loss of connectivity within the VLAN. When a VLAN spans multiple switches, it is recommended that the VLAN remain within the same Spanning Tree Group (have the same STG ID) across all the switches.
BLADE OS 5.1 Application Guide The relationship between ports, trunk groups, VLANs, and spanning trees is shown in Table 12.
BLADE OS 5.1 Application Guide Multiple Spanning Trees Each HP GbE2c Ethernet Blade Switch supports a maximum of 128 Spanning Tree Groups (STGs). Multiple STGs provide multiple data paths, which can be used for load-balancing and redundancy. You enable load balancing between two GbE2c modules using multiple STGs by configuring each path with a different VLAN and then assigning each VLAN to a separate STG. Each STG is independent.
BLADE OS 5.1 Application Guide Figure 12 Two VLANs on One Instance of Spanning Tree Protocol VLAN 1, STG 1 Switch 1 20 21 X 20 21 Switch 2 VLAN 2, STG 1 is blocked by STP In Figure 13, VLAN 1 and VLAN 2 belong to different Spanning Tree Groups. The two instances of spanning tree separate the topology without forming a loop, so that both VLANs can forward packets between the switches without losing connectivity.
BLADE OS 5.1 Application Guide Configuring Multiple Spanning Tree Groups This section explains how to assign each VLAN to its own Spanning Tree Group on example switches 1 and 2. By default, Spanning Tree Groups 2-127 are empty, and Spanning Tree Group 1 contains all configured VLANs until individual VLANs are explicitly assigned to other Spanning Tree Groups. Except for the default Spanning Tree Group 1, which may contain more than one VLAN, Spanning Tree Groups 2-128 may contain only one VLAN each.
BLADE OS 5.1 Application Guide Port Fast Forwarding Port Fast Forwarding permits a port that participates in Spanning Tree to bypass the Listening and Learning states and enter directly into the Forwarding state. While in the Forwarding state, the port listens to the BPDUs to learn if there is a loop and, if dictated by normal STG behavior (following priorities, etc.), the port transitions into the Blocking state.
BLADE OS 5.1 Application Guide Configuring Fast Uplink Convergence Use the following CLI commands to enable Fast Uplink Convergence on uplink ports. >> # /cfg/l2/upfast ena >> Layer 2# apply >> Layer 2# save (Enable Fast Uplink convergence) (Make your changes active) (Save for restore after reboot) Hot Links For network topologies that require Spanning Tree to be turned off, Hot Links provides basic link redundancy with fast recovery. Hot Links consists of up to five triggers.
BLADE OS 5.1 Application Guide FDB Update Use the FDB update option to notify other devices on the network about updates to the Forwarding Database (FDB). When you enable FDB update (/cfg/l2/hotlinks/sndfdb ena), the switch sends multicasts of addresses in the forwarding database (FDB) over the active interface, so that other devices on the network can learn the new path.
CHAPTER 6 RSTP and MSTP IEEE 802.1w Rapid Spanning Tree Protocol enhances the Spanning Tree Protocol to provide rapid convergence on Spanning Tree Group 1. IEEE 802.1s Multiple Spanning Tree Protocol extends the Rapid Spanning Tree Protocol, to provide both rapid convergence and load balancing in a VLAN environment.
BLADE OS 5.1 Application Guide Rapid Spanning Tree Protocol Rapid Spanning Tree Protocol (RSTP) provides rapid convergence of the spanning tree and provides for fast re-configuration critical for networks carrying delay-sensitive traffic such as voice and video. RSTP significantly reduces the time to reconfigure the active topology of the network when changes occur to the physical topology or its configuration parameters. RSTP reduces the bridged-LAN topology to a single Spanning Tree.
BLADE OS 5.1 Application Guide Port Type and Link Type Spanning Tree configuration includes the following parameters to support RSTP and MSTP: edge port link type. Although these parameters are configured for Spanning Tree Groups 1-128 (/cfg/l2/stg /port ), they only take effect when RSTP/MSTP is turned on. Edge Port A port that does not connect to a bridge is called an edge port. Edge ports generally connect to a server, therefore, ports 1-16 should have edge enabled.
BLADE OS 5.1 Application Guide RSTP Configuration Guidelines When Rapid Spanning Tree Protocol (RSTP) is turned on, the following applies: STP parameters apply only to STP Group (STG) 1. Only STG 1 is available. All other STGs are turned off. All VLANs, including management VLANs, are moved to STG 1. RSTP Configuration Example This section provides steps to configure Rapid Spanning Tree on the HP GbE2c Ethernet Blade Switch (GbE2c), using the Command-Line Interface (CLI). 1.
BLADE OS 5.1 Application Guide Multiple Spanning Tree Protocol IEEE 802.1s Multiple Spanning Tree extends the IEEE 802.1w Rapid Spanning Tree Protocol through multiple Spanning Tree Groups. MSTP maintains up to 32 spanning-tree instances, that correspond to STP Groups 1-32. For more information about Spanning Tree Protocol, see “Spanning Tree Protocol” on page 109. In Multiple Spanning Tree Protocol (MSTP), several VLANs can be mapped to each Spanning-Tree instance.
BLADE OS 5.1 Application Guide MSTP Configuration Guidelines When Multiple Spanning Tree Protocol is turned on, the following applies: The switch automatically moves all VLANs from STP Group 1 to the Common Internal Spanning Tree (CIST). The switch automatically moves management VLAN 4095 to the CIST. When MSTP is turned off, the switch moves VLAN 4095 from the CIST to Spanning Tree Group 128. Region Name must be configured. By default, the revision level is set to 1.
CHAPTER 7 Link Layer Discovery Protocol The BLADE OS software support Link Layer Discovery Protocol (LLDP). This chapter discusses the use and configuration of LLDP on the switch: “LLDP Overview” on page 127 “Enabling or Disabling LLDP” on page 128 “LLDP Transmit Features” on page 129 “LLDP Receive Features” on page 133 “LLDP Example Configuration” on page 135 LLDP Overview Link Layer Discovery Protocol (LLDP) is an IEEE 802.
BLADE OS 5.1 Application Guide The LLDP information to be distributed by the GbE2c ports, and that which has been collected from other LLDP stations, is stored in the switch’s Management Information Base (MIB). Network Management Systems (NMS) can use Simple Network Management Protocol (SNMP) to access this MIB information. LLDP-related MIB information is read-only.
BLADE OS 5.1 Application Guide LLDP Transmit Features Numerous LLDP transmit options are available, including scheduled and minimum transmit interval, expiration on remote systems, SNMP trap notification, and the types of information permitted to be shared. Scheduled Interval The GbE2c can be configured to transmit LLDP information to neighboring devices once each 5 to 32768 seconds. The scheduled interval is global; the same interval value applies to all LLDP transmit-enabled ports.
BLADE OS 5.1 Application Guide Time-to-Live for Transmitted Information The transmitted LLDP information is held by remote systems for a limited time. A time-to-live parameter allows the switch to determine how long the transmitted data should be held before it expires. The hold time is configured as a multiple of the configured transmission interval. >> # /cfg/l2/lldp/msgtxhld where multiplier is a value between 2 and 10.
BLADE OS 5.1 Application Guide If SNMP trap notification is enabled, the notification messages can also appear in the system log. This is enabled by default.
BLADE OS 5.1 Application Guide LLDP transmissions can also be configured to enable or disable inclusion of optional information, using the following command: >> # /cfg/l2/lldp/port /tlv/ {ena|dis} where type is an LLDP information option from Table 15: Table 15 LLDP Optional Information Types Type Description portdesc Port Description sysname System Name sysdescr System Description syscap System Capabilities mgmtaddr Management Address portvid IEEE 802.
BLADE OS 5.
BLADE OS 5.1 Application Guide To view detailed information for a remote device, specify the Index number as found in the summary.
BLADE OS 5.1 Application Guide LLDP Example Configuration 1. Turn LLDP on globally. >> # /cfg/l2/lldp/on 2. Set the global LLDP timer features. >> >> >> >> >> LLDP# LLDP# LLDP# LLDP# LLDP# (Schedule transmit every 30 seconds) (Never more often than 2 seconds) (Hold on remote side for 4 intervals) (Wait 2 seconds after reinitialization) (Minimum 5 seconds between traps) msgtxint 30 txdelay 2 msgtxhld 4 redelay 2 notifint 5 3. Set LLDP options for each port.
BLADE OS 5.
CHAPTER 8 Quality of Service Quality of Service features allow you to allocate network resources to mission-critical applications at the expense of applications that are less sensitive to such factors as time delays or network congestion. You can configure your network to prioritize specific types of traffic, ensuring that each type receives the appropriate Quality of Service (QoS) level.
BLADE OS 5.1 Application Guide Figure 14 QoS Model Ports Ingress Classify Packets Meter Traffic Perform Actions ACL Filter ACL Meter Drop/Pass/ Re-Mark Queue and Schedule Egress COS Queue The GbE2c uses the Differentiated Services (DiffServ) architecture to provide QoS functions. DiffServ is described in IETF RFC 2474 and RFC 2475. With DiffServ, you can establish policies to direct traffic.
BLADE OS 5.1 Application Guide Using ACL Filters Access Control Lists (ACLs) are filters that allow you to classify and segment traffic, so you can provide different levels of service to different traffic types. Each filter defines the conditions that must match for inclusion in the filter, and also the actions that are performed when a match is made.
BLADE OS 5.
BLADE OS 5.1 Application Guide Summary of ACL Actions Actions determine how the traffic is treated. The GbE2c QoS actions include the following: Pass or Drop Re-mark a new DiffServ Code Point (DSCP) Re-mark the 802.
BLADE OS 5.1 Application Guide Table 19 ACI Precedence Groups Precedence Group Member ACLs Supported Packet Classifiers Precedence Group 3 ACL 255 – ACL 381 Source MAC address Source IP address Ethernet type VLAN ID 802.
BLADE OS 5.1 Application Guide For each precedence group, only the first assigned ACL that matches the port traffic is considered. If multiple ACLs in the precedence group match the traffic, only the one with the lowest ACL number is considered. The others in the precedence group are ignored. One ACL match from each precedence group is permitted, meaning that up to six ACL matches may be considered for action: one from precedence group 1, one from precedence group 2, and so on.
BLADE OS 5.1 Application Guide Access Control List Groups An Access Control List Group (ACL Group) is a collection of ACLs. For example: ACL Group 1 ACL 300: VLAN = 1 SIP = 10.10.10.1 (255.255.255.0) Action = permit ACL 301: VLAN = 2 SIP = 10.10.10.2 (255.255.255.0) Action = deny ACL 500: DIP = 10.10.10.3 (255.255.255.0) Action = permit ACL Groups organize ACLs into traffic profiles that can be more easily assigned to ports. The GbE2c supports up to 762 ACL Groups.
BLADE OS 5.1 Application Guide ACL Metering and Re-Marking You can define a profile for the aggregate traffic flowing through the GbE2c by configuring a QoS meter (if desired) and assigning ACL Groups to ports. When you add ACL Groups to a port, make sure they are ordered correctly in terms of precedence. Actions taken by an ACL are called In-Profile actions. You can configure additional In-Profile and Out-of-Profile actions on a port.
BLADE OS 5.1 Application Guide ACL Configuration Examples The following configuration examples illustrate how to use ACLs to block traffic. These basic configurations illustrate common principles of ACL filtering. Note – Each ACL filters traffic that ingresses on the port to which the ACL is added. The egrport classifier filters traffic that ingresses the port to which the ACL is added, and then egresses the port specified by egrport. In most common configurations, egrport is not used.
BLADE OS 5.1 Application Guide 1. Configure an Access Control List. >> >> >> >> >> Main# cfg/acl/acl 401 (Define ACL 401) ACL 401# ipv4/sip 100.10.1.0 255.255.255.0 Filtering IPv4# dip 200.20.2.2 255.255.255.255 Filtering IPv4# .. ACL 401# action deny 2. Add ACL 2 to port 21. >> ACL 2# /cfg/port 21/aclqos >> Port 21 ACL# add acl 401 (Select port 21 to assign ACLs) (Assign ACL 2 to the port) 3. Apply and save the configuration.
BLADE OS 5.1 Application Guide Using DSCP Values to Provide QoS The six most significant bits in the TOS byte of the IP header are defined as DiffServ Code Points (DSCP). Packets are marked with a certain value depending on the type of treatment the packet must receive in the network device. DSCP is a measure of the Quality of Service (QoS) level of the packet. Differentiated Services Concepts To differentiate between traffic flows, packets can be classified by their DSCP value.
BLADE OS 5.1 Application Guide Per-Hop Behavior The DSCP value determines the Per Hop Behavior (PHB) of each packet. The PHB is the forwarding treatment given to packets at each hop. QoS policies are built by applying a set of rules to packets, based on the DSCP value, as they hop through the network. The GbE2c default settings are based on the following standard PHBs, as defined in the IEEE standards: Expedited Forwarding (EF)—This PHB has the highest egress priority and lowest drop precedence level.
BLADE OS 5.1 Application Guide QoS Levels Table 20 shows the default service levels provided by the GbE2c, listed from highest to lowest importance: Table 20 Default QoS Service Levels Service Level Default PHB 802.
BLADE OS 5.1 Application Guide Using 802.1p Priorities to Provide QoS 802.1p Overview BLADE OS provides Quality of Service functions based on the priority bits in a packet’s VLAN header. (The priority bits are defined by the 802.1p standard within the IEEE 802.1q VLAN header.) The 802.1p bits, if present in the packet, specify the priority that should be given to packets during forwarding.
BLADE OS 5.1 Application Guide Use the /cfg/qos/8021p/cur command to display the mapping between 802.1p values, Class of Service queues (COSq), and COSq scheduling weights: >> Main# /cfg/qos/8021p/cur Current priority to COS queue configuration: Number of COSq: 2 Priority COSq Weight -------- ---- -----0 0 1 1 0 1 2 0 1 3 0 1 4 1 2 5 1 2 6 1 2 7 1 2 802.1p Configuration Example 1. Configure a port’s default 802.1p priority. >> Main# cfg/port 20 >> Port 20# 8021ppri Current 802.
BLADE OS 5.1 Application Guide Queuing and Scheduling The GbE2c can have 2 output Class of Service (COS) queues per port, into which each packet is placed. Each packet’s 802.1p priority determines its COS queue, except when an ACL action sets the COS queue of the packet. Each COS queue uses Weighted Round Robin (WRR) scheduling, with user configurable weight from 1 to 15. The weight of 0 (zero) indicates strict priority, which might starve the low priority queues.
BLADE OS 5.
Part 2: IP Routing This section discusses Layer 3 switching functions. In addition to switching traffic at near line rates, the application switch can perform multi-protocol routing.
BLADE OS 5.
CHAPTER 9 Basic IP Routing This chapter provides configuration background and examples for using the HP GbE2c Ethernet Blade Switch (GbE2c) to perform IP routing functions. The following topics are addressed in this chapter: “IP Routing Benefits” on page 157 “Routing Between IP Subnets” on page 158 “Dynamic Host Configuration Protocol” on page 164 IP Routing Benefits The GbE2c uses a combination of configurable IP switch interfaces and IP routing options.
BLADE OS 5.1 Application Guide Routing Between IP Subnets The physical layout of most corporate networks has evolved over time. Classic hub/router topologies have given way to faster switched topologies, particularly now that switches are increasingly intelligent. The GbE2c is intelligent and fast enough to perform routing functions on a par with wire speed Layer 2 switching.
BLADE OS 5.1 Application Guide Even if every end-station could be moved to better logical subnets (a daunting task), competition for access to common server pools on different subnets still burdens the routers. This problem is solved by using GbE2cs with built-in IP routing capabilities. Cross-subnet LAN traffic can now be routed within the switches with wire speed Layer 2 switching performance.
BLADE OS 5.1 Application Guide Subnet Routing Example 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 BLADE OS 5.1 Command Reference. 1. Assign an IP address (or document the existing one) for each router and client workstation.
BLADE OS 5.1 Application Guide IP interfaces are configured using the following commands at the CLI: >> >> >> >> >> >> >> >> >> >> >> >> # /cfg/l3/if IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface 1 1# 1# 1# 2# 2# 2# 3# 3# 3# 4# 4# addr 205.21.17.3 ena ../if 2 addr 100.20.10.1 ena ../if 3 addr 131.15.15.1 ena ../if 4 addr 206.30.15.
BLADE OS 5.1 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.
BLADE OS 5.1 Application Guide Each time you add a port to a VLAN, you may get the following prompt: Port 1 is an untagged port and its current PVID is 1. Confirm changing PVID from 1 to 2 [y/n]? Enter y to set the default Port VLAN ID (PVID) for the port. 3. Add each IP interface to the appropriate VLAN. Now that the ports are separated into three VLANs, the IP interface for each subnet must be placed in the appropriate VLAN.
BLADE OS 5.1 Application Guide Dynamic Host Configuration Protocol 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.
BLADE OS 5.1 Application Guide DHCP Relay Agent Configuration To enable the GbE2c to be the BOOTP forwarder, you need to configure the DHCP/BOOTP server IP addresses on the switch. Generally, you should configure the switch IP interface on the client side to match the client’s subnet, and configure VLANs to separate client and server subnets. The DHCP server knows from which IP subnet the newly allocated IP address should come.
BLADE OS 5.1 Application Guide DHCP Server Configuration To modify the DHCP server configuration, open the configuration file (dhcpd.conf), and add new classes for server ports. Then define an IP address for each class. For Linux DHCP servers, option 82 information is referenced by the following variables: option agent.circuit-id option agent.remote-id You can use these variables in any expression allowed within a DHCP configuration file.
BLADE OS 5.1 Application Guide In the following example, one new class is added to define server port 2, then an IP address is associated with the new class: ******CLASS****** # in this class I have defined a switch in chassis with ID # 55:53:45:36:33:35:31:4d:34:36:00:00:00:00:00:00 # placed in slot 1 and blade server is connected in port 2 class "chass_a _sw_1_port_2" { match if option agent.circuit-id = 55:53:45:36:33:35:31:4d:34:36:00:00:00:00:00:00 and option agent.
BLADE OS 5.1 Application Guide ServerMobility The ServerMobility™ feature allows you to assign server IP addresses based on their physical location in a blade chassis. If a server fails, a replacement server can assume the identity of the failed unit. The replacement can be a new blade server placed into the slot of the failed unit, or it can be a backup server in another slot.
BLADE OS 5.1 Application Guide Switch Name-Based Scheme The switch option is the default scheme.
BLADE OS 5.1 Application Guide Chassis-Based Scheme Using the chassis option, the chassis ID, slot number, and port information are inserted into the DHCP request. The format of the information varies depending on the encoding method used by the DHCP server (option 61 or 82).
BLADE OS 5.1 Application Guide Configuring ServerMobility on the Switch Perform the following steps to configure the ServerMobility feature: 1. Turn on BOOTP Relay. >> /cfg/l3/bootp/on >> Bootstrap Protocol Relay# addr 10.10.1.1 Current bootp server: 0.0.0.0 New pending bootp server: 10.10.1.1 2. Turn on the ServerMobility feature, and add ports. >> /cfg/l3/sm/on >> ServerMobility# add 1 2 Confirm to enable DHCP request filtering on selected ports? [y/n]: y 3.
BLADE OS 5.1 Application Guide 5. Verify ServerMobility information. >> /info/l3/sm/port -----------------------------------------------------Server Mobility Port 1 Information: agent.circuit-id = 55:53:45:36:33:35:31:4d:34:36:00:00:00:00:00:00 agent.remote-id = 01:00:00:00:01 Server Mobility : enabled Filtering : enabled Port 1 has backup port 3 -----------------------------------------------------Server Mobility Port 2 Information: agent.circuit-id = 55:53:45:36:33:35:31:4d:34:36:00:00:00:00:00:00 agent.
BLADE OS 5.1 Application Guide Switch Name Identifiers In the following examples, consider a switch named “BladeS1”. Depending on the port type, the dhcpd.conf configuration might appear as follows. Using DHCP Option 61 Client Identifiers For non-trunked ports 1 and 7: group { host BntHost1 { option dhcp-client-identifier "\000BladeS1-1"; fixed-address 172.31.160.161; } host BntHost7 { option dhcp-client-identifier "\000BladeS1-7"; fixed-address 172.31.160.
BLADE OS 5.1 Application Guide Using DCHP Option 82 Agent Identifiers class "class-Blade-port1" { match if option agent.remote-id = 0:0:0:0:01 and option agent.circuit-id = "BladeS1"; } class "class-Blade-port7" { match if option agent.remote-id = 0:0:0:0:07 and option agent.circuit-id = "BladeS1"; } subnet 172.31.0.0 netmask 255.255.0.0 { pool { allow members of "class-Blade-port1"; range 172.31.160.161; } pool { allow members of "class-Blade-port7"; range 172.31.160.
BLADE OS 5.1 Application Guide Using DHCP Option 82 Agent Identifiers class "class-vmac-switch1-port1" { match if option agent.circuit-id = 0:13:0a:4f:7c:41 } class "class-vmac-switch1-port7" { match if option agent.circuit-id = 0:13:0a:4f:7c:47 } subnet 172.31.160.0 netmask 255.255.255.0 { pool { allow members of "class-vmac-switch1-port1"; range 172.31.160.161; } pool { allow members of "class-vmac-switch1-port7"; range 172.31.160.
BLADE OS 5.1 Application Guide Chassis-Based Identifiers The following example configuration declares a class for the server connected to port 8 of a switch in slot 1 of chassis ID of “ChasR1”. Using DHCP Option 61 Client Identifiers: group { host BntHost1 { option dhcp-client-identifier "\000ChasR1-1-1"; fixed-address 172.31.160.161; } } Note – The \000 in front of the chassis ID is the octal “type” byte required in the client identifier.
CHAPTER 10 Routing Information Protocol In a routed environment, routers communicate with one another to keep track of available routes. Routers can learn about available routes dynamically using the Routing Information Protocol (RIP). BLADE OS software supports RIP version 1 (RIPv1) and RIP version 2 (RIPv2) for exchanging TCP/IP route information with other routers. Distance Vector Protocol RIP is known as a distance vector protocol.
BLADE OS 5.1 Application Guide Routing Updates RIP sends routing-update messages at regular intervals and when the network topology changes. Each router “advertises” routing information by sending a routing information update every 30 seconds. If a router doesn’t receive an update from another router for 180 seconds, those routes provided by that router are declared invalid. The routes are removed from the routing table, but they remain in the RIP routes table (/info/l3/rip/routes).
BLADE OS 5.1 Application Guide RIPv2 in RIPv1 Compatibility Mode BLADE OS allows you to configure RIPv2 in RIPv1compatibility mode, for using both RIPv2 and RIPv1 routers within a network. In this mode, the regular routing updates use broadcast UDP data packet to allow RIPv1 routers to receive those packets. With RIPv1 routers as recipients, the routing updates have to carry natural or host mask. Hence, it is not a recommended configuration for most network topologies.
BLADE OS 5.1 Application Guide Default The RIP router can listen and supply a default route, usually represented as 0.0.0.0 in the routing table. When a router does not have an explicit route to a destination network in its routing table, it uses the default route to forward those packets. Metric The metric field contains a configurable value between 1 and 15 (inclusive) which specifies the current metric for the interface. The metric value typically indicates the total number of hops to the destination.
BLADE OS 5.1 Application Guide RIP Configuration Example Note – An interface RIP disabled uses all the default values of the RIP, no matter how the RIP parameters are configured for that interface. RIP sends out RIP regular updates to include an UP interface, but not a DOWN interface. 1. Add VLANs for routing interfaces.
BLADE OS 5.
CHAPTER 11 IGMP Internet Group Management Protocol (IGMP) is used by IP Multicast routers to learn about the existence of host group members on their directly attached subnet (see RFC 2236). The IP Multicast routers get this information by broadcasting IGMP Membership Queries and listening for IP hosts reporting their host group memberships.
BLADE OS 5.1 Application Guide IGMP Snooping IGMP Snooping allows the switch to forward multicast traffic only to those ports that request it. IGMP Snooping prevents multicast traffic from being flooded to all ports. The switch learns which server hosts are interested in receiving multicast traffic, and forwards it only to ports connected to those servers. IGMP Snooping conserves bandwidth.
BLADE OS 5.1 Application Guide IGMPv3 IGMPv3 includes new membership report messages to extend IGMP functionality. The GbE2c provides snooping capability for all types of IGMP version 3 (IGMPv3) Membership Reports, as described in RFC 3376. IGMPv3 supports Source-Specific Multicast (SSM). SSM identifies session traffic by both source and group addresses.
BLADE OS 5.1 Application Guide IGMP Snooping Configuration Example This section provides steps to configure IGMP Snooping on the GbE2c, using the Command-Line Interface (CLI). 1. Configure port and VLAN membership on the switch. 2. Turn on IGMP. (Turn on IGMP) >> /cfg/l3/igmp/on 3. Add VLANs to IGMP Snooping and enable the feature. (Access IGMP Snoop menu) (Add VLAN 1 to IGMP snooping) (Enable IGMP Snooping) >> IGMP Snoop# snoop >> IGMP Snoop# add 1 >> IGMP Snoop# ena 4.
BLADE OS 5.1 Application Guide Static Multicast Router A static multicast router (Mrouter) can be configured for a particular port on a particular VLAN. A static Mrouter does not have to be learned through IGMP Snooping. A total of 16 static Mrouters can be configured on the GbE2c. Downlink and uplink ports can accept a static Mrouter, but managment ports cannot. Note – Even when static Mrouters are configured, the switch continues to learn dynamic Mrouters through IGMP Snooping.
BLADE OS 5.1 Application Guide IGMP Filtering With IGMP Filtering, you can allow or deny a port to send and receive multicast traffic to certain multicast groups. Unauthorized users are restricted from streaming multicast traffic across the network. If access to a multicast group is denied, IGMP Membership Reports from the port are dropped, and the port is not allowed to receive IP multicast traffic from that group.
BLADE OS 5.1 Application Guide Configure IGMP Filtering 1. Enable IGMP Filtering on the switch. >> /cfg/l3/igmp/igmpflt >> IGMP Filter# ena Current status: disabled New status: enabled (Select IGMP Filtering menu) (Enable IGMP Filtering) 2. Define an IGMP filter. >> /cfg/l3/igmp/igmpflt >>IGMP Filter# filter 1 >>IGMP Filter 1 Definition# range 224.0.1.0 Current multicast address2: Enter new multicast address2: 226.0.0.0 Current multicast address1: New pending multicast address1: 224.0.1.
BLADE OS 5.
CHAPTER 12 OSPF BLADE OS supports the Open Shortest Path First (OSPF) routing protocol. The BLADE OS implementation conforms to the OSPF version 2 specifications detailed in Internet RFC 1583. The following sections discuss OSPF support for the HP GbE2c Ethernet Blade Switch (GbE2c): “OSPF Overview” on page 191.
BLADE OS 5.1 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.
BLADE OS 5.1 Application Guide Types of OSPF Routing Devices As shown in Figure 21, OSPF uses the following types of routing devices: Internal Router (IR)—a router that has all of its interfaces within the same area. IRs maintain LSDBs identical to those of other routing devices within the local area. Area Border Router (ABR)—a router that has interfaces in multiple areas. ABRs maintain one LSDB for each connected area and disseminate routing information between areas.
BLADE OS 5.1 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.
BLADE OS 5.1 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.
BLADE OS 5.1 Application Guide OSPF Implementation in BLADE OS BLADE OS supports a single instance of OSPF and up to 4K routes on the network.
BLADE OS 5.1 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.
BLADE OS 5.1 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: 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.
BLADE OS 5.1 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.
BLADE OS 5.1 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 GbE2c acting as an ABR automatically inserts a default route into each attached area.
BLADE OS 5.1 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 20 on page 192). 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.
BLADE OS 5.1 Application Guide Authentication OSPF protocol exchanges can be authenticated so that only trusted routing devices can participate. This ensures less processing on routing devices that are not listening to OSPF packets. OSPF allows packet authentication and uses IP multicast when sending and receiving packets. Routers participate in routing domains based on pre-defined passwords. BLADE OS supports simple password (type 1 plain text passwords) and MD5 cryptographic authentication.
BLADE OS 5.1 Application Guide Configuring Plain Text OSPF Passwords To configure simple plain text OSPF passwords on the switches shown in Figure 23 use the following commands: 1. Enable OSPF authentication for Area 0 on switches 1, 2, and 3. >> # /cfg/l3/ospf/aindex 0/auth password (Turn on password authentication) 2. Configure a simple text password up to eight characters for each OSPF IP interface in Area 0 on switches 1, 2, and 3.
BLADE OS 5.1 Application Guide Configuring MD5 Authentication Use the following commands to configure MD5 authentication on the switches shown in Figure 23: 1. Enable OSPF MD5 authentication for Area 0 on switches 1, 2, and 3. >> # /cfg/l3/ospf/aindex 0/auth md5 (Turn on MD5 authentication) 2. Configure MD5 key ID for Area 0 on switches 1, 2, and 3. >> # /cfg/l3/ospf/md5key 1/key test 3. Assign MD5 key ID to OSPF interfaces on switches 1, 2, and 3.
BLADE OS 5.1 Application Guide Host Routes for Load Balancing BLADE OS implementation of OSPF includes host routes. Host routes are used for advertising network device IP addresses to external networks, accomplishing the following goals: ABR Load Sharing As a form of load balancing, host routes can be used for dividing OSPF traffic among multiple ABRs. To accomplish this, each switch provides identical services but advertises a host route for a different IP address to the external network.
BLADE OS 5.1 Application Guide OSPF Configuration Examples A summary of the basic steps for configuring OSPF on the GbE2c 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 switch. 2. (Optional) Configure the router ID. The router ID is required only when configuring virtual links on the switch. 3.
BLADE OS 5.1 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.
BLADE OS 5.1 Application Guide 3. Define the backbone. The backbone is always configured as a transit area using areaid 0.0.0.0. >> >> >> >> Open OSPF OSPF OSPF Shortest Path First # aindex 0 Area (index) 0 # areaid 0.0.0.0 Area (index) 0 # type transit Area (index) 0 # enable (Select menu for area index 0) (Set the ID for backbone area 0) (Define backbone as transit type) (Enable the area) 4. Define the stub area.
BLADE OS 5.1 Application Guide Example 2: Virtual Links In the example shown in Figure 25, area 2 is not physically connected to the backbone as is usually required. Instead, area 2 will be connected to the backbone via a virtual link through area 1. The virtual link must be configured at each endpoint. Figure 25 Configuring a Virtual Link Switch 2 Application Switch 1 Blade Blade Chassis Chassis Configuring OSPF for a Virtual Link on Switch #1 1.
BLADE OS 5.1 Application Guide 4. Define the backbone. >> >> >> >> 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) 5. Define the transit area. The area that contains the virtual link must be configured as a transit area.
BLADE OS 5.1 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. >> >> >> >> >> >> >> >> # /cfg/l3/if IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface IP Interface 1 1 1 1 1 2 2 2 # # # # # # # addr 10.10.12.2 mask 255.255.255.0 enable ..
BLADE OS 5.1 Application Guide 6. Define the stub area. >> >> >> >> 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 (Select the menu for area index 2) (Set the area ID for OSPF area 2) (Define area as stub type) (Enable the area) 7. Attach the network interface to the backbone. >> OSPF Area (index) 2 # ..
BLADE OS 5.1 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.
BLADE OS 5.1 Application Guide 3. Define the backbone. >> >> >> >> Open OSPF OSPF OSPF Shortest Path First # aindex 0 Area (index) 0 # areaid 0.0.0.0 Area (index) 0 # type transit Area (index) 0 # enable (Select menu for area index 0) (Set the ID for backbone area 0) (Define backbone as transit type) (Enable the area) 4. Define the stub area. >> >> >> >> OSPF OSPF OSPF OSPF Area Area Area Area (index) (index) (index) (index) 0 1 1 1 # # # # ../aindex 1 areaid 0.0.0.
BLADE OS 5.1 Application Guide Verifying OSPF Configuration Use the following commands to verify the OSPF configuration on your switch: /info/l3/ospf/general /info/l3/ospf/nbr /info/l3/ospf/dbase/dbsum /info/l3/ospf/route /stats/l3/route Refer to the BLADE OS Command Reference for information on the above commands.
BLADE OS 5.
CHAPTER 13 Remote Monitoring Remote Monitoring (RMON) allows network devices to exchange network monitoring data. RMON performs the following major functions: Gathers cumulative statistics for Ethernet interfaces Tracks a history of statistics for Ethernet interfaces Creates and triggers alarms for user-defined events RMON Overview The RMON MIB provides an interface between the RMON agent on the switch and an RMON management application. The RMON MIB is described in RFC 1757.
BLADE OS 5.1 Application Guide RMON Group 1—Statistics The switch supports collection of Ethernet statistics as outlined in the RMON statistics MIB, in reference to etherStatsTable. You can enable RMON statistics on a per-port basis, and you can view them using the following command: /stat/port /rmon RMON statistics are sampled every second, and new data overwrites any old data on a given port. Note – RMON port statistics must be enabled for the port before you can view RMON statistics.
BLADE OS 5.1 Application Guide RMON Group 2—History The RMON History Group allows you to sample and archive Ethernet statistics for a specific interface during a specific time interval. Note – RMON port statistics must be enabled for the port before an RMON history group can monitor the port. Data is stored in buckets, which store data gathered during discreet sampling intervals.
BLADE OS 5.1 Application Guide 1. Enable RMON on each port where you wish to collect RMON History. >> >> >> >> # /cfg/port 20/rmon Port 20# ena Port 20 RMON# apply Port 20 RMON# save (Select Port 20 RMON) (Enable RMON) (Make your changes active) (Save for restore after reboot) 2. Configure the RMON History parameters. >> >> >> >> >> # /cfg/rmon/hist 1 (Select RMON History 1) RMON History 1# ifoid 1.3.6.1.2.1.2.2.1.1.
BLADE OS 5.1 Application Guide Alarm MIB Objects The most common data types used for alarm monitoring are ifStats: errors, drops, bad CRCs, and so on. These MIB Object Identifiers (OIDs) correlate to the ones tracked by the History group. An example of an ICMP stat is as follows: 1.3.6.1.2.1.5.1.0 - mgmt.icmp.
BLADE OS 5.1 Application Guide RMON Alarm Example 2 This example configuration creates an RMON alarm that checks icmpInEchos on the switch once every minute. If the statistic exceeds 200 within a 60 second interval, an alarm is generated that triggers event index 5. 1. Configure the RMON Alarm parameters to track ICMP messages. >> >> >> >> >> >> >> >> # /cfg/rmon/alarm 5 (Select RMON Alarm 5) RMON Alarm 5# oid 1.3.6.1.2.1.5.8.
BLADE OS 5.1 Application Guide RMON Events Example This example configuration creates an RMON event that sends a SYSLOG message each time it is triggered by an alarm. 1. Configure the RMON Event parameters. >> >> >> >> # /cfg/rmon/event 5 (Select RMON Event 5) RMON Event 5# descn "SYSLOG_generation_event" RMON Event 5# type log RMON Event 5# owner "Owner_event_5" 2. Apply and save the configuration.
BLADE OS 5.
Part 3: High Availability Fundamentals Internet traffic consists of myriad services and applications which use the Internet Protocol (IP) for data delivery. However, IP is not optimized for all the various applications. High Availability goes beyond IP and makes intelligent switching decisions to provide redundant network configurations.
BLADE OS 5.
CHAPTER 14 High Availability The HP GbE2c Ethernet Blade Switch (GbE2c) support high-availability network topologies. This release provides information about Layer 2 Failover (formerly called Uplink Failure Detection) and Virtual Router Redundancy Protocol (VRRP). The following topics are discussed in this chapter: “Layer 2 Failover” on page 228. This section discusses trunk failover without using VRRP. “VRRP Overview” on page 239.
BLADE OS 5.1 Application Guide Layer 2 Failover The primary application for Layer 2 Failover is to support Network Adapter Teaming. With Network Adapter Teaming, all the NICs on each server share the same IP address, and are configured into a team. One NIC is the primary link, and the other is a standby link. Note – Only two links per server blade can be used for Layer 2 Failover (one primary and one backup). Network Adapter Teaming allows only one backup NIC for each server blade.
BLADE OS 5.1 Application Guide VLAN Monitor The VLAN Monitor allows Layer 2 Failover to discern different VLANs. With VLAN Monitor turned on: If enough links in a trigger go down (see “Setting the Failover Limit” on page 231), the switch disables all downlink ports that reside in the same VLAN membership as the trunk(s) in the trigger. When enough links in the trigger return to service, the switch enables the downlink ports that reside in the same VLAN membership as the trunk(s) in the trigger.
BLADE OS 5.1 Application Guide Figure 28 shows a configuration with two trunks, each in a different Failover Trigger. Switch 1 is the primary GbE2c for Server 1 and Server 2. Switch 2 is the primary GbE2c for Server 3 and Server 4. VLAN Monitor is turned on. STP is turned off. If all links go down in trigger 1, Switch 1 disables all downlink ports that reside in VLAN 1. If all links in trigger 2 go down, Switch 1 disables all downlink ports that reside in VLAN 2.
BLADE OS 5.1 Application Guide Setting the Failover Limit The failover limit lets you specify the minimum number of operational links required within each trigger before the trigger initiates a failover event. For example, if the limit is two (/cfg/l2/failovr/trigger /limit 2), a failover event occurs when the number of operational links in the trigger is two or fewer. When you set the limit to zero, the switch triggers a failover event only when no links in the trigger are operational.
BLADE OS 5.1 Application Guide L2 Failover with Other Features L2 Failover works together with Link Aggregation Control Protocol (LACP) and with Spanning Tree Protocol (STP), as described below. LACP Link Aggregation Control Protocol allows the switch to form dynamic trunks. You can use the admin key to add up to two LACP trunks to a failover trigger using automatic monitoring.
BLADE OS 5.1 Application Guide Configuration Guidelines This section provides important information about configuring Layer 2 Failover. Note – Auto Monitor and Manual Monitor are mutually exclusive. They cannot both be configured on the switch. Auto Monitor Guidelines Any specific failover trigger may monitor static trunks only or LACP trunks only, but not both. All uplink ports in all static or LACP trunks added to any specific failover trigger must belong to the same VLAN.
BLADE OS 5.1 Application Guide Configuring Layer 2 Failover Auto Monitor Example The following procedure pertains to the configuration shown in Figure 27. 1. Configure Network Adapter Teaming on the servers. 2. Define a trunk group on the GbE2c.
BLADE OS 5.1 Application Guide Manual Monitor Example Use the following procedure to configure a Layer 2 Failover Manual Monitor. 1. Configure Network Adapter Teaming on the servers. 2. Configure general Layer 2 Failover parameters. >> >> >> >> # /cfg/l2/failovr/on Failover# trigger 2 Trigger 2# ena Trigger 2# limit 2 (Turn Failover on) (Select trigger 2) (Enable trigger 2) (Set Failover limit to 2 links) 3. Specify the links to monitor.
BLADE OS 5.1 Application Guide Server Link Failure Detection Server Link Failure Detection (SFD) allows the switch to monitor specific downlink ports to detect server link failures. When all of the server links in the Link to Monitor (LtM) fail, the switch enables the crosslink ports. To use SFD, configure the following groups of ports: Link to Monitor (LtM) The Link to Monitor group consists of server downlink ports, or one trunk group that contains only downlink ports.
BLADE OS 5.1 Application Guide Spanning Tree Protocol with SFD If Spanning Tree Protocol (STP) is enabled on ports in the LtM, then the switch monitors the STP state and the link status on ports in the LtM. The switch automatically enables the ports in the LtE when it detects a link failure or when STP is in the BLOCKING, LISTENING, or LEARNING state.
BLADE OS 5.1 Application Guide 2. Assign crosslink ports to enable when a server link failure occurs. >> >> >> >> >> Server Link Failure Detection# lte Link to Enable# addport 17 Link to Enable# addport 18 Link to Enable# .. Server Link Failure Detection# (Select Link to Enable menu) 3. Turn on SFD.
BLADE OS 5.1 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.
BLADE OS 5.1 Application Guide Master and Backup Virtual Router Within each virtual router, one VRRP router is selected to be the virtual router master. See “Selecting the Master VRRP Router” on page 241 for an explanation of the selection process. Note – If the IP address owner is available, it will always become the virtual router master. The virtual router master forwards packets sent to the virtual router.
BLADE OS 5.1 Application Guide Selecting the Master VRRP Router Each VRRP router is configured with a priority between 1–254. A bidding process determines which VRRP router is or becomes the master—the VRRP router with the highest priority. The master periodically sends advertisements to an IP multicast address. As long as the backups receive these advertisements, they remain in the backup state.
BLADE OS 5.1 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 application 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.
BLADE OS 5.1 Application Guide Active-Active Redundancy In an active-active configuration, shown in Figure 32, two switches provide redundancy for each other, with both active at the same time. Each switch processes traffic on a different subnet. When a failure occurs, the remaining switch can process traffic on all subnets. For a configuration example, see “High Availability Configurations” on page 246.
BLADE OS 5.1 Application Guide BLADE OS Extensions to VRRP This section describes VRRP enhancements that are implemented in BLADE OS. BLADE OS supports a tracking function that dynamically modifies the priority of a VRRP router, based on its current state. The objective of tracking is to have, whenever possible, the master bidding processes for various virtual routers in a LAN converge on the same switch. Tracking ensures that the selected switch is the one that offers optimal network performance.
BLADE OS 5.1 Application Guide Virtual Router Deployment Considerations Assigning VRRP Virtual Router ID During the software upgrade process, VRRP virtual router IDs will be automatically assigned if failover is enabled on the switch. When configuring virtual routers at any point after upgrade, virtual router ID numbers (/cfg/l3/vrrp/vr #/vrid) must be assigned. The virtual router ID may be configured as any number between 1 and 255.
BLADE OS 5.1 Application Guide High Availability Configurations Figure 33 shows an example configuration where two GbE2c modules are used as VRRP routers in an active-active configuration. In this configuration, both switches respond to packets. Figure 33 Active-Active High-Availability Configuration L2 Switch 20 VIR 1: 192.168.1.200 (Master) VIR 2: 192.168.2.200 (Backup) 21 Switch A NIC 1: 10.0.1.1/24 Server 1 NIC 2: 10.0.2.1/24 NIC 1: 10.0.1.2/24 Server 2 NIC 2: 10.0.2.2/24 Internet NIC 1: 10.0.1.
BLADE OS 5.1 Application Guide Task 1: Configure Switch A 1. Configure client and server interfaces. /cfg/l3/if 1 >> IP Interface 1# >> IP Interface 1# >> IP Interface 1# >> IP Interface 1# >> Layer 3# if 2 >> IP Interface 2# >> IP Interface 2# >> IP Interface 2# >> IP Interface 2# >> Layer 3# if 3 >> IP Interface 3# >> IP Interface 3# >> IP Interface 3# >> IP Interface 3# >> Layer 3# if 4 >> IP Interface 4# >> IP Interface 4# >> IP Interface 4# addr 192.168.1.100 vlan 10 ena .. addr 192.168.2.
BLADE OS 5.1 Application Guide 4. Enable tracking on ports. Set the priority of Virtual Router 1 to 101, so that it becomes the Master. /cfg/l3/vrrp/vr 1 (Select VRRP virtual router 1) >> VRRP Virtual Router 1# track/ports/ena (Set tracking on ports) >> VRRP Virtual Router 1 Priority Tracking# .. >> VRRP Virtual Router 1# prio 101 (Set the VRRP priority) >> VRRP Virtual Router 1# ..
BLADE OS 5.1 Application Guide Task 2: Configure Switch B 1. Configure client and server interfaces. /cfg/l3/if 1 >> IP Interface 1# >> IP Interface 1# >> IP Interface 1# >> IP Interface 1# >> Layer 3# if 2 >> IP Interface 2# >> IP Interface 2# >> IP Interface 2# >> IP Interface 2# >> Layer 3# if 3 >> IP Interface 3# >> IP Interface 3# >> IP Interface 3# >> IP Interface 3# >> Layer 3# if 4 >> IP Interface 4# >> IP Interface 4# >> IP Interface 4# addr 192.168.1.101 vlan 10 ena .. addr 192.168.2.
BLADE OS 5.1 Application Guide 4. Enable tracking on ports. Set the priority of Virtual Router 2 to 101, so that it becomes the Master. /cfg/l3/vrrp/vr 1 (Select VRRP virtual router 1) >> VRRP Virtual Router 1# track/ports/ena (Set tracking on ports) >> VRRP Virtual Router 1 Priority Tracking# .. >> VRRP Virtual Router 1# ..
Part 4: Appendices This section describes the following topics: Troubleshooting Glossary BMD00113, September 2009 251
BLADE OS 5.
APPENDIX A Troubleshooting BLADE OS provides two main methods for monitoring HP GbE2c Ethernet Blade Switch (GbE2c) network traffic, as well as a varietry of traditional network troubleshooting tools: sFlow—Statistical flow monitoring for high-speed data ports. Port Mirroring—Complete port data capture. Other tools such as ping, traceroute, etc. sFlow The GbE2c supports sFlow technology for monitoring traffic in data networks.
BLADE OS 5.1 Application Guide sFlow Network Sampling In addition to statistical counters, the GbE2c can be configured to collect periodic samples of the traffic data received on each port. For each sample, 128 bytes are copied, UDP-encapsulated, and sent to the configured sFlow analyzer. For each port, the sFlow sampling rate can be configured to occur once each 256 to 65536 packets. A sampling rate of 256 means that one sample will be taken for approximately every 256 packets received on the port.
BLADE OS 5.1 Application Guide sFlow Example Configuration 1. Specify the location of the sFlow analyzer (the server and optional port to which the sFlow information will be sent): >> # /cfg/sys/sflow/saddress >> sFlow# sport >> sFlow# ena (sFlow server) (Set the optional service port) (Enable sFlow features) By default, the switch uses established sFlow service port 6343. To disable sFlow features across all ports, use the /cfg/sys/sflow/dis command. 2.
BLADE OS 5.1 Application Guide Port Mirroring The port mirroring feature in the BLADE OS allows you to attach a sniffer to a monitoring port that is configured to receive a copy of all packets that are forwarded from the mirrored port. BLADE OS enables you to mirror port traffic for all layer 2 and layer 3. Port mirroring can be used as a troubleshooting tool or to enhance the security of your network.
BLADE OS 5.1 Application Guide Configuring Port Mirroring To configure port mirroring for the example shown in Figure 34, 1. Specify the monitoring port. >> # /cfg/pmirr/monport 20 (Select port 20 for monitoring) 2. Select the ports that you want to mirror.
BLADE OS 5.1 Application Guide Other Network Troubleshooting Techniques Other network troubleshooting techniques include the following. Console and Syslog Messages When a switch experiences a problem, review the console and Syslog messages. The switch displays these informative messages when state changes and system problems occur. Syslog messages can be viewed by using the following command: /info/sys/log For more information on interpreting syslog messages, see the BLADE OS 5.1 Command Reference.
BLADE OS 5.1 Application Guide Customer Support Tools The following diagnostics tools are not user-configurable and should be performed through HP technical support. Offline Diagnostics—This tool is used for troubleshooting suspected switch hardware issues. These tests verify that the selected hardware is performing within expected engineering specifications.
BLADE OS 5.
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.
BLADE OS 5.1 Application Guide VIR (Virtual Interface Router) A VRRP address that is an IP interface address shared between two or more virtual routers. Virtual Router A shared address between two devices utilizing VRRP, as defined in RFC 2338. One virtual router is associated with an IP interface. This is one of the IP interfaces that the switch is assigned. All IP interfaces on the GbE2c must be in a VLAN.
Index Symbols [ ]....................................................................... 20 Numerics 802.1Q VLAN tagging ......................................... 90 A accessing the switch LDAP ......................................................... 52 RADIUS authentication ................................. 43 security........................................................ 41 using the Browser-based Interface................... 27 active-active redundancy ....................................
BLADE OS 5.1 Application Guide H high-availability ................................................ 227 Host routes, OSPF ............................................. 205 Hot Links ......................................................... 119 HP-OpenView..................................................... 31 MSTP ...............................................................125 multi-links between switches using port trunking ....65 Multiple Spanning Tree Protocol .........................
BLADE OS 5.1 Application Guide R T RADIUS authentication ............................................... 43 port 1812 and 1645 ..................................... 140 port 1813 ................................................... 140 SSH/SCP ..................................................... 58 Rapid Spanning Tree Protocol (RSTP) ................ 122 redundancy, active-active ................................... 243 re-mark.............................................................
BLADE OS 5.1 Application Guide VRRP (Virtual Router Redundancy Protocol) active-active redundancy ............................. 243 overview.................................................... 239 virtual interface router ................................. 239 virtual router ID numbering.......................... 245 vrid ...........................................................
