Oracle Solaris 11 Network Administration - Ag

THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY.
COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
D78415GC20
Activity Guide
Administration
Edition 2.0 | December 2014 | D89523
Learn more from Oracle University at oracle.com/education/

Oracle Solaris 11 Network
Oracle University and Giganomics Lda use only

THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Copyright 2014, Oracle and/or its affiliates. All rights reserved.
Disclaimer
This document contains proprietary information and is protected by copyright and other intellectual property laws. You may copy and
print this document solely for your own use in an Oracle training course. The document may not be modified or altered in any way.
Except where your use constitutes "fair use" under copyright law, you may not use, share, download, upload, copy, print, display,
perform, reproduce, publish, license, post, transmit, or distribute this document in whole or in part without the express authorization
of Oracle.
The information contained in this document is subject to change without notice. If you find any problems in the document, please
report them in writing to: Oracle University, 500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not
warranted to be error-free.
Restricted Rights Notice
If this documentation is delivered to the United States Government or anyone using the documentation on behalf of the United
States Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS
The U.S. Governments rights to use, modify, reproduce, release, perform, display, or disclose these training materials are restricted
by the terms of the applicable Oracle license agreement and/or the applicable U.S. Government contract.
Trademark Notice
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective
owners.
Author
Uma Sannasi
Technical Contributors and Reviewers

Rajesh Rajasekharan, Venugopal Iyer, Girish Moodalbail, Cathy Zhou
This book was published using: Oracle Tutor

Table of Contents
Practices for Lesson 1: Course Introduction ........................................................................................... 1-1
Practices for Lesson 1: Overview............................................................................................................. 1-2
Practice 1-1: Getting Familiar with the Practice Environment .................................................................... 1-5
Practice 1-2: Scenario-Based Practices ................................................................................................... 1-17
Practices for Lesson 2: Networking Fundamentals ................................................................................. 2-1
Practice 2-1: Gather Network Information................................................................................................. 2-5
Practices for Lesson 3: Configuring a Virtual Network............................................................................ 3-1
Practice 3-1: Configure Virtual Network for the zclient Zone on s11-client ................................................. 3-5

Practice 3-2: Configure Virtual Network for Nonglobal Zones on s11-host01 ............................................. 3-10
Practice 3-3: Configure Virtual Network for Nonglobal Zones on s11-host02 ............................................. 3-27
Practice 3-4: Configure the EVS Controller .............................................................................................. 3-33
Practice 3-5: Configure EVS Client Nodes ............................................................................................... 3-41
Practices for Lesson 4: Configuring Network High Availability............................................................... 4-1
Practice 4-1: Configure IPMP .................................................................................................................. 4-5
Practice 4-2: Configure Link Aggregation ................................................................................................. 4-11
Practice 4-3: Configure L3 VRRP ............................................................................................................ 4-15
Practice 4-4: Configure ILB...................................................................................................................... 4-21
Practices for Lesson 5: Configuring Network Services ........................................................................... 5-1
Practice 5-1: Configure ISC DHCP .......................................................................................................... 5-5
Practice 5-2: Configure DNS ................................................................................................................... 5-10
Practice 5-3: Configure LDAP.................................................................................................................. 5-16
Practices for Lesson 6: Managing Network Resources ........................................................................... 6-1
Practice 6-1: Configure the Bandwidth Datalink Property .......................................................................... 6-4
Practice 6-2: Create Flows to Regulate Bandwidth and Priority Properties ................................................ 6-7
Practices for Lesson 7: Implementing Network Security ......................................................................... 7-1
Practice 7-1: Configure IP Filter to Secure the Network ............................................................................ 7-4
Practices for Lesson 8: Integrating with OpenStack................................................................................ 8-1
Practice 8-1: Configure Neutron............................................................................................................... 8-5
Practices for Lesson 9: Diagnosing Networking Issues .......................................................................... 9-1
Practice 9-1: Address Host Name Resolution Failure ............................................................................... 9-3
Practice 9-2: Address Web Server Failure................................................................................................ 9-5
Oracle Solaris 11 Network Administration Table of Contents

i


Practices for Lesson 1:
Course Introduction
Chapter 1
Practices for Lesson 1: Course Introduction

Chapter 1 - Page 1
Practices for Lesson 1: Overview

Practices Overview
This practice introduces you to the lab environment, which you will use for performing the
practices.
In the concluding part of this lesson, you will be introduced to scenario-based practices. Ensure
that you have read and understood clearly the macro scenario and the requirements you will
address during the course of the practices.
Practices Infrastructure
Your lab environment is based on the Oracle Virtual Machine (VM) VirtualBox (VBox)
virtualization software. The VBox software is a cross-platform virtualization application. The lab

environment comprises four VMs: s11-server, s11-client, s11-host01, and s11-host02. These
VMs are configured on a private internal network, 192.168.0. Figure 1 shows the configured
VMs in the VirtualBox environment.
Figure 1: Configured Oracle VirtualBox VMs

The following table provides a brief description of the configured VMs:
Name of the VM Description
s11-server This VM has the Oracle Solaris 11.2 guest OS image (Text install)
and is configured as an IPS Repository server.
This VM during the course of the practices will also be configured as
the EVS controller.
s11-client This VM has the Oracle Solaris 11.2 guest OS image (Live media
install) and acts as a client node. The student uses this system to
ssh into the various nodes or hosts in the system to perform tasks

Chapter 1 - Page 2
described in the practices.

s11-host01 This VM has the Oracle Solaris 11.2 guest OS image (Text install)
and acts as the primary node in the larger lab setup.
During the course of the practices, students will create the following
four nonglobal zones in this node to perform various tasks
described in the practices.
zgateway1
pri-services
ws1
zapp1
s11-host02 This VM has the Oracle Solaris 11.2 guest OS image (Text install)

and acts as the secondary node in the larger lab setup.
Students will create the following four nonglobal zones in this node
to perform various tasks described in the practices.
zgateway2
sec-services
ws2
zapp2
Note that Internet access is not available to these VMs.
These VMs are further configured to communicate with the Oracle Solaris 10 host machine
through the following shared directories.
Resource Name Location Description
Host share directory /opt/ora Is the shared directory that is
mapped to the host system
Student files /opt/ora/course_files Contains lab bundle content
Zone template files /opt/ora/zonetemplate Contains the XML files of the
zones to be created in the
s11-host02 VM
Script directory /opt/ora/script Contains the script file that
automates the creation of
resources on the s11-host02
VM
The following are the user credentials for accessing the s11-server, s11-client, s11-host01,
and s11-host02 VMs.
VM Credentials
s11-server Username: oracle
Password: oracle1
s11-client Username: oracle

Chapter 1 - Page 3
Password: oracle1
S11-host01 Username: oracle
Password: oracle1
S11-host02 Username: oracle
Password: oracle1
Note: As an oracle user, use su to switch to the primary administrator (root) role. The
password is oracle1. root is configured as a role by default in Oracle Solaris 11. Note that
the first username created in the system during installation is the initial privileged user who can
assume the primary administrator role. This can be verified in the /etc/user_attr file.

Best Practices
When required, always shut down the system with the correct procedure. If the system
contains zones, ensure that you shut down all the zones before proceeding with the
system or VM shutdown procedure. To shut down a zone, exit out to the global zone
and then use the zoneadm z <zonename> shutdown command.
(Optional) If you need to preserve the current state of the system, it is recommended
that you use the virtual boxs snapshot feature. With snapshots, you can save a
particular state of a virtual machine for later use. To learn more about this feature, click
the Help menu in the Virtual Box window, use CTRL + F, and then enter snapshot in
the search window. It is a good practice to take a snapshot of the VM at the end of
each practice. If you choose to follow this practice, ensure to delete the older snapshot
while taking a new snapshot. This helps in limiting system storage usage to the
minimum.
(Optional) Your system performance depends on the network speed and network load.
If you find your VM too slow to proceed with, it is recommended that you shut down the
VM and restart it.
Follow the instructions in the practices for a smooth learning experience.
The terminals you open in the s11-client desktop can be set with a terminal title
corresponding to the exact VM or zone. It helps to identify the resource you are
working with.
Keep all the terminals open, unless specifically asked to close. Because this is a
networking course, you will be constantly required to ping other resources to check, if
the configurations were completed successfully. Opening a new terminal every now
and then would be cumbersome.
Toggle between the terminals in the s11-client desktop by using the Alt + Tab key.
This is more seamless than scrolling the desktop up and down and trying to locate the
particular terminal.

Chapter 1 - Page 4
Practice 1-1: Getting Familiar with the Practice Environment
Tasks
1. Power on the VMs.
a. On your host system, start the Oracle VM VirtualBox Manager by double-clicking its
icon on your desktop.
b. In the Oracle VM VirtualBox Manager window, double-click the s11-server VM to start

it. Alternatively, you can select the s11-server VM and click the Start button.

Figure 2: Oracle VirtualBox VMs
Note: The s11-client VM is configured with 3 GB base memory, whereas the remaining
VMS, s11-server, s11-host01, and s11-host02 are configured with 2 GB base memory.

Chapter 1 - Page 5
2. Log in to the various hosts.

a. After the s11-server VM is powered on, at the command prompt, log in as user
oracle with the password, oracle1.

b. To switch to the primary administrator role, use the su command. The password is
oracle1.
s11-server console login: oracle
Password: oracle1
Last login: Mon Jan 28 04:51:14 on console
Oracle Corporation SunOS 5.11 11.1 September 2012
oracle@s11-server:~$ su
Password: oracle1
Jan 28 05:50:27 s11-server su: su root succeeded for
oracle on /dev/console
Oracle Corporation SunOS 5.11 11.1 September 2012
root@s11-server:~#

Chapter 1 - Page 6
c. Start the s11-client VM. If you receive any notice or a warning message or an
Information dialog box, click OK and continue.

d. When the Username login screen appears, enter oracle as the username and click
the Log In button.
e. Enter oracle1 as the password and click the Log In button.

Chapter 1 - Page 7
f. To open a terminal window, right-click the desktop and select Open Terminal. The
default login prompt will have oracle as the user. Alternatively, you can also open a
terminal window by clicking the terminal icon (highlighted in red) at the top of the
window.

g. To assume administrator privileges, switch to the root role by running the su
command. The password is oracle1.
oracle@s11-client:~$ su
Password: oracle1
root@s11-client:~#
h. You can close the terminal by clicking the X button at the top-right corner of the
window. Alternatively, you can use the exit command to exit from the terminal
session.
3. Establish secure remote connections with various nodes from the s11-client VM.
a. Use ssh to establish a secure remote connection with the s11-server VM
(192.168.0.100) from the s11-client VM. The password is oracle1.
oracle@s11-client:~$ ssh oracle@s11-server
The authenticity of host 's11-server (192.168.0.100)' can't be
established.
RSA key fingerprint is
bf:5d:9a:4b:60:e8:2f:6b:eb:46:ad:b3:4c:a6:df:22.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 's11-server,192.168.0.100' (RSA) to
the list of known hosts.
Password:
Last login: Sun Oct 19 05:20:17 2014
Oracle Corporation SunOS 5.11 11.2 June 2014

Chapter 1 - Page 8
oracle@s11-server:~$
When you establish the ssh connection for the first time, you are asked to authenticate
the host VM. Reply with a yes to the question, Are you sure you want to continue
connecting (yes/no)? This adds the host permanently to the list of known hosts.
b. Run the su command to assume primary administrator privileges.
Password: oracle1
root@s11-server:~#
4. Set up terminal titles.

a. In the terminal window, go to the Terminal menu and click Set Title.

Chapter 1 - Page 9
b. In the Set Title dialog box, enter the title name as s11-server and click the OK
button.

This sets the terminal title as s11-server, which helps identify the corresponding
terminal while performing specific tasks or commands.

Chapter 1 - Page 10
5. Shut down VMS.

a. You may need to power off a VM during the course of the practices. For instance, to
shut down the s11-client VM, click the System menu and select the Shut Down
option.

b. Click the Shut Down button in the Shut Down dialog box. This initiates the VM
shutdown procedure.

Chapter 1 - Page 11
c. If a dialog box with the following message appears, ignore the message and continue
by clicking the Shutdown Anyway button.

d. Alternatively, you can shut down this VM by clicking the close button (X) on the top-
right corner of the VM window, highlighted in red.

Chapter 1 - Page 12
e. In the Close Virtual Machine dialog box, select Send the shutdown signal option
and click OK. Alternatively, you can also use the Power off the machine option.

f. To verify that the VM is shut down, check the status that appears under the VMs name
in Oracle VM VirtualBox Manager. The status for the s11-client VM is Powered Off.

Chapter 1 - Page 13
g. Now you can practice shutting down the s11-server VM. Click the (X) button at the
extreme right corner of the window, highlighted with a red circle:

Chapter 1 - Page 14
h. In the Close Virtual Machine dialog box, select Send the shutdown signal and click
OK.

Chapter 1 - Page 15
i. In a few seconds or minutes, the Virtual Machine window disappears. To confirm,

switch to the Oracle VM VirtualBox Manager window. The status for the s11-server
VM is Powered Off.

This completes your initiation into the start state of the practices in this course.

Chapter 1 - Page 16
Practice 1-2: Scenario-Based Practices
Overview
The practices in this course are designed around scenarios or situations that give you some of
the right reasons to deploy a particular technology and address a specific requirement. Know
that you are a stakeholder in this setup. Because the scenarios are linked to a larger lab
infrastructure, you will be able to appreciate the interplay of various features and technologies of
Oracle Solaris 11, rather than learn to use them in isolation.
In this practice, you are introduced to the following:
Stakeholders
Requirements and implementations
Topology diagram

Resources and their IP addresses

Chapter 1 - Page 17
Stakeholders
Murraya Inc., a world-wide freighter has considered phasing in Oracle Solaris 11 into its data
center. You are part of a larger team of network administrators at Murraya that is responsible for
configuring a prototype that makes a case for consolidating a vastly distributed network
infrastructure. You need to test the various Oracle Solaris networking features and technologies,
especially the network virtualization and Software Defined Network (SDN) capabilities before
migrating to a production environment.
Requirements and Implementations

The following table captures the list of requirements to be addressed in the prototype. During
the course of the practices, you will implement the recommended technology Implementations
mentioned in the Requirement table.

Requirement Implementation
Network-in-a-box VNICs
Etherstubs
Virtual switch
IP Forwarding
Isolated nodes across hosts VXLAN
EVS
IP failover IPMP
Trunk aggregation
Link failover
DLMP
Router failover L3 VRRP
Load balancing ILB
Centralized database for granting IP addresses ISC DHCP
Centralized database for host name resolution DNS
Centralized data store for user authentication LDAP
Bandwidth regulation on datalinks Datalink properties
Traffic control and regulation on specific ports/channels Flows
Datalink protection dhcp-nospoof
ip-nospoof
mac-nospoof
restricted
Regulate client access to network services (Firewall) IP Filter
Cloud integration OpenStack (Neutron
Keystone)

Chapter 1 - Page 18
Topology Diagram
The topology diagram is a schematic representation of the recommended technology
implementations for the prototype. During the course of the practices, you will reconstruct this
setup piece by piece until you have assembled the whole. Know that you will have clear
instructions in each of the practices to achieve the desired outcomes.
Host: Oracle Solaris 10

s11-client s11-host01 s11-host02
192.168.0.111 pri-services 192.168.0.112 sec-services 192.168.0.113
192.168.3.4 192.168.3.5
DHCP server
DNS server
ws1
192.168.3.6
O ws2
192.168.3.7
LDAP server
f-ssh f-http
priority=high maxbw=7000 MB
stub01 stub02

zapp1
zgateway1 192.168.2.2 zgateway2 zapp2
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11 192.168.10.100 192.168.10.100
192.168.2.4 198.168.2.5
192.168.1.2
appSwitch (192.168.2.x)
gateSwitch(192.168.1.x)
IPMP IPMP
IPS Repository s11-server

EVS Controller 192.168.0.100
EVS Manager
cloudSwitch (192.168.20.x)
Keystone
Neutron
Virtual Box Copyright 2014, Oracle and/or its affiliates. All rights reserved. |

Chapter 1 - Page 19
Resources and their IP addresses

Considering the complex setup, it is useful to keep the resources table always handy for
reference. The various zones across hosts and the network services hosted on them are all
linked to IP addresses over Network Interface Cards (NICs), Virtual VNICs (VNICs), and virtual
ports (vports). It is easy to get confused regarding which IP is assigned to what resource and
how they are all connected. This table guides you through each of the practices.
VMs Zones NIC VNIC appSwitch gateSwitch L3 VRRP cloudSwitch
s11-server 192.168.20.x
192.168.0.100
s11-client zclient 192.168.10.11
192.168.0.111 192.168.1.2
s11-host01 zgateway1 192.168.10.22 192.168.3.2 192.168.2.4 192.168.1.3 192.168.10.100

192.168.0.112 pri-
services 192.168.3.4
ws1 192.168.3.6
zapp1 192.168.2.2
s11-host02 zgateway2 192.168.10.33 192.168.3.3 192.168.2.5 192.168.1.4 192.168.10.100
192.168.0.113 sec-
ws2 192.168.3.7
zapp2 192.168.2.3
Note of Assurance: Although the setup looks overwhelming at this stage, be assured that you
will be able to implement the setup in entirety by the end of the course, if you follow the
instructions carefully.

Chapter 1 - Page 20

Networking Fundamentals
Chapter 2
Practices for Lesson 2: Networking Fundamentals

Chapter 2 - Page 1
Practices Overview
Now is a good time to understand the base network that you will use for Murrayas prototype.
The base infrastructure consists of four hosts: s11-server, s11-client, s11-host01, and s11-
host02. These hosts are assigned over the 192.168.0.x network. The s11-server system is
configured as the local IPS repository. The s11-client will be the client interface to the other
hosts in the infrastructure.
In this lab, you will gather network information by probing the hosts and their devices.
Below is the schematic representation of the start state of the prototype infrastructure.

192.168.0.111 192.168.0.112 192.168.0.113

192.168.0.100

Chapter 2 - Page 2
Refer to the following table for IP addresses assigned to various resources.

s11-server 192.168.20.x
192.168.0.100
s11-client zclient 192.168.10.11

192.168.0.111 192.168.1.2
s11-host01 zgateway1 192.168.10.22 192.168.3.2 192.168.2.4 192.168.1.3 192.168.10.100
192.168.0.112 pri-
ws1 192.168.3.6
zapp1 192.168.2.2
s11-host02 zgateway2 192.168.10.33

192.168.3.3 192.168.2.5 192.168.1.4 192.168.10.100
192.168.0.113 sec-
ws2 192.168.3.7
zapp2 192.168.2.3

Chapter 2 - Page 3
Assumptions:
s11-server, s11-client, s11-host01, and s11-host02 VMs are running.
All tasks associated with the s11-server, s11-host01, and s11-host02 VMs are
performed via secure (ssh) login from the s11-client VM.
You perform all tasks in the root role, unless mentioned otherwise. (Assume root
privileges by using the su command and oracle1 as password.)
Some command output or values may vary across systems.
The font size of the output is reduced in a few places, to accommodate complete
command output.
General Instructions:

Ensure you set a title to the terminal window for easier recognition. These terminal
windows will be referenced by their titles in the labs. So follow the naming convention
mentioned in the procedures.
Keep the terminal windows open unless specifically asked to close.
In case, you happen to shut down a specific terminal, you can re-establish the
connection:
o Open a new terminal window.
o SSH to the host (global zone) by using the ssh oracle@s11-<host>
command and specifying oracle1 as password.
o Assume root privileges by using the su command and oracle1 as password.
There will be occasions where you will use the shutdown command to shut down the
nonglobal zones. In case your terminal hangs while shutting down, open a new
terminal and re-establish the connection as mentioned in the previous step.
In case, a zone is not running, boot the zone first by using the zoneadm z
<zonename> boot command. Then log in to the zone by using the zlogin
<zonename> command.

Chapter 2 - Page 4
Practice 2-1: Gather Network Information
Overview
Apart from acquainting yourself with the start state of the hosts in the prototype infrastructure,
you will familiarize yourself with some basic network settings, and verify if all hosts are pinging
each other at this stage.
Tasks
In this practice, you will identity the network configuration of:
The s11-server VM
The s11-client VM

The s11-host01 VM
The s11-host02 VM
Task 1/4
1. Identify the network configuration of the s11-client VM.
a. Verify that the s11-server, s11-client, s11-host01, and s11-host02 VMs are running.
b. Log in to the s11-client VM with username oracle and password as oracle1.
c. From the s11-client desktop, open a terminal window and set the title of the window as
s11-client.
d. Switch to the root role by using the su command.
oracle@s11-client:~$ su
Password: oracle1
root@s11-client:~#
e. Disable the sendmail notification.
root@s11-client:~# svcadm disable sendmail
f. Display information about the physical attributes of the datalinks on the s11-client VM.
root@s11-client:~# dladm show-phys
LINK MEDIA STATE SPEED DUPLEX DEVICE
net1 Ethernet unknown 0 unknown e1000g1
net0 Ethernet up 1000 full e1000g0
g. Find the active network configuration profile by using the netadm command.
root@s11-client:~# netadm list
TYPE PROFILE STATE
ncp Automatic disabled
ncp DefaultFixed online
loc DefaultFixed online
loc Automatic offline
loc NoNet offline

Chapter 2 - Page 5
The active NCP is DefaultFixed. You can switch between the profile types. For
example, to switch from a fixed to a reactive profile, you can use the netadm enable
-p ncp Automatic command.
To verify that the network/physical:default service has restarted and is online,

you can use the svcs -xv network/physical:default command.
In this case though, you need to retain the DefaultFixed profile.

h. Display the address information of the network interfaces.
root@s11-client:~# ipadm show-addr
ADDROBJ TYPE STATE ADDR

lo0/v4 static ok 127.0.0.1/8
net0/v4 static ok 192.168.0.111/24
l0/v6 static ok ::1/28
Observation: The s11-client VM is on an IPv4 network and configured over the
192.168.0.111 IP address. Additional details regarding this system are:
There are four physical NICS: net0, net1, net2, and net3
The hardware-based link name is net0.
Only net0 is configured at this point.
Media is Ethernet.
The device state is up.
Data transfer speed is 1000 Mb.
The duplex state is full, which means that there can be two-way data
transmission.
The device type is e1000g0, which refers to the Intel gigabit controller type device.
Task 2/4
2. Identify the network configuration of the s11-server VM.
a. From the s11-client desktop, open another terminal window and set the title of the
window as s11-server.
b. Establish a secure remote connection with the s11-server VM by using the ssh
command.
oracle@s11-client:~$ ssh oracle@s11-server
Password:
Last login: Sun Oct 19 05:33:12 2014 from 192.168.0.111
c. Switch to the root role by using the su command.
Password: oracle1
root@s11-server:~#
d. Disable the sendmail notification.
root@s11-server:~# svcadm disable sendmail

Chapter 2 - Page 6
e. Display information about the physical attributes of the datalinks currently on the s11-
server VM.
root@s11-server:~# dladm show-phys
f. Find the active network configuration profile by using the netadm command.
root@s11-server:~# netadm list
TYPE PROFILE STATE

loc NoNet offline
g. Display the address information of the interface by using the ipadm command.
root@s11-server:~# ipadm show-addr
lo0/v4 static ok 127.0.0.1/8
net0/v4 static ok 192.168.0.100/24
lo0/v6 static ok ::1/128
net0/v6 addrconf ok fe80::a00:27ff:fe8d:cada/10
Observation: The s11-server VM is on an IPv4 network and configured over the
192.168.0.100 IP address.
Task 3/4
3. Identify the network configuration of the s11-host01 VM.
window as s11-host01.
b. Establish a secure remote connection with the s11-host01 VM by using the ssh
command.
oracle@s11-client:~$ ssh oracle@s11-host01
Password: oracle1
Last login: Wed Oct 8 07:54:59 2014 from 192.168.0.111
oracle@s11-host01:~$ su
Password: oracle1
root@s11-host01:~#
root@s11-host01:~# svcadm disable sendmail

Chapter 2 - Page 7
e. Display information about the physical attributes of the datalinks on the s11-host01
VM.
root@s11-host01:~# dladm show-phys
root@s11-host01:~# netadm list
TYPE PROFILE STATE

loc NoNet offline
g. Display the address information of the network interfaces.
root@s11-host01:~# ipadm show-addr
lo0/v4 static ok 127.0.0.1/8
net0/v4 static ok 192.168.0.112/24
net0/v6 addrconf ok fe80::a00:27ff:fe7f:9496/10
Observation: The s11-host01 VM is on an IPv4 network and configured over the
192.168.0.112 IP address.
Task 4/4
4. Identify the network configuration of the s11-host02 VM.
a. From the s11-client desktop, open yet another terminal window and set the title of the
window as s11-host02.
b. Establish a secure remote connection with the s11-host02 VM by using the ssh
command.
Password: oracle1
Password: oracle1
root@s11-host02:~#
root@s11-host02:~# svcadm disable sendmail

