| Sun Fire B10n Content Load Balancing Blade Version 1.3 Administration Guide |    
|
| Sun Fire B10n Content Load Balancing Blade Version 1.3 Administration Guide |
|
| A P P E N D I X C |
|
Enterprise VLANs |
This appendix provides an example for configuring the Sun Fire B10n blade with VLANs in the enterprise.
The following is a review of the VLAN capabilities of the Sun Fire Blade chassis and its components including the Content load balancing and SSL proxy blades. Detailed below is an example using VLANs in a typical enterprise configuration including the command lines to configure the individual components of the chassis. It is expected that some knowledge of the B1600 chassis and its components has already been attained. We have chosen the enterprise model as the example as it represents a common configuration as well as providing concepts that can either be expanded to or simplified as required. As security is best deployed throughout a data center we will focus on how the B1600 and its components may best fit into this larger framework.
This section does not include detail on the SSL or TLS security protocols. The SSL Proxy Blade offloads servers from compute intensive cryptographic processing and provides a secure centralized location for key and certificate administration and configuration. The decrypted traffic can be protected using VLANs and this section describes a suggested configuration for doing this.
The B1600 chassis employs both logical and physical separation features to enable protection and isolation. The first level is the separation of management and data traffic. Management access can either be by direct ethernet or serial connection to the System Service Controller (SSC) ports or inband over the ethernet switch fabric. The SSC uses a Layer 3 filter between the internal switch fabric and the system controller. An SSH agent is employed on the System Controller (SC) to provide authentication and cryptographic protection. The SSC is connected to each chassis blade by redundant point to point serial connections providing an out of band path to each blade. Individual blade consoles can be accessed inband over the switch fabric as well. IEEE 802.1Q VLANs are available to logically separate the management traffic from the data traffic as well to segregate data traffic from different users.
When using the Sun Fire B10n content loadbalancing blade traffic can be divided into loadblancing groups and packets are forwarded based on services. Services can then be assigned a unique VLAN ID and the loadbalancer will tag traffic to the servers. If https is one of the types of traffic within a service the Sun Fire B10p SSL Proxy will return the decrypted ingress traffic to the B10n for the loadbalancing decision and will add the service VLAN tag before sending them to the server. When data leaves the servers headed for the client the packets are tagged with the data VLAN ID thus isolating this traffic from the service and management traffic. The following figure shows the configuration for our example and highlights the concepts described above.
Once traffic leaves the B1600 switch toward the external network the data VLAN tag can be either stripped or left and extended to the next hop router or firewall. Traffic ingress to the B1600 can be tagged by the router or firewall or can be tagged by the SSC.
While the diagram above is useful in understanding the VLAN membership concepts and logical packet flow it does not show the actual physical port connections. For example the Loadbalancer has one physical interface per switch. Therefore the switch interface must be configured to allow all three VLANs in our example. This is true for the SSL Proxy as well. The Server (or loadbalance group) interfaces must be configured with the management, data and its service VLAN IDs. In this way the this server is isolated from the other service traffic through the switches. It is important to know that the links between the blades and the switch are point to point therefore, the switch vlan filtering can prevent other vlan traffic from being forwarded to a particular link.
User Access levels are provided to restrict features from different administration users. The B1600 Service controller allows multiple username and password accounts. Users are assigned up to four user access privileges types u, a, c, r which allow setting user accounts (u), administration of system controller configuration (a), console access to blades and switches (c) and the ability to power on/off blades and reset them (r).
Once you have console access, the server blades provide Unix access level options based on the type of OS you are running. In general root access is required to configure the VLAN parameters.
For the B10n Content Loadbalancing Blade there are two levels, Level 1 is limited to read access to system information and status, Level 2 is full access.
The B10p SSL Proxy blade employs three levels, Service Officer (SO)which provides full access, Administrator which allows access to network configuration but does not allow access to keys or certificates and third is User which allows read access to some system information.
1. Ingress (RX) - Packets/Frames entering the device or network being described. In data/center or server centric discussions sometimes referred to as client side or client traffic. That is traffic transmitted by the client and received by the data center.
2. Egress (TX) - Packets/Frames leaving the local device or network. In data/center or server centric discussion it is traffic transmitted by the device or network and received by the client.
3. Native - Provided to allow network control traffic (like IGMP) to travel through VLAN enabled fabrics. From a switch perspective untagged ingress packets are tagged with a specified value and egress packets with a specified ID are sent untagged.
4. Allowed - If ingress filtering is enabled the switch will allow only tagged packets specified in the list for that port. If tagged is specified it will leave tags on egress. If untagged is specified it will strip tags on egress.
5. GVRP - VLAN Registration Protocol defines the way for switches to exchange information in order to automatically register members on interfaces across a network.
IEEE 802.1Q - Up to 256 VLANs - GVRP and manual configuration
|
Note - The switch supports Port and Hybrid VLAN configurations. All configurations in this example use Hybrid mode where tagged and untagged VLAN IDs are specified. |
(Default is all VLANs disabled)
Role is to decrypt incoming SSL traffic and encrypt outgoing SSL.
FIGURE C-2 provides an example VLAN configuration of four VLANs.
For the enterpise example figure xxx shows a physical view including network links, Loadbalancer blade (LB), SSL Proxy blade (SSL), and two server groups each with a unique service (SVC1 & SVC2). One for Internet access and the other for Intranet traffic. VLANs IDs are only shown for the end points of the management network as this is common to all blades and switch ports. The load balancer and SSL Interfaces must be a member of all four VLANs. The Server Interfaces are members of management, data and a service VLAN. Below is a example of commands to configure the B1600 and its components based on the figure xxxx. The exception being we will not extend VLANs to the external firewall but configure the switch to untag the egress Data VLAN packets and Tag the Ingress Data VLAN packets.
The following four VLANs IDs will be used.
2. Data (or client side) VLAN ID 30
To configure the system the first step will be configuring the VLANs for the SSC. The external network or "client side" uplink ports (NETPx), the internal (SNPx) ports and the management ports configurations will be shown. The approach we will use for the uplink (NETPx) ports is enable ingress filtering allowing only untagged VLAN IDs. The SSCs employ the concept of "native" VLANs which allow incoming untagged packets to be tagged with the VPID or native tag and untag egress packets that contain the VPID. The approach we will use for the internal (SNPx) ports is to allow both service VLANs as well as the management and data VLANs for the Load balancer and SSL Proxy blades. Server blade ports also allow management and data VLAN, but only one service VLAN is allowed. If all elements are in the same shelf, this contains the service VLANs (and thus cleartext and other service traffic) within the B1600. If external servers (or multiple shelves) are used, these VLANs can be extended by adding these VLAN IDs on those uplink ports connected to the additional servers or shelves. GVRP will be used in this example.
The interfaces to configured on the switch are:
For details on SSC switch configuration see the Sun Fire B1600 Blade System Chassis Switch Administration Guide.
1. Go to the SSC console from the SC prompt.
Where n is either 0 or 1 for systems with redundant switches.
2. Type your user name and password.
User access needs to at least have [a] administration privileges set.
3. Configure the Management port (this step can be skipped if default vlan 2 has not been changed)
Console(config)#interface ethernet NETMGT Console(config)#switchport allowed vlan add 2 Console(config)#switchport native 2 Console(config)#switchport allowed vlan remove vlan id |
Where vlan id is the previously configured value.
5. Configure the Uplink ports.
|
Note - By default the gvrp is disabled for all ports. Anytime you change the port configuration you must include the no switchport gvrp command to restore gvrp. |
6. Configure this uplink port to untag egress packets for these VLANs.
7. Configure this uplink port to tag ingress untagged packets with this PVID.
8. Remove the default data VLAN.
Console(config-if)#switchport allowed vlan remove 1 Console(config-if)#switchport ingress-filtering Console(config-if)#exit |
Repeat this step for all uplink ports you want to include in the shared Data VLAN (30).
9. Configure the internal port for the Loadbalancer and SSL proxy blades.
Repeat the above instructions (10) for the SSL Proxy changing snp0 to snp1.
10. Configure the internal ports for the servers.
Repeat this sequence for the second server changing snp3 to snp5.
Repeat this sequence for the second service group changing the firs allowed VLAN form 10 to 20.
Service VLANs The B10n load balancers must be a member of all four VLANs. The management VLAN must be the same for all blades to be loadbalanced as monitoring messages go between them and the B10n. The two services will be named SVC1 and SVC2 for the two loadbalancing groups.
The steps to configure VLANs on the B10n are as follows:
1. Go to the B10n console from the SC prompt.
Where n is the slot number of the load balancing blade.
2. Type your user name and password.
User access privileges must be Level 2.
3. Enter the B10n configuration mode.
4. Set the management vlan and enable.
5. Set the data vlan and enable.
6. Set the service VLAN for SVC1 and enable.
|
Note - The service SVC1 and SVC2 must be configured prior to these commands. See the Sun Fire B10n Content Loadbalancing Administration Guide for details. |
puma(config){admin}# service vlan SVC1 vlan 10 puma(config){admin}# enable service vlan SVC1 puma(config){admin}# enable service name SVC1 |
7. Set the service vlan for SVC2 and enable.
puma(config){admin}# service vlan SVC2 vlan 20 puma(config){admin}# enable service vlan SVC2 puma(config){admin}# enable service name SVC2 puma(config){admin}# exit |
The SSL Proxy blade must be configured for all four vlans. The default is VLANs are enabled. If the blade has been configured and you are just adding VLANs you will begin by enabling VLANs.
1. Access the SSL proxy blade console from the SC command line interface.
Where n is the slot number for the SSL proxy blade.
2. Type your user name and password.
User access needs to be Security Officer (SO) or Administrator (admin).
|
Note - Non-zero VLANs tags cannot be set before vlans are enabled |
4. Configure the management VLAN.
5. Configure the data (client side) VLAN.
6. Configure the SVC1 Service VLAN.
7. Configure the SVC1 Service VLAN.
CLI# show vlan client client vlan: 30 CLI# show vlan manage port 1: vlan: 2 port 2: vlan: 2 CLI# show vlan inband port 1: vlan: 10 port 2: vlan: 20 CLI# show vlan filter vlan filter: enabled |
The command example here is for Solaris if Linux is being used the syntax will vary slightly but the concepts are the same.
The server must also be a member of three VLANs, the management, the data (client side) and service VLAN. The management VLAN is used to exchange configuration and monitoring messages between the content load balancing blade and the blade server. The service VLAN is used for all data traffic between the content load balancing blade and the blade server.
The route from the server to the client network must use the data (client side) VLAN. For security reasons, the server cannot bind any services to its IP address on this interface.
1. Go to the server blade console from the SC prompt.
Where n is the slot number of the server blade.
2. Type your user name and password.
User access privileges must be superuser.
3. Configure the data VLAN interface.
4. Configure the management VLAN interface:
5. Configure the SVC1 service VLAN interface:
6. Configure the VIP on the loopback interface:
The IP address on the service VLAN is never used in any traffic, however, a valid IP address must be configured.
7. Add all three interfaces to the load balanced interfaces:
# /opt/SUNWclb/bin/clbconfig add ce2000 # /opt/SUNWclb/bin/clbconfig add ce10000 # /opt/SUNWclb/bin/clbconfig add ce30000 |
8. Verify that the route to the default gateway uses interface ce30000.
The netstat -r command displays the routing table, including the default route.
Remove any other default route shown by netstat -r. Note that there are other ways to set the default route to use this interface. See the Solaris Administration Guide.
|
Note - If the physical interface used were connected to ssc1, the virtual interfaces would be ce2001, ce10001, and ce30001, respectively. |
The interface number for VLAN n on physical interface i is determined by the following formula: 1000 * n + i
Hence, the interface name for VLAN 123 on physical interface ce0 is ce123000
These steps need to be repeated for the other servers in the loadbalancing group. For the second loadbalancing group the VIP must be different and the service vlan changes from ce10000 to ce20000.
| Sun Fire B10n Content Load Balancing Blade Version 1.3 Administration Guide | 817-6210-10 |
|
Copyright © 2004, Sun Microsystems, Inc. All rights reserved.