BLADE OS™ Application Guide HP GbE2c Ethernet Blade Switch for c-Class BladeSystem Version 5.1 Advanced Functionality Software
Table Of Contents
- Contents
- Figures
- Tables
- Preface
- Part 1: Basic Switching
- Accessing the Switch
- The Management Network
- Local Management Using the Console Port
- The Command Line Interface
- Remote Management Access
- Client IP Address Agents
- Securing Access to the Switch
- Setting Allowable Source IP Address Ranges
- RADIUS Authentication and Authorization
- TACACS+ Authentication
- LDAP Authentication and Authorization
- Secure Shell and Secure Copy
- Configuring SSH/SCP Features on the Switch
- Configuring the SCP Administrator Password
- Using SSH and SCP Client Commands
- SSH and SCP Encryption of Management Messages
- Generating RSA Host and Server Keys for SSH Access
- SSH/SCP Integration with Radius Authentication
- SSH/SCP Integration with TACACS+ Authentication
- End User Access Control
- Ports and Trunking
- Port-Based Network Access Control
- VLANs
- Spanning Tree Protocol
- RSTP and MSTP
- Link Layer Discovery Protocol
- Quality of Service
- Accessing the Switch
- Part 2: IP Routing
- Basic IP Routing
- Routing Information Protocol
- IGMP
- OSPF
- OSPF Overview
- OSPF Implementation in BLADE OS
- OSPF Configuration Examples
- Remote Monitoring
- Part 3: High Availability Fundamentals
- High Availability
- Layer 2 Failover
- Server Link Failure Detection
- VRRP Overview
- Failover Methods
- BLADE OS Extensions to VRRP
- Virtual Router Deployment Considerations
- High Availability Configurations
- High Availability
- Part 4: Appendices
- Index
BLADE OS 5.1 Application Guide
BMD00113, September 2009 Chapter 8: Quality of Service 143
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.
Of the matching ACLs that are permitted, each configured ACL action is applied in sequence, based
on ACL number, with the lowest-numbered ACL’s action applied first. If any ACL action
contradicts the action of a preceding ACL (one with a lower ACL number), the action of the
higher-numbered ACL is ignored.
If no assigned ACL matches the port traffic, no ACL action is applied.
ACL Groups
ACLs allow you to classify packets according to a particular content in the packet header, such as
the source address, destination address, source port number, destination port number, and others.
Once classified, packet flows can be identified for more processing.
To assist in organizing multiple ACLs and assigning them to ports, you can place ACLs into ACL
Groups, thereby defining complex traffic profiles. ACLs and ACL Groups can then be assigned on
a per-port basis. Any specific ACL can be assigned to multiple ACL Groups, and any ACL or ACL
Group can be assigned to multiple ports. If, as part of multiple ACL Groups, a specific ACL is
assigned to a port multiple times, only one instance is used. The redundant entries are ignored.
Individual ACLs
The GbE2c supports up to 762 ACLs. Each ACL defines one filter rule for matching traffic
criteria. Each filter rule can also include an action (permit or deny the packet). For example:
ACL 300:
VLAN = 1
SIP = 10.10.10.1 (255.255.255.0)
Action = permit