Chapter 2 - Page 8
e. Display information about the physical attributes of the datalinks on the s11-host02
VM.
root@s11-host02:~# dladm show-phys
root@s11-host02:~# netadm list
TYPE PROFILE STATE

loc NoNet offline
g. Display the address information of the network interfaces.
root@s11-host02:~# ipadm show-addr
lo0/v4 static ok 127.0.0.1/8
net0/v4 static ok 192.168.0.113/24
net0/v6 addrconf ok fe80::a00:27ff:fe01:c195/10
The s11-host02 VM is on an IPv4 network and configured over the 192.168.0.113

IP address.
h. Finally, try pinging one host from the other and observe if all of them are able to ping
each other.
Note: Do not shut down the terminal windows. You will need them in the next practice.
Summary: You now have an overall picture of the systems that form the base infrastructure
for your prototype. From the next lab onwards, you will start building and testing your
infrastructure block by block.

Chapter 2 - Page 9

Chapter 2 - Page 10

Configuring a Virtual Network
Chapter 3
Practices for Lesson 3: Configuring a Virtual Network

Chapter 3 - Page 1
Practices Overview
By using the essential building blocks of network virtualization, such as VNICs, virtual switches,
etherstubs, and routing functionality, it is possible to consolidate an entire distributed computing
environment onto a single system for prototyping, testing, and deployment scenarios without the
restriction of the physical network devices attached to the system.
In this lab, you will perform the following practices:

Configure virtual network for the zclient zone on s11-client
Configure virtual network for non-global zones on s11-host01

Configure virtual network for non-global zones on s11-host02
Configure the EVS controller on s11-server
Configure EVS client nodes
Below is the schematic representation of the setup you will build and test in this lab:

192.168.3.4 192.168.3.5
ws1 ws2
192.168.3.6 192.168.3.7
stub01 stub02
zapp1
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11
192.168.2.4 198.168.2.5
192.168.1.2

EVS Manager

Chapter 3 - Page 2

s11-server
192.168.0.100 192.168.20.x
s11-client zclient
192.168.0.111 192.168.10.11 192.168.1.2
s11-host01 zgateway1 192.168.10.22 192.168.3.2 192.168.2.4 192.168.1.3 192.168.10.100
192.168.0.112 pri-
ws1 192.168.3.6
zapp1 192.168.2.2
s11-host02 zgateway2

192.168.10.33 192.168.3.3 192.168.2.5 192.168.1.4 192.168.10.100
192.168.0.113 sec-
ws2 192.168.3.7
zapp2 192.168.2.3

Chapter 3 - Page 3
Assumptions:
The s11-server, s11-client, s11-host01, and s11-host02 VMs are running.
command output.

connection:
nonglobal zones. In case your terminal hangs while shutting down, open a new
<zonename> command.

Chapter 3 - Page 4
Practice 3-1: Configure Virtual Network for the zclient Zone on s11-
client
Overview
In this practice, you create a nonglobal zone called zclient on the s11-client system. This
zone needs to be plumbed on the net1 interface and assigned a static IP address,
192.168.10.11. All client requests to the resources on s11-server, s11-host01, and s11-
host02 systems will be initiated from the zclient zone.

192.168.0.111 192.168.0.112 192.168.0.113
zclient
192.168.10.11

192.168.0.100
Tasks:
In this practice, you will configure virtual network for the zclient zone.
Task 1/1
1. Configure virtual network for the zclient zone.
Because this is a new zone, you will first configure the zclient zone and then configure
the virtual network for the zone.
a. Open the s11-client VM terminal and rename the terminal title as zclient.
b. List zone information by using the zoneadm command.
root@s11-client:~# zoneadm list -cv
ID NAME STATUS PATH BRAND IP
0 global running / solaris shared
There is no nonglobal zone configured at this stage.

c. Create the zclient zone by using the zonecfg command.
root@s11-client:~# zonecfg -z zclient

Chapter 3 - Page 5
Use 'create' to begin configuring a new zone.

zonecfg:zclient> create
create: Using system default template 'SYSdefault'
zonecfg:zclient> set zonepath=/zones/zclient
zonecfg:zclient> add net
zonecfg:zclient:net> set physical=net1
zonecfg:zclient:net> end
zonecfg:zclient> exit
The net1 interface will be used for configuring the 192.168.10.11 IP address.
d. Remove the net0 interface from the zone configuration.

root@s11-client:~# zonecfg -z zclient remove anet
linkname=net0
By default, the net0 interface is a nonpersistent interface assigned to every zone from
the SYSdefault template. You can verify this by reading the
/etc/zones/zclient.xml file. Because you do not require this interface, for now
you will remove it.
e. Confirm that the zclient zone is configured and listed.
- zclient configured /zones/zclient solaris excl
f. Verify that the s11-client VM can contact the IPS server, before installing the zclient
zone.
root@s11-client:~# pkg publisher
PUBLISHER TYPE STATUS P LOCATION
solaris origin online F http://s11-server.mydomain.com/
g. Install the zclient zone by using the zoneadm install command.
root@s11-client:~# zoneadm -z zclient install
The following ZFS file system(s) have been created:
rpool/zones
rpool/zones/zclient
Progress being logged to
/var/log/zones/zoneadm.20141008T025441Z.zclient.install
Image: Preparing at /zones/zclient/root.
Install Log: /system/volatile/install.5849/install_log

AI Manifest: /tmp/manifest.xml.5taOzl
SC Profile: /usr/share/auto_install/sc_profiles/enable_sci.xml
Zonename: zclient
Installation: Starting ...

Chapter 3 - Page 6
Creating IPS image

Startup linked: 1/1 done
Installing packages from:
solaris
origin: http://s11-server.mydomain.com/
DOWNLOAD PKGS FILES
XFER (MB) SPEED
Completed 282/282 53274/53274
351.9/351.9 5.2M/s

PHASE ITEMS
Installing new actions 71043/71043
Updating package state database Done
Updating package cache 0/0
Updating image state Done
Creating fast lookup database Done
Installation: Succeeded
Note: Man pages can be obtained by installing

pkg:/system/manual
done.
Done: Installation completed in 188.624 seconds.
Next Steps: Boot the zone, then log into the zone console
(zlogin -C)
to complete the configuration process.
Log saved in non-global zone as

/zones/zclient/root/var/log/zones/zoneadm.20141008T025441Z.zclie
nt.install
The installation process may take several minutes depending on the network speed.
h. Now check the status of the zclient zone.
- zclient installed /zones/zclient solaris excl

Chapter 3 - Page 7
i. Boot the zclient zone and check its status again.

root@s11-client:~# zoneadm -z zclient boot
- zclient running /zones/zclient solaris excl
j. Log in to the zclient zone console by using the zlogin C command.
root@s11-client:~# zlogin -C zclient
Note: If it takes considerable amount of time for the console to appear, press the Enter
key. When prompted, provide the following information to set up the zclient zone
and use the F2 key to move to the next option.

Item Value
Computer name zclient
Networking Manually
Manual network configuration net1
IP Address 192.168.10.11
DNS Do not configure DNS
Alternate name service None
Time zone Choose appropriately
Time zone locations Choose appropriately
Root password oracle1
Username oracle
Unser password oracle1
k. When done, press F2 to allow the zclient zone to restart.
[Connected to zone 'zclient' console]
SC profile successfully generated as:

/etc/svc/profile/sysconfig/sysconfig-20141008-
030406/sc_profile.xml
Exiting System Configuration Tool. Log is available at:

/system/volatile/sysconfig/sysconfig.log.9913
Hostname: zclient
zclient console login:
l. Log in to the zclient zone as user oracle and oracle1 as password.
zclient console login: oracle
Password: oracle1
oracle@zclient:~$

Chapter 3 - Page 8
m. Switch to the root role by using the su command.

oracle@zclient:~$ su
Password: oracle1
root@zclient:~#
n. Verify that the network is configured on the zclient zone.
root@zclient:~# ipadm show-addr
lo0/v4 static ok 127.0.0.1/8
net1/v4 static ok 192.168.10.11/24
net1/v6 addrconf ok

fe80::a00:27ff:feb0:7de/10
Observation: The zclient zone is up and is configured with the 192.168.10.11 IP
address.

Chapter 3 - Page 9
Practice 3-2: Configure Virtual Network for Nonglobal Zones on s11-

host01
Overview
For now, the s11-host VM will host three nonglobal zones: zgateway1, pri-services, and
ws1. The zgateway1 zone is the entry point to the pri-services and ws1 zones that are
configured over an etherstub (private virtual network). This implies that all communication from
the external network to the zones on the private virtual network will happen through
zgateway1. As you configure each of the zones, the requirement is to ensure that one by one
each of the zones is able to ping the other. They all need to communicate with each other:
within the private virtual network, within the host, and across hosts.

Tasks
In this practice, you will perform the following tasks:
1. Configure the zimage zone.
2. Configure the zgateway1 zone.
3. Create the stub1 etherstub.
4. Configure the pri-services zone.
5. Reconfigure the zgateway1 zone for a different subnet.
6. Configure the ws1 zone.
Task 1/6
1. Create the zimage zone.
Because so many zones need to be configured on the system, it is a good practice to use
the cloning feature to expedite the zone installation process. The zimage zone is
configured minimally and will be used for cloning other zones in the s11-host01 system.
a. Switch to the s11-host01 terminal and rename the title to zimage.
b. List zone details by using the zoneadm command.
root@s11-host01:~# zoneadm list -cv
c. Configure the zimage zone by using the zonecfg command.
root@s11-host01:~# zonecfg -z zimage
zonecfg:zimage> create
zonecfg:zimage> set zonepath=/zones/zimage
zonecfg:zimage> exit
d. Install the zone.
root@s11-host01:~# zoneadm z zimage install
rpool/zones
rpool/zones/zimage

Chapter 3 - Page 10

/var/log/zones/zoneadm.20141008T025933Z.zimage.install
Image: Preparing at /zones/zimage/root.

AI Manifest: /tmp/manifest.xml.Z4aOaf
Zonename: zimage
Creating IPS image


solaris
DOWNLOAD PKGS FILES XFER
(MB) SPEED
Completed 282/282 53274/53274
351.9/351.9 739k/s
PHASE ITEMS

pkg:/system/manual
done.
Next Steps: Boot the zone, then log into the zone console (zlogin
-C)

/zones/zimage/root/var/log/zones/zoneadm.20141008T025933Z.zimage.in
stall

Chapter 3 - Page 11
root@s11-host01:~#
The installation process may take several minutes depending on the network speed.
e. Display zone information by using the zoneadm command.
- zimage installed /zones/zimage solaris excl
Do not close this terminal. You can continue with the next task on this terminal.
Observation: The zimage zone has been successfully installed and will be used as a

clone to install the various zones in the s11-host01 system.
Task 2/6
2. Configure the zgateway1 zone.
Plumb the zgateway1 zone on the net1 interface with 192.168.10.22 static IP address.

192.168.0.111 192.168.0.112 192.168.0.113
zgateway1
192.168.10.22
zclient
192.168.10.11

192.168.0.100
a. Reset the zimage terminal window to zgateway1.

b. Display zone information by using the zoneadm command.
c. Configure the zgateway1 zone by using the zonecfg command.
root@s11-host01:~# zonecfg -z zgateway1

Chapter 3 - Page 12
zonecfg:zgateway1> create
zonecfg:zgateway1> set zonepath=/zones/zgateway1
zonecfg:zgateway1> add net
zonecfg:zgateway1:net> set physical=net1
zonecfg:zgateway1:net> end
zonecfg:zgateway1> exit

The net1 interface will be used for configuring the 192.168.10.22 IP address. The
net2 interface along with net1 will be required later for configuring IPMP.
root@s11-host01:~# zonecfg -z zgateway1 remove anet
linkname=net0
e. Confirm that the zgateway1 zone is configured and listed.
- zgateway1 configured /zones/zgateway1 solaris excl
f. Install the zgateway1 zone by cloning with the zimage zone.
root@s11-host01:~# zoneadm -z zgateway1 clone zimage
rpool/zones/zgateway1
/var/log/zones/zoneadm.20141008T041159Z.zgateway1.clone
/zones/zgateway1/root/var/log/zones/zoneadm.20141008T041159Z.zga
teway1.clone
root@s11-host01:~#
Observe that the zone installation is much faster now.

g. Check the status of the zgateway1 zone.
- zgateway1 installed /zones/zgateway1 solaris excl
h. Start the zgateway1 zone and check its status again.
root@s11-host01:~# zoneadm z zgateway1 boot

Chapter 3 - Page 13

2 zgateway1 running /zones/zgateway1 solaris excl
i. Log in to the zgateway1 zone console by using the zlogin C command.
root@s11-host01:~# zlogin -C zgateway1
[Connected to zone 'zgateway1' console]
key. When prompted, provide the following information to set up the zgateway1 zone.
Press the F2 key to move to the next option.

Item Value
Computer name zgateway1
Networking Manually
Manual network configuration net1
IP Address 192.168.10.22
Username oracle
User password oracle1
j. When done, press F2 to allow the zgateway1 zone to restart.
etc/svc/profile/sysconfig/sysconfig-20141008-

Hostname: zgateway1
zgateway1 console login:
The zgateway1 zone has been successfully configured.

k. Log in to the zgateway1 zone as user oracle.
zgateway1 console login: oracle
Password:
oracle@zgateway1:~$

Chapter 3 - Page 14
l. Switch to the root role by using the su command.

oracle@zgateway1:~$ su
Password: oracle1
root@zgateway1:~#
m. Verify that the network is configured on the zgateway1 zone.
root@zgateway1:~# ipadm show-addr
lo0/v4 static ok 127.0.0.1/8
net1/v4 static ok 192.168.10.22/24
net1/v6 addrconf ok

fe80::a00:27ff:feb3:5828/10
n. Ping the zclient zone on the s11-client system.
root@zgateway1:~# ping 192.168.10.11
192.168.10.11 is alive
o. Switch to the zclient terminal and ping zgateway1 from the zclient zone.
root@zclient:~# ping 192.168.10.22
192.168.10.22 is alive
Observation: The zgateway1 (192.168.10.22) and zclient (192.168.10.11)
zones are able to communicate with each other.
Task 3/6
3. Create the stub1 etherstub.
You have successfully created and configured the zgateway1 zone. You now require
additional zones (pri-services and ws1) to configure various network services in
subsequent labs. However, these zones need to be specifically protected from the larger
network and the outside world. Recall that etherstubs help you to create private virtual
networks. The pri-services and ws1 zones will be plumbed with VNICs created off the
etherstub, stub1.

Chapter 3 - Page 15

192.168.0.111 192.168.0.112 192.168.0.113
stub01
zgateway1
192.168.10.22
zclient
192.168.10.11

192.168.0.100
window as etherstub.
b. Establish a secure remote connection with the s11-host01 VM by using ssh.
Password: oracle1
Password: oracle1
root@s11-host01:~#
d. Create an etherstub called stub1.
root@s11-host01:~# dladm create-etherstub stub1
e. Verify that the etherstub has been created.
root@s11-host01:~# dladm show-etherstub -Z
LINK ZONE
stub1 global
f. Create three VNICs (vnic2, vnic4, and vnic6) over the stub1 etherstub.
root@s11-host01:~# dladm create-vnic -l stub1 vnic2
g. Display VNIC details.
root@s11-host01:~# dladm show-vnic
LINK OVER SPEED MACADDRESS MACADDRTYPE VIDS

Chapter 3 - Page 16
vnic2 stub1 40000 2:8:20:fa:51:55 random 0

Observation: These VNICs created off stub1 will be assigned to the pri-services and
ws1 zones to create a private virtual network.
Task 4/6
4. Configure the pri-services zone.
The pri-services zone will host essential network services, such as DHCP, DNS, and
LDAP later in your infrastructure. For now, the pri-services zone needs to be
configured on the private virtual network, to isolate it from the external network. All access
to the pri-services zone will be through zgateway1 and never directly. You therefore
need to plumb pri-services over vnic4 with the 192.168.3.4 IP address.

192.168.0.111 pri-services 192.168.0.112 192.168.0.113
192.168.3.4
stub01
zgateway1
192.168.10.22
zclient
192.168.10.11

192.168.0.100
a. Reset the title of the terminal from etherstub to pri-services.

b. Display zone information by using the zoneadm command.
c. Configure the pri-services zone by using the zonecfg command.
root@s11-host01:~# zonecfg -z pri-services
zonecfg:pri-services> create
zonecfg:pri-services> set zonepath=/zones/pri-services

Chapter 3 - Page 17
zonecfg:pri-services> add net

zonecfg:pri-services:net> set physical=vnic4
zonecfg:pri-services:net> end
zonecfg:pri-services> exit
Observe that you have assigned vnic4 to the pri-services zone.

root@s11-host01:~# zonecfg -z pri-services remove anet
linkname=net0
e. Confirm that the pri-services zone is configured and listed.

- pri-services configured /zones/pri-services solaris excl
f. Install the pri-services zone by cloning with the zimage zone.
root@s11-host01:~# zoneadm -z pri-services clone zimage
rpool/zones/pri-services
/var/log/zones/zoneadm.20141008T043157Z.pri-services.clone
Log saved in non-global zone as /zones/pri-
services/root/var/log/zones/zoneadm.20141008T043157Z.pri-
services.clone
- pri-services installed /zones/pri-services solaris excl
g. Start the pri-services zone and check its status again.
root@s11-host01:~# zoneadm -z pri-services boot
5 pri-services running /zones/pri-services solaris excl
h. Log in to the pri-services zone console by using the zlogin C command.
root@s11-host01:~# zlogin -C pri-services

Chapter 3 - Page 18
[Connected to zone 'pri-services' console]

134/134
key. When prompted, provide the following information to set up the pri-services
zone. Use the F2 key to proceed to the next option.
Item Value
Computer name pri-services
Networking Manually
Manual network configuration vnic4
IP Address 192.168.3.4

Username oracle
i. When done, press F2 to allow the pri-services zone to restart.

Hostname: pri-services
pri-services console login:
The pri-services zone has been successfully configured.

j. Log in to the pri-services zone as user oracle.
pri-services console login: oracle
Password: oracle1
oracle@pri-services:~$
k. Switch to the root role by using the su command.
oracle@pri-services:~$ su
Password: oracle1
root@pri-services:~#
l. Verify that the network is configured on the pri-services zone.

Chapter 3 - Page 19
root@pri-services:~# ipadm show-addr

lo0/v4 static ok 127.0.0.1/8
vnic4/v4 static ok 192.168.3.4/24
vnic4/v6 addrconf disabled ::
m. Ping the zgateway1 (192.168.10.22) zone.
root@pri-services:~# ping 192.168.10.22
^C
root@pri-services:~#

Observation: The pri-services zone has been successfully created. However, at this
point, pri-services (192.168.3.4) is not be able to reach zgateway1
(192.168.10.22) because both these zones are on different subnets. You will see how
they will eventually communicate in the next task.
Task 5/6
For pri-services to be able to communicate with the external network, it has to go
through zgateway1, which is currently on the 192.168.10.x network. zgateway1 needs
to be additionally assigned to the 192.168.3.x network for zgateway1 and pri-
services to be able to communicate with each other. You will now plumb vnic2 (created
over stub1) on zgateway1 and assign it the 192.168.3.2 IP address.

192.168.0.111 pri-services 192.168.0.112 192.168.0.113
192.168.3.4
stub01
zgateway1
192.168.10.22
192.168.3.2
zclient
192.168.10.11

192.168.0.100
a. Switch to the zgateway1 terminal.

b. Shut down the zgateway1 zone before modifying the configuration.
root@s11-zgateway1:~# shutdown y g0 -i5

Chapter 3 - Page 20
c. Assign vnic2 to zgateway1 by using the zonecfg command.

zonecfg:zgateway1:net> set physical=vnic2
d. Boot zgateway1 for changes to take effect.
root@s11-host01:~# zoneadm -z zgateway1 boot
e. Log in to the zgateway1 zone.
root@s11-host01:~# zlogin zgateway1

[Connected to zone 'zgateway1' pts/4]
root@zgateway1:~#
f. Display the IP addresses configured on zgateway1.
lo0/v4 static ok 127.0.0.1/8
net1/v4 static ok 192.168.10.22/24
net1/v6 addrconf ok
fe80::a00:27ff:feb3:5828/10
g. Display link details.
root@zgateway1:~# dladm show-link
LINK CLASS MTU STATE OVER
net1 phys 1500 up --
net2 phys 1500 unknown --
vnic2 vnic 9000 up ?
h. Plumb vnic2 on the zgateway1 zone.
root@zgateway1:~# ipadm create-ip vnic2
i. Assign the 192.168.3.2 IP address to vnic2 and display the address details.
root@zgateway1:~# ipadm create-addr -T static -a 192.168.3.2
vnic2
vnic2/v4
lo0/v4 static ok 127.0.0.1/8
net1/v4 static ok 192.168.10.22/24
vnic2/v4 static ok 192.168.3.2/24
net1/v6 addrconf ok
fe80::a00:27ff:feb3:5828/10

Chapter 3 - Page 21
j. Check if zgateway1 is now able to reach the pri-services zone.

192.168.3.4 is alive
k. Check if zgateway1 is able to reach the zclient zone.
192.168.10.11 is alive
l. Switch to the pri-services terminal, and verify if the pri-services zone is able to
reach the zgateway1 zone.
192.168.3.2 is alive

m. Check if the pri-services zone is able to reach the zclient zone.
ping: sendto No route to host
Although pri-services is able to reach zgateway1 through the 192.168.3.x

network, it cannot get to zclient, which is on the 192.168.10.x network.
n. Switch back to the zgateway1 terminal, and check the IP forwarding property of the
zgateway1 zone.
root@zgateway1:~# ipadm show-prop -p forwarding ipv4
PROTO PROPERTY PERM CURRENT PERSISTENT DEFAULT POSSIBLE
ipv4 forwarding rw off -- off on,off
The IP forwarding property is switched off.

o. Enable zgateway1 to function as a router by turning on its IP forwarding property.
root@zgateway1:~# ipadm set-prop -p forwarding=on ipv4
root@zgateway1:~# ipadm show-prop -p forwarding ipv4
PROTO PROPERTY PERM CURRENT PERSISTENT DEFAULT POSSIBLE
ipv4 forwarding rw on on off on,off
p. Switch to the pri-services terminal and check if the pri-services zone is now able
to reach both the zgateway1 and zclient zones over the 192.168.10.x network.
192.168.10.22 is alive
192.168.10.11 is alive
q. Now, switch to the zclient terminal, and check if the zclient zone is able to reach
zgateway1 and pri-services through both the 192.168.10.x and
192.168.3.x networks.
192.168.10.22 is alive
192.168.3.2 is alive

Chapter 3 - Page 22

192.168.3.4 is alive
Observation: You have successfully established a communication channel from the
zclient zone all the way to the pri-services zone through the zgateway1 zone. You
first plumbed a VNIC from an etherstub to the zgateway1 zone and assigned it a
192.168.3.2 IP address. Secondly, by enabling the IP forwarding property, you
transformed the zgateway1 zone to also act as a router and allow communication across
subnets.
Task 6/6
6. Configure the ws1 zone.

The ws1 zone will be used in a subsequent lab to configure the Apache web server. For
now, you will configure the zone over the private virtual network (vnic6) and ensure that it
is able to communicate with other zones within the host and with the zclient zone on the
s11-client system.

192.168.0.111 pri-services 192.168.0.112 192.168.0.113
192.168.3.4
ws1
192.168.3.6
stub01
zgateway1
192.168.10.22
192.168.3.2
zclient
192.168.10.11

192.168.0.100
window as ws1.
Password: oracle1
Password: oracle1

Chapter 3 - Page 23
root@s11-host01:~#
d. Display zone information by using the zoneadm command.
e. Configure the ws1 zone by using the zonecfg command.
root@s11-host01:~# zonecfg -z ws1

zonecfg:ws1> create
zonecfg:ws1> set zonepath=/zones/ws1
zonecfg:ws1> add net
zonecfg:ws1:net> set physical=vnic6
zonecfg:ws1:net> end
zonecfg:ws1> exit
f. Remove the net0 interface from the zone configuration.
root@s11-host01:~# zonecfg -z ws1 remove anet linkname=net0
g. Start the ws1 zone by cloning with the zimage zone.
root@s11-host01:~# zoneadm -z ws1 clone zimage
rpool/zones/ws1
/var/log/zones/zoneadm.20141009T010407Z.ws1.clone
/system/zones/ws1/root/var/log/zones/zoneadm.20141009T010407Z.ws
1.clone
root@s11-host01:~#
h. Boot the ws1 zone.
root@s11-host01:~# zoneadm -z ws1 boot
8 ws1 running /zones/ws1 solaris excl
i. Log in to the ws1 zone console by using the zlogin C command.
root@s11-host01:~# zlogin -C ws1
[Connected to zone 'ws1' console]

Chapter 3 - Page 24
134/134
Note: If it takes considerable amount of time for the console to appear, press Enter.
When prompted, provide the following information to set up the ws1 zone.
Item Value
Computer name ws1
Networking Manually
Manual network configuration vnic6
IP Address 192.168.3.6

Username oracle
j. When done, press F2 to allow the ws1 zone to restart.

Hostname: ws1
ws1 console login:
k. Log in to the ws1 zone as user oracle.
ws1 console login: oracle
Password: oracle1
l. Switch to the root role by using the su command.
oracle@ws1:~$ su
Password: oracle1
root@ws1:~#
m. Verify that the network is configured on the ws1 zone.
root@ws1:~# ipadm show-addr
lo0/v4 static ok 127.0.0.1/8
vnic6/v4 static ok 192.168.3.6/24

Chapter 3 - Page 25
vnic6/v6 addrconf ok
fe80::8:20ff:fe30:945d/10
n. Verify that the ws1 zone is able to communicate with the pri-services,
zgateway1, and zclient zones.
root@ws1:~# ping 192.168.3.4
192.168.3.4 is alive
root@ws1:~# ping 192.168.3.2
192.168.3.2 is alive
root@ws1:~# ping 192.168.10.22
192.168.10.22 is alive
root@ws1:~# ping 192.168.10.11

192.168.10.11 is alive
o. Switch to the zgateway1 terminal, and verify that the zgateway1 zone is able to
communicate with ws1.
192.168.3.6 is alive
p. Switch to the zclient terminal on the s11-client system and verify that the zclient
zone is able to communicate with the ws1 zone.
192.168.3.6 is alive
Observation: You have successfully configured the ws1 zone on a private virtual network.
The ws1 zone is able to communicate with other zones in the s11-host01 system and with
the zclient zone on the s11-client system. This is because zgateway1 was already
reconfigured on the 192.168.3.x network, and additionally enabled as a router.

Chapter 3 - Page 26
Practice 3-3: Configure Virtual Network for Nonglobal Zones on s11-

host02
Overview
Just the way you created nonglobal zones in the s11-host01 system, you will now create a
similar setup on the s11-host02 system. You will be able to appreciate the usefulness of a
redundant system in the next lab on High Availability (HA). For now, you just create the setup
and ensure that all the zones (zgateway2, sec-services, and ws2) are on the network and
are able to communicate with each other within the host and across hosts.
To expedite the process, you will this time configure all these resources by just running a script.
However, just as you did in the s11-host01 system, you will start by creating a zone called
zimage with the most basic configuration to be used as a clone for configuring other zones in

the host.
Tasks
1. Create the zimage zone for cloning.
2. Run the zcreate.sh script to create resources on s11-host02.
Task 1/3
1. Create the zimage zone for cloning.
window as zimage.
Password: oracle1
Password: oracle1
root@s11-host02:~#
d. Display zone information by using the zoneadm command.
e. Configure the zimage zone by using the zonecfg command.
root@s11-host02:~# zonecfg -z zimage
zonecfg:zimage> create
zonecfg:zimage> set zonepath=/zones/zimage

Chapter 3 - Page 27
zonecfg:zimage> exit
f. Install the zimage zone.
root@s11-host02:~# zoneadm z zimage install
rpool/zones
rpool/zones/zimage
/var/log/zones/zoneadm.20141008T025933Z.zimage.install
Image: Preparing at /zones/zimage/root.

AI Manifest: /tmp/manifest.xml.Z4aOaf
Zonename: zimage
Creating IPS image

solaris
DOWNLOAD PKGS FILES
XFER (MB) SPEED
Completed 282/282 53274/53274
351.9/351.9 739k/s
PHASE ITEMS

pkg:/system/manual
done.

Chapter 3 - Page 28
Next Steps: Boot the zone, then log into the zone console
(zlogin -C)

/zones/zimage/root/var/log/zones/zoneadm.20141008T025933Z.zimage
.install
root@s11-host01:~#
The installation may take a few minutes depending on the network speed.

g. Display zone information by using the zoneadm command.
Observation: The zimage zone has been successfully installed and will be used by the
script to install the various zones.
Task 2/3
2. Run the zcreate.sh script to create resources on s11-host02.
The zcreate.sh script is meant to create the zgateway2, sec-services, and ws2
zones, along with the stub2 etherstub and vnic3, vnic5, and vnic7 VNICs in the s11-
host02 system.

192.168.3.4 192.168.3.5
ws1 ws2
192.168.3.6 192.168.3.7
stub01 stub02
zgateway1 zgateway2
192.168.10.22 192.168.3.3
192.168.3.2
zclient
192.168.10.11

192.168.0.100
a. Reset the zimage terminal title to s11-host02.

Chapter 3 - Page 29
b. Run the zcreate.sh script from the /opt/ora/script folder.

root@s11-host02:~# /opt/ora/script/zcreate.sh
Watch the messages as each of the resource is being configured.

c. Verify that the zones were successfully created and installed.
5 sec-services running /zones/sec-services solaris excl
6 ws2 running /zones/ws2 solaris excl

The zones have indeed been successfully configured.

d. Remove the net0 interface from the zone configurations.
root@s11-host02:~# zonecfg -z zgateway2 remove anet
linkname=net0
root@s11-host02:~# zonecfg -z sec-services remove anet
linkname=net0
root@s11-host02:~# zonecfg -z ws2 remove anet linkname=net0
Observation: The zgateway2, sec-services, and ws2 zones have been successfully
configured. Optionally, you can log in into each of these zones and verify if the zones are
able to communicate with each other within the host. They certainly will be able to, because
they are all on the 192.168.3.x network. However, they cannot communicate with the
external network (192.168.10.x) yet.
Task 3/3
You will now reconfigure the zgateway2 zone by plumbing it with the net1 interface and
assigning it the 192.168.10.33 IP address to extend communication across subnets.
This will allow the zones on the private virtual network to communicate with the external
network through zgateway2.

Chapter 3 - Page 30

192.168.3.4 192.168.3.5
ws1 ws2
192.168.3.6 192.168.3.7
stub01 stub02
zgateway1 zgateway2
192.168.10.22 192.168.3.3
192.168.3.2 192.168.10.33
zclient
192.168.10.11

192.168.0.100
a. Rename the terminal from s11-host02 to zgateway2 now.

b. Log in to the zgateway2 zone.
c. Display IP address details.
lo0/v4 static ok 127.0.0.1/8
vnic3/v4 static ok 192.168.3.3/24
d. Check whether you can ping the zclient zone on the s11-client system.
ping: sendto No route to host
This is because the zgateway2 zone is not on the 192.168.10.x subnet yet.
e. Shut down the zgateway2 zone.
root@zgateway2:~# shutdown y g0 i5
f. Assign the net1 and net2 interfaces to the zgateway2 zone from the global zone.

Chapter 3 - Page 31
Although you will use the net1 interface to plumb on zgateway2 right away, you will
use the net2 interface later in a subsequent lab to configure IPMP.
g. Boot the zone.
h. Log in to the zone.
i. Display link details.

j. Plumb the net1 interface.
root@zgateway2:~# ipadm create-ip net1
k. Assign the 192.168.10.33 IP address to net1.
net1
net1/v4
l. Display IP address details.
lo0/v4 static ok 127.0.0.1/8
vnic3/v4 static ok 192.168.3.3/24
net1/v4 static ok 192.168.10.33/24
m. Now, enable IP forwarding on the zgateway2 zone to allow data routing across
subnets.
root@zgateway2:~# ipadm set-prop -p forwarding=on ipv4
Observation: You have successfully created a basic virtual network infrastructure spanning
three hosts. In the next part of this lab, you can take the setup to the next level of
virtualization by isolating zones across hosts with the VXLAN and EVS technologies.

Chapter 3 - Page 32
Practice 3-4: Configure the EVS Controller
Overview
EVS enables you to create and administer a virtual switch spanning multiple nodes. In
Murrayas prototype, you need to isolate the application zones (zapp1 and zapp2) across
hosts, s11-host01 and s11-host02. Secondly, these application zones need to communicate
with another set of isolated zones (zclient, zgateway1, and zgateway2 across three
different hosts) that provide connectivity with the external network.

1. Configure the EVS controller on s11-server.
2. Configure EVS controller properties.

3. Create the appSwitch EVS on the EVS controller.
4. Create the gateSwitch EVS on the EVS controller.
Task 1/4
1. Configure the EVS controller on s11-server.
An EVS controller provides functionality for the configuration and administration of an EVS
and all the resources associated with it. You must set up only one physical machine as the
EVS controller in a network. In this setup, you will configure the s11-server system as the
EVS controller.

192.168.3.4 192.168.3.5
ws1 ws2
192.168.3.6 192.168.3.7
stub01 stub02
zgateway1 zgateway2
192.168.10.22 192.168.3.3
192.168.3.2 192.168.10.33
zclient
192.168.10.11

EVS Manager
a. Switch to the s11-server terminal and verify that the IPS repository is accessible.
root@s11-server:~# pkg publisher
PUBLISHER TYPE STATUS P LOCATION
solaris origin online F http://s11-server.mydomain.com/
b. Install the mandatory evs package. This package must be installed on all hosts that
participate in an EVS setup.

Chapter 3 - Page 33
root@s11-server:~# pkg install evs

Packages to install: 1
Services to change: 1
Create boot environment: No
Create backup boot environment: No
DOWNLOAD PKGS FILES
XFER (MB) SPEED
Completed 1/1 15/15
0.1/0.1 76.4k/s
PHASE ITEMS

root@s11-server:~#
c. Install the rad-ev-controller package. This package needs to be installed on the
EVS controller only.
root@s11-server:~# pkg install rad-evs-controller
DOWNLOAD PKGS FILES
XFER (MB) SPEED
Completed 1/1 7/7
0.1/0.1 192k/s
PHASE ITEMS
root@s11-server:~#
d. Restart the rad:local service to load the EVS controller.
root@s11-server:~# svcadm restart rad:local
root@s11-server:~# svcs rad:local
STATE STIME FMRI
online 10:49:58 svc:/system/rad:local

Chapter 3 - Page 34
e. Generate an RSA key pair in the local system to set up SSH authentication.
root@s11-server:~# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): <Enter>
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase): <Enter>
Enter same passphrase again: <Enter>
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
0b:b2:0f:f9:68:be:09:dd:ee:37:72:0a:73:33:2d:d2 root@s11-server

root@s11-server:~# ls /root/.ssh
id_rsa id_rsa.pub
f. Copy the id_rsa.pub file from the local system directory root/.ssh/id_rsa.pub
to the system directory, /var/user/evsuser/.ssh/authorized_keys.
root@s11-server:~# cat /root/.ssh/id_rsa.pub >>
/var/user/evsuser/.ssh/authorized_keys
g. Set the controller property to use the user, evsuser.
root@s11-server:~# evsadm set-prop -p
controller=ssh://evsuser@localhost
The user, evsuser is created when the mandatory service/network/evs

package is installed. evsuser has all the authorizations and privileges to perform
EVS operations.
h. Display the configured EVS controller details.
root@s11-server:~# evsadm show-prop
PROPERTY PERM VALUE DEFAULT
controller rw ssh://evsuser@localhost --
i. Log in to the system as evsuser from the local system.
root@s11-server:~# ssh evsuser@localhost
The authenticity of host 'localhost (::1)' can't be established.
f2:fe:20:51:b8:f8:27:2a:f2:30:bc:fb:e0:67:87:6d.
Warning: Permanently added 'localhost' (RSA) to the list of
known hosts.
Last login: Thu Oct 9 11:07:57 2014 from localhost
evsuser@s11-server:~$ exit
Connection to localhost closed.
Observation: The EVS controller has been successfully configured on the s11-server
system.

Chapter 3 - Page 35
Task 2/4
2. Configure EVS controller properties.
Because the plan is to use VXLAN as the EVS backbone, you need to set the properties on
the EVS controller accordingly.
a. Display the properties of the EVS controller.
root@s11-server:~# evsadm show-controlprop
PROPERTY PERM VALUE DEFAULT HOST
l2-type rw vlan vlan --
uplink-port rw -- -- --
vlan-range rw -- -- --

vlan-range-avail r- -- -- --
vxlan-addr rw 0.0.0.0 0.0.0.0 --
vxlan-ipvers rw v4 v4 --
vxlan-mgroup rw 0.0.0.0 0.0.0.0 --
vxlan-range rw -- -- --
vxlan-range-avail r- -- -- --
b. Set the l2-type property to vxlan.
root@s11-server:~# evsadm set-controlprop -p l2-type=vxlan
l2-type rw vxlan vlan --
vxlan-addr rw 0.0.0.0 0.0.0.0 --
vxlan-mgroup rw 0.0.0.0 0.0.0.0 --
c. Set the IP address for the VXLAN.
root@s11-server:~# evsadm set-controlprop -p vxlan-
addr=192.168.0.0/24
vxlan-addr rw 192.168.0.0/24 0.0.0.0 --
vxlan-mgroup rw 0.0.0.0 0.0.0.0 --

Chapter 3 - Page 36
d. Set the VXLAN range.
root@s11-server:~# evsadm set-controlprop -p vxlan-range=200-300
vxlan-addr rw 192.168.0.0/24 0.0.0.0 --

vxlan-mgroup rw 0.0.0.0 0.0.0.0 --
vxlan-range rw 200-300 -- --
vxlan-range-avail r- 200-300 -- --
Observation: You have successfully configured the EVS controller properties. The EVS
controller is now set for use over VXLAN.
Task 3/4
3. Create the appSwitch EVS on the EVS controller.
The appSwitch EVS needs to be over the 192.168.2.x subnet. It will eventually host
the zapp1 and zapp2 zones over it.

192.168.3.4 192.168.3.5
ws1 ws2
192.168.3.6 192.168.3.7
stub01 stub02
zgateway1 zgateway2
192.168.10.22 192.168.3.3
192.168.3.2
zclient
192.168.10.11

EVS Manager
a. Create the appSwitch EVS.

root@s11-server:~# evsadm create-evs appSwitch
root@s11-server:~# evsadm show-evs
EVS TENANT STATUS NVPORTS IPNETS HOST

Chapter 3 - Page 37
appSwitch sys-global idle 0 -- --

b. Add subnet details to appSwitch.
root@s11-server:~# evsadm add-ipnet -p subnet=192.168.2.0/24
appSwitch/app_ipnet
root@s11-server:~# evsadm show-ipnet
NAME TENANT SUBNET DEFROUTER
AVAILRANGE
appSwitch/app_ipnet sys-global 192.168.2.0/24 192.168.2.1
192.168.2.6-192.168.2.254
c. Add four vports to appSwitch for later use.
root@s11-server:~# evsadm add-vport appSwitch/vport0

root@s11-server:~# evsadm show-vport
NAME TENANT STATUS VNIC HOST
appSwitch/vport0 sys-global free -- --
Observation: Of the four vports configured over appSwitch, two will be used by the
zapp1 and zapp1 zones and two by the zgateway1 and zgateway2 zones.

Chapter 3 - Page 38
Task 4/4
4. Create the gateSwitch EVS on the EVS controller.
The gateSwitch EVS is the second EVS switch that will isolate the zgateway1,
zgateway2, and zclient zones across three different hosts. These zones are the main
channels of communication with the external network. The gateSwitch EVS needs to be
over the 192.168.1.x subnet.

192.168.3.4 192.168.3.5
ws1 ws2
192.168.3.6 192.168.3.7

stub01 stub02
zgateway1 zgateway2
192.168.10.22 192.168.3.3
192.168.3.2
zclient
192.168.10.11

EVS Manager
a. In the s11-server terminal, create the gateSwitch EVS.

root@s11-server:~# evsadm create-evs gateSwitch
root@s11-server:~# evsadm show-evs
appSwitch sys-global idle 4 app_ipnet --
gateSwitch sys-global idle 0 -- --
b. Add subnet details to the gateSwitch EVS.
root@s11-server:~# evsadm add-ipnet -p subnet=192.168.1.0/24
gateSwitch/gate_ipnet
AVAILRANGE
192.168.2.6-192.168.2.254
gateSwitch/gate_ipnet sys-global 192.168.1.0/24 192.168.1.1
192.168.1.2-192.168.1.254

Chapter 3 - Page 39
c. Add four vports to the gateSwitch EVS.

root@s11-server:~# evsadm add-vport gateSwitch/vport0
root@s11-server:~# evsadm show-vport
NAME TENANT STATUS VNIC HOST
appSwitch/vport0 sys-global used -- --

gateSwitch/vport0 sys-global free -- --
Observation: You have successfully created the gateSwitch EVS. Of the four vports
created, only three will be used: one each by the zgateway1, zgateway2, and the
zclient zones.

Chapter 3 - Page 40
Practice 3-5: Configure EVS Client Nodes
Overview
The EVS controller, along with the appSwitch and gateSwicth EVSs, has been configured.
You now need to isolate nodes over these EVSs. The zapp1 and zapp2 zones will go over the
appSwitch EVS, whereas the zgateway1, zgateway2, and zclient zones will go over the
gateSwitch EVS. You will be exposed to specific requirements of isolating the zones under
each task, as you perform them.

1. Configure the zapp1 zone over the appSwitch EVS.

3. Assign the gateSwitch EVS to the zclient zone.
4. Assign the gateSwitch EVS to the zgateway1 and zgateway2 zones.
5. Assign the appSwitch EVS to the zgateway1 and zgateway2 zones.
Task 1/5
There are two parts to this setup. First, every host that participates in an EVS setup needs
to be authenticated by the system configured as the EVS controller. After that is done, the
zones that are to be consolidated over the EVS switch need to be either configured or
reconfigured to become part of the EVS network.

192.168.3.4 192.168.3.5
ws1 ws2
192.168.3.6 192.168.3.7
stub01 stub02
zapp1
zgateway1 192.168.2.2 zgateway2
192.168.10.22 192.168.3.3
192.168.3.2
zclient
192.168.10.11

EVS Manager
a. From the s11-client desktop, open a terminal window and set the title of the window as
zapp1.
Password: oracle1

Chapter 3 - Page 41

Password: oracle1
root@s11-host01:~#
d. Install the mandatory evs package on the host system.
root@s11-host01:~# pkg install evs

Planning linked: 0/4 done; 1 working: zone:ws1
Planning linked: 1/4 done; 1 working: zone:zimage
Planning linked: 2/4 done; 1 working: zone:pri-services
Planning linked: 3/4 done; 1 working: zone:zgateway1
Planning linked: 4/4 done
DOWNLOAD PKGS FILES
XFER (MB) SPEED
Completed 1/1 15/15
0.1/0.1 212k/s
Downloading linked: 0/4 done; 1 working: zone:ws1

Downloading linked: 1/4 done; 1 working: zone:zimage
Downloading linked: 2/4 done; 1 working: zone:pri-services
Downloading linked: 3/4 done; 1 working: zone:zgateway1
Downloading linked: 4/4 done
PHASE ITEMS
Executing linked: 0/4 done; 1 working: zone:ws1
Executing linked: 1/4 done; 1 working: zone:zimage
Executing linked: 2/4 done; 1 working: zone:pri-services
Executing linked: 3/4 done; 1 working: zone:zgateway1
Executing linked: 4/4 done
root@s11-host01:~# ssh-keygen -t rsa

Chapter 3 - Page 42

c9:6c:68:07:dd:3a:3b:c9:8e:18:4b:8d:96:fb:78:fc root@s11-host01
root@s11-host01:~# ls /root/.ssh
id_rsa id_rsa.pub
f. Copy the id_rsa.pub file to the /var/tmp/ local directory.

root@s11-host01:~# cat /root/.ssh/id_rsa.pub >>
/var/tmp/host01.public
g. Copy the host01.public file to the /var/tmp folder on the s11-server system.
root@s11-host01:~# scp /var/tmp/host01.public oracle@s11-
server:/var/tmp
established.
f2:fe:20:51:b8:f8:27:2a:f2:30:bc:fb:e0:67:87:6d.
Password: oracle1
host01.public 100% |*****************************| 397
00:00
h. Now, switch to the s11-server terminal and check whether the host01.public file
exists.
root@s11-server:~# ls /var/tmp/
host01.public
i. Copy the host01.public file from the /var/tmp directory to the system directory,
/var/user/evsuser/.ssh/authorized_keys.
root@s11-server:~# cat /var/tmp/host01.public >>
The EVS node has now been authenticated by the EVS controller.
j. Now, switch back to the zapp1 terminal.
k. Set the controller property to use the user, evsuser.
root@s11-host01:~# evsadm set-prop -p
controller=ssh://evsuser@s11-server
root@s11-host01:~# evsadm show-prop

Chapter 3 - Page 43
controller rw ssh://evsuser@s11-server --
l. Log in to the remote system as evsuser from the local system.
root@s11-host01:~# ssh evsuser@s11-server
Last login: Fri Oct 10 04:54:10 2014
m. Display EVS information.
root@s11-host01:~# evsadm
NAME TENANT STATUS VNIC IP
HOST
appSwitch sys-global idle -- app_ipnet --

vport0 -- free -- 192.168.2.2/24 --
vport1 -- free -- 192.168.2.3/24 --
vport2 -- free -- 192.168.2.4/24 --
vport3 -- free -- 192.168.2.5/24 --
gateSwitch sys-global idle -- gate_ipnet --
vport0 -- free -- 192.168.1.2/24 --
vport1 -- free -- 192.168.1.3/24 --
vport2 -- free -- 192.168.1.4/24 --
vport3 -- free -- 192.168.1.5/24 --
root@s11-host01:~# evsadm show-evs
appSwitch sys-global idle 4 app_ipnet --
gateSwitch sys-global idle 4 gate_ipnet --
root@s11-host01:~# evsadm show-controlprop
vxlan-addr rw 192.168.0.0/24 0.0.0.0 --
vxlan-mgroup rw 0.0.0.0 0.0.0.0 --
Now that the host has been authenticated with the EVS controller system, you can
configure the zapp1 zone as an EVS node.
n. Configure the zapp1 zone with the appSwitch EVS on the vport0 port.
root@s11-host01:~# zonecfg -z zapp1
zonecfg:zapp1> create

Chapter 3 - Page 44

zonecfg:zapp1> set zonepath=/zones/zapp1
zonecfg:zapp1> add anet
zonecfg:zapp1:anet> set evs=appSwitch
zonecfg:zapp1:anet> set vport=vport0
zonecfg:zapp1:anet> end
zonecfg:zapp1> exit
o. Remove the net0 interface from the zone configuration.
root@s11-host01:~# zonecfg -z zapp1 remove anet linkname=net0
p. Install the zapp1 zone by using the zimage clone.

root@s11-host01:~# zoneadm -z zapp1 clone zimage
rpool/zones/zapp1
/var/log/zones/zoneadm.20141010T011747Z.zapp1.clone
/zones/zapp1/root/var/log/zones/zoneadm.20141010T011747Z.zapp1.c
lone
q. Boot the zapp1 zone.
root@s11-host01:~# zoneadm -z zapp1 boot
r. Log in to the zapp1 console.
root@s11-host01:~# zlogin -C zapp1
[Connected to zone 'zapp1' console]
134/134
When prompted, provide the following information to set up the zapp1 zone.
Item Value
Computer name zapp1
Networking You will see this message:
No configurable interface
found. They are all controlled
from global zone. This is
because you did not assign
any interface to the zone. The
zones interface is now
controlled by the EVS
controller.
Also note that you will not see
pages to configure DNS and
LDAP, because there is no
network interface at all.

Chapter 3 - Page 45

Username Oracle
s. When done, press F2 to allow the zapp1 zone to boot.


Hostname: zapp1
zapp1 console login:
t. Log in to the zapp1 zone.
zapp1 console login: oracle
Password: oracle1
u. Assume root role by using su.
oracle@zapp1:~$ su
password: oracle1
root@zapp1:~#
v. Verify the IP address of zapp1.
root@zapp1:~# ipadm show-addr
lo0/v4 static ok 127.0.0.1/8
net1/v4 inherited ok 192.168.2.2/24
Observe that the 192.168.2.2 IP address for the net1/v4 interface has been
inherited from the EVS controller. Note that the net1/v4 nomenclature has nothing to
do with the physical net1 interface. The net1/v4 interface here has been created
over a vport, vport0.
w. Switch to the s11-server terminal and display EVS details.
root@s11-server:~# evsadm
NAME TENANT STATUS VNIC IP HOST
appSwitch sys-global busy -- app_ipnet s11-
host01
vport0 -- used zapp1/net1 192.168.2.2/24 s11-
host01
vport1 -- free -- 192.168.2.3/24 --
vport2 -- free -- 192.168.2.4/24 --

Chapter 3 - Page 46
vport3 -- free -- 192.168.2.5/24 --

gateSwitch sys-global idle -- gate_ipnet
--
vport0 -- free -- 192.168.1.2/24 --
vport1 -- free -- 192.168.1.3/24 --
vport2 -- free -- 192.168.1.4/24 --
vport3 -- free -- 192.168.1.5/24 --
Task 2/5
Because the zapp2 zone is to be configured on the s11-host02 system, you need to once
again follow the two-step procedure. First, authenticate the host with the EVS controller and

then configure the zone for the EVS setup.

192.168.3.4 192.168.3.5
ws1 ws2
192.168.3.6 192.168.3.7
stub01 stub02
zapp1
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2
zclient
192.168.10.11

EVS Manager
zapp2.
Password: oracle1
Password: oracle1
root@s11-host02:~#
d. Install the mandatory evs package on the host system.
root@s11-host02:~# pkg install evs

Chapter 3 - Page 47
Planning linked: 0/4 done; 1 working: zone:zimage
Planning linked: 1/4 done; 1 working: zone:sec-services
Planning linked: 2/4 done; 1 working: zone:ws2
Planning linked: 3/4 done; 1 working: zone:zgateway2
DOWNLOAD PKGS FILES
XFER (MB) SPEED

Completed 1/1 15/15
0.1/0.1 168k/s
Downloading linked: 0/4 done; 1 working: zone:zimage

Downloading linked: 1/4 done; 1 working: zone:sec-services
Downloading linked: 2/4 done; 1 working: zone:ws2
Downloading linked: 3/4 done; 1 working: zone:zgateway2
PHASE ITEMS
Executing linked: 0/4 done; 1 working: zone:zimage
Executing linked: 1/4 done; 1 working: zone:sec-services
Executing linked: 2/4 done; 1 working: zone:ws2
Executing linked: 3/4 done; 1 working: zone:zgateway2
root@s11-host02:~# ssh-keygen -t rsa
5f:fa:53:8a:25:53:4e:bf:d3:5f:12:5d:06:30:da:61 root@s11-host02

Chapter 3 - Page 48
root@s11-host02:~# ls /root/.ssh
id_rsa id_rsa.pub
f. Copy the id_rsa.pub file to the /var/tmp/ local directory.
root@s11-host02:~# cat /root/.ssh/id_rsa.pub >>
/var/tmp/host02.public
g. Copy the host01.public file to the /var/tmp folder on the s11-server system.
root@s11-host02:~# scp /var/tmp/host02.public oracle@s11-
server:/var/tmp
established.

f2:fe:20:51:b8:f8:27:2a:f2:30:bc:fb:e0:67:87:6d.
Password: oracle1
host02.public 100% |*****************************| 397
00:00
h. Now, switch to the s11-server terminal and check whether the host02.public file
exists.
host01.public host02.public
i. Copy the host01.public file from the /var/tmp directory to the system directory,
root@s11-server:~# cat /var/tmp/host02.public >>
j. Now, switch back to the zapp2 terminal.
k. Set the controller property to use the user, evsuser.
root@s11-host02:~# evsadm set-prop -p
l. Log in to the remote system as evsuser from the local system.
root@s11-host02:~# ssh evsuser@s11-server
Connection to s11-server closed.
m. Display EVS information.
root@s11-host02:~# evsadm show-evs
appSwitch sys-global busy 4 app_ipnet s11-host01

Chapter 3 - Page 49
Now that the s11-host02 system has been authenticated by the EVS controller, you
can configure the zapp2 zone to connect with the appSwitch EVS.
n. Configure the zapp2 zone with the appSwitch EVS on the vport1 port.
root@s11-host02:~# zonecfg -z zapp2
zonecfg:zapp2> create
zonecfg:zapp2> set zonepath=/zones/zapp2
zonecfg:zapp2> add anet
zonecfg:zapp2:anet> set evs=appSwitch
zonecfg:zapp2:anet> set vport=vport1

zonecfg:zapp2:anet> end
zonecfg:zapp2> exit
o. Remove the net0 interface from the zone configuration.
root@s11-host02:~# zonecfg -z zapp2 remove anet linkname=net0
p. Install the zapp2 zone by cloning with the zimage clone.
root@s11-host02:~# zoneadm -z zapp2 clone zimage
rpool/zones/zapp2
/var/log/zones/zoneadm.20141010T011747Z.zapp1.clone
/zones/zapp2/root/var/log/zones/zoneadm.20141010T011747Z.zapp2.c
lone
root@s11-host02:~#
q. Boot the zapp2 zone.
root@s11-host02:~# zoneadm -z zapp2 boot
r. Log in to the zapp2 console.
root@s11-host02:~# zlogin -C zapp2
[Connected to zone 'zapp2' console]
134/134
When prompted, provide the following information to set up the zapp2 zone.
Item Value
Computer name zapp2
Networking You will see this message:
No configurable interface
found. They are all controlled
from global zone. This is
because you did not assign
any interface to the zone. The
zones interface is now
controlled by the EVS

Chapter 3 - Page 50
controller.
Also note that you will not see
pages to configure DNS and
LDAP, because there is no
network interface at all.
Username oracle

s. When done, press F2 to allow the zone to boot.

Hostname: zapp2
zapp2 console login:
t. Log in to the zapp2 zone.
zapp2 console login: oracle
Password: oracle1
oracle@zapp2:~$
u. Assume the root role by using the su command.
oracle@zapp2:~$ su
password: oracle1
root@zapp2:~#
v. Verify the IP address of the zapp2 zone.
root@zapp2:~# ipadm show-addr
lo0/v4 static ok 127.0.0.1/8
Observe that the 192.168.2.3 IP address for the net1/v4 interface has been
inherited from the EVS controller.
w. Verify if the zapp2 zone is able to communicate with the zapp1 zone across hosts.
root@zapp2:~# ping 192.168.2.2

Chapter 3 - Page 51
192.168.2.2 is alive
x. Switch to the s11-server terminal and display EVS details.
HOST
host01,s11-host02
host01
host02

vport2 -- free -- 192.168.2.4/24 --
vport3 -- free -- 192.168.2.5/24 --
vport0 -- free -- 192.168.1.2/24 --
vport1 -- free -- 192.168.1.3/24 --
vport2 -- free -- 192.168.1.4/24 --
vport3 -- free -- 192.168.1.5/24 --
Observation: You have successfully isolated the zapp1 and zapp2 zones over the
appSwitch EVS.
Task 3/5
3. Assign the gateSwitch EVS to the zclient zone.
Because the s11-client system has not yet been authenticated by the EVS controller, you
need to perform host authentication with s11-server before assigning the gateSwitch
EVS to the zclient zone.

192.168.3.4 192.168.3.5
ws1 ws2
192.168.3.6 192.168.3.7
stub01 stub02
zapp1
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient
192.168.10.11
192.168.1.2

EVS Manager

Chapter 3 - Page 52
a. Switch to the zclient terminal and exit out of the zclient zone.
root@zclient:~# shutdown y g0 i5
root@s11-client:~#
b. Install the mandatory evs package on the s11-client host system.
root@s11-client:~# pkg install evs
Planning linked: 0/1 done; 1 working: zone:zclient

DOWNLOAD PKGS FILES
XFER (MB) SPEED
Completed 1/1 15/15
0.1/0.1 212k/s
Downloading linked: 0/1 done; 1 working: zone:zclient

PHASE ITEMS
Executing linked: 0/1 done; 1 working: zone:zclient
c. Generate an RSA key pair in the local system to set up SSH authentication.
root@s11-client:~# ssh-keygen -t rsa
Enter file in which to save the key (/root/.ssh/id_rsa):
c9:6c:68:07:dd:3a:3b:c9:8e:18:4b:8d:96:fb:78:fc root@s11-host01
root@s11-client:~# ls /root/.ssh
id_rsa id_rsa.pub
d. Copy the id_rsa.pub file to the /var/tmp/ local directory.

Chapter 3 - Page 53
root@s11-client:~# cat /root/.ssh/id_rsa.pub >>

/var/tmp/client01.public
e. Copy the client01.public file to the /var/tmp folder on the s11-server system.
root@s11-client:~# scp /var/tmp/client01.public oracle@s11-
server:/var/tmp
Password: oracle1
client01.public 100% |*****************************|
397 00:00
f. Now, switch to the s11-server terminal and check whether the client01.public file
exists.

clint01.public
g. Copy the client01.public file from the /var/tmp directory to the system directory,
root@s11-server:~# cat /var/tmp/client01.public >>
h. Now, switch back to the zclient terminal.
i. Set the controller property to use the user, evsuser.
root@s11-client:~# evsadm set-prop -p
root@s11-client:~# evsadm show-prop
controller rw ssh://evsuser@s11-server --
j. Log in to the remote system as evsuser from the local system.
root@s11-client:~# ssh evsuser@s11-server
k. Display EVS information.
root@s11-client:~# evsadm
host01,s11-host02
vport0 -- used zapp1/net1 192.168.2.2/24
s11-host01
s11-host02
vport2 -- free -- 192.168.2.4/24
--
vport3 -- free -- 192.168.2.5/24
--
vport0 -- free -- 192.168.1.2/24 --

Chapter 3 - Page 54
vport1 -- free -- 192.168.1.3/24

--
vport2 -- free -- 192.168.1.4/24
--
vport3 -- free -- 192.168.1.5/24
--
root@s11-client:~# evsadm show-evs
appSwitch sys-global busy 4 app_ipnet s11-
host01,s11-host02

Now that the host has been authenticated by the EVS controller, you can configure the
zclient zone to connect with the gateSwitch EVS.
l. Assign the zclient zone to the gateSwitch EVS over the port, vport2.
zonecfg:zclient> add anet
zonecfg:zclient:anet> set evs=gateSwitch
zonecfg:zclient:anet> set vport=vport0
zonecfg:zclient:anet> end
m. Boot the zclient zone.
n. Log in to the zone.
root@s11-client:~# zlogin zclient
o. Display the IP address details.
lo0/v4 static ok 127.0.0.1/8
net1/v4 static ok 192.168.10.11/24
net1/v6 addrconf ok fe80::a00:27ff:fe8b:9d42/10
Observation: The 192.168.1.2 IP address has been inherited from the gateSwitch
EVS. You have successfully attached the zclient zone to the gateSwitch EVS.

Chapter 3 - Page 55
Task 4/5
4. Assign the gateSwitch EVS to the zgateway1 and zgateway2 zones.

192.168.3.4 192.168.3.5
ws1 ws2
192.168.3.6 192.168.3.7
stub01 stub02
zapp1
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11
192.168.1.2


EVS Manager
a. Now, switch to the zgateway1 terminal and shut down the zgateway1 zone.
b. Assign the gateSwitch EVS to zgateway1.
root@s11-host01:~# zonecfg z zgateway1
zonecfg:zgateway1> add anet
zonecfg:zgateway1:anet> set evs=gateSwitch
zonecfg:zgateway1:anet> set vport=vport1
zonecfg:zgateway1:anet> end
c. Boot the zgateway1 zone.
d. Log in to the zone.
e. Display the IP address details.
lo0/v4 static ok 127.0.0.1/8
net1/v4 static ok 192.168.10.22/24
vnic2/v4 static ok 192.168.3.2/24

Chapter 3 - Page 56
net1/v6 addrconf ok
fe80::a00:27ff:fe48:25db/10
The 192.168.1.3 IP address has been inherited from the gateSwitch EVS. You
have successfully attached the zgateway1 zone to the gateSwitch EVS.
f. Now, switch to the zgateway2 terminal and shut down the zgateway2 zone.
root@zgateway2:~# shutdown -y g0 i5
g. Assign the gateSwitch to zgateway2.
zonecfg:zgateway2:anet> set evs=gateSwitch

h. Boot the zgateway2 zone.
i. Log in to the zone.
j. Display the IP address details.
lo0/v4 static ok 127.0.0.1/8
vnic3/v4 static ok 192.168.3.3/24
net1/v4 static ok 192.168.10.33/24
The 192.168.1.4 IP address has been inherited from the gateSwitch EVS. You
have successfully attached the zgateway2 zone to the gateSwitch EVS.
k. Now, ping the zgateway1 zone on 192.168.1.3.
192.168.1.3 is alive
l. Switch to the zgateway1 terminal, and ping the zgateway2 zone on 192.168.1.4.
192.168.1.4 is alive
Observation: Both the zgateway1 and zgateway2 zones are able to ping each other
over the 192.168.1.x VXLAN network. However, they cannot communicate with the
zones on the appSwicth EVS, which is on the 192.168.2.x VXLAN network.

Chapter 3 - Page 57
Task 5/5
5. Assign the appSwitch EVS to the zgateway1 and zgateway2 zones.
A zone can belong to two different EVS switches. In this case, the zgateway zones over
the gateSwitch EVS need to be able to communicate with the zapp zones over the
appSwitch EVS.

192.168.3.4 192.168.3.5
ws1 ws2
192.168.3.6 192.168.3.7
stub01 stub02

zapp1
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11
192.168.2.4 198.168.2.5
192.168.1.2

EVS Manager
a. Switch to the zgateway1 terminal and shut down the zgateway1 zone.
b. Assign the appSwitch EVS to the zgateway1 zone.
zonecfg:zgateway1:anet> set evs=appSwitch
Recall that vports, vport0 and vport1 have already been taken by zapp1 and zapp2
zones.
c. Boot the zone.
d. Log in to the zone.
e. Display IP address details.

Chapter 3 - Page 58
lo0/v4 static ok 127.0.0.1/8

net1/v4 static ok 192.168.10.22/24
vnic2/v4 static ok 192.168.3.2/24
net1/v6 addrconf ok
fe80::a00:27ff:fe48:25db/10
The zgateway1 zone has picked up another IP, 192.168.2.4, this time from the
appSwitch EVS.

f. Now, ping the zapp1 zone.
192.168.2.2 is alive
g. Switch to the zapp1 terminal and ping the zgateway1 zone on the 192.168.2.4 IP.
root@zapp1:~# ping 192.168.2.4
192.168.2.4 is alive
h. Now, switch to the zgateway2 terminal. You need to perform similar steps to bring
zgateway2 on to the appSwitch EVS.
i. Shut down the zgateway2 zone.
j. Modify the zone to add the appSwitch EVS details.
zonecfg:zgateway2:anet> set evs=appSwitch
k. Boot the zone.
l. Log in to the zone.
m. Display IP address details.
lo0/v4 static ok 127.0.0.1/8
vnic3/v4 static ok 192.168.3.3/24
net1/v4 static ok 192.168.10.33/24

Chapter 3 - Page 59
The zgateway2 zone has picked up the 192.168.2.5 IP address from the
appSwitch EVS.
n. Now, ping the zapp1 zone.
192.168.2.2 is alive
Notice that you can now also ping zones on the appSwitch EVS through zgateway1
and zgateway2 but not from zclient. That is because the zgateway zones are part
of the appSwitch EVS as well, which the zclient zone is not.
o. Switch to the s11-server terminal and collect the overall EVS statistics.

appSwitch sys-global busy -- app_ipnet s11-host01,s11-
host02
vpot0 -- used zapp1/net1 192.168.2.2/24 s11-host01
vpot1 -- used zapp2/net1 192.168.2.3/24 s11-host02
vpot2 -- used zgateway1/net3 192.168.2.4/24 s11-host01
vpot3 -- used zgateway2/net3 192.168.2.5/24 s11-host02
gateSwitch sys-global busy -- gate_ipnet s11-client,s11-
host02
vport0 -- used zclient/net0 192.168.1.2/24 s11-client
vport1 -- used zgateway1/net0 192.168.1.3/24 s11-host01
vport2 -- used zgateway2/net0 192.168.1.4/24 s11-host02
vport3 -- free -- 192.168.1.5/24 --
Observe how easily zones can be isolated and consolidated by using EVS. You have
successfully tested the EVS setup. You also managed to illustrate that one zone can
belong to two different EVS switches. In this case, the zgateway zones are part of
both the appSwitch and gateSwitch EVSs.
Note: Now, given that this is a VBox environment, with certain limitations on resources, it
would help to unconfigure the zclient, zgateway1, and zgateway2 zones off the EVS
switches for now. The multiple IPs inherited from EVSs and the vports on a VBox setup can
potentially lead to router conflicts. By unconfiguring the three zones off the EVS setup, you
pre-empt any such disruptions.
p. Switch to the zclient terminal and unconfigure the zclient zone from the
gateSwitch EVS.
root@zclient:~# shutdown y g0 i5
root@s11-client:~# zonecfg z zclient remove anet
evs=gateSwitch
root@s11-client:~# zoneadm z zclient boot
root@zclient:~#
q. Switch to the zgateway1 terminal and unconfigure the zgateway1 zone from the
gateSwitch and appSwitch EVSs.

Chapter 3 - Page 60
root@s11-host01:~# zonecfg z zgateway1 remove anet

evs=gateSwitch
evs=appSwitch
root@zgateway1:~#
r. Switch to the zgateway2 terminal and unconfigure the zgateway2 zone from the
gateSwitch and appSwitch EVSs.

evs=gateSwitch
evs=appSwitch
root@zgateway2:~#
Summary: You observed how zones can be isolated by using EVS. You can apply this
knowledge to another setup. You can now proceed with testing the Oracle Solaris 11 HA
technologies in the next lab.

Chapter 3 - Page 61

Chapter 3 - Page 62

Configuring Network High
Availability
Chapter 4
Practices for Lesson 4: Configuring Network High Availability

Chapter 4 - Page 1
Practices Overview
Murraya Inc. requires a network that is failure proof. In one of the previous labs, you created a
set of redundant resources on a redundant system, s11-host02. A redundant host ensures that
the network and network services continue to operate on the alternative host, if one of the hosts
fails. Now, within each of these hosts, you will establish network High Availability (HA) at various
levels, such as IPMP for IP failover, link aggregation for higher bandwidth and datalink HA, L3
VRRP for router failover, and ILB for load balancing across nodes.
Configure IPMP
Configure link aggregation

Configure L3 VRRP
Configure ILB
The following is the schematic representation of the setup you will build and test in this lab:

192.168.3.4 192.168.3.5
ws1 ws2
192.168.3.6 192.168.3.7
stub01 stub02
zapp1
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11 192.168.10.100 192.168.10.100
192.168.2.4 198.168.2.5
192.168.1.2
IPMP IPMP

EVS Manager

Chapter 4 - Page 2

s11-server
192.168.0.100 192.168.20.x
s11-client zclient
192.168.0.111 192.168.10.11 192.168.1.2
s11-host01 zgateway1 192.168.10.22 192.168.3.2 192.168.2.4 192.168.1.3 192.168.10.100
192.168.0.112 pri-
ws1 192.168.3.6
zapp1 192.168.2.2

192.168.10.33 192.168.3.3 192.168.2.5 192.168.1.4 192.168.10.100
192.168.0.113 sec-
ws2 192.168.3.7
zapp2 192.168.2.3

Chapter 4 - Page 3
Assumptions:
command output.

connection:
nonglobal zones. In case, your terminal hangs while shutting down, open a new
<zonename> command.

Chapter 4 - Page 4
Practice 4-1: Configure IPMP
Overview
The zgateway1 and zgateway2 zones are the entry zones for the network-in-a-box setup.
These zones are configured over the net1 interfaces. This means that if there is network failure
on the net1 interfaces of the zgateway1 or zgateway2 zones, all zones in the internal
network lose network connectivity with the external network. It is therefore critical to configure a
redundant interface so that network continuity is ensured in the event of any one interface
failing.
Tasks

1. Assign an IPMP group to the zgateway1 zone.
Task 1/2
To configure an IPMP group, you require two interfaces. Because net1 has already been
configured on the zgateway1 zone, you need to dismantle it first and then reuse it for
creating an IPMP group. In addition, you will use the net2 interface along with the net1
interface.
Note: The net0 and net3 interfaces will be used in subsequent practices.

192.168.3.4 192.168.3.5
ws1 ws2
192.168.3.6 192.168.3.7
stub01 stub02
zapp1
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11 192.168.2.4 192.168.2.5
192.168.1.2
IPMP

EVS Manager

b. Identify the network devices to be used for configuring IPMP.
root@zgateway1:~# dladm show-phys

Chapter 4 - Page 5

c. Display link details.
d. Display the IP address information of the interfaces.

lo0/v4 static ok 127.0.0.1/8
net1/v4 static ok 192.168.10.22/24
vnic2/v4 static ok 192.168.3.2/24
net1/v6 addrconf ok fe80::a00:27ff:fe48:25db/10
e. Delete the IP address on net1.
root@zgateway1:~# ipadm delete-addr net1/v4
lo0/v4 static ok 127.0.0.1/8
vnic2/v4 static ok 192.168.3.2/24
net1/v6 addrconf ok fe80::a00:27ff:fe48:25db/10
f. Delete the net1 interface.
root@zgateway1:~# ipadm delete-ip net1
g. Create the net1 and net2 interfaces.
h. Create the IPMP group, ipmp2 with net1 and net2 interfaces.
root@zgateway1:~# ipadm create-ipmp -i net1 -i net2 ipmp2

Chapter 4 - Page 6
i. Assign IP address (192.168.10.22) to the IPMP group, ipmp2.

ipmp2
ipmp2/v4
lo0/v4 static ok 127.0.0.1/8
vnic2/v4 static ok 192.168.3.2/24
ipmp2/v4 static ok 192.168.10.22/24
j. Display the group-wise IPMP subsystem status.

root@zgateway1:~# ipmpstat -g
GROUP GROUPNAME STATE FDT INTERFACES
ipmp2 ipmp2 ok -- net2 net1
k. Display the interface information about the IPMP group.
root@zgateway1:~# ipmpstat -i
INTERFACE ACTIVE GROUP FLAGS LINK PROBE STATE
net2 yes ipmp2 ------- up disabled ok
net1 yes ipmp2 --mbM-- up disabled ok
where:
m indicates that the interface is designated for sending and receiving IPv4 multicast
traffic for the IPMP group
b indicates that the interface is designated for receiving broadcast traffic for the IPMP
group
M indicates that the interface is designated for sending and receiving IPv6 multicast
traffic for the IPMP group
l. Verify that zgateway1 is able to communicate with zgateway2 and zclient over
the 192.168.10.x network.
192.168.10.11 is alive
192.168.10.33 is alive
Observation: The zgateway1 zone is plumbed over an IPMP group, ipmp2 with the
192.168.10.22 IP address. This means, that even if one of the underlying interfaces
were to fail, either net1 or net2, the alternative interface would become operational.

Chapter 4 - Page 7
Task 2/2
To configure an IPMP group on the zgateway2 zone, perform similar steps as you did in
the zgateway1 zone.

192.168.3.4 192.168.3.5
ws1 ws2
192.168.3.6 192.168.3.7
stub01 stub02
zapp1

192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11 192.168.2.4 198.168.2.5
192.168.1.2
IPMP IPMP

EVS Manager

b. Identify the network devices to be used for configuring IPMP.
root@zgateway2:~# dladm show-phys
c. Display link details.
d. Display the IP address information of the interfaces.
lo0/v4 static ok 127.0.0.1/8
vnic3/v4 static ok 192.168.3.3/24
net1/v4 static ok 192.168.10.33/24

Chapter 4 - Page 8
e. Delete the IP address on net1.

root@zgateway2:~# ipadm delete-addr net1/v4
lo0/v4 static ok 127.0.0.1/8
vnic3/v4 static ok 192.168.3.3/24
f. Delete the net1 interface.
root@zgateway2:~# ipadm delete-ip net1

g. Create the net1 and net2 interfaces.
h. Create the IPMP group, ipmp2 with net1 and net2 interfaces.
root@zgateway2:~# ipadm create-ipmp -i net1 -i net2 ipmp2
i. Assign the 192.168.10.33 IP address to the IPMP group.
ipmp2
ipmp2/v4
lo0/v4 static ok 127.0.0.1/8
vnic3/v4 static ok 192.168.3.3/24
ipmp2/v4 static ok 192.168.10.33/24
j. Display the group-wise IPMP subsystem status.
root@zgateway2:~# ipmpstat -g
GROUP GROUPNAME STATE FDT INTERFACES
ipmp2 ipmp2 ok -- net2 net1

Chapter 4 - Page 9
k. Display the interface information about the IPMP group.

root@zgateway2:~# ipmpstat -i
INTERFACE ACTIVE GROUP FLAGS LINK PROBE STATE
net2 yes ipmp2 ------- up disabled ok
net1 yes ipmp2 --mbM-- up disabled ok
l. Verify that the zgateway2 zone is able to communicate with the zgateway1 and
zclient zones over the 192.168.10.x network.
192.168.10.22 is alive
192.168.10.11 is alive

Observation: The zgateway2 zone is plumbed over the IPMP group, ipmp2 and
assigned the 192.168.10.33 IP address. The zgateway2 zone is able to communicate
with both the zgateway1 and zclient zones.

Chapter 4 - Page 10
Practice 4-2: Configure Link Aggregation
Overview
Link aggregation allows multiple NICs to be grouped into a single logical interface. Link
aggregations provide cumulative bandwidth as well as HA. The zclient zone would do better
with aggregated bandwidth than just the bandwidth from a single interface.
Tasks
In this practice, you will configure trunk aggregation for the zclient zone.

192.168.3.4 192.168.3.5
ws1 ws2
192.168.3.6 192.168.3.7
stub01 stub02
zapp1
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11 192.168.2.4 198.168.2.5
192.168.1.2
IPMP IPMP

EVS Manager
Task 1/1
1. Configure trunk aggregation for the zclient zone.
To configure trunk aggregation, you again require a minimum of two interfaces. The net1
interface has already been configured on the zclient zone. You, therefore, need to
dismantle and repurpose it along with net2 for creating the aggregation, aggr0.
Note that trunk aggregation can only be created in the global zone. After plumbing the
aggregation to a zone, you then assign it with an IP address from inside the nonglobal
zone.
a. Open the zclient terminal and display link information.
root@zclient:~# dladm show-link

Chapter 4 - Page 11
b. Display IP address information.

lo0/v4 static ok 127.0.0.1/8
net1/v4 static ok 192.168.10.11/24
net1/v6 addrconf ok
fe80::a00:27ff:fe8b:9d42/10
c. Delete the net1 address.
root@zclient:~# ipadm delete-addr net1/v4

lo0/v4 static ok 127.0.0.1/8
net1/v6 addrconf ok
fe80::a00:27ff:fe8b:9d42/10
d. Shut down the zclient zone.
root@zclient:~# shutdown y g0 -i5
e. Display IP address information of the s11-client host.
root@s11-client:~# ipadm show-addr
lo0/v4 static ok 127.0.0.1/8
net0/v4 static ok 192.168.0.111/24
f. Display link details.
root@s11-client:~# dladm show-link
zclient/net1 phys 1500 up --
g. Create the aggregation, aggr0 with net1 and net2 interfaces.
root@s11-client:~# dladm create-aggr -l net1 -l net2 aggr0
root@s11-client:~# dladm show-link
aggr0 aggr 1500 up net1 net2

Chapter 4 - Page 12
h. Assign the aggregation, aggr0, to the zclient zone.

zonecfg:zclient:net> set physical=aggr0
zonecfg:zclient:net> set physical=net2
Apart from adding the aggr0 interface to the zclient zone, you also need to add the

net2 interface. This is because aggr0 requires both net1 and net2 as the underlying
interfaces. Because the net1 interface is already configured on the zone, you now
need to only add the net2 interface.
i. Boot the zclient zone for the changes to take effect.
j. Log in to the zone.
[Connected to zone 'zclient' pts/2]
Oracle Corporation SunOS 5.11 11.2 May 2014
k. Display IP address information.
lo0/v4 static ok 127.0.0.1/8
net1/v6 addrconf disabled ::
l. Create the aggregation interface.
root@zclient:~# ipadm create-ip aggr0
aggr0 aggr 1500 up net1, net2
m. Reassign the 192.168.10.11 IP address to the aggregation, aggr0.
root@zclient:~# ipadm create-addr -T static -a 192.168.10.11
aggr0
aggr0/v4
lo0/v4 static ok 127.0.0.1/8
aggr0/v4 static ok 192.168.10.11/24

Chapter 4 - Page 13
At the first attempt at displaying the IP information, you might see the aggregation
STATE as disabled. Try the ipadm show-addr command again and it should show
OK.
n. Verify that zclient is able to ping the zgateway1 and zgateway2 zones.
192.168.10.22 is alive
192.168.10.33 is alive
Observation: You have successfully configured an aggregation, aggr0 and assigned the
collective bandwidth of the aggregation to the zclient zone.

Note: Configuring Datalink Multipathing (DLMP)
The next level of HA can be achieved at the datalink level. This is possible through DLMP.
However, because of the limited interfaces in a virtual box setup and the requirement for
physical switches, you will be unable to implement DLMP in this setup. Configuring DLMP
involves a simple step of mentioning the mode type in the dladm create-aggr command.
Caution: Do not perform the following steps. Although the command can be executed, but
because DLMP has a hardware dependency, it will disrupt other activities in the labs that
follow.
root@s11-client:~# dladm modify-aggr -m dlmp aggr0
root@s11-client:~# dladm show-aggr
LINK MODE POLICY ADDRPOLICY LACPACTIVITY LACPTIMER
aggr0 dlmp -- -- -- --

Chapter 4 - Page 14
Practice 4-3: Configure L3 VRRP
Overview
Oracle Solaris 11 provides proprietary Layer 3 VRRP to support the creation of VRRP routers
over IPMP and infiniBand interfaces. Configuring L3 VRRP over the ipmp2 interfaces on
zgateway1 and zgateway2 will ensure that if either of the zgateway zones is down, the
VRRP router on the alternative zgateway zone would continue to route data packets.

1. Configure L3 VRRP on the zgateway1 zone.

Task 1/2
You can repurpose the IPMP group, ipmp2 as the fundamental channel for the L3 VRRP
router in this prototype. An L3 VRRP router, unlike an L2 VRRP router, can be configured
over an IPMP group.

192.168.3.4 192.168.3.5
ws1 ws2
192.168.3.6 192.168.3.7
stub01 stub02
zapp1
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11 192.168.10.100
192.168.2.4 198.168.2.5
192.168.1.2
IPMP IPMP

EVS Manager
a. On the zgateway1 terminal, install the vrrp package.

root@zgateway1:~# pkg install vrrp
DOWNLOAD PKGS FILES
XFER (MB) SPEED
Completed 1/1 15/15
0.1/0.1 245k/s

Chapter 4 - Page 15
PHASE ITEMS

lo0/v4 static ok 127.0.0.1/8
vnic2/v4 static ok 192.168.3.2/24
ipmp2/v4 static ok 192.168.10.22/24
c. Create the L3 VRRP router.
root@zgateway1:~# vrrpadm create-router -V 1 -I ipmp2 -A inet -T
L3 -a 192.168.10.100 -p 255 vrrp2
lo0/v4 static ok 127.0.0.1/8
vnic2/v4 static ok 192.168.3.2/24
ipmp2/v4 static ok 192.168.10.22/24
ipmp2/v4a vrrp ok 192.168.10.100/24
d. Display router details.
root@zgateway1:~# vrrpadm show-router
NAME VRID TYPE IFNAME AF PRIO ADV_INTV MODE STATE VNIC
vrrp2 1 L3 ipmp2 IPv4 255 1000 eopa- MASTER
The vrrp2 router at this point is the MASTER router as indicated by its STATE.
e. Display the currently active routes.
root@zgateway1:~# netstat -rm
streams allocation:
cumulative allocation current maximum total failures
streams 458 470 104102 0
queues 984 996 119673 0
mblk 11502 11780 73016 0
dblk 11503 12573 1888573 0
linkblk 42 83 77 0
syncq 12 25 199 0

Chapter 4 - Page 16
qband 0 0 0 0
3091 Kbytes allocated for streams data
Routing Table: IPv4

Destination Gateway Flags Ref Use Interface
-------------- ---------------- ----- ----- ---- --------
Localhost localhost UH 2 60 lo0
192.168.3.0 192.168.3.2 U 2 0 vnic2
192.168.10.0 192.168.10.100 U 2 0 ipmp2

192.168.10.0 zgateway1 U 4 4 ipmp2
Routing Table: IPv6

Destination/Mask Gateway Flags Ref Use If
-------------------- ---------- ----- --- ---- -----
localhost localhost UH 2 252 lo0
Observation: The zgateway1 zone now has an L3 VRRP router, vrrp2, configured over
the IPMP interface, ipmp2, with the 192.168.10.100 VIP.
Task 2/2
The reason you would configure an L3 VRRP router on zgateway2 as well, is to ensure
that if zgateway1 goes down, the VRRP router on zgateway2 would become the MASTER
router and continue routing data packets.

192.168.3.4 192.168.3.5
ws1 ws2
192.168.3.6 192.168.3.7
stub01 stub02
zapp1
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11 192.168.10.100 192.168.10.100
192.168.2.4 198.168.2.5
192.168.1.2
IPMP IPMP

EVS Manager

Chapter 4 - Page 17
a. Switch to the zgateway2 terminal and install the vrrp package.

root@zgateway2:~# pkg install vrrp
DOWNLOAD PKGS FILES
XFER (MB) SPEED
Completed 1/1 15/15
0.1/0.1 245k/s

PHASE ITEMS
lo0/v4 static ok 127.0.0.1/8
vnic3/v4 static ok 192.168.3.3/24
ipmp2/v4 static ok 192.168.10.33/24
c. Create the L3 VRRP router.
root@zgateway2:~# vrrpadm create-router -V 1 -I ipmp2 -A inet -T
L3 -a 192.168.10.100 -p 100 vrrp2
lo0/v4 static ok 127.0.0.1/8
vnic3/v4 static ok 192.168.3.3/24
ipmp2/v4 static ok 192.168.10.33/24
ipmp2/v4a vrrp down 192.168.10.100/24
It is important that the VIP of the router is the same across both the zgateway1 and
zgateway2 zones. Only then router failover is possible.
However, the p value for priority should be different on the routers. p 255 specified
on zgateway1 is the priority of the MASTER router. p 100 specified on the
zgateway2 zone is the priority of the BACKUP router.

Chapter 4 - Page 18
d. Display router details.

vrrp2 1 L3 ipmp2 IPv4 100 1000 e-pa- BACKUP --
The vrrp2 router on zgateway2 is in the BACKUP state. This is because currently the
VRRP router in zgateway1 is in the MASTER state.
e. Display the currently active routes.
root@zgateway2:~# netstat -rm
streams allocation:
cumulative allocation current maximum total failures

streams 437 450 69456 0
queues 953 960 81822 0
mblk 11471 11780 66882 0
dblk 11472 12648 1679216 0
linkblk 42 83 69 0
syncq 12 25 156 0
qband 0 0 0 0
3061 Kbytes allocated for streams data
Routing Table: IPv4

Destination Gateway Flags Ref Use Interface
-------------- ---------- ----- ----- ---- ---------
Localhost localhost UH 2 28 lo0
192.168.3.0 zgateway2 U 2 0 vnic3
192.168.10.0 192.168.10.33 U 4 3 ipmp2
Routing Table: IPv6

Destination/Mask Gateway Flags Ref Use If
-------------------- ---------- ----- --- ---- -----
localhost localhost UH 2 252 lo0
The 192.168.10.100 IP does not appear in the routing list because, the IP is active
on the MASTER router, zgateway1.
f. Now, switch to the zgateway1 terminal and bring down the zgateway1 zone.
root@zgateway1:~# init 5

Chapter 4 - Page 19
g. Switch back to the zgateway2 terminal, and watch the state of the VRRP router.
vrrp2 1 L3 ipmp2 IPv4 100 1000 e-pa- MASTER --
Observation: As zgateway1 comes down, the state of the VRRP router changes from
BACKUP to MASTER on zgateway2.

Chapter 4 - Page 20
Practice 4-4: Configure ILB
Overview
Another level of HA implementation is through ILB. ILB provides Layer 3 and Layer 4 load-
balancing capabilities on SPARC and x86-based Oracle Solaris systems. ILB intercepts
incoming requests from clients, decides which back-end server should address the request
based on load-balancing rules, and then forwards the request to the selected server.
You will configure ILB on the zgateway1 and zgateway2 zones to implement load balancing
over the ws1 and ws2 zones that act as web servers across two hosts.
Tasks

1. Install ILB on the zgateway1 zone.
3. Test http requestresponse activity from the zclient zone.
Task 1/3
The plan is to install ILB on the zgateway1 zone. The ILB algorithm, on request from a
client, would then decide which of the web servers configured on ws1 and ws2 zones would
respond to the request.

192.168.3.4 192.168.3.5
ws1 ws2
192.168.3.6 192.168.3.7
stub01 stub02
zapp1
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11 192.168.10.100 192.168.10.100
192.168.2.4 198.168.2.5
192.168.1.2
IPMP IPMP

EVS Manager
a. Open the zgateway1 terminal.

b. Because the zgateway1 zone was shut down in the previous task, boot up the zone.
c. Log in to the zgateway1 zone.

Chapter 4 - Page 21
d. Install the ilb package.

root@zgateway1:~# pkg install ilb
DOWNLOAD PKGS FILES
XFER (MB) SPEED
Completed 1/1 23/23
0.2/0.2 782k/s

PHASE ITEMS
e. Enable the ilb service.
root@zgateway1:~# svcadm enable ilb
f. Create server groups with ws1 (192.168.3.6) and ws2 (192.168.3.7) zones.
root@zgateway1:~# ilbadm create-servergroup -s
server=192.168.3.6,192.168.3.7 sg1
root@zgateway1:~# ilbadm show-servergroup
SGNAME SERVERID MINPORT MAXPORT IP_ADDRESS
sg1 _sg1.0 -- -- 192.168.3.6
sg1 _sg1.1 -- -- 192.168.3.7
A server group is a bunch of servers across which the load balancing algorithm
operates. In this case, it would be ws1 and ws2 zones, configured across two hosts.
g. Create a health check, hc1 by using the built-in PING probe to monitor the health of
the server group.
root@zgateway1:~# ilbadm create-healthcheck h hc-test=PING,hc-
timeout=2,hc-count=3,hc-interval=10 hc1
root@zgateway1:~# ilbadm show-healthcheck
HCNAME TIMEOUT COUNT INTERVAL DEF_PING TEST
hc1 2 3 10 y PING

Chapter 4 - Page 22
h. Create the ilb rule.

root@zgateway1:~# ilbadm create-rule e -p -i
vip=192.168.10.100,port=80,protocol=tcp -m lbalg=rr,type=HALF-
NAT, -h hc-name=hc1 -o servergroup=sg1 rule1
root@zgateway1:~# ilbadm show-rule
RULENAME STATUS LBALG TYPE PROTOCOL VIP PORT
rule1 E roundrobin HALF-NAT TCP 192.168.10.100 80
i. Optionally, display health check results.
root@zgateway1:~# ilbadm show-hc-result
RULENAME HCNAME SERVERID STATUS FAIL LAST NEXT RTT
rule1 hc1 _sg1.0 alive 3 07:55:54 07:56:09 0

rule1 hc1 _sg1.1 unreach 0 07:55:57 07:56:12 119
j. Open the ws1 terminal.
k. Install the apache-22 package.
root@ws1:~# pkg install apache-22
DOWNLOAD PKGS FILES
XFER (MB) SPEED
Completed 8/8 680/680
9.5/9.5 501k/s
PHASE ITEMS
l. Make the following entry in the index.html file.
root@ws1:~# echo "WS1 responding..." >
/var/apache2/2.2/htdocs/index.html
Depending on which web server responds to the client request, you will see the
respective index.html file being called.
m. Enable the http service.
root@ws1:~# svcadm enable http
n. Finally, add the 192.168.3.2 IP address of zgateway1 as the default route on ws1.
root@ws1:~# route add default 192.168.3.2

Chapter 4 - Page 23
Observation: You have successfully configured ILB on the zgateway1 zone and the
Apache web server on the ws1 zone.
Task 2/3
Because the plan is to test load-balancing implemented over a VRRP setup, you will
configure ILB and Apache web server on the zgateway2 and ws2 zones, respectively.

192.168.3.4 192.168.3.5
ws1 ws2
192.168.3.6 192.168.3.7

stub01 stub02
zapp1
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11 192.168.10.100 192.168.10.100
192.168.2.4 198.168.2.5
192.168.1.2
IPMP IPMP

EVS Manager
a. Open the zgateway2 terminal and install the ilb package.

root@zgateway2:~# pkg install ilb
DOWNLOAD PKGS FILES
XFER (MB) SPEED
Completed 1/1 23/23
0.2/0.2 782k/s
PHASE ITEMS

Chapter 4 - Page 24
b. Enable the ilb service.

root@zgateway2:~# svcadm enable ilb
c. Create server groups with the ws1 and ws2 zones.
root@zgateway2:~# ilbadm create-servergroup -s
server=192.168.3.6,192.168.3.7 sg1
root@zgateway2:~# ilbadm show-servergroup
SGNAME SERVERID MINPORT MAXPORT IP_ADDRESS
sg1 _sg1.0 -- -- 192.168.3.6
sg1 _sg1.1 -- -- 192.168.3.7
d. Create a health check, hc1 by using the built-in PING probe to monitor the health of
the server group.

root@zgateway2:~# ilbadm create-healthcheck h hc-test=PING,hc-
timeout=2,hc-count=3,hc-interval=10 hc1
root@zgateway1:~# ilbadm show-healthcheck
HCNAME TIMEOUT COUNT INTERVAL DEF_PING TEST
hc1 2 3 10 y PING
e. Create the ilb rule.
root@zgateway2:~# ilbadm create-rule e -p -i
vip=192.168.10.100,port=80,protocol=tcp -m lbalg=rr,type=HALF-
NAT, -h hc-name=hc1 -o servergroup=sg1 rule1
root@zgateway1:~# ilbadm show-rule
RULENAME STATUS LBALG TYPE PROTOCOL VIP PORT
rule1 E roundrobin HALF-NAT TCP 192.168.10.100 80
f. Optionally, display health check results.
root@zgateway2:~# ilbadm show-hc-result
RULENAME HCNAME SERVERID STATUS FAIL LAST NEXT RTT
rule1 hc1 _sg1.0 unreach 3 07:55:30 07:55:36 0
rule1 hc1 _sg1.1 alive 0 07:55:29 07:55:39 119
g. Now, open a new terminal from the s11-client desktop, and rename it as ws2.
h. Establish a secure remote connection with the s11-host02 VM, and log in to the ws2
zone.
Password: oracle1
Password: oracle1
root@s11-host02:~# zlogin ws2
i. Install the apache-22 package.
root@ws2:~# pkg install apache-22

Chapter 4 - Page 25

DOWNLOAD PKGS FILES
XFER (MB) SPEED
Completed 8/8 680/680
9.5/9.5 501k/s
PHASE ITEMS

j. Make the following entry in the index.html file.
root@ws2:~# echo "WS2 responding..." >
/var/apache2/2.2/htdocs/index.html
Depending on which web server responds to the client request, you will see the
respective index.html file being called.
k. Enable the http service.
root@ws2:~# svcadm enable http
l. Also, add the 192.168.3.3 IP address of zgateway2 as the default route on ws2.
root@ws2:~# route add default 192.168.3.3
Observation: You have successfully configured the redundant ILB on the zgateway2
zone and the Apache web server on the ws2 zone.
Task 3/3
3. Test http requestresponse activity.
a. Open the zclient terminal.
b. Add the 192.168.10.100 IP address of the VRRP router as the default route.
root@zclient:~# route add default 192.168.10.100
Know that route add default is a nonpersistent command. So if ever, you reboot
the zclient zone and would like to retest the http requestresponse activity, ensure
that you make the route add default entry once again.
c. Make an http request to the web server.
root@zclient:~# wget http://192.168.10.100:80
--2014-09-22 17:50:27-- http://192.168.10.100/
Connecting to 192.168.10.100:80... connected.
HTTP request sent, awaiting response... 200 OK

Chapter 4 - Page 26
Length: 17 [text/html]
Saving to: index.html
100%[======================================>] 17 --.-
K/s in 0s
2014-09-22 17:50:27 (1.55 MB/s) - index.html saved [17/17]

d. Output the index.html file to verify which of the web servers responded to your
request.
root@zclient:~# cat index.html
WS1 responding

root@zclient:~#
This indicates that the http request went to the zgateway1 zone, where ILB routed
the request to the web server on the ws1 zone. This is when both zgateway1 and
zgateway2 zones are up.
e. Now, switch to the zgateway1 terminal and bring down the zgateway1 zone.
root@zgateway1:~# init 5
f. Switch back to the zclient terminal and make an http request to the web server
again.
--2014-09-22 17:50:27-- http://192.168.10.100/
Saving to: index.html.1
100%[======================================>] 17 --.-
K/s in 0s
2014-09-22 17:50:27 (1.55 MB/s) - index.html.1 saved [17/17]
The x in the index.html.x file carries an incremental value with every response from
the web server.
g. Output the index.html.1 file to verify which of the web servers responded to your
request.
root@zclient:~# cat index.html.1
WS2 responding
root@zclient:~#

Chapter 4 - Page 27
This time the request was answered by the ws2 zone. Because zgateway1 was
down, VRRP router became the MASTER router on the zgateway2 zone. The ILB on
the zgateway2 zone sends the request to the web server on the ws2 zone.
Note: Now that you have understood how a redundant system provides HA to the
infrastructure, you can continue to build redundant resources on the s11-host02 system,
just as you did in this lab. However, for the sake of convenience, and to optimize on
memory resources in a VBox setup, you will only reinforce the s11-host01 system with
network services and resource optimization. Therefore, you can now shut down the s11-
host02 resources.
h. Switch to the zgateway2 terminal and shut down the zones running in the s11-host02
system.

root@s11-host02:~# zoneadm z sec-services shutdown
root@s11-host02:~# zoneadm z ws2 shutdown
i. Close the terminal window by clicking the X symbol at the far-right corner.
j. Shut down the s11-host02 system by clicking the X symbol in the s11-host02 VM
window.
k. Select the Power-off the system option.
Summary: You successfully configured L3 VRRP and ILB on resources across hosts to be
able to test how ILB load balances over an L3 VRRP setup that provides router high
availability. When one of the zgateway zones goes down on one host, the zgateway on
the other host becomes the MASTER router and continues with the transactions.

Chapter 4 - Page 28

Configuring Network
Services
Chapter 5
Practices for Lesson 5: Configuring Network Services

Chapter 5 - Page 1
Practices Overview
Murraya Inc. requires a centralized database for leasing IP addresses to clients, a centralized
naming server for host name resolution, and a central data store for user authentication. In
addition, Murraya also requires resource-sharing capabilities between the Oracle Solaris and
Windows platforms. You will, therefore, implement the following solutions to address each of the
above requirements: DHCP, DNS, and LDAP.
Configure ISC DHCP
Configure DNS


Configure LDAP

192.168.3.4 192.168.3.5
DHCP server ws1 ws2
DNS server 192.168.3.6 192.168.3.7
LDAP server
stub01 stub02
zapp1
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11 192.168.10.100 192.168.10.100
192.168.2.4 198.168.2.5
192.168.1.2
IPMP IPMP

EVS Manager

Chapter 5 - Page 2

s11-server
192.168.0.100 192.168.20.x
s11-client zclient
192.168.0.111 192.168.10.11 192.168.1.2
s11-host01 zgateway1 192.168.10.22 192.168.3.2 192.168.2.4 192.168.1.3 192.168.10.100
192.168.0.112 pri-
ws1 192.168.3.6
zapp1 192.168.2.2

192.168.10.33 192.168.3.3 192.168.2.5 192.168.1.4 192.168.10.100
192.168.0.113 sec-
ws2 192.168.3.7
zapp2 192.168.2.3

Chapter 5 - Page 3
Assumptions:
command output.

Ensure that you set a title to the terminal window for easier recognition. These terminal
connection:
<zonename> command.

Chapter 5 - Page 4
Practice 5-1: Configure ISC DHCP
Overview
To address the need for a dedicated and centralized data store for managing IP addresses for
clients within the network, you will configure the DHCP server in the pri-services zone on
the s11-host01 system. The DHCP relay agent will be configured on the zgateway1 zone, and
the zclient zone on the s11-client system will act as the DHCP client.

192.168.3.4 192.168.3.5
ws2

DHCP server ws1
192.168.3.6 192.168.3.7
stub01 stub02
zapp1
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11 192.168.10.100 192.168.10.100
192.168.2.4 198.168.2.5
192.168.1.2
IPMP IPMP

EVS Manager
Tasks
1. Configure the DHCP server on the pri-services zone.
2. Configure the DHCP relay agent on the zgateway1 zone.
3. Request an IP address from the DHCP server.
Task 1/3
1. Configure the DHCP server on the pri-services zone.
a. Switch to the pri-services terminal.
b. Install the isc-dhcp package.
root@pri-services:~# pkg install isc-dhcp

Chapter 5 - Page 5
DOWNLOAD PKGS FILES

XFER (MB) SPEED
Completed 1/1 24/24
2.5/2.5 4.7M/s
PHASE ITEMS

c. Create the DHCP server configuration file, /etc/inet/dhcpd4.conf, with the
following entries.
root@pri-services:~# vi /etc/inet/dhcpd4.conf
subnet 192.168.3.0 netmask 255.255.255.0 {
}
subnet 192.168.10.0 netmask 255.255.255.0 {
range 192.168.10.101 192.168.10.130;
}
For IPv6, the configuration file would be dhcpd6.conf.

d. Restart the DHCP server.
root@pri-services:~# svcadm restart
svc:/network/dhcp/server:ipv4
e. Enable the DHCP server.
root@pri-services:~# svcadm enable svc:/network/dhcp/server:ipv4
root@pri-services:~# svcs svc:/network/dhcp/server:ipv4
STATE STIME FMRI
online 8:04:52 svc:/network/dhcp/server:ipv4
The DHCP server addresses both, DHCP and BOOTP requests from IPv4 clients.
Task 2/3
2. Configure the DHCP relay agent.
The relay agent relays both, DHCP and BOOTP requests from IPv4 clients to the DHCP
server.
a. Switch to the zgayeway1 terminal.
b. Because the zgateway1 zone was shut down in the previous task, boot up the zone.
c. Log in to the zgateway1 zone.

Chapter 5 - Page 6
d. Install the isc-dhcp package in the zgateway1 zone.

root@zgateway1:~# pkg install isc-dhcp
DOWNLOAD PKGS FILES
XFER (MB) SPEED
Completed 1/1 24/24
2.5/2.5 18.0M/s

PHASE ITEMS
e. Set the zgateway1 zone as the relay agent and enable the relay services.
root@zgateway1:~# /usr/lib/inet/dhcrelay 192.168.3.4
Internet Systems Consortium DHCP Relay Agent 4.1-ESV-R7
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on Socket/ipmp2
Sending on Socket/ipmp2
Listening on Socket/vnic2
Sending on Socket/vnic2
The IP address 192.168.3.4 specified in the command is the IP address of the pri-
services zone that is configured as the DHCP server.
Observation: You have successfully configured both the ISC DHCP server and the DHCP
relay agent. You should now be able to request for IP addresses from the DHCP server.
Task 3/3
3. Request an IP address from the DHCP server.
To verify that the DHCP server is working, request for a test IP for the net3 interface on
the zclient zone.
a. Switch to the zclient terminal window and exit from the zclient zone.
root@zclient:~# exit

Chapter 5 - Page 7
b. Add the net3 interface to the zclient zone and reboot the zone.
root@s11-client:~# zonecfg z zclient
zonecfg:zclient:anet> set physical=net3
zonecfg:zclient:anet> end
root@s11-client:~# zoneadm z zclient reboot
c. Log in to the zclient zone.
d. Display IP address and link information.

lo0/v4 static ok 127.0.0.1/8
aggr0/v4 static ok 192.168.10.11/24
aggr0 aggr 1500 up net1,net2
e. Plumb the net3 interface.
root@zclient:~# ipadm create-ip net3
aggr0 aggr 1500 up net,net2
f. Request for a DHCP IP for the net3 interface.
root@zclient:~# ipadm create-addr -T dhcp net3
net3/v4
lo0/v4 static ok 127.0.0.1/8
aggr0/v4 static ok 192.168.10.11/24
net3/v4 dhcp ok 192.168.10.102/24
The IP address granted to the net3 interface is a dynamic address from the range
specified in the dhcpd.conf file in the DHCP server.

Chapter 5 - Page 8
g. For now, there is no need for a net3 interface. So, delete the interface.
root@zclient:~# ipadm delete-addr net3/v4
lo0/v4 static ok 127.0.0.1/8
aggr0/v4 static ok 192.168.10.11/24
Observation: The zclient zone is able to fetch the DHCP address from the DHCP server
configured on the pri-services zone on the s11-host01 system.

Chapter 5 - Page 9
Practice 5-2: Configure DNS
Overview
You will once again use the pri-services zone to configure the DNS server and the
zclient zone will be your DNS client. After successfully configuring this setup, zclient
should be able to access any other system (zone) in the network by using host names.

192.168.3.4 192.168.3.5
DHCP server ws1 ws2
DNS server 192.168.3.6 192.168.3.7

stub01 stub02
zapp1
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11 192.168.10.100 192.168.10.100
192.168.2.4 198.168.2.5
192.168.1.2
IPMP IPMP

EVS Manager
Tasks
1. Configure the DNS server.
2. Configure the DNS client.
Task 1/2
1. Configure the DNS server.
a. Switch to the pri-services terminal window.
b. Install the DNS package. Configuring the DNS server involves installing DNS BIND,
which is a DNS server package.
root@pri-services:~# pkg install
pkg://solaris/service/network/dns/bind
DOWNLOAD PKGS FILES
XFER (MB) SPEED

Chapter 5 - Page 10
Completed 1/1 38/38

1.4/1.4 1.6M/s
PHASE ITEMS
c. Create the main configuration file for the DNS server. Before the named daemon starts,

a valid configuration file must exist. This file is called /etc/named.conf by default.
You can either:
Copy the file by first exiting to the s11-host01 system and then using the scp
command. Note that the file must be copied into the /etc directory.
root@pri-services:~# exit
root@s11-host01:~# scp /opt/ora/course_files/dns/named.conf
/zones/pri-services/root/etc
root@s11-host01:~# zlogin pri-services
Do not forget to log back in to the pri-services zone to continue with the procedure.
Or, create the file by using the vi editor and enter the following details about the db
files associated with each subnet.
root@pri-services:~# vi /etc/named.conf
options {
directory "/var/named";
};
zone "0.0.127.in-addr.arpa" {type master; file "db.127.0.0";};

zone "mydomain.com" {type master; file "db.mydomain";};
zone "10.168.192.in-addr.arpa" {type master; file
"db.192.168.10";};
"db.192.168.3";};
"db.192.168.0";};
d. Create a directory called /var/named and switch to this directory. This is the base
directory that stores all the db files.
root@pri-services:~# mkdir /var/named
root@pri-services:~# cd /var/named
e. The db files need to be created, which contain configuration information about the
system and the network. You can either:

Chapter 5 - Page 11
Copy the files by first exiting to the s11-host01 system and then using the scp
command.
root@s11-host01:~# scp /opt/ora/course_files/dns/db/*
/zones/pri-services/root/var/named/
root@pri-services:~# cd /var/named
Or, create each of the following individual db files by using the vi editor.
root@pri-services:/var/named# vi db.127.0.0
$TTL 86400
@ SOA pri-services.mydomain.com

root.mydomain.com (2 10800 3600 604800 600)
NS pri-services.mydomain.com
1 PTR localhost.
:wq
root@pri-services:/var/named# vi db.mydomain
$TTL 86400
@ SOA pri-services root (2 10800 3600
604800 600)
NS pri-services
localhost A 127.0.0.1
zgateway1 A 192.168.10.22
zgateway1 A 192.168.3.2
pri-services A 192.168.3.4
ws1 A 192.168.3.6
zgateway2 A 192.168.10.33
zgateway2 A 192.168.3.3
sec-services A 192.168.3.5
ws2 A 192.168.3.7
zclient A 192.168.10.11
s11-server A 192.168.0.100
s11-client A 192.168.0.111
s11-host01 A 192.168.0.112
s11-host02 A 192.168.0.113
:wq
$TTL 86400
@ SOA pri-services.mydomain.com root.mydomain.com
(2 10800 3600 604800 600)
100 PTR s11-server.mydomain.com
111 PTR s11-client.mydomain.com

Chapter 5 - Page 12
112 PTR s11-host01.mydomain.com

113 PTR s11-host02.mydomain.com
:wq
$TTL 86400
@ SOA pri-services.mydomain.com root.mydomain.com
(2 10800 3600 604800 600)
11 PTR zclient.mydomain.com
22 PTR zgateway1.mydomain.com

:wq
$TTL 86400
@ SOA pri-services.mydomain.com
root.mydomain.com (2 10800 3600 604800 600)
4 PTR pri-services.mydomain.com
6 PTR ws1.mydomain.com
5 PTR sec-services.mydomain.com
7 PTR ws2.mydomain.com
:wq
f. Check the files in the directory.
root@pri-services:/var/named# ls
db.127.0.0 db.192.168.10 db.mydomain
db.192.168.0 db.192.168.3
All five db files have been created inside the /var/named directory.
g. Check the validity of the /etc/named.conf configuration file.
root@pri-services:/var/named# cd
root@pri-services:~# named-checkconf
You should not see an error message. That indicates that the named.conf file is
correct.
h. Now start the DNS server.
root@pri-services:~# svcs -a | grep dns/server
disabled 10:22:44 svc:/network/dns/server:default
root@pri-services:~# svcadm enable dns/server

Chapter 5 - Page 13
root@pri-services:~# svcs -a | grep dns/server

online 10:46:11 svc:/network/dns/server:default
Observation: The DNS server has been successfully configured.
Task 2/2
1. Configure the DNS client.
a. Switch to the zclient terminal.
b. Update the network/dns/client service.
root@zclient:~# svccfg -s network/dns/client
svc:/network/dns/client> setprop config/search=astring:
("mydomain.com")

svc:/network/dns/client> setprop config/nameserver=net_address:
(192.168.3.4)
svc:/network/dns/client> select network/dns/client:default
svc:/network/dns/client:default> refresh
svc:/network/dns/client:default> quit
c. Update the name service SMF.
root@zclient:~# svccfg -s system/name-service/switch
svc:/system/name-service/switch> setprop config/host=astring:
"files dns"
svc:/system/name-service/switch> select system/name-
service/switch:default
svc:/system/name-service/switch:default> refresh
svc:/system/name-service/switch:default> quit
The name service switch is a configurable selection service that enables an

administrator to specify the name information service or source to use for each type of
network information. The services are called a database.
d. Enable the DNS client and the name service.
root@zclient:~# svcadm enable network/dns/client
root@zclient:~# svcs network/dns/client
STATE STIME FMRI
online 10:59:03 svc:/network/dns/client:default
root@zclient:~# svcadm enable system/name-service/switch
root@zclient:~# svcs system/name-service/switch
STATE STIME FMRI
online 7:52:44 svc:/system/name-service/switch:default
e. Verify that the DNS server is able to perform host name resolution by using the
nslookup command.
root@zclient:~# nslookup zgateway1
Server: 192.168.3.4
Address: 192.168.3.4#53

Chapter 5 - Page 14
Name: zgateway1.mydomain.com
Address: 192.168.3.2
Address: 192.168.10.22
root@zclient:~# nslookup zgateway1.mydomain.com

Server: 192.168.3.4
Address: 192.168.3.4#53

Address: 192.168.3.2
Address: 192.168.10.22
root@zclient:~# ping zgateway1

zgateway1 is alive
Observation: The DNS server, 192.168.3.4, is able to resolve, for instance, the
zgateway1 host name.

Chapter 5 - Page 15
Practice 5-3: Configure LDAP
Overview
Murrayas next requirement is an LDAP server. The primary function of the LDAP server is to
authenticate users on the network. You will now configure the LDAP server on the pri-
services zone and the zclient zone will act as the LDAP client.
Know that there are two implementations of LDAP in Oracle Solaris 11, Oracle Directory Server
Enterprise Edition (DSEE) and OpenLDAP. For the purpose of this setup, you will use
OpenLDAP, which is the default LDAP server in Oracle Solaris 11.

192.168.3.4 192.168.3.5
DHCP server ws1 ws2
DNS server 192.168.3.6 192.168.3.7
LDAP server
stub01 stub02
zapp1
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11 192.168.10.100 192.168.10.100
192.168.2.4 198.168.2.5
192.168.1.2
IPMP IPMP

EVS Manager
Tasks
1. Configure the LDAP server.
2. Configure the LDAP client.
3. Verify LDAP client communication with the LDAP server.
Task 1/3
1. Configure the LDAP server.
a. In the pri-services terminal, verify the SMF status of the OpenLDAP server.
root@pri-services:~# svcs network/ldap/server
STATE STIME FMRI
disabled Oct_09 svc:/network/ldap/server:openldap_24
The OpenLDAP service should be in the disabled state.

Chapter 5 - Page 16
b. As a precautionary step, delete the content of the /var/openldap/openldap-

data/ directory to remove any previous entries.
root@pri-services:~# ls /var/openldap/openldap-data/
DB_CONFIG.example
root@pri-services:~# rm /var/openldap/openldap-data/*
c. Enable the executable bit for the LDAP configuration command, /usr/lib/slapd.
root@pri-services:~# chmod +x /usr/lib/slapd
root@pri-services:~# ls -l /usr/lib/slapd
-r-xr-xr-x 1 root bin 2743456 Oct 8 08:38
/usr/lib/slapd
d. Create a copy of the slapd.conf.default file to reuse it for configuring the

OpenLDAP server.
root@pri-services:~# cp /etc/openldap/slapd.conf.default
/etc/openldap/slapd.conf
e. The slapd.conf file needs to be edited to include the following schema at the top of
the file, immediately following the line, include
/etc/openldap/schema/core.schema. Also the string my-domain to mydomain
needs to be changed. You can either:
Copy the file from the system.
root@s11-host01:~# scp /opt/ora/course_files/ldap/slapd.conf
/zones/pri-services/root/etc/openldap/
Or, edit the file by using the vi editor.
root@pri-services:~# vi /etc/openldap/slapd.conf
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
# Define global ACLs to disable default read access.
# Do not enable referrals until AFTER you have a working

directory

Chapter 5 - Page 17
# service AND an understanding of referrals.

#referral ldap://root.openldap.org
pidfile /var/openldap/run/slapd.pid
argsfile /var/openldap/run/slapd.args
# Load dynamic backend modules:

# modulepath /usr/lib/amd64/openldap
# moduleload back_bdb.la
# moduleload back_hdb.la
# moduleload back_ldap.la

# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:

# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
################################################################
#######
# BDB database definitions

Chapter 5 - Page 18
################################################################
#######
database bdb
suffix "dc=mydomain,dc=com"
rootdn "cn=Manager,dc=mydomain,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw secret
# The database directory MUST exist prior to running slapd AND

# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/openldap/openldap-data
# Indices to maintain
index objectClass eq
:wq
A directory schema specifies, among other rules, the types of objects that a directory
may have and the mandatory and optional attributes of each object type.
f. Change the ownership of the openldap directory to the default LDAP user,
openldap.
root@pri-services:~# chown -R openldap:openldap /var/openldap
g. Enable the LDAP server.
root@pri-services:~# svcadm enable ldap/server
root@pri-services:~# svcs ldap/server
STATE STIME FMRI
online 11:18:57 svc:/network/ldap/server:openldap_24
h. The LDAP Data Interchange Format (LDIF) file needs to be created. The LDIF file is a
standard plain text data interchange format for representing LDAP directory content
and update requests. This file contains the user information directory. You can either:
Copy the file from the host system.
root@s11-host01:~# scp /opt/ora/course_files/ldap/data.ldif
/zones/pri-services/root/root/
Or, create the file by using the vi editor.
root@pri-services:~# vi /root/data.ldif
dn: dc=mydomain,dc=com
o: mydomain
objectClass: dcObject
dc: mydomain

Chapter 5 - Page 19
objectClass: organization
dn: ou=profile,dc=mydomain,dc=com
objectClass: organizationalUnit
objectClass: top
ou: profile
dn: cn=default,ou=profile,dc=mydomain,dc=com
objectClass: DUAConfigProfile
cn: default
defaultSearchBase: dc=mydomain,dc=com

credentialLevel: anonymous
authenticationMethod: none
defaultSearchScope: sub
profileTTL: 300
searchTimeLimit: 60
defaultServerList: 192.168.3.4
serviceSearchDescriptor: passwd: ou=users,dc=mydomain,dc=com
serviceSearchDescriptor: shadow: ou=users,dc=mydomain,dc=com
serviceSearchDescriptor: group: ou=groups,dc=mydomain,dc=com
dn: ou=groups,dc=mydomain,dc=com
ou: groups
dn: cn=staff,ou=groups,dc=mydomain,dc=com
gidNumber: 10
cn: staff
objectClass: posixGroup
objectClass: top
dn: ou=users,dc=mydomain,dc=com
objectClass: top
ou: users
dn: uid=scarter,ou=users,dc=mydomain,dc=com
cn: Sam Carter
sn: Carter
givenName: Sam
uid: scarter
uidNumber: 1002
gidNumber: 10

Chapter 5 - Page 20
homeDirectory: /home/scarter
loginShell: /bin/bash
gecos: Normal User
mail: sam.carter@mydomain.com
shadowMax: 45
objectClass: top
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: posixAccount
objectClass: shadowAccount

userPassword: oracle1
dn: uid=proxy,dc=mydomain,dc=com
objectClass: account
objectClass: simpleSecurityObject
objectClass: top
uid: proxy
i. Add the ldap directory content to the data.ldif configuration file.
root@pri-services:~# ldapadd -D "cn=Manager,dc=mydomain,dc=com"
-f /root/data.ldif
Enter bind password: secret
adding new entry dc=mydomain,dc=com
adding new entry ou=profile,dc=mydomain,dc=com
adding new entry cn=default,ou=profile,dc=mydomain,dc=com
adding new entry ou=groups,dc=mydomain,dc=com
adding new entry cn=staff,ou=groups,dc=mydomain,dc=com
adding new entry ou=users,dc=mydomain,dc=com
adding new entry uid=scarter,ou=users,dc=mydomain,dc=com
adding new entry uid=proxy,dc=mydomain,dc=com

Observation: The LDAP server has been successfully created.
Task 2/3
1. Configure the LDAP client.
a. Switch to the zclient terminal.
b. Create a home directory for the LDAP user scarter.

Chapter 5 - Page 21
root@zclient:~# cd /export/home
root@zclient:/export/home# mkdir scarter
c. Add the user directory information marked in red to the /etc/auto_home file. This
ensures that the home directory is auto-mounted.
root@zclient:/export/home# vi /etc/auto_home
#
# Copyright 2005 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
# ident "%Z%%M% %I% %E% SMI"
#

# Home directory map for automounter
#
oracle localhost:/export/home/oracle
scarter localhost:/export/home/scarter
+auto_home
:wq
d. Change to the root directory by using the cd command.
root@zclient:/export/home# cd
e. Set domainname to mydomain.com.
root@zclient:~# domainname mydomain.com
root@zclient:~# domainname > /etc/defaultdomain
f. The LDAP client needs to be initialized by using the ldapclient command. The
ldapclient command is used to set up LDAP clients in the Oracle Solaris system.
ldapclient assumes that the server has already been configured with the
appropriate client profiles. You can either:
Output the .txt file of the command and then copy-paste it in the zclient zone in
the zclient terminal.
root@zclient:~# exit
root@s11-client:~# cat /opt/ora/course_files/ldap/ldapclient-
command-syntax.txt
Or, type out the command manually.
root@zclient:~# ldapclient -v manual -a credentialLevel=proxy -a
authenticationMethod=simple -a
proxyDN=uid=proxy,dc=mydomain,dc=com -a proxyPassword=oracle1 -a
defaultServerList=192.168.3.4 -a
defaultSearchBase=dc=mydomain,dc=com -a
serviceSearchDescriptor=passwd:ou=users,dc=mydomain,dc=com?one -
a serviceSearchDescriptor=group:ou=groups,dc=mydomain,dc=com?one
Parsing credentialLevel=proxy
Parsing authenticationMethod=simple
Parsing proxyDN=uid=proxy,dc=mydomain,dc=com

Chapter 5 - Page 22
Parsing proxyPassword=oracle1
Parsing defaultServerList=192.168.3.4
Parsing defaultSearchBase=dc=mydomain,dc=com
Parsing
serviceSearchDescriptor=passwd:ou=users,dc=mydomain,dc=com?one
Parsing
serviceSearchDescriptor=group:ou=groups,dc=mydomain,dc=com?one
Arguments parsed:
authenticationMethod: simple
credentialLevel: proxy

proxyDN: uid=proxy,dc=mydomain,dc=com
serviceSearchDescriptor:
arg[0]: passwd:ou=users,dc=mydomain,dc=com?one
arg[1]: group:ou=groups,dc=mydomain,dc=com?one
proxyPassword: oracle1
.
.
Validate service properties for: svc:/system/name-
service/cache
successful import.
import successful
start: sleep 100000 microseconds
start: system/name-service/cache:default... success
start: sleep 100000 microseconds
start: network/smtp:sendmail... success
restart: sleep 100000 microseconds
restart: milestone/name-services:default... success
System successfully configured
root@zclient:~#
Observation: The LDAP client has been successfully configured.
Task 3/3
1. Verify LDAP client communication with the LDAP server.
The next task is to set the search criteria for user authentication. This enables the LDAP
client to query the LDAP server.
a. Check the LDAP client service status. If the service is in the maintenance mode,
disable and enable the service again.
root@zclient:~# svcadm disable ldap/client
root@zclient:~# svcadm enable ldap/client
root@zclient:~# svcs ldap/client
online 17:19:06 svc:/network/ldap/client:default

Chapter 5 - Page 23
b. Set the LDAP search host path by using the ldapsearch command. The
ldapsearch utility connects with the LDAP server, binds, and performs a search
using a filter.
root@zclient:~# ldapsearch -h 192.168.3.4 -D
'cn=Manager,dc=mydomain,dc=com' -b 'dc=mydomain,dc=com'
objectClass=*
Enter bind password: secret
version: 1
dn: dc=mydomain,dc=com
o: mydomain
objectClass: dcObject
objectClass: organization

dc: mydomain
objectClass: top
ou: profile
dn: cn=default,ou=profile,dc=mydomain,dc=com
objectClass: DUAConfigProfile
cn: default
credentialLevel: anonymous
authenticationMethod: none
defaultSearchScope: sub
profileTTL: 300
searchTimeLimit: 60
serviceSearchDescriptor: passwd: ou=users,dc=mydomain,dc=com
serviceSearchDescriptor: shadow: ou=users,dc=mydomain,dc=com
serviceSearchDescriptor: group: ou=groups,dc=mydomain,dc=com
objectClass: top
ou: groups
dn: cn=staff,ou=groups,dc=mydomain,dc=com
gidNumber: 10
cn: staff
objectClass: posixGroup
objectClass: top

Chapter 5 - Page 24
objectClass: top
ou: users
dn: uid=scarter,ou=users,dc=mydomain,dc=com
cn: Sam Carter
sn: Carter
givenName: Sam
uid: scarter

uidNumber: 1002
gidNumber: 10
homeDirectory: /home/scarter
loginShell: /bin/bash
gecos: Normal User
mail: sam.carter@mydomain.com
shadowMax: 45
objectClass: top
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: account
objectClass: simpleSecurityObject
objectClass: top
uid: proxy
c. Retrieve the LDAP user password information by using the getent command. This
command helps a user get entries from LDAP databases.
root@zclient:~# getent passwd
root:x:0:0:Super-User:/root:/usr/bin/bash
daemon:x:1:1::/:
bin:x:2:2::/usr/bin:
sys:x:3:3::/:
adm:x:4:4:Admin:/var/adm:
lp:x:71:8:Line Printer Admin:/:
uucp:x:5:5:uucp Admin:/usr/lib/uucp:

Chapter 5 - Page 25
nuucp:x:9:9:uucp
Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico
dladm:x:15:65:Datalink Admin:/:
netadm:x:16:65:Network Admin:/:
netcfg:x:17:65:Network Configuration Admin:/:
smmsp:x:25:25:SendMail Message Submission Program:/:
gdm:x:50:50:GDM Reserved UID:/var/lib/gdm:
zfssnap:x:51:12:ZFS Automatic Snapshots Reserved
UID:/:/usr/bin/pfsh
upnp:x:52:52:UPnP Server Reserved UID:/var/coherence:/bin/ksh
xvm:x:60:60:xVM User:/:

mysql:x:70:70:MySQL Reserved UID:/:
openldap:x:75:75:OpenLDAP User:/:
webservd:x:80:80:WebServer Reserved UID:/:
postgres:x:90:90:PostgreSQL Reserved UID:/:/usr/bin/pfksh
svctag:x:95:12:Service Tag UID:/:
unknown:x:96:96:Unknown Remote UID:/:
nobody:x:60001:60001:NFS Anonymous Access User:/:
noaccess:x:60002:60002:No Access User:/:
nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/:
ikeuser:x:67:12:IKE Admin:/:
aiuser:x:61:61:AI User:/:
pkg5srv:x:97:97:pkg(5) server UID:/:
oracle:x:100:10:oracle:/export/home/oracle:/usr/bin/bash
scarter:x:1002:10:Normal User:/home/scarter:/bin/bash
The information about the LDAP user, scarter, is coming from the LDAP server.
d. Identify the LDAP user group by using the getent command.
root@zclient:~# getent group
root::0:
other::1:root
bin::2:root,daemon
sys::3:root,bin,adm
adm::4:root,daemon
uucp::5:root
mail::6:root
tty::7:root,adm
lp::8:root,adm
nuucp::9:root
staff::10:
daemon::12:root
sysadmin::14:

Chapter 5 - Page 26
games::20:
smmsp::25:
gdm::50:
upnp::52:
xvm::60:
netadm::65:
mysql::70:
openldap::75:
webservd::80:
postgres::90:
unknown::96:

nobody::60001:
noaccess::60002:
nogroup::65534:
aiuser::61:
pkg5srv::97:
staff::10:
The LDAP user, scarter, belongs to the user group, staff.

e. List the naming information from the LDAP server, pri-services.
root@zclient:~# ldaplist
root@zclient:~# su - scarter
-bash-4.1$ id
uid=1002(scarter) gid=10(staff)
-bash-4.1$ exit
logout
root@zclient:~#
Observation: The naming information for the user, scarter, is coming from the
LDAP server. This indicates that LDAP has been successfully configured.
Summary: Recall the schematic representation of the tasks that you set out to accomplish
at the start of this lab. You have successfully configured ISC DHCP, DNS, and LDAP. In the
next lab, you will secure the network by using IP Filter.

Chapter 5 - Page 27

Chapter 5 - Page 28

Managing Network
Resources
Chapter 6
Practices for Lesson 6: Managing Network Resources

Chapter 6 - Page 1
Practices Overview
Given that Murrayas DNS, DHCP, and LDAP servers along with the web server would be high-
impact systems, you need to regulate the network resources so that network processes can
proceed without being interrupted or blocked. Network bandwidth is one such resource that
needs to be regulated. The bandwidth limit can be applied either directly to a datalink, such as a
VNIC, or to a user-defined flow.

Configure the bandwidth datalink property.


Create flows to regulate bandwidth and priority properties.

s11-server
192.168.0.100 192.168.20.x
s11-client zclient
192.168.0.111 192.168.10.11 192.168.1.2
s11-host01 zgateway1 192.168.10.22 192.168.3.2 192.168.2.4 192.168.1.3 192.168.10.100
192.168.0.112 pri-
ws1 192.168.3.6
zapp1 192.168.2.2
s11-host02 zgateway2 192.168.10.33 192.168.3.3 192.168.2.5 192.168.1.4 192.168.10.100
192.168.0.113 sec-
ws2 192.168.3.7
zapp2 192.168.2.3

Chapter 6 - Page 2
Assumptions:
command output.

connection:
<zonename> command.

Chapter 6 - Page 3
Practice 6-1: Configure the Bandwidth Datalink Property
Overview
The three VNICs created over stub1 have a maximum bandwidth of 40000 MB. At any given
time, any one zone over these VNICs could consume the entire bandwidth, crowding out the
other channels. It would, therefore, be prudent to assign a fixed quota of bandwidth to each of
these VNICs depending on the load-bearing capacity. Regulate bandwidth among the three
VNICs as follows: vnic2=20000, vnic4=10000, and vnic6=10000.


192.168.3.4 192.168.3.5
DHCP server ws1 ws2
DNS server 192.168.3.6 192.168.3.7
LDAP server
10000 MB 10000 MB
stub01 stub02
zapp1
20000 MB
192.168.10.22 192.168.3.3 192.168.2.3

192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11 192.168.10.100 192.168.10.100
192.168.2.4 198.168.2.5
192.168.1.2
IPMP IPMP

EVS Manager
In this practice, you will configure the bandwidth datalink property.
Task 1/1
1. Configure the bandwidth datalink property.
s11-host01.
Password: oracle1
c. Switch to the root role by using the su command. Password is oracle1.
Password: oracle1
root@s11-host01:~#
d. Display VNIC information on the host.

Chapter 6 - Page 4
root@s11-host01:~# dladm show-vnic

LINK OVER SPEED MACADDRESS MACADDRTYPE VIDS
vnic2 stub1 40000 2:8:20:7c:5d:28 random 0
zgateway1/vnic2 stub1 40000 2:8:20:7c:5d:28 random 0
vnic4 stub1 40000 2:8:20:49:31:3c random 0
pri-services/vnic4 stub1 40000 2:8:20:49:31:3c random 0
vnic6 stub1 40000 2:8:20:83:3f:46 random 0
ws1/vnic6 stub1 40000 2:8:20:83:3f:46 random 0
zapp1/net1 evs-vxlan200 1000 2:8:20:a6:a7:b7 fixed 0
Observe that vnic2, vnic4, and vnic6 have 40000 MB speed.

e. Now, display the maxbw property of the links.
root@s11-host01:~# dladm show-linkprop -p maxbw
LINK PROPERTY PERM VALUE EFFECTIVE DEFAULT POSSIBLE
net1 maxbw rw -- -- -- --
zgateway1/net1 maxbw rw -- -- -- --
stub1 maxbw rw -- -- -- --
vnic2 maxbw rw -- -- -- --
zgateway1/vnic2 maxbw rw -- -- -- --
pri-services/vnic4 maxbw rw -- -- -- --
ws1/vnic6 maxbw rw -- -- -- --
evs-vxlan200 maxbw rw -- -- -- --
zapp1/net1 maxbw rw -- -- -- --
The maxbw value under Property indicates that the current bandwidth allocation on
the etherstub-based VNICs is set to maximum. That would be 40000 MB. This implies
that at any given time, any one of the VNICs can possibly consume all of the 40000
MB, depriving the other VNICs. Considering the traffic-bearing capacity of each of the
VNICs, you can regulate the bandwidth accordingly.
f. Regulate bandwidth among the three VNICs as follows: vnic2=20000, vnic4=10000,
and vnic6=10000.
root@s11-host01:~# dladm set-linkprop -p maxbw=20000
zgateway1/vnic2
root@s11-host01:~# dladm set-linkprop -p maxbw=10000 pri-
services/vnic4
root@s11-host01:~# dladm set-linkprop -p maxbw=10000 ws1/vnic6
g. Now, display details about the datalink properties.
root@s11-host01:~# dladm show-linkprop -p maxbw

Chapter 6 - Page 5
LINK PROPERTY PERM VALUE EFFECTIVE DEFAULT POSSIBLE

stub1 maxbw rw -- -- -- --
vnic2 maxbw rw 20000 20000 -- --
zgateway1/vnic2 maxbw rw 20000 20000 -- --
vnic4 maxbw rw 10000 10000 -- --
pri-services/vnic4 maxbw rw 10000 10000 -- --

vnic6 maxbw rw 10000 10000 -- --
ws1/vnic6 maxbw rw 10000 10000 -- --
evs-vxlan200 maxbw rw -- -- -- --
zapp1/net1 maxbw rw -- -- -- --
Observation: The bandwidth for the VNICs has been altered to ensure that none of the
three VNICs exclusively exhaust the entire bandwidth. Each VNIC now has access to a
certain allotment of bandwidth for bearing traffic.
Note: You will not be able to set the other datalink properties, such as CPU, pool, txring
and rxring. There is a hardware dependency, which will not allow you to regulate these
properties in a VBox environment.

Chapter 6 - Page 6
Practice 6-2: Create Flows to Regulate Bandwidth and Priority

Properties
Overview
The zgateway1 zone functions as the gateway for SSH and HTTP requestresponse traffic to
and from pri-services and ws1 zones, respectively. The network traffic to ws1 is higher but
is not time sensitive. Whereas, the network traffic to pri-services is low and time sensitive.
Therefore, to process network traffic faster for pri-services, you need to limit the bandwidth
allocated to the network traffic for ws1. If the bandwidth allocated for ws1 is not limited, it could
potentially use up all the available bandwidth leading to a denial of bandwidth to pri-
services.

192.168.3.4 192.168.3.5
DHCP server ws1 ws2
DNS server 192.168.3.6 192.168.3.7
LDAP server
f-ssh f-http
stub01 stub02
zapp1
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11 192.168.10.100 192.168.10.100
192.168.2.4 198.168.2.5
192.168.1.2
IPMP IPMP

EVS Manager
Tasks
In this practice, you will create flows to regulate bandwidth and priority.
Task 1/1
1. Create flows to regulate bandwidth and priority.
b. Create a flow called f-http for the HTTP traffic to ws1 (192.168.3.6). The traffic
here is higher but not time sensitive.
root@zgateway1:~# flowadm add-flow -l vnic2 -a
transport=tcp,local_ip=192.168.3.2,remote_ip=192.168.3.6,local_p
ort=80 f-http
c. Create a flow called f-ssh for the SSH traffic to pri-services (192.168.3.4). The
traffic here is low but time sensitive.

Chapter 6 - Page 7
root@zgateway1:~# flowadm add-flow -l vnic2 -a

transport=tcp,local_ip=192.168.3.2,local_port=22 f-ssh
d. Verify that the flows have been created.
root@zgateway1:~# flowadm show-flow
FLOW LINK PROTO LADDR LPORT RADDR RPORT DSFLD
f-http vnic2 tcp 192.168.3.2 80 192.168.3.6 -- --
f-ssh vnic2 tcp 192.168.3.2 22 -- -- --
e. Display flow properties.
root@zgateway1:~# flowadm show-flowprop
FLOW PROPERTY PERM VALUE DEFAULT POSSIBLE
f-http maxbw rw -- -- --

f-http priority rw medium medium low,medium,high
f-http hwflow r- off -- on,off
f-ssh maxbw rw -- -- --
f-ssh priority rw medium medium low,medium,high
f-ssh hwflow r- off -- on,off
f. Now, set the bandwidth property on the f-http flow to a maximum of 7000 MB.
root@zgateway1:~# flowadm set-flowprop -p maxbw=7000 f-http
g. Set the priority property for the f-ssh flow to high.
root@zgateway1:~# flowadm set-flowprop -p priority=high f-ssh
h. Verify the properties you just set on the flows.
root@zgateway1:~# flowadm show-flowprop
FLOW PROPERTY PERM VALUE DEFAULT POSSIBLE
f-http maxbw rw 7000 -- --
f-http priority rw medium medium low,medium,high
f-http hwflow r- off -- on,off
f-ssh maxbw rw -- -- --
f-ssh priority rw high medium low,medium,high
f-ssh hwflow r- off -- on,off
Summary: You have successfully configured the datalink and flow properties to ensure that
bandwidth is judiciously used and traffic is prioritized based on the infrastructure
requirements.
In the next lab, you will implement the first level of security to the network by using IP Filter.

Chapter 6 - Page 8

Implementing Network
Security
Chapter 7
Practices for Lesson 7: Implementing Network Security

Chapter 7 - Page 1
Practices Overview
Although a network can be secured in many ways and at many levels, firewall is one of the
primary mechanisms, and also a robust one. A general implementation of the firewall is to close
the internal network from the outside world. Then, based on requirements, the internal network
and its resources can be allowed access from the external network and vice versa.
Note: Certain limitations in the VBox environment will not allow you to implement link protection
in the virtual network. You will, therefore, deploy only IP Filter in this lab.
Below is the schematic representation of the setup you will build and test in this lab:

192.168.3.4 192.168.3.5
DHCP server ws1 ws2
DNS server 192.168.3.6 192.168.3.7
LDAP server
f-ssh f-http
stub01 stub02
zapp1
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11 192.168.10.100 192.168.10.100
192.168.2.4 198.168.2.5
192.168.1.2
IPMP IPMP

EVS Manager

s11-server
192.168.0.100 192.168.20.x
s11-client zclient
192.168.0.111 192.168.10.11 192.168.1.2
s11-host01 zgateway1 192.168.10.22 192.168.3.2 192.168.2.4 192.168.1.3 192.168.10.100
192.168.0.112 pri-
ws1 192.168.3.6
zapp1 192.168.2.2
s11-host02 zgateway2 192.168.10.33 192.168.3.3 192.168.2.5 192.168.1.4 192.168.10.100
192.168.0.113 sec-
ws2 192.168.3.7
zapp2 192.168.2.3

Chapter 7 - Page 2
Assumptions:
command output.

connection:
<zonename> command.

Chapter 7 - Page 3
Practice 7-1: Configure IP Filter to Secure the Network
Overview
The zgateway1 zone, being the gateway to the external network, is the most crucial zone in
the box. It is, therefore, a good practice to initially block all access to the internal network and its
resources. Then, use a need-based approach to open up the services one by one, while the rest
of the network continues to remain inaccessible to the outside world.

1. Check the network services that are running.
2. Block all client requests to the zgateway1 zone.

3. Allow ping and ssh communication.
4. Allow host name resolution.
5. Allow LDAP server access.
Task 1/5
1. Check the network services that are running.
Before configuring IP Filter, check whether all the network services are accessible from the
zclient zone.
a. Switch to the zclient terminal and verify that DNS lookup is taking place by running the
nslookup command for the zgateway1 zone.
Server: 192.168.3.4
Address: 192.168.3.4#53
Address: 192.168.3.2
Address: 192.168.10.22
b. Check the LDAP client service status. If the service is in the maintenance mode,
disable and enable the service again.
root@zclient:~# svcadm disable ldap/client
root@zclient:~# svcs -a | grep ldap/client
online 17:19:06 svc:/network/ldap/client:default
c. Verify that the LDAP server is operational.
daemon:x:1:1::/:
sys:x:3:3::/:

Chapter 7 - Page 4

nuucp:x:9:9:uucp
UID:/:/usr/bin/pfsh

User scarter is being fetched from the LDAP server.

d. Verify that the Apache web server is accessible.
--2014-09-22 17:50:27-- http://192.168.10.100/
100%[======================================>] 17 --.-
K/s in 0s

WS1 responding

Chapter 7 - Page 5
root@zclient:~#
The Apache web server is responding too.

Observation: At this stage, all network services are accessible from the zclient zone.
Task 2/5
2. Block all client requests to the zgateway1 zone.
Because zgateway1 is the access zone for all other zones in the box, you will configure IP
Filter on the zgateway1 zone to block all client requests. Thereafter, you will discerningly
edit the firewall rules to allow specific client requests.

b. Display IP address information on the zgateway1 zone.
lo0/v4 static ok 127.0.0.1/8
ipmp2/v4 static ok 192.168.10.22/24
ipmp2/v4a vrrp ok 192.168.10.100/24
vnic2/v4 static ok 192.168.3.2/24
c. Protecting the ipmp2 link is critical because it is the primary interface that connects the
internal network with the external network. Create IP Filter rules by adding the line
block in on ipmp2 all in the IP Filter configuration file, /etc/ipf/ipf.conf.
root@zgateway1:~# vi /etc/ipf/ipf.conf
#
# ipf.conf
#
# IP Filter rules to be loaded during startup
#
# See ipf(4) manpage for more information on
# IP Filter rules syntax.
block in on ipmp2 all
:wq
d. Enable and confirm the IP Filter service status.
root@zgateway1:~# svcs -a | grep ipfilter
disabled Oct_01 svc:/network/ipfilter:default
root@zgateway1:~# svcadm enable ipfilter
root@zgateway1:~# svcs -a | grep ipfilter
online 11:07:51 svc:/network/ipfilter:default
e. Validate the IP Filter configuration file.
root@zgateway:~# ipf -f /etc/ipf/ipf.conf
1:ioctl(add/insert rule): File exists

Chapter 7 - Page 6
f. Verify the assigned rules by using the ipfstat command.

root@zgateway:~# ipfstat -io
empty list for ipfilter(out)
g. Now, switch to the zclient terminal and verify host name resolution is happening for
zgateway1.
ping: getaddrinfo: temporary name resolution failure
ping: unknown host zgateway
h. Verify if the DNS server is available.

;; connection timed out; no servers could be reached
i. Verify if the LDAP server can be contacted.
daemon:x:1:1::/:
sys:x:3:3::/:
nuucp:x:9:9:uucp
UID:/:/usr/bin/pfsh

Chapter 7 - Page 7
The scarter user is not listed.

j. Check if the Apache web server is responding.
root@zclient:~# wget 192.168.10.100:80
--2014-09-22 17:48:30-- http://192.168.10.100/
Connecting to 192.168.10.100:80... ^C
root@zclient:~#

If it takes very long to connect, or you notice a connection timed out message, it
means that the web server is not reachable.
k. Check whether a secure shell access to the zgateway1 zone is allowed.
root@zclient:~# ssh oracle@192.168.10.22
ssh: connect to host 192.168.10.22 port 22: Connection timed out
Observation: None of the network services are available or reachable from the zclient
zone now. This implies that the IP Filter rule (block in on ipmp0 all) is active on the
zgateway1 zone.
Task 3/5
3. Allow ping and ssh communication.
Reconfigure the IP Filter rule to allow ping and ssh communication with the zgateway1
zone.
b. Run the ipfstat -io command to display the I/O statistics for IP Filter.
root@zgateway1:~# ipfstat -io
c. Run the ipfstat command to view the detailed statistics for IP Filter.
root@zgateway1:~# ipfstat
bad packets: in 0 out 0
IPv6 packets: in 0 out 0
input packets: blocked 4 passed 5 nomatch 5 counted 0
short 0
output packets: blocked 0 passed 85 nomatch 85 counted 0
short 0
input packets logged: blocked 0 passed 0
output packets logged: blocked 0 passed 0
packets logged: input 0 output 0
log failures: input 0 output 0
fragment state(in): kept 0 lost 0 not fragmented 0

Chapter 7 - Page 8
fragment reassembly(in): bad v6 hdr 0 bad v6 ehdr 0

failed reassembly 0
fragment state(out): kept 0 lost 0 not fragmented 0
packet state(in): kept 0 lost 0
packet state(out): kept 0 lost 0
ICMP replies: 0 TCP RSTs sent: 0
Invalid source(in): 0
Result cache hits(in): 0 (out): 0
IN Pullups succeeded: 0 failed: 0
OUT Pullups succeeded: 0 failed: 0
Fastroute successes: 0 failures: 0

TCP cksum fails(in): 0 (out): 0
IPF Ticks: 157
Packet log flags set: (0)
none
d. Now, modify the firewall rules to allow ping and ssh communication.
#
# ipf.conf
#
#
# adding for ping and SSH
pass in quick on ipmp2 proto ICMP from any to any keep state
pass in quick on ipmp2 proto tcp from any to 192.168.10.2/24
port=22 keep state
:wq
e. Validate the IP Filter configuration file entries.
root@zgateway1:~# ipf -f /etc/ipf/ipf.conf
f. Refresh the IP Filter firewall service.
root@zgateway1:~# svcadm refresh ipfilter
g. Verify the status of the IP Filter rules by using the ipfstat io command.
pass in quick on ipmp2 proto icmp from any to any keep state
port = ssh keep state

Chapter 7 - Page 9
h. Now, switch to the zclient terminal and verify that the IP addresses configured on the
ipmp2 interface of the zgateway1 zone are reachable by using the ping command.
192.168.10.22 is alive
192.168.10.100 is alive
i. Verify that the 192.168.10.22 (zgateway1) IP is accessible by using the ssh
command.
root@zclient:~# ssh oracle@192.168.10.22
The authenticity of host '192.168.10.22 (192.168.10.22)' can't
be established.

4d:fa:a7:92:f7:db:5b:b1:e8:8a:d8:a0:67:46:8a:bc.
Warning: Permanently added '192.168.10.22' (RSA) to the list of
known hosts.
Password: oracle1
Last login: Wed Oct 8 09:52:34 2014
oracle@zgateway1:~$
j. Exit zgateway1 and return to the zclient terminal.
oracle@zgateway1:~$ exit
root@zclient:~#
k. Now ping the zgateway1 zone by using its host name.
ping: getaddrinfo: temporary name resolution failure
ping: unknown host zgateway1
Observation: While ping and ssh are now working, host name resolution is not available
yet because the DNS port is still closed via the firewall.

Chapter 7 - Page 10
Task 4/5
4. Allow host name resolution.
Reconfigure the IP Filter rule to open the DNS port for host name resolution.
b. Modify the firewall rules to open the DNS port.
#
# ipf.conf
#
#

port=22 keep state
# adding for DNS
pass in log proto tcp from any to any port = 53 keep state
pass in log proto udp from any to any port = 53 keep state
:wq
c. Validate the configuration file.
d. Refresh the IP Filter service.
e. Verify the IP Filter statistics by using the ipfstat command.
pass in log proto tcp from any to any port = domain keep state
pass in log proto udp from any to any port = domain keep state
f. Now, switch to the zclient terminal and verify if host name resolution is operational.
Server: 192.168.3.4
Address: 192.168.3.4#53

Chapter 7 - Page 11
Address: 192.168.3.2
Address: 192.168.10.22
The DNS port has been opened.

g. Now, run the getent passwd command to query the LDAP server.
daemon:x:1:1::/:

sys:x:3:3::/:
nuucp:x:9:9:uucp

The scarter user is still not listed.

Observation: While host name resolution is now happening, the LDAP server is still not
reachable.
Task 5/5
5. Allow LDAP server access.
a. Switch to the zgateway1 terminal and edit the ipf.conf file to allow access to the
LDAP server.
#
# ipf.conf
#
#

Chapter 7 - Page 12

port=22 keep state
# adding for DNS
# adding for LDAP
pass in proto tcp from any to any port = 389 keep state

:wq
b. Validate the configuration file.
c. Refresh the IP Filter service.
d. Check the IP Filter statistics.
pass in proto tcp from any to any port = ldap keep state
e. Switch to the zclient terminal and restart the ldap/client service.
root@zclient:~# svcadm restart ldap/client
f. Enable the ldap/client service.
g. Run the getent passwd command to query the LDAP server.
daemon:x:1:1::/:
sys:x:3:3::/:

Chapter 7 - Page 13


nuucp:x:9:9:uucp

The scarter user is getting resolved by the LDAP server.

Summary: You have successfully installed IP Filter on the zgateway1 zone and modified
the firewall rules to allow selective client access to network services hosted on the s11-
host01 system. You can perform similar steps on the redundant zgateway2 zone to
secure access to the s11-host02 resources.

Chapter 7 - Page 14

Integrating with OpenStack
Chapter 8
Practices for Lesson 8: Integrating with OpenStack

Chapter 8 - Page 1
Practices Overview
With Oracle Solaris 11, OpenStack is bundled with the OS. The group package,
pkg:/cloud/openstack installs all components of OpenStack. However, you will specifically
use the Keystone and Neutron packages to configure Neutron in this lab.
Note: The entire OpenStack configuration is beyond the scope of this course. This lab is meant
to expose you to the Neutron component of OpenStack and appreciate its role in configuring
cloud-ready EVS switches that can be assigned to Nova compute instances, in case Nova
should also be configured. Also note that Horizon is not configured in this lab because of
dependencies with other OpenStack components. The Horizon dashboard is a graphic interface
that allows you to manage OpenStack components. You can manage your Neutron entities

through Horizon.
In this lab, you will configure Neutron.

192.168.3.4 192.168.3.5
DHCP server
DNS server
ws1
192.168.3.6
O ws2
192.168.3.7
LDAP server
f-ssh f-http
stub01 stub02
zapp1
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11 192.168.10.100 192.168.10.100
192.168.2.4 198.168.2.5
192.168.1.2
IPMP IPMP

EVS Manager
Keystone
Neutron

Chapter 8 - Page 2

s11-server
192.168.0.100 192.168.20.x
s11-client zclient
192.168.0.111 192.168.10.11 192.168.1.2
s11-host01 zgateway1 192.168.10.22 192.168.3.2 192.168.2.4 192.168.1.3 192.168.10.100
192.168.0.112 pri-
ws1 192.168.3.6
zapp1 192.168.2.2

192.168.10.33 192.168.3.3 192.168.2.5 192.168.1.4 192.168.10.100
192.168.0.113 sec-
ws2 192.168.3.7
zapp2 192.168.2.3

Chapter 8 - Page 3
Assumptions:
command output.

connection:
<zonename> command.

Chapter 8 - Page 4
Practice 8-1: Configure Neutron
Overview
Recall that in an earlier lab, you have already configured the EVS setup. That EVS setup you
built was for isolating nonglobal zones across hosts. Now, consider scaling up a similar setup
for the cloud.
Oracle Solaris 11 integrates with OpenStack to allow you to set up your infrastructure on the
cloud. You can interface with the Neutron component of OpenStack by using EVS as a
backbone. In this lab, you will work only with the Neutron component. However, the same setup
that you will build and test in this lab can be performed through the Horizon dashboard, where
you can assign Nova instances in the Glance database to the EVS switches created using
Neutron. Because that is beyond the scope of this course, you will work the Neutron component
for now. As you complete the setup, you will appreciate the fact that your existing EVS setup is

also exposed through Neutron for larger cloud deployment.

1. Install the packages.
2. Authenticate with Keystone.
3. Configure the SSH keys for root, evsuser and neutron users.
4. Configure the EVS controller properties.
5. Create the cloudSwitch EVS.
Task 1/5
1. Install the packages.
There are multiple ways to install OpenStack. In this instance, you will perform a manual
install of the required packages. Because the s11-server system has already been
configured as an EVS controller, later in the procedure, make note of the steps that you can
skip. If you were to configure Neutron on a new system, then you will need to perform all the
steps listed here.
a. Switch to the s11-server terminal.
b. Install the openstack, rabbitmq, and rad-evs-controller packages.
root@s11-server:~# pkg install openstack rabbitmq rad-evs-
controller
Create backup boot environment: Yes
DOWNLOAD PKGS FILES
XFER (MB) SPEED
Completed 178/178 23165/23165
116.2/116.2 799k/s
PHASE ITEMS

Chapter 8 - Page 5

c. Restart the rad:local service.
root@s11-server:~# svcadm restart rad:local
d. Enable the rabbitmq service.
root@s11-server:~# svcadm enable rabbitmq
RabbitMQ provides support for the Advanced Message Queuing Protocol (AMQP),

which is used for communication between all OpenStack services. Generally, a single
node in the cloud is configured to run RabbitMQ.
Task 2/5
2. Authenticate with Keystone.
The Keystone component of OpenStack is the authentication module.
a. Customize the Keystone configuration, by editing the keystone.conf file. In the file,
go to the specific sections and either uncomment the following entries or provide
values as specified.
root@s11-server:~# vi /etc/keystone/keystone.conf
[DEFAULT]
admin_token=ADMIN
[identity]
driver=keystone.identity.backends.sql.Identity
[token]
provider=keystone.token.providers.uuid.Provider
[signing]
token_format=UUID
:wq
Note: The keystone.conf fie is a very long file. Be careful not to edit out anything
else in the file.
Tip: To look for a specific entry in the file, you can use the search (/) option. Press /
and enter the word you are looking for, and press Enter. The cursor will take you to the
word that matches your search. You can repeat the same step for the next word.
b. Enable the keystone service.
root@s11-server:~# svcadm enable -rs keystone
root@s11-server:~# svcs keystone
STATE STIME FMRI
online 8:18:54 svc:/application/openstack/keystone:default
c. Populate the Keystone database. This can be done manually or by using the
convenience script provided with the OpenStack bundle.
root@s11-server:~# /usr/demo/openstack/keystone/sample_data.sh

Chapter 8 - Page 6
+-------------+---------------------------------------+
| Property | Value |
+-------------+---------------------------------------+
| adminurl | http://localhost:$(admin_port)s/v2.0 |
| id | fedef812340ce9779bbbae00ef4c713f |
| internalurl | http://localhost:$(public_port)s/v2.0 |
| publicurl | http://localhost:$(public_port)s/v2.0 |
| region | RegionOne |
| service_id | 3e573eeb029160968f3aff4752e11259 |
+-------------+---------------------------------------+
+-------------+-------------------------------------------------

-----+
| Property | Value
|
+-------------+-------------------------------------------------
-----+
| adminurl |
http://localhost:$(compute_port)s/v1.1/$(tenant_id)s |
| id | b612e49fb6b2e0c1dbb0d7472e9ac7e3
|
| internalurl |
| publicurl |
| region | RegionOne
|
| service_id | af8325d6214c46e29210c8692ea7b165
|
+-------------+-------------------------------------------------
-----+
+-------------+----------------------------------------+
+-------------+----------------------------------------+
| adminurl | http://localhost:8776/v1/$(tenant_id)s |
| id | 1917ae199aa0eeb1a14698fe805dc174 |
| internalurl | http://localhost:8776/v1/$(tenant_id)s |
| publicurl | http://localhost:8776/v1/$(tenant_id)s |
| service_id | 31557c169cd145db9a6c8e51e5dfbcf3 |
+-------------+----------------------------------------+
+-------------+----------------------------------+
+-------------+----------------------------------+
| adminurl | http://localhost:9292 |

Chapter 8 - Page 7
| id | d59a0a1e92dece5ac223d960fcc0ab56 |
| internalurl | http://localhost:9292 |
| publicurl | http://localhost:9292 |
| service_id | 4796b084f2cfe2cfe820fc0283d5d655 |
+-------------+----------------------------------+
+-------------+--------------------------------------+
+-------------+--------------------------------------+
| adminurl | http://localhost:8773/services/Admin |
| id | e8fdb8fd7a36ceb2e768f7658379b7f9 |

| internalurl | http://localhost:8773/services/Cloud |
| publicurl | http://localhost:8773/services/Cloud |
| service_id | 2a42c304c72a417a8a4099e58d0893ed |
+-------------+--------------------------------------+
+-------------+---------------------------------------------+
+-------------+---------------------------------------------+
| adminurl | http://localhost:8080/v1 |
| id | e384dddeec69ea0dbc52b15e93ded6b6 |
| internalurl | http://localhost:8080/v1/AUTH_$(tenant_id)s |
| publicurl | http://localhost:8080/v1/AUTH_$(tenant_id)s |
| service_id | 103fbece0a2e4b6198869436486ad922 |
+-------------+---------------------------------------------+
+-------------+----------------------------------+
+-------------+----------------------------------+
| adminurl | http://localhost:9696/ |
| id | ce85dc1f180f6329f9e3c21f1496bc29 |
| internalurl | http://localhost:9696/ |
| publicurl | http://localhost:9696/ |
| service_id | caf09b8c3a73efb5c09693f48c389ef6 |
+-------------+----------------------------------+
d. Export the following global variables.
root@s11-server:~# export
SERVICE_ENDPOINT=http://localhost:35357/v2.0
root@s11-server:~# export SERVICE_TOKEN=ADMIN
e. Check the user list for OpenStack components in the Keystone database.
root@s11-server:~# keystone user-list

Chapter 8 - Page 8
+----------------------------------+---------+---------+-------+
| id | name | enabled | email |
+----------------------------------+---------+---------+-------+
| b5a99fc19e0a6787f033aaaa96ef88b2 | admin | True | |
| 6d814f10dc066ae2db62d23b648ca75a | cinder | True | |
| 877f67afbe5a4cb8ec65cf5c8a3ff55e | ec2 | True | |
| 0a259f9203596a5bcd7ef4e05407d9fe | glance | True | |
| b46637c20ec046f2c9ffc8c3a324fccc | neutron | True | |
| da0a11518933ce83f55587d838cd1eb1 | nova | True | |
| 4f8b72fc1ea3e627d72b8f702126e004 | swift | True | |
+----------------------------------+---------+---------+-------+

Task 3/5
3. Configure the SSH keys for root, evsuser, and neutron users.
a. Create the SSH public key for user, evsuser.
root@s11-server:~# su - evsuser -c "ssh-keygen -N '' -f
/var/user/evsuser/.ssh/id_rsa -t rsa"
Your identification has been saved in
/var/user/evsuser/.ssh/id_rsa.
Your public key has been saved in
/var/user/evsuser/.ssh/id_rsa.pub.
58:a9:2e:7e:ce:71:a1:49:a4:ac:08:c3:6c:53:76:d1 evsuser@s11-
server
b. Create the SSH public key for user, neutron.
root@s11-server:~# su - neutron -c "ssh-keygen -N '' -f
/var/lib/neutron/.ssh/id_rsa -t rsa"
Created directory '/var/lib/neutron/.ssh'.
Your identification has been saved in
/var/lib/neutron/.ssh/id_rsa.
Your public key has been saved in
/var/lib/neutron/.ssh/id_rsa.pub.
0c:bf:36:3e:17:80:08:5a:23:6c:c5:75:23:e3:74:35 neutron@s11-
server
c. Append the public keys to the authorized_keys file for evsuser.
root@s11-server:~# cat /var/user/evsuser/.ssh/id_rsa.pub
/var/lib/neutron/.ssh/id_rsa.pub /root/.ssh/id_rsa.pub >>

Chapter 8 - Page 9
d. For these accounts, verify that SSH connectivity is working correctly by using ssh to
connect as evsuser@localhost.
root@s11-server:~# su - evsuser -c "ssh evsuser@localhost
whoami"
known hosts.
evsuser
root@s11-server:~# su - neutron -c "ssh evsuser@localhost

whoami"
known hosts.
evsuser
root@s11-server:~# ssh evsuser@localhost whoami
evsuser
Task 4/5
4. Configure the EVS controller properties.
If you were to configure EVS on a new system, you would need to perform all the steps
mentioned here. However, because you have already configured the EVS controller
properties in an earlier lab, you can skip the following steps:
root@s11-server:~# evsadm set-prop -p
controller=ssh://evsuser@localhost
root@s11-server:~# evsadm set-controlprop -p l2-type=vxlan
root@s11-server:~# evsadm set-controlprop -p vxlan-range=200-300
HOST
appSwitch sys-global busy -- app_ipnet
s11-host01,s11-host02
s11-host01
s11-host02
vport2 -- used zgateway1/net4 192.168.2.4/24 s11-
host01
host02

Chapter 8 - Page 10
gateSwitch sys-global busy -- gate_ipnet

s11-client,s11-host01,s11-host02
vport0 -- used zclient/net0 192.168.1.2/24
s11-client
host01
host02
vport3 -- free -- 192.168.1.5/24 --
root@s11-server:~# evsadm show-prop
controller rw ssh://evsuser@localhost --

vxlan-addr rw 192.168.0.0/24 0.0.0.0 --
vxlan-mgroup rw 0.0.0.0 0.0.0.0 --
a. The new cloudSwitch EVS that you are going to create through Neutron will be on a
net0 uplink port. So set the controller property to the uplink port.
root@s11-server:~# evsadm set-controlprop -p uplink-port=net0
HOST
uplink-port rw net0 -- --
vxlan-addr rw 192.168.0.0/24 0.0.0.0 --
vxlan-mgroup rw 0.0.0.0 0.0.0.0 --

Chapter 8 - Page 11
Task 5/5
5. Configure Neutron.
a. Customize the Neutron component by either uncommenting or adding values to
the neutron.conf files.
root@s11-server:~# vi /etc/neutron/neutron.conf
auth_strategy=keystone
rabbit_host=localhost
auth_uri=http://127.0.0.1:5000/v2.0
identity_uri=http://127.0.0.1:35357
admin_tenant_name=service
admin_user=neutron
admin_password=neutron

:wq
b. Also, edit the following neutron-specific files to set the address of the EVS controller by
uncommenting the evs_controller=ssh://evsuser@localhost line.
root@s11-server:~# vi /etc/neutron/dhcp_agent.ini
evs_controller=ssh://evsuser@localhost
root@s11-server:~# vi /etc/neutron/l3_agent.ini
evs_controller=ssh://evsuser@localhost
c. Enable the neutron services.
root@s11-server:~# svcadm enable -rs neutron-server neutron-
dhcp-agent
d. Export the following global variables you edited in the neutron.conf file.
root@s11-server:~# export
OS_AUTH_URL=http://localhost:5000/v2.0/
root@s11-server:~# export OS_PASSWORD=neutron
root@s11-server:~# export OS_USERNAME=neutron
root@s11-server:~# export OS_TENANT_NAME=service
e. Display the EVS details with the neutron command.
root@s11-server:~# neutron net-list
+--------------------------------------+------------+-----------
------------------------------------------+
| id | name | subnets
|
+--------------------------------------+------------+-----------
------------------------------------------+
| 85aa1672-5769-11e4-a20c-bd72f1a7608c | appSwitch | b4b1a1b0-
5769-11e4-a20d-bd72f1a7608c 192.168.2.0/24 |
| 6ac855de-576a-11e4-a212-bd72f1a7608c | gateSwitch | a5e3b5fa-
576a-11e4-a213-bd72f1a7608c 192.168.1.0/24 |
+--------------------------------------+------------+-----------
------------------------------------------+

Chapter 8 - Page 12
Observe that the appSwitch and gateSwitch EVSs configured earlier with the
evsadm command have been picked up in the statistics.
f. Now create another switch called cloudSwich specifically for any Nova instances that
you might create in the future.
root@s11-server:~# neutron net-create cloudSwitch
Created a new network:
+--------------------------+------------------------------------
--+
| Field | Value
|
+--------------------------+------------------------------------

--+
| admin_state_up | True
|
| id | 2ae0074a-580b-11e4-a6db-
bd72f1a7608c |
| name | cloudSwitch
|
| provider:network_type | vxlan
|
| provider:segmentation_id | 202
|
| router:external | False
|
| shared | False
|
| status | ACTIVE
|
| subnets |
|
| tenant_id | 7512ae3c9133691de569987faefe2e0c
|
+--------------------------+------------------------------------
--+

Chapter 8 - Page 13
g. Display EVS details again with the neutron command. Know that you can also use the
evsadm command.
+--------------------------------------+-------------+----------
-------------------------------------------+
|
+--------------------------------------+-------------+----------
-------------------------------------------+
5769-11e4-a20d-bd72f1a7608c 192.168.2.0/24 |

576a-11e4-a213-bd72f1a7608c 192.168.1.0/24 |
| 2ae0074a-580b-11e4-a6db-bd72f1a7608c | cloudSwitch |
|
+--------------------------------------+-------------+----------
-------------------------------------------+
Observe that cloudSwitch EVS now shows up in the list of configured EVSs.
However, although appSwitch and gateSwitch show subnet details, cloudSwitch
at this point has no subnet assigned to it.
h. Display subnet details.
root@s11-server:~# neutron subnet-list
+--------------------------------------+------------+-----------
-----+--------------------------------------------------+
| id | name | cidr
| allocation_pools |
+--------------------------------------+------------+-----------
-----+--------------------------------------------------+
| b4b1a1b0-5769-11e4-a20d-bd72f1a7608c | app_ipnet |
192.168.2.0/24 | {"start": "192.168.2.2", "end":
"192.168.2.254"} |
| a5e3b5fa-576a-11e4-a213-bd72f1a7608c | gate_ipnet |
192.168.1.0/24 | {"start": "192.168.1.2", "end":
"192.168.1.254"} |
+--------------------------------------+------------+-----------
-----+--------------------------------------------------+

AVAILRANGE
192.168.2.6-192.168.2.254
192.168.1.6-192.168.1.254

Chapter 8 - Page 14
Because there is no subnet for cloudSwitch yet, it does not appear in both the
outputs.
i. Assign a subnet to the cloudSwitch EVS.
root@s11-server:~# neutron subnet-create --enable-dhcp=False --
name cloudsubnet cloudSwitch 192.168.20.0/24
Created a new subnet:
+------------------+--------------------------------------------
--------+
| Field | Value
|
+------------------+--------------------------------------------
--------+

| allocation_pools | {"start": "192.168.20.2", "end":
"192.168.20.254"} |
| cidr | 192.168.20.0/24
|
| dns_nameservers |
|
| enable_dhcp | False
|
| gateway_ip | 192.168.20.1
|
| host_routes |
|
| id | fd2baca4-580b-11e4-a6dc-bd72f1a7608c
|
| ip_version | 4
|
| name | cloudsubnet
|
| network_id | 2ae0074a-580b-11e4-a6db-bd72f1a7608c
|
| tenant_id | 7512ae3c9133691de569987faefe2e0c
|
+------------------+--------------------------------------------
--------+
j. Verify using the neutron and evsadm commands.
+--------------------------------------+-------------+----------
--------------------------------------------+
|
+--------------------------------------+-------------+----------
--------------------------------------------+
5769-11e4-a20d-bd72f1a7608c 192.168.2.0/24 |

Chapter 8 - Page 15

576a-11e4-a213-bd72f1a7608c 192.168.1.0/24 |
| 2ae0074a-580b-11e4-a6db-bd72f1a7608c | cloudSwitch | fd2baca4-
580b-11e4-a6dc-bd72f1a7608c 192.168.20.0/24 |
+--------------------------------------+-------------+----------
-------------------------------------------+
AVAILRANGE
192.168.2.6-192.168.2.254

192.168.1.6-192.168.1.254
cloudSwitch/cloudsubnet 7512ae3c9133691de569987faefe2e0c
192.168.20.0/24 192.168.20.1 192.168.20.2-192.168.20.254
Observe that the cloudSwitch EVS now appears with its subnet details just as the
other two switches do.
Summary: You have successfully configured the Neutron component of OpenStack. This
is by no means a complete setup for the cloud. The EVS switch that you just created is now
cloud ready. In the sense, that you could assign Nova instances to the cloudSwitch EVS
just as you assigned the zapp1 and zapp2 nonglobal zones to the appSwitch EVS in
your prototype earlier.

Chapter 8 - Page 16

Diagnosing Networking
Issues
Chapter 9
Practices for Lesson 9: Diagnosing Networking Issues

Chapter 9 - Page 1
Practices Overview
With your background knowledge about the Oracle Solaris 11 networking technology, you will
attempt to resolve some cases in this lab.
In this lab, you will perform the following tasks:
Address host name resolution failure
Address web server failure
Assumptions:

command output.
connection:
<zonename> command.

Chapter 9 - Page 2
Practice 9-1: Address Host Name Resolution Failure
Overview
Recall that you had successfully configured DNS on the pri-services zone. You also tested
its validity from the zclient zone by pinging various resources. However, now during final
testing, DNS host name resolution is again failing. You need to identify the root cause and
address the gap.
In this practice, you will address host name resolution failure.
Task 1/1
1. Address host name resolution failure.
The zclient zone is unable to resolve zgateway1.

a. Switch to the zclient terminal and ping zgateway1.
^C
root@zclient:~#
This was working when you set up DNS earlier.

b. Verify if DNS lookup is happening.
Server: 192.168.3.4
Address: 192.168.3.4#53
Address: 192.168.3.2
Address: 192.168.10.22
While nslookup is working, why is ping <hostname> not getting resolved? Here is
a clue:
Recall that you configured LDAP after configuring DNS. While configuring the LDAP
client, the LDAP configuration file overwrites the network services switch configuration
file, /etc/nsswitch.conf. This removes the DNS entry from the
/etc/nsswitch.conf file, which impacts DNS hostname resolution. Note that the
/etc/nsswitch.conf file is used to configure services that are used for determining
information such as host names, password files, and group files.
c. Edit the /etc/nsswitch.conf file and modify the hosts entry to look up the DNS
server. Add dns against hosts and ipnodes as marked in the following file:
root@zclient:~# vi /etc/nsswitch.conf
#
# _AUTOGENERATED_FROM_SMF_V1_
#
# WARNING: THIS FILE GENERATED FROM SMF DATA.

Chapter 9 - Page 3
# DO NOT EDIT THIS FILE. EDITS WILL BE LOST.

# See nsswitch.conf(4) for details.
passwd: files ldap

group: files ldap
hosts: files ldap dns
ipnodes: files ldap dns
networks: files ldap
protocols: files ldap
rpc: files ldap
ethers: files ldap

netmasks: files ldap
bootparams: files ldap
publickey: files ldap
netgroup: ldap
automount: files ldap
aliases: files ldap
services: files ldap
:wq
d. Run the name service configuration command to import name service resolution
content from the SMF service.
root@zclient:~# nscfg import f name-service/switch
e. Ping zgateway1 to verify if host name resolution is taking place.
zgateway1 is alive
f. Verify that DNS lookup is also taking place.
Server: 192.168.3.4
Address: 192.168.3.4#53
Address: 192.168.3.2
Address: 192.168.10.22
Observation: DNS service is now operational. zclient is able to resolve zgateway1.

Chapter 9 - Page 4
Practice 9-2: Address Web Server Failure
Overview
Recall that you had successfully configured DNS on the pri-services zone. You also tested
its validity from the zclient zone by pinging various resources. However, now during final
testing, DNS host name resolution is again failing. You need to identify the root cause and
address the gap.
In this practice, you will address web server failure.
Task 1/1
1. Address web server failure.
zclient is not receiving a response from the Apache web server.

a. From the zclient terminal, check if the Apache web server configured over ws1 is
responding.
root@zclient:~# wget 192.168.10.100:80
--2014-09-22 17:48:30-- http://192.168.10.100/
Connecting to 192.168.10.100:80... ^C
root@zclient:~#
If it takes very long to connect, or you notice a connection timed out message, it
means that the web server is not reachable.
When you configured ILB earlier, Apache web server was responding to client
requests. You tested load balancing over VRRP and it was operational then. Here is a
clue:
Recall that while setting up firewall rules in a previous lab, you blocked all network
services. You created an IP Filter rule by adding the line block in on ipmp2 all
in the IP Filter configuration file, /etc/ipf/ipf.conf.
b. Switch to the zgateway1 terminal and modify the configuration file to include the
Apache web servers entry.
#
# ipf.conf
#
#
port=22 keep state
# adding for DNS

Chapter 9 - Page 5
# ading for LDAP
# adding for Web Server
:wq
c. Validate the configuration file.

d. Refresh the IP Filter service.
e. Check the IP Filter firewall statistics.
pass in proto tcp from any to any port = ldap keep state
f. Now, switch to the zclient terminal and check if the Apache web server is reachable.
--2014-09-22 17:50:27-- http://192.168.10.100/
100%[======================================>] 17 --.-
K/s in 0s

WS1 responding

Chapter 9 - Page 6
root@zclient:~#
Observation: You have successfully unblocked port 80 and restored http request
response activities from the client.
Summary: With this, you have successfully configured the prototype you set out to build
and test. A glance at the topology diagram will indicate that you have been able to
implement the setup in entirety, starting from the very first interface you plumbed on the
zclient zone up until you integrated with the Neutron component of OpenStack.

192.168.3.4 192.168.3.5
O

DHCP server ws1 ws2
DNS server 192.168.3.6 192.168.3.7
LDAP server
f-ssh f-http
stub01 stub02
zapp1
192.168.10.22 192.168.3.3 192.168.2.3
192.168.3.2 192.168.10.33
zclient 192.168.1.3 192.168.1.4
192.168.10.11 192.168.10.100 192.168.10.100
192.168.2.4 198.168.2.5
192.168.1.2
IPMP IPMP

EVS Manager
Keystone
Neutron

Chapter 9 - Page 7

Chapter 9 - Page 8

Oracle Solaris 11 Network Administration - Ag

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle Solaris 11 Network Administration - Ag

Uploaded by

Copyright:

Available Formats

THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY.

COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED

Edition 2.0 | December 2014 | D89523

Learn more from Oracle University at oracle.com/education/

Oracle University and Giganomics Lda use only

Copyright 2014, Oracle and/or its affiliates. All rights reserved.

Restricted Rights Notice

Oracle University and Giganomics Lda use only

Technical Contributors and Reviewers

This book was published using: Oracle Tutor

Oracle University and Giganomics Lda use only

Copyright 2014, Oracle and/or its affiliates. All rights reserved.

Oracle Solaris 11 Network Administration Table of Contents

Oracle University and Giganomics Lda use only

Oracle University and Giganomics Lda use only

Copyright 2014, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 1: Course Introduction

Practices for Lesson 1: Overview

Oracle University and Giganomics Lda use only

Figure 1: Configured Oracle VirtualBox VMs

Practices for Lesson 1: Course Introduction

described in the practices.

Oracle University and Giganomics Lda use only

Copyright 2014, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 1: Course Introduction

Oracle University and Giganomics Lda use only

Copyright 2014, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 1: Course Introduction

Practice 1-1: Getting Familiar with the Practice Environment

b. In the Oracle VM VirtualBox Manager window, double-click the s11-server VM to start

Oracle University and Giganomics Lda use only

Copyright 2014, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 1: Course Introduction

2. Log in to the various hosts.

Oracle University and Giganomics Lda use only

Copyright 2014, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 1: Course Introduction

Oracle University and Giganomics Lda use only

e. Enter oracle1 as the password and click the Log In button.

Copyright 2014, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 1: Course Introduction

Oracle University and Giganomics Lda use only

Practices for Lesson 1: Course Introduction

4. Set up terminal titles.

Oracle University and Giganomics Lda use only

Copyright 2014, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 1: Course Introduction

Oracle University and Giganomics Lda use only

Copyright 2014, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 1: Course Introduction

5. Shut down VMS.

Oracle University and Giganomics Lda use only

Copyright 2014, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 1: Course Introduction

Oracle University and Giganomics Lda use only

Copyright 2014, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 1: Course Introduction

Oracle University and Giganomics Lda use only

Copyright 2014, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 1: Course Introduction

Oracle University and Giganomics Lda use only

Copyright 2014, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 1: Course Introduction