Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
We
highly
recommend
to
create
your
own
diagram
at
the
beginning
of
each
lab
so
you
are
able
to
draw
on
your
own
diagram,
making
it
much
easier
when
you
step
into
the
real
lab.
General Rules
Try
to
diagram
out
the
task.
Draw
your
own
connections
the
way
you
like
it
Create
a
checklist
to
aid
as
you
work
thru
the
lab
Take
a
very
close
read
of
the
tasks
to
ensure
you
don’t
miss
any
points
during
grading!
Take
your
time.
This
is
not
a
Mock
Lab,
so
no
time
constraints
are
in
place
for
finishing
this
particular
chapter
Solutions
With
this
chapter
we
will
finalize
the
configuration
of
the
UCS
system,
by
configuring
all
management
related
configuration
on
the
system.
This
means
that
we
will
be
configuring
everything
related
to
the
hardware,
the
system
wide
policies,
management protocols,
backups
and
role based access control (RBAC)
of
the
UCS
system.
We
are
still
using
the
same
topology
as
from
the
previous
UCS
chapters.
We
will
not
change
anything
to
the
topology,
or
use
any
data
connections.
In
this
chapter
we
will
only
use
the
management
connections
used
by
the
management
protocols
to
set-‐up
connections
to
the
management
servers
that
are
available
on
the
management
network.
We
start
by
answering
the
questions
from
the
first
task,
which
is
about
managing
the
hardware
itself
and
setting
up
time
synchronization.
As
the
first
question
states,
we
should
enable
a
physical
location
mechanism,
so
that
an
engineer
who
is
on-‐site
is
able
to
find
the
chassis
very
fast,
when
parts
needs
to
be
services.
Using
the
beacon
LED,
which
is
available
on
almost
all
components
of
the
UCS
system,
does
this.
The
option
to
turn
on
the
LED
is
found
in
the
General
tab
when
clicking
on
the
Chassis
in
the
Equipment
tab
of
the
UCS
Manager.
Second
we
need
to
ensure
that
the
chassis
is
no
longer
using
an
ID
of
1,
but
is
using
an
ID
of
2
instead.
This
is
not
possible
to
be
done
when
the
Chassis
is
in
service.
It
does
require
a
power
off
of
all
the
blade
systems
that
are
running.
Therefore
this
is
not
an
easily
found
task
in
the
CCIE Data Center
lab.
The
step
required
is
that
the
chassis
is
“Decommissioned”
from
the
UCS
Manager.
When
a
chassis
is
decommissioned,
all
configuration
is
removed
and
the
chassis
is
no
longer
considered
as
part
of
the
system.
The
system
still
sees
that
the
chassis
is
connected,
due
to
the
interfaces
on
the
Fabric
Interconnect.
There
it’s
also
possible
to
get
the
chassis
back
into
the
UCS
system
again.
Because
the
decommissioning
takes
a
lot
of
time,
we
added
2
chassis
to
the
UCS
Simulator
available
from
Cisco.com.
Here
we
decommission
one
chassis.
The
complete
decommissioning
will
fail,
but
you
are
able
to
see
the
process
how
the
renumbering
works.
When
this
button
is
clicked,
a
clear
warning
is
shown
that
this
process
is
a
very
definitive
one.
It
also
shows
where
the
chassis
can
be
found
after
the
decommissioning
is
finished.
When
we
access
this
tab,
we
see
that
there
is
one
chassis
in
this
list.
The
ID
of
the
decommissioned
chassis
is
set
to
the
same
ID it
had
when
decommissioning
the
chassis
from
production.
Clicking
on
the
field
can
change
this
ID.
When
the
ID
is
changed
and
“Recommission”
is
checked.
The
Chassis
will
come
back
into
the
system
with
it’s
new
ID.
The next question is to set the timezone and time synchronization of the UCS system.
First
the
time
management
is
set
on
the
Admin
tab.
First
we
set
the
time
zone
to
the
location
that
we
are
now.
In
this
case
Europe/Amsterdam.
Finally
the
time
synchronization
server
(NTP)
is
set
to
the
IP
address
as
mentioned
in
the
question.
We configure this under the Management Interface configuration under the Admin
tab. The Monitoring Policy is found on the second tab.
First do not forget to Enable the feature, otherwise it will not work in total.
Then
we
set
the
polling
interval
to
90
seconds
as
per
the
question.
The
fail
report
count
is
the
amount
of
times
the
polling
fails
consecutively,
which
is
set
to
2.
We
then
set
the
policy
to
Ping
the
Default
Gateway
of
the
Management
interface.
The
ping
requests
that
are
send
are
an
amount
of
5,
where
the
timeout
is
maximum
10
seconds.
The
next
task
is
about
configuring
policies,
which
are
system
wide,
meaning
that
they
cover
settings
that
are
applied
to
all
parts
of
the
system.
Mostly
having
to
do
with
the
configuration
of
the
automatic
detection
of
chassis
and
other
automatic
settings.
These
policies
are
found
in
the
Equipment
tab,
where
they
can
be
configured
when
you
click
on
the
Equipment
item
in
the
tree
view.
In
this
view
there
is
a
tab
called
Policies.
On
this
page
all
the
system
wide
policies
can
be
configured.
We
need
to
set
some
expectations
on
the
physical
connections
that
we
expect
to
be
on
the
UCS
chassis
when
they
are
connected
to
the
Fabric
Interconnect.
The
amount
of
connections
that
a
UCS
chassis
is
connected
with
can
be
changed
at
any
given
point
in
time,
but
when
connecting
multiple
chassis
at
the
same
time,
it’s
recommended
to
let
the
system
wide
policy
be
configured
for
the
preferred
amount
of
links,
so
that
this
is
automatically
configured
once
a
chassis
is
discovered
(meaning
an
interface
on
the
Fabric
Interconnect
is
marked
as
Server
port).
First
we
need
to
ensure
that
the
chassis
assumes
that
there
are
2 power supplies
selected
to
act
as
redundancy,
so
the
2 other
power
supplies
can
fail.
By
default
the
UCS
system
is
set
to
be
redundant
for
only
a
single
power
supply.
Meaning
N+1
redundancy.
The
set-‐up
that
we
are
looking
for
is
called
“Grid”
redundancy.
This
means
that
the
UCS
system
is
connected
to
2
power
grids.
Where
1 power
grid
may
fail,
thus
meaning 2
power
supplies
fail.
Next
we
need
to
configure
that
there
are
going
to
be
4
links
connected
to
each
Fabric
Extender
/
IO module
of
a
chassis,
which
need
to
be
port-‐channeled
preferably
(meaning:
supported).
The
next
question
is
about
how
long
MAC
addresses
that
are
learnt
(pinned)
on
ports,
should
be
kept
in
a
cache
for
540
seconds.
Now
this
is
done
by
configuring
the
MAC
Address
Table
Aging
configuration
option.
This
option
is
by
default
set
to
Default,
but
can
be
set
to
Other
when
a
text
field
is
displayed.
This
field
can
be
filled
with
how
long
the
entries
should
be
kept
before
timing
out.
The
time
out
needs
to
be
set
in
a
strict
format.
540
seconds
means
9
minutes
(540/60=9).
Ensure
that
this
is
set
according
to
the
correct
format.
The
next
question
in
the
task
is
about
sending
log
files
from
the
blade
servers.
These
log
files
are
automatically
kept
on
the
blade
server
itself
and
on
the
UCS
Manager,
but
the
space
is
limited.
Therefore
the
UCS
system
has
a
mechanism
to
export
the
log
files
to
a
file
server
with
FTP,
SCP,
etc.
In
this
question
we
need
to
make
sure
that
the
logging
is
exported
to
an
FTP
server.
This
is
set
on
the
SEL
Policy
tab
under
Backup
configuration.
We
need
to
set
this
that
log
files
are
only
sent
when
the
log
is
full
or
when
the
service
profile
is
disassociated
from
the
blade
system.
The backup should be scheduled every 24 hours. To make room the log should be cleared.
One
important
thing
to
remember
is
that
when
the
exclamation
mark
is
in
front
of
the
field,
it
means
that
the
setting
is
not
saved
yet.
This
is
only
saved
when
the
“Save
Changes”
button
is
clicked.
Usually
when
wizards
are
used,
the
settings
are
automatically
saved,
but
when
things
are
changed
directly
in
the
management
interface
the
changes
are
not
applied
directly.
Pay
attention
to
click
this
button
often
and
at
least
every
time
you
change
the
window.
The
final
question
of
this
task
is
about
DNS
name
resolving.
This
is
set
on
the
Admin
tab
again
and
is
an
easy
setting.
After
the
correct
IP
address
is
entered
as
the
DNS
server.
The
changes
are
applied
automatically,
because
the
DNS
server
is
entered
using
a
small
wizard.
This
following
task
is
about
creating
backups
of
the
UCS
system.
This
is
an
important
topic
and
will
very
likely
be
a
task
on
the
lab
exam.
Backups
can
be
created
using
a
number
of
options.
• Full
state
o This
backup
is
a
binary
file
containing
ALL
information
including
the
cluster
IP
addresses
and
other
initial
configurations
• All
configuration
o This
is
a
clear-‐text
backup
file
containing
ALL
settings
of
the
UCS
Manager
except
the
cluster
information.
Meaning
that
this
back-‐up
would
be
restored
once
the
cluster
information
is
configured
again
• System
configuration
o The
system
configuration
is
about
half
of
the
configuration.
Which
means
that
it
configured
all
the
management
related
configurations
and
all
system
policy
configurations,
what
we
are
configuring
in
this
chapter.
• Logical
configuration
o The
logical
configuration
is
the
other
half
of
the
configuration.
This
clear-‐
text
file
contains
all
the
configuration
of
the
service
profile
and
template
related
configuration.
Meaning
that
it
would
configure
all
the
server
blades,
except
the
management
configuration.
In
this
task
we
are
configuring
multiple
backup
jobs.
The
first
one
is
a
job
that
is
exporting
the
backup
to
an
FTP
server.
We
need
to
make
a
backup
of
the
configuration
applied
after
the
cluster
information.
Meaning
that
we
are
configuring
an
“All
configuration”
back-‐up.
The
backup
configuration
options
are
found
in
the
Admin
tab
under
the
All
option
in
the
tree
view.
Then
we
can
start
creating
the
back-‐up
jobs.
The
first
one
is
to
set
to
an
FTP
server.
Do
not
forget
to
set
the
state
to
Enabled
and
that
All
configuration
is
checked.
As
the
other
question
states,
the
MAC
addresses,
WWPN’s
and
other
settings
having
to
do
with
the
state
of
the
server,
need
to
be
preserved
after
backups.
This
means
that
the
checkbox
of
Preserve
Identities
need
to
be
checked.
Otherwise
all
pool
allocations
are
lost
after
backups.
The backup should finish successfully when this configuration is applied to the UCS system.
The
next
question
is
to
download
a
binary
file
of
the
configuration,
which
means
that
we
need
to
create
a
Local
Backup
of
the
Full
State
configuration.
When
configuring
the
backup
and
clicking
OK,
the
backup
file
is
automatically
created,
which
might
take
some
time.
The
final
question
in
this
task
is
to
create
another
backup
job
to
the
FTP
server,
but
now
not
saving
all
configuration,
but
only
the
service
profile
and
policy
configurations.
Be
sure
to
be
using
a
different
file-‐name
for
this
backup
file,
as
we
do
not
want
to
overwrite
the
other
backup
file.
Again
do
not
forget
to
enable
the
backup
configuration.
This
next
task
is
about
configuring
Syslog
and
other
logging
configurations
related
to
the
UCS
Manager.
The
first
task
is
about
collecting
information,
which
is
used
for
starting
a
TAC
case.
This
information
should
be
based
on
the
entire
UCS
system.
This
is
configured
under
the
same
menu
option
as
the
Backup
operations
and
is
called
“Tech
Support”
information
as
this
is
usually
collected
only
by
the
request
of
Cisco
TAC.
The
first
file
that
needs
to
be
generated
is
a
file
containing
all
information
related
to
the
UCS
system.
This file is easily generated as by default the option is set to the Entire System.
With
the
UCSM
option,
you
create
an
instance
of
the
Tech
Support
information
about
all
information
in
the
UCS system.
Next
we
need
to
collect
logging
about
all
CIMC
modules
in
the
system
(the
out
of
band
blade
management
chip).
Checking
the
Chassis
radio-‐button,
where
the
option
comes
available
to
create
a
Tech
Support
file
about
the
CIMC
modules,
does
this.
As
the
question
states
we
want
to
collect
information
about
all
the
CIMC
modules
in
the
chassis.
As
we
only
have
a
single
chassis,
we
are
collecting
information
about
this
chassis.
Now
the
files
need
to
be
prepared,
before
they
are
downloaded
to
your
system.
This
progress
can
be
monitored
from
the
TechSupport
Files
section.
Next
up
is
the
configuration
of
the
clearing
of
messages
in
the
log
file.
These
message
should
only
be
cleared
after
they
are
not
re-‐occurring.
This
is
the
first
settings
that
is
asked
for.
When
you
clear
a
fault
in
the
log
message
overview
and
the
fault
re-‐occurs,
it’s
remains
visible
in
the
overview
and
is
uncleared.
Except
when
the
event
does
not
re-‐occur
for
the
time
the
Flapping
Interval
is
set
to.
Next
is
to
set
the
time
length
how
long
to
retain
cleared
faults
in
the
log
file.
As
the
question
states
this
should
be
set
to
500
seconds.
This
is
exactly
8 minutes
and
20 seconds
(8*60=480+20=500).
The
next
question
requires
us
to
configure
a
location
where
core
dumps
are
stored,
when
a
component
of
the
UCS
system
crashes.
This
export
should
be
stored
on
a
TFTP server.
Finally
do
not
forget
to
save
the
settings
on
this
page,
otherwise
they
will
be
lost
when
you
switch
to
another
screen.
Next
up
we
are
configuring
the
syslog
settings
of
the
UCS
system.
This
screen
is
quite
big
with
a
lot
of
settings,
but
the
process
is
relatively
easy
when
you
know
the
meaning
of
the
logging.
• Console
logging
is
logging
that
is
shown
on
the
CLI,
when
plugged
into
the
system
with
a
serial
console
cable
• Monitor
logging
is
logging
shown
on
the
CLI
when
logged
into
the
system
using
Telnet
or
SSH
• File logging is simple logging, where messages are saved in a clear text file
• Server
logging
is
the
Syslog
feature,
where
Syslog
messages
are
sent
to
a
remote
server
for
storing
logging
outside
of
the
system.
A
total
of
3
syslog
servers
can
be
configured
on
the
UCS
system
First
we
are
configuring
the
logging
towards
the
Telnet
and
SSH sessions,
meaning
that
we
are
configuring
the
Monitor
Logging
settings.
We should ensure that only Emergencies are logged to these sessions.
Next
all
the
log
messages
should
be
exported
to
a
Syslog
server
using
a
specific
facility.
When
the
question
states
to
export
all
possible
log
messages,
we
need
to
select
the
most
granular
level
of
log
messages.
This
is
done
using
the
Debugging
level
of
messages.
Also
known
as Level 7.
Which
includes
debugging
information,
but
also
all
other
messages
that
are
logged
on
the
system.
Do
not
forget
to
select
the
correct
Facility
to
log
messages
to.
Finally
we
should
configure
another
server
to
export
the
log
messages
to.
Here
we
should
export
all
the
Major
warnings.
Major
in
this
case
means
the
alarms
that
the
UCS
system
marks
as
Major
(Orange Square).
As
the
following
overview
indicates,
the
syslog
logging
levels
are
also
matched
against
the
UCS
Manager
alarm
mapping.
This
mapping
is
equal
to
the
icons
on
the
top
left
corner
of
the
management
interface.
Besides
these
alarms,
also
all
the
other
alarms
beneath
this
level
are
exported
to
the
Syslog
server
which
is
configured
as
the
second
server
in
this
overview.
And
with
the
configuration
of
this
second
syslog
server
we
finished
the
task.
This
task
will
be
all
about
configuring
the
management
protocols
that
are
used
to
manage
the
UCS
system.
The
settings
in
this
task
are
only
configured
for
accessing
the
management
protocols
and
not
about
limiting
access
to
them
(authorizations),
which
is
done
in
a
later
task.
All
of
these
settings
are
found
in
the
Admin
section
of
the
UCS
Manager
under
the
section
Communication
Services.
This
screen
holds
a
lot
of
settings,
all
related
to
the
various
management
protocols
which
can
be
used
to
access
the
UCS
manager.
As
the
first
question
states
we
should
ensure
that
only
HTTPS
sessions
can
be
set-‐up
to
the
UCS
Manager
and
that
it
should
not
automatically
redirect
sessions
connecting
to
HTTP.
This
comes
down
to
that
we
should
completely
disable
the
HTTP
protocol
as
sessions
may
not
be
connected
at
all.
When
settings
to
the
HTTP
or
HTTPS
protocol
are
changed
the
UCS
Manager
warns
that
the
session
might
get
disconnected.
As
we
are
already
connected
through
the
HTTPS
session,
as
redirection
is
by
default
enabled,
nothing
will
happen
with
our
current
session
though.
Next
we
focus
on
the
session
limit.
The
session
limit
is
the
maximum
amount
of
sessions
that
can
be
set-‐up
to
any
of
the
protocols.
Besides
that
there
is
a
limit
on
which
any
particular
user
can
set-‐up
for
amount
of
sessions
to
any
of
the
management
protocols.
You
will
usually
find
that
these
limits
are
quite
large,
but
it
can
happen
that
there
are
multiple
sessions
going
on
at
the
same
time.
KVM
sessions
are
for
example
counting
up
in
this
session
limit,
so
when
opening
multiple
windows
at
the
same
time,
the
amount
of
sessions
can
add
up
quickly.
There
should
not
be
more
than
5 sessions per user active and 64 in total.
The
next
question
is
to
enable
a
standards
based
protocol
running
on
a
particular
TCP
port.
This
port
is
reserved
for
the
use
of
the
CIM-XML
interface.
This
is
used
by
applications
to
access
the
XML
interface
of
the
UCS.
This
model
looks
a
lot
like
the
RPC
Protocol,
but
is
based
on
an
open
standard
over
HTTP.
By
default
this
is
disabled,
but
here
we
enable
the
protocol.
When
we
enable
the
protocol,
we
see
the
TCP
port
mentioned,
which
is
how
you
would
easily
spot
it
when
you
are
not
sure
what
is
meant
with
this
question.
Just
try
and
this
should
immediately
be
spotted
so
you
are
sure
that
the
question
is
correct.
In
the
next
couple
questions
we
fill
focus
on
the
configuration
of
the
SNMP
protocol.
This
configuration
can
be
a
bit
complex
with
using
several
versions
throughout
the
configuration
and
in
a
number
of
combinations.
We
should
start
with
configuring
the
default
settings
of
SNMP.
During
the
SNMP
questions
it’s
important
to
keep
in
mind
that
some
questions
relate
to
each
other.
Initially
we
are
configuring
the
basic
properties
that
we
are
configuring
an
SNMP
configuration
which
supports
both
SNMP version 2c
based
on
community
strings
and
SNMP version
3 based
on
usernames
and
passwords.
We
configure
our
name
and
location
as
the
SNMP
property
and
we
need
to
make
sure
that
systems
can
read
from
the
UCS
using
a
specific
keyword.
These
are
all
properties
that
we
can
configure
in
the
initial
few
fields.
As
we
need
to
support
both
SNMP version 2c
and
version 3
we
also
need
to
configure
a
SNMP
username.
The
configuration
of
the
Username
in
the
first
field
is
enough
for
the
SNMP
version
2c
configuration,
as
that
enables
the
community
string.
Both
a
authentication
password
and
a
privacy
password
is
configured.
It’s
not
required
to
have
both
configured,
but
the
end-‐host
system
will
begin
it’s
session
either
with
only
authenticating
or
with
also
encrypting
traffic.
In
case
of
the
second
option
(encryption)
we
also
need
the
privacy
password
to
be
configured.
We
should
now
ensure
that
traps
in SNMP version 3
are
sent
to
a
specific
server.
This
trap
is
configured
separately.
The
options
that
are
required
to
configure
are
the
host
that
should
receive
the
traps,
the
username
of
the
SNMP version 3
user
that
is
used
and
what
kind
of
traps
are
send.
The
next
2
questions
indicate
that
the
traps
should
be
encrypted
using
the
strongest
encryption
possible.
Therefore
we
first
need
to
ensure
that
the
traps
are
encrypted
by
selecting
the
Priv
option
in
the
trap
configuration.
Finally
the
traps
should
be
confirmed
by
the
host
system
once
it’s
received.
This
kind
of
trap
is
called
an
“inform”,
which
is
also
an
option
for
the
configuration
of
the
SNMP version 3
trap.
Finally
we
should
configure
the
SNMP
username
related
to
this
configuration.
As
stated
we
should
be
using
the
strongest
encryption
possible.
So
we
ensure
that
we
select
the
SHA
hashing
algorithm
and
the
AES-‐128
encryption.
By
default
MD5
hashing
and
DES
(56-‐bit)
encryption
is
used
for
SNMP version 3.
With
the
creation
of
the
user
the
task
about
management
protocols
is
finished.
This
next
task
is
about
creating
containers
to
place
objects
in
that
can
be
managed
separately.
The
whole
Cisco
UCS
system
is
created
to
a
multi-‐tenant
environment
is
possible
to
create.
This
means
that
multiple
departments
or
companies
can
own
their
piece
of
the
entire
UCS
system
without
interfering
with
the
other
configurations
on
the
system.
The spread between the organizations is quite fixed and there is limited overlap.
You
can
place
anything
there
is
in
the
UCS
Manager
inside
an
organization.
Resources
are
not
shared
between
them
when
they
are
on
the
same
level.
It’s
possible
to
create
organizations
within
another
organization,
which
creates
a
parent
and
child
relationship
between
them.
When
resources,
from
for
example
a
pool,
run
out
on
the
child
organization
it’s
allowed
to
“borrow”
the
resources
from
the
parent
pool.
This
holds
also
true
for
organizations
directly
created
under
the
root,
which
can
borrow
resources
from
the
root
organization
which
always
exists.
In
every
menu
there
is
an
option
to
create
the
specific
resource
within
a
certain
organization
thus
creating
multiple
tenants.
In
the
next
tasks
about
Authentication
this
will
be
used
so
that
users
can
log-‐in
to
the
UCS
into
certain
organizations.
We
first
need
to
create
the
organizations.
Organizations
can
be
created
from
anywhere
in
the
UCS
Manager.
In
this
case
we
choose
to
create
them
under
the
Pool
configuration
of
the
Server
tab,
but
when
an
organization
is
created
here
it’s
automatically
created
everywhere
in
the
configuration.
The
root
organization
always
exists
and
cannot
be
edited.
Under
the
Sub-‐
Organizations
tab
it’s
possible
to
create
new
organizations.
We
should
first
create
a
container
(organization)
for
the
finance
department
with
several
child-‐organizations
under
it.
When
this
initial
container
is
created,
you
can
see
that
automatically
the
organization
is
available
anywhere
in
the
UCS
Manager.
Here
it’s
shown
that
under
the
newly
created
Finance
department
it
becomes
possible
to
create
additional
organizations
beneath
this
level.
Which
is
what
we
need
to
do
with
the
following
3
organizations.
After the 3 departments have been created they are available throughout the UCS Manager.
Next
we
create
another
organization
for
the
HR
department.
Now
this
organization
should
not
fall
under
the
Finance
department,
so
this
should
be
created
back
at
the
top
level
again.
Pay
attention
that
you
create
the
organization
at
the
correct
level,
because
nested
organizations
can
be
managed
through
the
same
user.
Which
means
that
a
user
assigned
to
the
Finance
department
can
also
manage
the
Contracts,
Control
and
Purchase
department,
because
those
are
child
organizations
of
Finance.
In
case
of
HR
we
do
not
want
any
Finance
users
to
manage
those
resources.
Finally
we
should
ensure
that
there
can
be
users
connected
to
the
UCS
Manager
that
only
access
resources
within
these
containers.
To
make
sure
that
users
log
in
and
are
limited
to
accessing
resources
within
the
organization
and
still
using
the
various
user
roles
that
are
available,
the
UCS
Manager
knows
the
concept
of
Locales.
The
Locales
are
defined
so
a
certain
user
is
connected
to
a
Locale
which
defines
to
which
Organizations
the
user
has
access
to.
Locales are configured under the Admin tab where users are also configured.
We create Locales according to all the organizations that were just created, because this
Keep
in
mind
that
it
works
as
a
tree
structure.
Meaning
that
when
a
user
has
access
to
the
Finance
organization
it
automatically
also
has
access
to
the
organizations
beneath
it
as
it
Now
we
configured
this
task
successfully
and
we
can
start
configuring
the
next
part
which
is
giving
users
access
to
the
UCS
configuration.
In
this
task
we
will
be
configuring
for
giving
access
to
users
to
the
UCS
configuration
and
accessing
the
UCS Manager.
Besides
that
we
will
be
configuring
all
the
changes
that
the
users
are
allowed
to
make
on
the
system
as
well.
This
has
been
split
in
to
different
roles
just
as
on
the
Nexus
and
MDS
switches.
The
roles
are
even
similar
to
them
as
is
the
configuration.
The
first
questions
that
we
need
to
answer
are
related
to
changing
the
password
and
setting
a
banner
to
welcome
users.
We
first
need
to
set
the
configuration
so
that
users
are
not
allowed
to
change
their
password
for
7 days
and
do
not
re-‐use
the
same
password
as
the
last
5
ones.
We
configure
this
under
the
Admin
tab
under
Locally
Authenticated
Users.
The
fields
that
we
are
looking
for
are
the
History
Count
and
the
No
Change
Interval.
As
this
is
not
a
wizard,
do
not
forget
to
save
the
settings
on
this
page,
otherwise
the
changes
are
gone
after
you
change
pages
on
the
UCS
Manager.
Next
we
need
to
configure
a
banner
that
users
will
see
when
logging
in.
This
settings
can
take
you
quite
some
time
to
find,
but
it’s
located
in
the
Admin
tab
under
User
Services
and
then
you
will
see
the
Banners
tab.
There
you
will
see
an
option
to
create
the
banner.
Create
the
banner
with
the
exact
specified
text.
Keep
in
mind
that
when
another
text
is
used
in
this
field,
the
task
will
be
marked
wrong.
Next
we
are
going
to
configure
a
locally
authenticated
user
with
a
specified
username
and
password.
This
user
should
get
it’s
own
role
assigned
as
it’s
only
allowed
to
change
networking
and
service
profile
related
settings
and
we
are
not
allowed
to
use
pre-‐
Be
sure
to
select
everything
related
to
the
configuration
of
a
Service
Profile
and
to
the
Uplink
Networking
(called
Ext
Lan
in
the
role
configuration).
Pay
attention
that
you
do
not
select
anything
about
external
SAN
connectivity
as
that’s
not
what
the
question
stated.
Now
we
can
start
configuring
the
user.
We
should
use
a
defined
username
and
password
as
stated
in
the
question.
Finally
we
should
use
a
pre-‐defined
locale
configuration.
As
previously
explained,
organizations
which
are
nested
are
automatically
allowed
access.
Meaning
that
we
need
to
select
the
Finance
organization
in
this
question
to
give
the
user
access
to
both
the
Contracts
and
the
Control
organization
at
the
same
time.
Next
we
need
to
create
a
user
which
is
only
allowed
to
change
configuration
in
the
HR
department
and
which
should
expire
by
the
end
of
next
month.
The
user
should
be
able
to
change
everything,
which
means
we
will
use
the
pre-‐defined
“Admin”
role.
It
turns
out
that
we
cannot
use
the
system-wide default roles
such
as
Admin,
AAA,
Fault
or
Operations.
These
are
roles
that
change
settings
which
cannot
be
placed
inside
an
organization,
so
when
a
locale
is
attached,
the
user
cannot
be
given
those
rights.
To
work
around
this
we
configure
the
user
to
be
in
all
the
other
pre-‐defined
roles
which
all
take
care
for
some
piece
of
the
configuration.
Combining
all
those
pre-‐defined
roles
together,
without
the
system-‐wide
ones.
We
can
change
anything
we
want
related
to
the
resources
available
in
the
HR
organization.
Next
we
are
configuring
RADIUS
authentication
on
the
UCS
Manager.
The
next
few
questions
are
all
related
to
the
configuration
of
the
RADIUS
server
on
the
UCS
Manager.
We
should
first
configure
the
RADIUS
server
details.
We
fill
in
all
the
details
which
are
given
in
the
questions.
To be able to use the RADIUS server we should also configure a RADIUS Provider Group,
which
is
where
you
can
select
multiple
RADIUS
servers
to
be
used
for
failover
scenarios.
We
select
the
first
and
only
RADIUS
server
that
we
just
configured.
Next
the
Authentication
Domain
needs
to
be
configured.
We
will
not
be
needing
any
other
domains,
so
we
can
use
the
Native
domain
as
we
need
to
configure
the
default
authentication
mechanism.
Domains
work
like
the
order
that
you
configure
in
IOS.
So
they
are
just
there
for
failover
reasons.
When
no
domains
are
configured,
the
native
authentication
is
used.
We
select
it
to
use
the
RADIUS
protocol
and
use
the
provider
group
which
we
just
configured.
When
you
do
not
configure
any
provider
group,
it
just
uses
all
servers
which
are
configured
in
order
of
configuration.
Finally
we
select
that
users
should
be
assigned
to
a
Read-Only default role
when
there
is
no
attribute
pushed
from
the
RADIUS
server.
Now
we
finished
our
authentication
task
and
we
start
with
the
final
task
of
this
chapter.
In
this
final
task
we
will
focus
a
bit
more
on
creating
roles
and
assigning
locales
to
locally
authenticated
users.
We
first
configure
a
new
role
for
uplink
configuration.
The
trick
in
this
configuration
is
that
you
need
to
ensure
that
the
configurations
for
both
the
Ethernet
uplinks
and
the
Fibre
Channel
uplinks
are
taken
into
account
when
creating
this
role.
Ensure
that
all
checkboxes
are
set
for
all
Ext
Lan
and
Ext
San
options.
As
you
should
be
able
to
change
all
settings
related
to
uplinks.
Next
we
need
to
create
a
role
which
is
able
to
change
system
wide
settings
and
management
tasks.
This
means
we
need
to
check
all
boxes
that
have
nothing
to
do
with
setting
interfaces,
configuring
servers,
profiles
or
blades,
but
all
the
rest.
This
comes
down
to:
• AAA
• Fault
• Operations
• Power Mgmt
The
final
question
is
to
create
a
new
user
which
is
able
to
change
service
profiles
and
everything
related
to
servers.
We
should
create
a
custom
role
and
custom
locale,
whilst
the
user
should
still
be
able
to
change
everything
in
all
organizations.
First
we
create
the
role
and
we
check
all
the
boxes
for
anything
related
to
servers
and
service
profiles.
Then
we
create
the
new
locale
and
we
assign
the
root
organization.
You
could
also
assign
all
the
organizations
separately,
but
it’s
easier
to
just
do
this
via
the
root
configuration.
Finally we can create the user itself and combine all the settings together.
Chapter
14:
Data
Center
Unified
Computing
Management
is
intended
to
let
you
be
familiar
with
the
basic
features
of
setting
up,
provisioning,
configuring
and
implementing
a
Cisco
Nexus
1000V
virtual
switch
inside
a
virtualized
environment.
We
highly
recommend
creating
your
own
diagram
at
the
beginning
of
each
lab
so
you
are
able
to
draw
on
your
own
diagram,
making
it
much
easier
when
you
step
into
the
real
lab.
Multiple
topology
drawings
are
available
for
this
chapter.
General
Rules
Try
to
diagram
out
the
task.
Draw
your
own
connections
the
way
you
like
it.
Create
a
checklist
to
aid
as
you
work
thru
the
lab.
Take
a
very
close
read
of
the
tasks
to
ensure
you
don’t
miss
any
points
during
grading!
Take
your
time.
This
is
not
a
Mock
Lab,
so
no
time
constraints
are
in
place
for
finishing
this
particular
chapter
Solutions
In
this
chapter
we
will
be
using
a
fully
virtual
component
used
in
the
CCIE Data Center
lab.
This
is
the
Nexus
1000V
switch
from
Cisco.
This
switch
is
completely
virtual
and
is
not
using
any
physical
components.
It’s
installed
inside
of
the
VMware ESX hypervisor
and
it
replaces
the
default
vSwitch
of
the
ESX
host.
This
virtual
switch
is
known
as
the
Virtual
Ethernet
Module
or
VEM.
The
VEM
can
be
seen
as
a
linecard
performing
distributed
forwarding
in
a
chassis
switch.
This
is
managed
through
a
single
management
point
known
as
the
Virtual
Supervisor
Module
or
VSM.
The
VSM
is
seen
as
the
Supervisor
of
a
Catalyst
or
Nexus
switch.
Of
course
there
can
be
2
VSMs
inside
a
Nexus
1000V,
with
SSO
synchronization
between
them
meaning
a
Supervisor
switchover
can
be
implemented.
This
brings
us
to
the
deployment
of
the
Nexus
1000V.
During
your
lab
attempt
you
will
not
have
access
to
the
VMware
vCenter
environment.
This
means
you
need
to
be
able
to
perform
all
the
settings
you
make
from
the
Nexus
1000V
VSM.
You
do
have
access
to
the
Nexus
1000V
installer
through
a
Web
page,
which
becomes
available
after
you
deploy
the
VSM
into
VMware
vCenter.
It’s
unlikely
that
you
will
be
faced
with
the
clean
installation
of
the
Nexus
1000V,
but
it
is
possible
as
you
only
require
the
Web
Installation
application.
This
Java
based
installer
will
run
you
through
the
configuration
of
the
Nexus
1000V,
the
addition
of
ESX(i)
servers
and
the
migration
of
port
groups
to
the
installation.
To
cover
the
full
details
of
the
Nexus
1000V
installation
we
cover
the
installation
in
detail
for
deploying
the
VSMs
and
installing
the
Nexus
1000V
from
scratch.
It’s
highly
likely
that
you
will
be
faced
with
a
pre-‐configured,
but
broken
configuration
in
the
CCIE
Data
Center
lab
exam,
because
there
are
much
more
interesting
troubleshooting
tasks
to
be
done
than
the
installation
is.
The
installation
starts
with
the
deployment
of
the
VSM
using
an
OVF
template.
The
template
is
a
script,
which
carries
a
VM
settings
file
(.vmx)
and
a
harddisk
(.vmdk).
Then
the
OVF
file
then
combines
all
the
settings
and
has
a
script
to
ask
for
more
questions.
Be
sure
to
install
the
latest
version
of
the
Nexus
1000V,
at
least
the
version
as
described
in
the
screenshot
above.
This
version
is
the
first
version
to
support
VMware ESXi 5.1.
You
need
to
name
the
VSM
accordingly
and
place
it
within
the
Datacenter
in
the
inventory.
The
install
option
that
you
will
mostly
use
is
the
Installer
option.
The
Secondary
option
is
used
when
you
are
deploying
a
second
VSM
inside
the
same
cluster.
This
secondary
VSM
will
act
as
a
redundant
supervisor
inside
of
the
Nexus
1000V.
Manually
configuring
the
Nexus
1000V
has
almost
no
advantages
over
using
the
Installer,
because
the
installer
will
arrange
the
connectivity
between
the
Nexus
1000V
and
the
vCenter
server
automatically.
This
is
something
you
will
need
to
configure
manually
when
you
are
using
the
Nexus 1000V manual installation.
Leave
the
installation
options
default
for
the
Disk Format.
The
Network
mapping
is
a
very
important
one!
The
Nexus
1000V
requires
3 network connections
to
function
well.
1. Management
a. The
Management
connection
needs
to
be
a
separate
VLAN
and
this
should
be
the
VLAN
that
you
use
to
manage
your
other
network
connections.
This
connection
is
placed
inside
a
dedicated
VRF
just
like
is
the
case
on
all
the
Nexus
switches.
2. Packet
a. The
Packet
connection
is
required
to
be
a
separate
VLAN
from
the
management
and
it’s
used
to
transport
control-plane packets
from
the
VEM
towards
the
VSM
like
IGMP,
CDP
and
LACP.
3. Control
a. The
Control
VLAN
is
used
for
control
commands
between
the
VSM
and
VEM,
like
the
updating
of
DVS
ports
and
NetFlow exports.
The
Packet
and
Control
VLANs
can
be
separated,
but
it’s
also
allowed
to
let
these
share
the
same
VLAN.
The
final
sheet
is
about
configuring
various
settings
for
the
VSM.
The
Domain ID
needs
to
be
the
same
between
redundant
supervisors
and
different
when
installing
different
Nexus
1000V
switches.
The
admin
password
needs
to
be
set
as
is
the
Management
IP
address.
After
deployment
of
the
Nexus 1000V VSM
you
can
immediately
SSH
into
it.
After
the
completion
of
the
deployment
of
the
VSM
the
VSM
is
automatically
registered
with
the
ESXi
server.
Now
the
installation
of
the
Primary
VSM
is
finished.
The
installation
of
the
Secondary
VSM
is
very
similar.
You
do
not
need
to
configure
a
management
IP
address
on
the
secondary
as
it
will
learn
this
from
the
Primary
VSM
through
the Packet
and
Control
VLANs.
After
that
it
will
automatically
join
the
SSO
“cluster”
and
your
VSM
is
redundant.
From
the
Nexus 1000V Installer app
you
are
able
to
let
ESXi
hosts
join
the
Nexus
1000V,
but
in
this
case
we
chose
to
use
the
VMware
vSphere
client
instead.
We
add
2
of
our
hosts
to
the
1000V
on
which
we
also
already
installed
the
VEMs.
This
VEM
can
be
installed
through
the
VMware Update Manager
(VUM)
or
by
CLI
on
the
ESXi
host
itself.
/tmp # esxcli software vib install -v /vmfs/volumes/511a11c9-b4ae05ba-
0bd8-005056ab04c1/cross_cisco-vem-v147-4.2.1.1.5.2b.0-
3.1.1.vib
Installation Result
Message: Operation finished successfully.
Reboot Required: false
VIBs Installed: Cisco_bootbank_cisco-vem-v147-esx_4.2.1.1.5.2b.0-3.1.1
VIBs Removed:
VIBs Skipped:
/tmp #
Only
after
the
installation
of
the
VEM
the
Host
can
be
successfully
added
to
the
Nexus
1000V
configuration.
Task
1:
Initial
set-‐up
Now
we
can
begin
with
our
first
task
of
the
chapter.
We
login
to
the
previously
installed
and
mapped
Nexus
1000V
and
verify
it’s
operational
state.
The
VEMs,
meaning
the
software,
is
already
loaded
onto
the
ESXi
hosts.
We
now
need
to
set-‐up
the
Nexus
1000V
from
the
beginning
as
there
is
nothing
attached
to
it
yet.
We
verify
that
the
Nexus
1000V
is
fully
empty.
switch# sh module
Mod Ports Module-Type Model Status
--- ----- -------------------------------- ------------------ --------
----
Mod Sw Hw
--- ------------------ ------------------------------------------------
1 4.2(1)SV1(5.2b) 0.0
version 4.2(1)SV1(5.2b)
no feature telnet
ip domain-lookup
ip host switch 10.200.17.53
errdisable recovery cause failed-port-state
snmp-server user admin network-admin auth md5
0x33a0b614d342f4f44e8348f33652a4b2 priv
0x33a0b614d342f4f44e8348f33652a4b2 loc
alizedkey
vdc switch id 1
limit-resource vlan minimum 16 maximum 2049
interface mgmt0
ip address 10.200.17.53/24
interface control0
line console
boot kickstart bootflash:/nexus-1000v-kickstart.4.2.1.SV1.5.2b.bin sup-1
boot system bootflash:/nexus-1000v.4.2.1.SV1.5.2b.bin sup-1
boot kickstart bootflash:/nexus-1000v-kickstart.4.2.1.SV1.5.2b.bin sup-2
boot system bootflash:/nexus-1000v.4.2.1.SV1.5.2b.bin sup-2
svs-domain
domain id 101
control vlan 0
packet vlan 0
svs mode L2
vservice global type vsg
tcp state-checks
vnm-policy-agent
registration-ip 0.0.0.0
shared-secret **********
log-level
switch#
Before
a
connection
to
vCenter
can
be
made
the
Nexus 1000V extension key
needs
to
be
installed
on
the
vCenter server.
This
has
already
been
prepared
in
the
Proctor
Labs
Rack.
You
install
this
extension
key
by
loading
the
XML
file
from
the
Nexus 1000V webpage
into
the
vCenter Extension Manager.
After
that
we
can
start
preparing
the
system
for
the
settings
as
is
stated
in
the
questions
of
the
task.
We
are
going
to
use
a
Layer 2 control mechanism
and
we
configure
a
number
of
VLANs
to
support.
This
means
we
need
to
create
the
port profile
for
the Control
and
Packet
VLAN
and
we
need
to
create
the
VLANs.
Finally
we
need
to
create
a
port-profile
to
ensure
the
uplink
connections
are
created
and
the
right
VLANs
are
allowed
on
it.
It’s
important
that
the
server
comes
online
and
that
communication
from
the
VSM
to
the
VEM
needs
to
be
up
and
running
right
away.
This
is
done
using
the
System VLAN
command.
When
a
VLAN
is
marked
as
a
System
VLAN
then
it
will
not
require
the
VSM
to
be
online
for
the
VLAN
to
work
on
the
VEM.
This
situation
will
occur
when
an
ESXi
host
boots.
We
first
set
the
correct
hostname
and
create
the
VLANs.
switch# conf t
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# switchname N1kv1
N1kv1(config)# vlan 2000
N1kv1(config-vlan)# name management
N1kv1(config-vlan)# vlan 2001
N1kv1(config-vlan)# name packet
N1kv1(config-vlan)# vlan 2002
N1kv1(config-vlan)# name control
N1kv1(config-vlan)# exit
N1kv1(config)#
Next
we
create
the
port-‐profiles
that
we
require.
N1kv1(config)# port-profile type vethernet CONTROL
N1kv1(config-port-prof)# switchport mode access
N1kv1(config-port-prof)# switchport access vlan 2002
N1kv1(config-port-prof)# vmware port-group
N1kv1(config-port-prof)# state enabled
N1kv1(config-port-prof)# no shutdown
N1kv1(config-port-prof)# system vlan 2002
N1kv1(config-port-prof)#
N1kv1(config-port-prof)#
N1kv1(config-port-prof)# port-profile type vethernet PACKET
N1kv1(config-port-prof)# sw mode access
N1kv1(config-port-prof)# sw acc vlan 2001
N1kv1(config-port-prof)# vmware port-group
N1kv1(config-port-prof)# state enabled
N1kv1(config-port-prof)# no shut
N1kv1(config-port-prof)# system vlan 2001
N1kv1(config-port-prof)#
N1kv1(config-port-prof)#
N1kv1(config-port-prof)# port-profile type ethernet UPLINK
N1kv1(config-port-prof)# switchport mode trunk
N1kv1(config-port-prof)# switchport trunk allowed vlan all
N1kv1(config-port-prof)# 2013 Mar 5 10:06:50 N1kv1 %PORT-PROFILE-1-
VLAN_CONFIGURED_CONTROL_VLAN: Port-profile is configured to carry the
control VLAN 0. Also configure the vlan as system VLAN in this port-
profile and other uplink port-profiles that are configured to carry the
VLAN for VSM-VEM traffic.
2013 Mar 5 10:06:50 N1kv1 %PORT-PROFILE-1-VLAN_CONFIGURED_PACKET_VLAN:
Port-profile is configured to carry the packet VLAN 0. Also configure the
VLAN as system VLAN in this port-profile and other uplink port-profiles
that are configured to carry the VLAN for VSM-VEM traffic.
N1kv1(config-port-prof)# no shutdown
N1kv1(config-port-prof)# vmware port-group
N1kv1(config-port-prof)# state enabled
N1kv1(config-port-prof)# system vlan 2000,2001,2002
Now
the
settings
to
ensure
the
connections
to
the
VMware
servers
can
be
created
are
made.
The
System
VLANs
can
only
be
put
on
the
port-profile
as
a
final
step.
After
the
profile
is
set
to
no
shutdown.
Otherwise
it
will
give
an
error
message.
When
control-plane
VLANs
are
added
to
a
trunk
profile
you
are
warned
that
the
VLANs
should
also
be
marked
as
System
VLAN.
Now
we
will
configure
the
connection
towards
the
vCenter
server.
N1kv1(config)# svs connection ?
WORD Name of the connection (Max Size 64)
N1kv1(config-svs-conn)# protocol ?
vmware-vim Vmware-vim protocol
When
configuring
the
SVS
connection
(vCenter
connection)
we
need
to
set
the
protocol
to
be
vmware.
In
the
release
that
is
currently
running
only
the
VMware
protocol
is
supported.
N1kv1(config-svs-conn)# remote ?
hostname Configure remote host name
ip Configure IP features
port Configure remote host tcp port
N1kv1(config-svs-conn)# remote ip ?
address Configure ipv4 address
Next
we
configure
the
Datacenter
group
name
on
which
the
Nexus
1000V
should
be
installed
in.
Finally
we
need
to
ensure
the
connection
is
made.
N1kv1(config-svs-conn)# connect
ERROR: Failed to create vmware dvs because svs-domain not configured.
N1kv1(config-svs-conn)# sv
svs svs-domain
N1kv1(config-svs-conn)# svs-domain
N1kv1(config-svs-domain)# ?
control Configure control vlan number
domain Configure domain-id
no Negate a command or set its defaults
packet Configure packet vlan number
svs Configure SVS
end Go to exec mode
exit Exit from command interpreter
pop Pop mode from stack or restore from name
push Push current mode to stack or save it under name
where Shows the cli context you are in
N1kv1(config-svs-domain)# domain ?
id Configure id for this domain
N1kv1(config-svs-domain)# domain id ?
<1-4095> Domain-id number
svs-domain
domain id 101
control vlan 2002
packet vlan 2001
svs mode L2
svs connection VCENTER
protocol vmware-vim
remote ip address 10.200.17.50 port 80
vmware dvs datacenter-name CCIEDC
max-ports 8192
connect
vservice global type vsg
tcp state-checks
vnm-policy-agent
registration-ip 0.0.0.0
shared-secret **********
log-level
When
the
connect
is
configured
again
the
connection
is
successfully
set-‐up.
N1kv1(config-svs-conn)# show svs connection
connection VCENTER:
ip address: 10.200.17.50
remote port: 80
protocol: vmware-vim https
certificate: default
datacenter name: CCIEDC
admin:
max-ports: 8192
DVS uuid: 65 8a 10 50 47 d3 7f a3-b9 66 e7 bf f1 2c 35 cd
config status: Enabled
operational status: Connected
sync status: Complete
version: VMware vCenter Server 5.1.0 build-947673
vc-uuid: BD87C0C0-A3C7-451B-91CA-96A748B768CD
We can also verify that the Distributed Switch is created in vCenter itself.
In
the
screenshot
below
we
can
see
that
the
N1kv1
is
created
inside
of
vCenter
and
that
the
port-‐profiles
that
were
configured
previously
are
also
shown
in
the
overview.
The
next
step
is
to
let
the
ESXi
hosts
connect
to
the
Nexus
1000V.
This
will
not
happen
automatically
as
they
need
to
be
migrated
to
the
Nexus
1000V.
This
can
be
done
using
the
Installer
application
or
using
VMware
vCenter.
In
our
example
we
will
be
using
VMware
vCenter.
We
need
to
select
which
ESXi
hosts
should
be
migrated
to
the
Nexus
1000V.
We
select
4
hosts
to
be
migrated
on
which
the
VEM
module
is
already
installed.
Ensure
you
select
the
uplinks
that
are
coming
into
the
Nexus
1000V
and
select
the
UPLINK
port
profile.
After
the
adding
using
this
wizard
the
hosts
are
added
to
the
Nexus
1000V
and
they
should
appear
in
the
Nexus
1000V.
Be
sure
to
only
include
a
single
NIC
into
the
Nexus
1000V
at
first.
When
ports
are
not
port-‐
channelled
the
Nexus
1000V
will
mark
them
as
loops
and
certain
VLANs
might
get
blocked
due
to
loop
prevention.
You
issue
a
show module
to
verify
the
operation
of
all
the
modules.
With
a
show module
vem
you
can
see
only
the
VEM
modules
and
verify
the
software
version
of
the
VEM,
which
is
loaded
on
the
ESXi
host.
Here
you
are
also
able
to
see
the
version
of
ESX(i)
that
is
installed
on
the
host.
N1kV# show module vem ?
<CR>
<1-66> Enter module number
> Redirect it to a file
>> Redirect it to a file in append mode
counters Show Virtual Ethernet Module counters
ipv6-info Show Module IPV6 address
license-info Show Module License Info
mapping Show host/module mapping
missing Show modules that are added to VC but missing from VSM
| Pipe command output to filter
Mod Sw Hw
--- ------------------ ------------------------------------------------
3 4.2(1)SV1(5.2b) VMware ESXi 5.1.0 Releasebuild-799733 (3.1)
4 4.2(1)SV1(5.2b) VMware ESXi 5.1.0 Releasebuild-799733 (3.1)
5 4.2(1)SV1(5.2b) VMware ESXi 5.1.0 Releasebuild-799733 (3.1)
6 4.2(1)SV1(5.2b) VMware ESXi 5.1.0 Releasebuild-799733 (3.1)
With
the
license-‐info
command
you
are
able
to
verify
if
licensing
is
properly
installed.
In
previous
versions
of
the
Nexus
1000V
you
were
required
to
purchase
a
license
per
processor.
With
this
newest
version
of
the
Nexus
1000V
this
is
no
longer
necessary
and
the
Nexus
1000V
became
free
of
charge.
You
only
require
a
license
for
the
security
features
(Virtual
Security
Gateway
product)
of
the
Nexus
1000V.
The
security
features
are
not
tested
on
the
CCIE
Data
Center
lab
exam.
N1kV# show module vem license-info
Licenses are Sticky
Mod Socket Count License Usage Count License Version License
Status
--- ------------ ------------------- --------------- -------------
-
3 2 2 1.0 licensed
4 2 2 1.0 licensed
5 2 2 1.0 licensed
6 2 2 1.0 licensed
With
the
visibility
of
the
VEMs
inside
of
the
Nexus
1000V
we
are
ready
with
the
first
task
of
this
chapter.
Task
2:
Configure
VLANs
&
port-‐profiles
In
this
next
task
we
will
continue
to
create
the
VLANs
and
port-‐profiles.
We
first
need
to
create
a
number
(range)
of
VLANs.
This
can
be
easily
done
by
just
typing
a
dash
between
the
VLAN
numbers
just
like
on
other
Nexus
switches.
N1kv1(config)#
N1kv1(config)# vlan 101-110
N1kv1(config-vlan)# exit
N1kv1(config)# vlan 501-525
N1kv1(config-vlan)# exit
N1kv1(config)# vlan 3999
^
invalid vlans (reserved values) at '^' marker.
As
the
next
question
indicates
you
should
create
the
highest
number
of
VLAN
possible
in
the
3000
range.
You
have
to
know
that
there
are
Reserved
VLANs
in
the
Nexus
1000V.
This
range
is
from
3968
up
to
4047
and
4094.
This
means
that
in
our
case
we
can
create
the
VLAN
3967.
Others
are
reserved,
which
will
give
you
an
error
message.
The
next
question
indicates
that
we
should
create
a
profile
so
that
hosts
in
VLAN
105
can
be
accessed
from
the
Nexus
1000V.
We
create
a
“vEthernet”
port-‐profile,
because
we
want
VMs
to
access
the
VLAN.
The
other
type
we
can
create
is
“Ethernet”.
This
type
is
only
used
for
uplink
physical
ethernet
connections.
N1kv1(config)# port-profile type vethernet VLAN105
N1kv1(config-port-prof)# switchport mode access
N1kv1(config-port-prof)# switchport access vlan 105
N1kv1(config-port-prof)# vmware port-group
N1kv1(config-port-prof)# state enabled
N1kv1(config-port-prof)# no shutdown
N1kv1(config-port-prof)#
After
the
“state
enabled”
is
typed
in.
The
port-‐group
is
applied
to
the
vCenter
server.
Next
we
need
to
change
the
uplink
port
profile
to
create
an
automatic
port-‐channel.
There
are
multiple
settings
for
this
in
the
Nexus
1000V
and
depending
on
the
deployment
you
might
choose
different
ones.
When
applied
on
a
physical
server
with
NICs
connecting
to
the
same
switch
(or
a
vPC
/
MC-LAG
configuration)
the
LACP
mode
(mode
active)
is
the
best
practice.
When
connecting
to
different
uplink
switches
this
is
not
possible
anymore.
Therefore
the
best
practice
becomes
the
“mac-‐pinning”
mode.
This
is
a
port-‐channeling
from
the
point
of
view
from
the
Nexus
1000V,
but
is
just
a
plain
Ethernet
port
from
the
uplink
switch
point
of
view.
This
is
what
we
will
configure
on
our
deployment
as
that’s
the
overall
best
practice
for
the
Nexus
1000V
deployment.
Because
there
are
no
changes
necessary
for
making
the
port-‐channel
on
the
side
of
the
Nexus
1000V.
It
will
act
just
like
a
UCS
server
and
pin
all
the
MAC
addresses
to
a
certain
uplink.
When
traffic
for
that
MAC
address
is
received
on
the
other
uplink
it
will
be
dropped.
This
is
how
the
switch
will
prevent
loops.
As
a
generic
best
practice
it’s
wise
to
always
migrate
a
single
uplink
to
the
Nexus
1000V
switch
before
moving
on.
Or
you
need
to
configure
both
uplinks
in
a
port-‐channel
right
away,
otherwise
the
ESXi
server
might
end
up
with
blocking
all
of
the
uplink
ports.
As
you
cannot
configure
the
port-‐channel
numbers,
you
will
configure
the
port-‐channel
configuration
as
automatic
on
the
uplink
port profile.
This
port-‐profile
will
be
created
as
an
Ethernet
port-profile
as
it
will
hold
physical
(or
vNICs
in
case
of
a
UCS
environment)
connections.
N1kv1(config)# port-profile type ethernet UPLINK
N1kv1(config-port-prof)# channel-group ?
auto Allocate channel-id automatically
Next
we
need
to
create
another
port-‐profile,
which
can
hold
physical
Ethernet
uplinks,
but
then
we
need
to
use
the
LACP
protocol
to
apply
to
the
uplinks.
We
will
not
be
using
this
profile
to
connect
actual
uplinks,
but
we
will
only
use
it
to
show
the
functionality.
N1kv1(config)# port-profile type ethernet UPLINK_LACP
N1kv1(config-port-prof)# switchport mode trunk
N1kv1(config-port-prof)# vmware port-group
N1kv1(config-port-prof)# state enabled
N1kv1(config-port-prof)# no shutdown
N1kv1(config-port-prof)# sw trunk allowed vlan all
2013 Mar 11 10:33:54 N1kv1 %PORT-PROFILE-1-VLAN_CONFIGURED_CONTROL_VLAN:
Port-profile is configured to carry the control VLAN 2002. Also configure
the vlan as system VLAN in this port-profile and other uplink port-
profiles that are configured to carry the VLAN for VSM-VEM traffic.
2013 Mar 11 10:33:54 N1kv1 %PORT-PROFILE-1-VLAN_CONFIGURED_PACKET_VLAN:
Port-profile is configured to carry the packet VLAN 2001. Also configure
the VLAN as system VLAN in this port-profile and other uplink port-
profiles that are configured to carry the VLAN for VSM-VEM traffic.
N1kv1(config-port-prof)# system vlan 2000-2002
N1kv1(config-port-prof)# channel-group auto mode ?
active Set channeling mode to ACTIVE
on Set channeling mode to ON
passive Set channeling mode to PASSIVE
Now
we
allow
VLANs
over
500
and
exclude
all
the
reserved
VLANs.
The
next
task
is
to
create
another
uplink
port
profile
allowing
Standard
VLANs.
This
means
we
only
use
VLAN 1
to
1005.
Above
1005
the
VLANs
fall
in
the
Extended
range.
As
explained
earlier,
port-‐channels
can
also
be
connected
to
switches
running
CDP.
Based
on
the
CDP
information
multiple
port-‐channels
are
generated
when
uplinks
are
connected
to
different
switches.
N1kv1(config-port-prof)# port-profile type ethernet UPLINK_CDP
N1kv1(config-port-prof)# switchport mode trunk
N1kv1(config-port-prof)# sw trunk allowed vlan 1-1005
N1kv1(config-port-prof)# vmware port-group
N1kv1(config-port-prof)# state enabled
N1kv1(config-port-prof)# no shut
N1kv1(config-port-prof)# channel-group auto mode on ?
<CR>
mac-pinning Sub group type mac-pinning
sub-group Choose type cdp or manual
Next
we
should
create
a
profile,
which
allows
hosts
in
a
VLAN
to
access
the
network
and
to
allow
iSCSI multi-pathing.
N1kv1(config)# port-profile type vethernet VLAN505
We
first
configure
the
profile
to
contain
hosts,
just
as
an
access
port
on
a
normal
Ethernet
switch.
Besides
that
we
enable
the
capability
to
support iSCSI
multi-‐pathing.
The
next
task
is
that
DVportIDs
should
be
removed
when
a
server
is
shutdown.
Changing
the
port-‐binding
setting
does
this.
N1kv1(config-port-prof)# port-binding ?
dynamic Port is connected when VM is powered on and disconnected when
powered off. Max-port limits are enforced
ephemeral Port is created when VM is powered on and destroyed when
powered off. Max-port limits are not enforced
static Port is always connected. Max-port limits are enforced
Before
the
port-‐binding
can
be
changed
you
have
to
remove
the
VMware
associations
first,
as
the
system
warns
you
for.
After
the
removal
you
can
re-‐add
it
and
the
port-profile
will
be
added
to
vCenter
again.
The
“auto”
keyword
is
the
trigger
to
automatically
expand
the
maximum
number
of
ports
in
the
profile,
as
the
next
question
asks.
Finally
in
this
task
we
create
a
port-‐profile
without
configuring
the
VLAN.
It’s
another
profile
for
the
same
VLAN.
This
means
we
can
inherit
the
already
configured
profile.
N1kv1(config-port-prof)# port-profile type vethernet VLAN105_2
N1kv1(config-port-prof)# inherit port-profile ?
WORD Enter the name of the profile
To
finish
the
task
we
need
to
take
flow
records
from
this
second
profile
based
on
the
number
of
packets
per
second
that
is
going
over
the
port-profiles.
This
is
done
by
configuring
the
NetFlow
feature
on
the
Nexus
1000V.
This
works
the
same
as
on
the
Nexus
platform
for
the
physical
switches.
We
first
need
to
configure
a
record
to
collect
the
amount
of
packets
per
second,
in
this
example
we
use
64-bit counters
instead
of
32-bit,
which
could
run
out
in
10Gbps
links.
The
question
did
not
state
what
to
specify
so
any
answer
would
be
fine.
N1kv1(config)# feature netflow
Do
not
forget
to
enable
the
NetFlow
feature.
Some
commands
are
available
when
the
feature
is
not
yet
configured,
but
the
configured
commands
would
not
work
without
the
enabling
of
the
feature
itself.
N1kv1(config)# flow ?
exporter Define a Flow Exporter
monitor Define a Flow Monitor
record Define a Flow Record
N1kv1(config-flow-record)# collect ?
counter Counters to collect
timestamp Timestamp fields
transport Transport layer fields
N1kv1(config-flow-monitor)# record ?
WORD Name of record (Max Size 63)
netflow Traditional NetFlow collection schemes
netflow-original Traditional IPv4 input NetFlow with origin ASs
N1kv1(config-flow-monitor)# record ?
WORD Name of record (Max Size 63)
netflow Traditional NetFlow collection schemes
netflow-original Traditional IPv4 input NetFlow with origin ASs
N1kv1(config-cmap-qos)# match ip ?
rtp Real Time Protocol
We
specify
the
whole
port
range
of
the
Voice
traffic
so
we
match
all
the
RTP
traffic.
Now
we
matched
the
correct
traffic
and
now
we
should
continue
by
creating
a
policy
in
the
3-‐
step
architecture
of
the
Modular QoS Configuration (MQC).
N1kv1(config)# policy-map type qos PM_VLAN105
N1kv1(config-pmap-qos)# class ?
VOICE Class map name
class-default (no abbrev) System default class matching otherwise
unclassified packets
type Specify the type of class
Now
our
first
question
is
finished
and
we
can
continue
with
the
input
classification
from
the
uplinks.
Here
we
assume
that
the
traffic
is
already
classified
and
now
needs
to
be
classified
correctly
inside
of
the
Nexus
1000V.
The
question
specifically
mentions
Voice
data
traffic,
because
signaling
traffic
typically
has
a
different
marking.
In
this
task
we
are
only
looking
for
the
data
traffic
which
is
marked
with
an
802.1p
value
of
“5”.
Signaling
traffic
uses
a
marking
of
“4”.
N1kv1(config-port-prof)# class-map type qos VOICE_801P
N1kv1(config-cmap-qos)# match cos ?
<0-7> List of class-of-service values
Now
this
policy
needs
to
be
applied
to
all
the
uplink
profiles
as
we
don’t
know
yet
which
profile
all
the
different
hosts
will
use.
N1kv1(config)# show port-profile | in UPLINK
port-profile UPLINK
port-group: UPLINK
port-profile UPLINK_CDP
port-group: UPLINK_CDP
port-profile UPLINK_LACP
port-group: UPLINK_LACP
We
first
look-‐up
all
the
different
profiles
which
are
used
for
uplinks.
It’s
recommended
to
do
this
check,
because
there
might
be
other
profiles
already
pre-‐configured
when
you
step
into
the
CCIE
lab
exam,
on
which
you
might
forget
to
apply
your
policy
to.
N1kv1(config)# port-profile type ethernet UPLINK
N1kv1(config-port-prof)# service-policy type qos input PM
PM_UPLINK_INPUT PM_VLAN105
N1kv1(config-port-prof)# service-policy type qos input PM_UPLINK_INPUT
N1kv1(config-port-prof)# port-profile type ethernet UPLINK_CDP
N1kv1(config-port-prof)# service-policy type qos input PM_UPLINK_INPUT
N1kv1(config-port-prof)# port-profile type ethernet UPLINK_LACP
N1kv1(config-port-prof)# service-policy type qos input PM_UPLINK_INPUT
N1kv1(config-port-prof)#
Now
all
the
Voice
traffic
coming
in
to
the
switch
is
marked
to
the
correct
QOS-‐group
mapping
inside
of
the
switch.
Next
the
correct
mapping
needs
to
be
done
when
traffic
is
leaving
the
switch
through
the
uplinks.
Here
we
can
rely
on
our
previously
set
QOS-‐group
configuration.
N1kv1(config)# class-map typ qos VOICE_QOS
N1kv1(config-cmap-qos)# match qos-group 5
N1kv1(config-cmap-qos)# exit
The
question
states
that
not
only
the
CoS
value
needs
to
be
set,
but
also
the
correct
DiffServ
marking.
We
set
the
EF
value,
we
could
have
also
set
the
decimal
value
of
46,
which
equals
to
EF.
Now
we
have
set
the
correct
802.1p
or
CoS
marking
on
all
outgoing
traffic
leaving
the
uplinks.
Next
we
need
to
ensure
that
the
Voice
traffic
will
never
cross
a
certain
limit,
when
it
goes
over
it’s
limit
by
70%,
meaning
it
carries
70%
more
traffic
than
the
maximum
of
50 Mbps,
the
traffic
should
be
marked
with
best-‐effort
(CoS
0).
Above
a
double
throughput
(100%
oversubscription)
the
traffic
should
be
dropped.
This
can
be
done
in
the
same
policy
as
where
the
CoS
mapping
is
set.
N1kv1(config)# policy-map type qos UPLINK_OUTPUT
N1kv1(config-pmap-qos)# class VOI
VOICE VOICE_801P VOICE_QOS
N1kv1(config-pmap-qos)# class VOICE_QOS
N1kv1(config-pmap-c-qos)# police ?
<1-80000000000> Committed Information Rate value in bps/kbps/mbps/gbps
cir Specify committed information rate
percent Specify rate as percentage of interface data-rate
Now
our
final
question
of
this
task
is
to
configure
queuing
inside
the
Nexus
1000V.
Here
we
need
to
ensure
that
control-plane protocols
of
the ESX(i)
host
itself
is
always
given
a
bandwidth
guarantee.
The
Nexus
1000V
has
some
special
feature
that
it
can
recognize
the
protocols
that
ESXi
use
and
that
the
Nexus
1000V
itself
uses
for
easy
matching
and
easy
queuing
configuration.
The
type
of
class-‐map
uses
the
queuing
configuration.
Within
this
configuration
it
allows
for
configuration
of
all
the
different
protocols
that
the
Nexus
1000V
can
recognize.
N1kv1(config)# class-map type queuing ?
match-all Logical-AND all match statements under this classmap
match-any Logical-OR all match statements under this classmap
In
our
case
we
configure
the
different
protocols
related
to
the
Nexus
1000V.
We
configured
the
class-map of
being
a
type
of
any,
because
it
should
match
all
of
them,
but
cannot
match
all
of
them
at
the
same
time.
Next
we
configure
a class-map
for
the
Storage
protocols
and
one
for
the
VMware
management
protocols.
N1kv1(config-cmap-que)# class-map type queuing match-any STORAGE
N1kv1(config-cmap-que)# match protocol vmw_nfs
N1kv1(config-cmap-que)# match protocol vmw_iscsi
N1kv1(config-cmap-que)#
N1kv1(config-cmap-que)# class-map type queuing match-any VMWARE
N1kv1(config-cmap-que)# match protocol vmw_ft
N1kv1(config-cmap-que)# match protocol vmw_mgmt
N1kv1(config-cmap-que)# match protocol vmw_vmotion
N1kv1(config-cmap-que)#
Now
we
create
our
policy-map
to
create
the
scheduling
of
the
protocols.
N1kv1(config)# policy-map type queuing PM_QUEUE_UPLINK
N1kv1(config-pmap-que)# class ?
type Specify the type of class
N1kv1(config-pmap-c-que)# bandwidth ?
percent Percentage of available bandwidth
We
specify
the
bandwidth
as
stated
in
the
question
that
we
want
to
guarantee
for
the
traffic.
It
doesn’t
mean
it’s
always
reserved
for
that
traffic,
but
when
there
is
congestion
on
the
link
it’s
guaranteed.
N1kv1(config-pmap-c-que)# exit
N1kv1(config-pmap-que)# class type queuing STORAGE
N1kv1(config-pmap-c-que)# bandwidth percent 30
N1kv1(config-pmap-c-que)# class type queuing VMWARE
N1kv1(config-pmap-c-que)# bandwidth percent 30
N1kv1(config-cmap-que)# match ?
cos IEEE 802.1Q class of service
protocol Protocol
N1kv1(config-pmap-c-que)# bandwidth ?
percent Percentage of available bandwidth
As
a
final
step
we
configure
this
policy
on
all
of
the
uplink
profiles,
because
the
question
stated
that
the
“uplink bandwidth”
is
reserved.
Task
4:
Network
Monitoring
The
monitoring
of
network
traffic
is
also
a
unique
capability
of
the
Nexus
1000V.
This
monitoring
feature
is
all
about
creating
SPAN
sessions.
The
technology
used
here
is
based
on
either
local
SPAN,
by
copying
traffic
from
one
VM
to
another
VM
where
a
traffic
analyzer/sniffer
is
running.
The
other
feature
is
that
you
can
use
ERSPAN,
where
traffic
is
copied
onto
a
GRE
tunnel
outside
of
the
Nexus
1000V.
N1kv1(config)# port-profile type vethernet SPAN
N1kv1(config-port-prof)# vmware port-group
N1kv1(config-port-prof)# state enabled
N1kv1(config-port-prof)# no shutdown
N1kv1(config-port-prof)# exit
We
first
created
a
port-profile
where
the
traffic
will
be
sent.
The
profile
does
not
need
to
have
a
VLAN
connected,
because
it
will
just
receive
the
traffic
from
the
VLAN.
N1kv1(config)# monitor session ?
<1-64>
all All sessions
<CR>
, Multi range separator
- Range separator
both Both
rx Ingress
tx Egress
We
do
not
need
to
apply
the
profile
to
any
VM
as
that
would
be
a
role
for
the
VMware
administrators
to
which
we
do
not
have
access
to
inside
the
CCIE Data Center
lab
exam.
Next
we
are
configuring
a
ERSPAN
session
where
traffic
is
sent
to
a
layer
3
address.
N1kv1(config)# monitor session 2 ?
<CR>
, Multi range separator
- Range separator
shutdown Shut the selected session
type Specify a session type
N1kv1(config-erspan-src)# source ?
interface Configure interfaces
port-profile Port profile name
vlan Vlan type
N1kv1(config-erspan-src)# destination ip ?
A.B.C.D
N1kv1(config-erspan-src)# erspan-id 2
The
ERSPAN
session
will
only
come
online
when
the
ID’s
match.
The
ID
on
the
source
and
the
destination
has
to
match.
N1kv1(config-erspan-src)# ip ?
dscp Set the IP DSCP value
prec Set the IP presedence value
ttl Set the IP time-to-live value
N1kv1(config-erspan-src)# ip dscp ?
<0-63>
N1kv1(config-erspan-src)# ip prec 3
We
need
to
ensure
that
the
traffic
is
sent
with
high
priority.
It’s
not
very
important
which
priority
it
gets
as
long
as
the
priority
is
high
as
the
question
did
not
state
which
exact
priority
should
be
given.
N1kv1(config-erspan-src)# mtu ?
<50-9000>
Finally
we
configure
the
MTU
of
the
SPAN
session,
so
all
packets
that
are
captured
have
an
MTU
of
1100
bytes.
The
rest
of
the
packet
when
it’s
longer,
will
be
truncated.
N1kv1(config-erspan-src)# no shutdown
N1kv1(config-erspan-src)# exit
To
verify
the
configuration
has
been
applied
successfully
we
check
the
configuration.
N1kv1(config)# show monitor session 2
session 2
---------------
type : erspan-source
state : down (No operational src/dst)
source intf :
rx :
tx :
both :
source VLANs :
rx :
tx :
both :
source port-profile :
rx : VLAN105
tx : VLAN105
both : VLAN105
filter VLANs : filter not specified
destination IP : 10.198.0.11
ERSPAN ID : 2
ERSPAN TTL : 64
ERSPAN IP Prec. : 3
ERSPAN DSCP : 0
ERSPAN MTU : 1100
ERSPAN Header Type: 2
N1kv1(config)#
Finally
we
need
to
make
sure
that
our
collected
flow
information
is
exported
to
a
correct
server.
N1kv1(config)# flow exporter EXPORT
N1kv1(config-flow-exporter)# ?
description Provide a description for this Flow Exporter
destination Specify the destination address
dscp Optional DSCP
no Negate a command or set its defaults
source Source Interface for this destination
transport Transport Destination Port
version Specify the export version
end Go to exec mode
exit Exit from command interpreter
pop Pop mode from stack or restore from name
push Push current mode to stack or save it under name
where Shows the cli context you are in
N1kv1(config-flow-exporter)# destination ?
A.B.C.D Destination IP address for collector
A:B::C:D Destination IPv6 address for collector
N1kv1(config-flow-monitor)# exporter ?
WORD Name of exporter (Max Size 63)
This
finishes
the
configuration
of
the
task
about
monitoring
and
creating
SPAN
sessions.
Finally
we
now
export
our
flow
information,
which
is
also
related
to
related
monitoring.
Task
5:
Management
Protocols
Another
important
topic
of
the
configuration
of
a
Nexus
1000V
switch
is
the
configuration
of
the
management
protocols.
This
means
the
reachability
of
the
switch
from
the
management
domain
of
a
company.
The
configuration
is
similar
to
how
this
is
done
on
any
other
NX-‐OS
based
switch.
When
you
already
configured
this
during
your
lab
attempt
and
the
questions
look
similar
to
those
ones
it’s
easily
possible
to
copy
and
paste
the
configuration.
In
our
case
we
will
run
through
the
configuration
again
on
the
Nexus
1000V.
The
first
question
in
the
task
indicates
that
we
are
configuring
SNMP
related
configuration.
There
is
one
important
difference
between
IOS
and
NX-‐OS
and
that
is
that
SNMP version 3
is
by
default
enabled
on
the
device.
This
is
done,
because
the
Data Center Network
Manager (DCNM) uses
SNMP v3
to
communicate
with
the
Nexus
switches.
When
you
create
a
user-‐account
the
device
automatically
creates
a
SNMP
version 3
user
account,
making
it
possible
to
log-‐in
using
SNMPv3
as
well.
Still
NX-‐OS
is
compatible
with
SNMPv2c,
because
the
entire
world
is
still
using
it
to
manage
their
networks.
We
start
by
configuring
the
classical
SNMP
environment
for
our
switch.
N1kv1(config)# snmp-server host ?
A.B.C.D|A:B::C:D|WORD IPv4 or IPv6 address or DNS Name of SNMP
notification host
Ensure
traps
are
sent
to
the
host
as
the
question
stated.
N1kv1(config)# snmp-server host 172.16.100.110 traps version ?
1 Use SNMPv1
2c Use SNMPv2c
3 Use SNMPv3
We
also
need
to
configure
the
version
at
which
the
traps
should
be
send.
In
this
case
we
will
be
using
the
Version 2c.
N1kv1(config)# snmp-server host 172.16.100.110 traps version 2c IPexpert
N1kv1(config)# snmp-server enable traps ?
<CR>
aaa Module notifications enable
bridge Enable SNMP STP Bridge MIB traps
callhome Module notifications enable
cfs Module notifications enable
config Module notifications enable
entity Module notifications enable
fcdomain Module notifications enable
fcns Module notifications enable
fcs Module notifications enable
fctrace Module notifications enable
fdmi Module notifications enable
feature-control Module notifications enable
fspf Module notifications enable
license Module notifications enable
link Module notifications enable
rf Module notifications enable
rmon Module notifications enable
rscn Module notifications enable
scsi Module notifications enable
snmp Module notifications enable
stpx Enable SNMP STPX MIB traps
sysmgr Module notifications enable
upgrade Module notifications enable
vsan Module notifications enable
vtp Module notifications enable
zone Module notifications enable
Before
the
switch
will
actually
send
traps.
They
need
to
be
enabled
first.
By
default
the
switch
will
not
send
any
traps,
so
then
the
question
would
not
be
answered
correctly.
Ensure
that
traps
are
enabled
when
is
stated
in
the
question
that
a
server
needs
to
receive
traps.
It’s
not
only
the
possibility,
but
it
actually
needs
to
receive
them.
In
this
case
we
enable
all
the
possible
traps.
The
next
question
specifies
that
the
server
should
also
be
able
to
access
the
switch
via
a
specific
community
string.
N1kv1(config)# snmp-server community ?
WORD SNMP community string (Max Size 32)
Read
the
question
carefully
as
it
clearly
specified
that
the
server
should
be
able
to
‘read’
information.
So
we
can
configure
the
read-only
feature
here.
The
server
is
now
able
to
access
the
switch
to
read
out
all
information
and
it
will
receive
traps.
The
next
questions
are
related
to
some
contact
information,
which
is
used
in
management
systems
to
identify
devices
based
on
their
location.
It’s
a
free
text
format,
so
you
can
fill
out
anything
you
like.
N1kv1(config)# snmp-server location Utrecht, Netherlands, Europe
N1kv1(config)# snmp-server ?
aaa-user Set duration for which aaa-cached snmp user exists
community Set community string and access privs
contact Modify sysContact
context SNMP context to be mapped
enable Enable SNMP Traps
globalEnforcePriv Globally enforce privacy for all the users
host Specify hosts to receive SNMP notifications
location Modify sysLocation
mib Mib access parameters
protocol Snmp protocol operations
source-interface Source interface to be used for sending out SNMP
notifications
tcp-session Enable one time authentication for snmp over tcp
session.
user Define a user who can access the SNMP engine
As
the
next
question
states,
we
want
the
switch
to
enforce
encryption
for
SNMPv3
traffic.
One
of
the
biggest
complaints
about
SNMPv1
and
SNMPv2c
is
that
it
has
no
support
for
any
authentication
other
than
the
community
strings
and
that
it
has
no
support
for
encryption.
SNMPv3
offers
all
of
that,
but
it’s
not
required
by
default.
With
a
single
command
we
can
turn
the
switch
so
it
will
only
accept
encrypted
SNMPv3
requests.
N1kv1(config)# snmp-server ?
aaa-user Set duration for which aaa-cached snmp user exists
community Set community string and access privs
contact Modify sysContact
context SNMP context to be mapped
enable Enable SNMP Traps
globalEnforcePriv Globally enforce privacy for all the users
host Specify hosts to receive SNMP notifications
location Modify sysLocation
mib Mib access parameters
protocol Snmp protocol operations
source-interface Source interface to be used for sending out SNMP
notifications
tcp-session Enable one time authentication for snmp over tcp
session.
user Define a user who can access the SNMP engine
We
then
should
configure
a
user
for
SNMPv3
with
rights.
Now
here
is
an
overlap
with
the
RBAC
configuration
as
SNMPv3
uses
roles
from
RBAC
to
give
access
to
what
the
management
device
can
access.
When
you
create
a
username,
the
switch
will
automatically
create
an
SNMPv3
username
with
the
same
rights
as
well.
You
can
individually
delete
the
SNMPv3
usernames
when
you
like,
but
it’s
not
possible
to
turn
it
off
that
the
user
is
automatically
created
in
the
first
place.
When
an
SNMPv3
user
is
created
it
also
works
vice
versa.
It
will
automatically
create
a
user-‐
account
as
well.
N1kv1(config)# snmp-server user ?
WORD Name of the user (Max Size 32)
Finally
the
user
should
be
given
the
same
rights
as
a
currently
existing
user
role.
Now
at
first
it
seems
strange
where
to
configure
this,
but
the
roles
are
called
groups
in
this
configuration.
You
should
use
normal
role
names
as
the
group
name
in
this
user
configuration.
After
which
it
will
take
over
the
rights
the
user
has
and
work
as
the
question
stated.
Now
we
finished
the
part
for
configuring
SNMP
related
configurations.
We
can
verify
if
everything
is
configured
at
is
should.
N1kv1(config)# show snmp ?
<CR>
> Redirect it to a file
>> Redirect it to a file in append mode
community Show snmp community strings
context Show snmp context mapping entries
engineID Show snmp engineID
______________________________________________________________
NOTIFICATION TARGET USERS (configured for sending V3 Inform)
______________________________________________________________
Here
it’s
shown
that
all
the
users
that
have
a
regular
user
account
are
also
configured
as
SNMPv3
users.
N1kv1(config)# show snmp host
-------------------------------------------------------------------
Host Port Version Level Type SecName
-------------------------------------------------------------------
172.16.100.110 162 v2c noauth trap IPexpert
Here
you
can
verify
which
servers
receive
the
traps
that
the
switch
sends.
N1kv1(config)# show snmp community
Community Group / Access context acl_filter
--------- -------------- ------- ----------
IPexpert network-operator
N1kv1(config)#
Finally
you
can
verify
which
SNMP
communities
are
configured
on
the
switch
and
how
they
are
operating.
The
next
management
protocol
that
we
will
be
configuring
is
the
Syslog
protocol.
This
protocol
is
used
for
troubleshooting
and
debug
messages
and
not
so
much
for
alarming.
For
alarming
SNMP
traps
are
used
and
Syslog
is
used
mostly
during
troubleshooting
processes.
There
are
several
levels
of
message
priority
you
are
able
to
see
and
which
you
are
able
to
process
in
separate
log
files
when
desired.
There
are
7 levels
of
syslog
priorities.
0: Emergency
1: Alert
2: Critical
3: Error
4: Warning
5: Notification
6: Informational
7: Debugging
All
messages
that
the
system
can
give
have
a
priority
attached.
Usually
up
to
level 4
is
shown
as
errors
of
the
system.
Level 5
and
level 6
are
messages
related
to
processes
that
perform
actions.
For
example
an
OSPF
neighbor
comes
online.
When
a
neighbor
goes
down,
it’s
possibly
an
error
so
this
get’s
a
higher
priority.
Level 7
is
only
used
for
debug
messages
and
is
therefore
never
shown.
In
IOS
they
were
always
shown
on
the
Console
port,
but
this
could
cause
serious
issues
as
every
console
character
had
impact
on
the
CPU.
Therefore
in
NX-‐OS
this
has
been
disabled
and
you
need
to
turn
logging
for
debugging
specifically
on.
By
default
the
following
levels
of
logging
are
enabled.
The
logging
monitor
is
the
logging,
which
is
shown
in
Telnet
and
SSH
sessions.
N1kv1(config)# show logging
Currently
it’s
not
even
supported
to
raise
the
logging
level
of
the
console,
without
having
changed
the
console
speed
itself.
N1kv1(config)# logging console 6
With
the
question
mark
it’s
verifiable
which
level
should
be
configured
on
the
logging
level.
N1kv1(config)# show logging
Now
the
informational
messages
are
logged
in
Telnet
and
SSH
sessions.
The
next
question
states
that
debugging
messages
should
be
logged
into
a
logfile.
N1kv1(config)# logging ?
abort Flushes cached data without committing and releases the lock
commit Commits cached data (of all msg types) and releases the lock
console Set console logging
distribute Enables/disables fabric distribution using cfs.
event Interface events
level Facility parameter for syslog messages
logfile Set File logging
message Interface events
module Set module logging
monitor Set terminal line(monitor) logging level
server Enable forwarding to Remote Syslog Server
timestamp Set logging timestamp granularity
We
can
configure
logfiles
in
which
we
can
enable
separate
severities
to
be
logged.
N1kv1(config)# show logging
Next
we
should
be
ensuring
that
the
log
files
are
marked
with
timestamps
that
are
very
precise.
N1kv1(config)# logging timestamp ?
microseconds Timestamp in micro-seconds
milliseconds Timestamp in milli-seconds
seconds Timestamp in seconds (Default)
We
should
specify
the
correct
level,
which
is
5
in
this
case
where
we
want
the
notifications
to
be
forwarded
to
the
server.
N1kv1(config)# logging server 172.16.100.110 5 ?
<CR>
facility Facility to use when forwarding to server
use-vrf Enter VRF name, default is default VRF
The
last
step
is
configuring
the
correct
facility
that
should
be
used.
Facilities
in
Syslog
are
used
for
grouping
messages
together
on
the
server
itself
and
have
no
technical
feature.
N1kv1(config)# logging server 172.16.100.110 5 facility local3 ?
<CR>
facility Facility to use when forwarding to server
use-vrf Enter VRF name, default is default VRF
This
finalizes
the
syslog
configuration
and
it
finalizes
the
configuration
of
management
protocols
in
this
chapter.
Task
6:
Miscellaneous
features
The
final
task
of
this
chapter
is
about
configuring
miscellaneous
features
on
the
Nexus
1000V
switch.
This
configuration
should
require
you
to
take
a
look
at
the
documentation
as
these
features
are
too
random
and
too
rarely
used
that
it
won’t
be
useful
to
remember
them
all,
although
it
always
comes
in
handy
of
course!.
The
first
feature
indicates
that
FHRP
protocols
like
HSRP
and
VRRP
should
be
supported
to
run
in
the
VM
which
is
running
on
op
of
the
Nexus
1000V.
This
comes
down
to
how
the
Nexus
1000V
treats
traffic
coming
from
the
VMs.
To
prevent
loops
the
Nexus
1000V
will
pin
a
MAC
address
to
a
certain
vEthernet
or
Ethernet
interface.
When
a
packet
destined
for
the
same
MAC
address
is
seen
on
another
port,
the
packet
is
dropped.
When
an
HSRP
failover
occurs
the
same
MAC
address
will
be
seen
on
another
VM.
Therefore
the
Nexus
1000V
will
drop
the
packet,
unless
you
configure
this
features.
This
feature
will
ensure
that
for
some
protocols
the
packet
is
inspected
and
allowed
through.
It
also
means
that
you
do
not
need
to
disable
the
whole
loop
prevention
mechanism
to
support
it.
In
this
question
we
need
to
disable
the
loop
prevention
for
FHRP
protocols.
This
means
that
we
are
configuring
the
mechanism
to
be
disabled
for
HSRP
and
VRRP.
N1kv1(config)# port-profile VLAN505
N1kv1(config-port-prof)# disable-loop-detection ?
carp Disable Loop Detection for CARP control packets
custom-rp Disable Loop Detection for a custom protocol control packets
hsrp Disable Loop Detection for HSRP control packets
vace Disable Loop Detection for vACE FT packets
vrrp Disable Loop Detection for VRRP control packets
Next
we
need
to
force
VLAN 105
to
join
a
particular
multicast
group.
This
is
a
configuration
not
done
under
the
port-profile,
but
under
the
VLAN
itself.
Finally
we
need
to
statically
specify
the
interface
that
belongs
to
module 3.
The
uplinks
we
configured
to
be
using
a
port-‐
channel.
Port-‐channels
are
created
based
on
the
order
of
coming
online.
The
first
module
which
comes
online
automatically
get’s
assigned
number 3 and
then
the
first
port-‐channel
which
is
generated
is
number 1.
N1kv1(config)# vlan 105
N1kv1(config-vlan)# ip igmp ?
snooping Configures IGMP Snooping
The
next
question
indicates
that
we
should
disable
the
multicast
security
mechanism,
which
is
enabled
by
default
on
all
the
NX-‐OS
platforms.
This
is
IGMP
snooping.
We
can
disable
this
per
VLAN.
N1kv1(config)# vlan 502
N1kv1(config-vlan)# no ip igmp snooping
N1kv1(config-vlan)# ip igmp snooping ?
<CR>
explicit-tracking Configures Explicit Host tracking for
vlan
fast-leave Configures Fast leave for the vlan
last-member-query-interval Configures interval between group-
specific Query transmissions
link-local-groups-suppression Configures Vlan link-local groups
suppression
mrouter Configures static multicast router
interface
static-group Configures static group membership
Active ports:
N1kv1(config-vlan)#
Again
another
single
command
feature
is
enabling
Jumbo
frames
on
the
Nexus
1000V.
Because
this
is
a
software
switch
it
does
not
require
complex
configuration
like
on
the
Nexus
5000
platform.
N1kv1(config)# system ?
clis Cli server
cores Copy cores to destination
default Configure system-level default values
jumbomtu Configure system jumbomtu
memory-thresholds Set memory thresholds on the card
switchover To configure switchover for system
trace To configure system trace level
With
this
configuration
we
enabled
Jumbo
MTU
on
the
VMXnet3
adapters.
All
other
drivers
within
VMware
do
not
support
larger
MTU sizes
than
1500
bytes.
Of
course
the
VMware
protocols
self
like
VMotion
and
Storage
protocols
could
support
larger
frames,
when
the
rest
of
the
network
will
support
it
as
well.
The
next
question
is
about
keeping
vEthernet
interfaces
up
and
running
when
VMs
are
powered
off
or
removed
from
the
dvSwitch.
This
configuration
could
come
in
handy
when
you
want
to
have
consistent
vEthernet
numbering
even
when
VMs
are
moved
off
from
the
dvSwitch
for
a
while.
N1kv1(config)# svs ?
connection Configure connection information
license Global License Configuration
upgrade Configure upgrade vsm information
veth Configure a virtual ethernet global policy
With
disabling
this
by
default
enabled
feature
the
Nexus
1000V
will
keep
the
vEthernet
interfaces
even
when
the
VM
is
removed
from
the
whole
switch.
The
final
question
of
the
chapter
is
about
configuring
network-state tracking.
This
single
command
feature
is
about
tracking
the
state
of
the
uplinks
of
the
Nexus
1000V.
As
soon
as
something
happens
with
the
uplinks
the
switch
will
sent
a
link-down
event
to
all
the
VMs
as
well.
Usually
this
is
not
a
best
practice,
because
some
applications
can
respond
very
strange
to
a
link
down
event
in
a
VM.
UCS
is
a
system,
which
performs
this
same
feature
and
signals
the
link
down
event
to
the
ESXi
host,
which
then
initiates
a
failover.
N1kv1(config)# track network-state ?
<CR>
interval Set timer interval at which tracking packets need to be sent
split Configure the settings for split-network mode
threshold Set max threshold value
N1kv1(config)#
With
this
final
command
we
finished
the
Nexus
1000V
chapter.
The
next
chapter
will
focus
on
the
security
features
within
the
1000V
and
giving
focus
to
the
features,
which
make
the
1000V
unique
besides
the
QoS
feature.
N1kv1(config)# cli alias name wr copy run start
N1kv1(config)# wr
[########################################] 100%
N1kv1(config)#
Take
a
short
break,
save
your
configuration
and
continue
with
the
next
chapter!
We
highly
recommend
creating
your
own
diagram
at
the
beginning
of
each
lab
so
you
are
able
to
draw
on
your
own
diagram,
making
it
much
easier
when
you
step
into
the
real
lab.
General
Rules
• Try
to
diagram
out
the
task.
Draw
your
own
connections
the
way
you
like
it
• Create
a
checklist
to
aid
as
you
work
thru
the
lab
• Take
a
very
close
read
of
the
tasks
to
ensure
you
don’t
miss
any
points
during
grading!
• Take
your
time.
This
is
not
a
Mock
Lab,
so
no
time
constraints
are
in
place
for
finishing
this
particular
chapter
Estimated
Time
to
Complete:
4
hours
Solutions
In
this
chapter
we
will
be
focusing
on
the
Security
features
of
the
Nexus
1000V.
This
will
come
down
to
very
similar
tasks
to
the
NX-‐OS
Security
features,
because
this
is
also
the
exact
same
Operating
System
which
runs
on
the
Nexus
1000V.
Task
1:
Private
VLANs
Private
VLANs
are
set-‐up
in
such
a
way
that
traffic
is
protected
between
certain
ports.
There
is
a
Primary
VLAN,
which
only
contains
the
so-‐called
Promiscuous
ports.
These
ports
can
receive
all
traffic
from
all
ports
that
are
associated
with
this
primary
VLAN.
This
means
that
the
‘client’
ports
are
in
other
VLANs
than
the
promiscuous
port.
The
secondary
VLANs
can
be
create
in
2
ways.
The
“Isolated”
and
“Community”
VLANs
are
these
2
types
of
secondary
VLANs.
The
Isolated
version
means
that
all
ports
that
are
configured
in
these
VLANs
cannot
communicate
to
each
other,
as
pointed
out
in
the
drawing
below.
Within
the
layer
2
domain
of
this
particular
VLAN,
ports
will
never
communicate
with
each
other,
but
can
only
talk
to
the
promiscuous
port
in
the
primary
VLAN,
which
they
are
associated
with.
The
second
type
is
the
Community
VLANs.
All
interfaces
in
these
VLANs
can
communicate
to
each
other
within
the
same
Community
VLAN.
This
means
that
hosts
in
different
community
VLANs
cannot
communicate
to
each
other.
Again
these
community
VLANs
are
able
to
talk
to
the
promiscuous
port
in
the
primary
VLAN,
which
they
are
associated
with.
The
drawing
below
illustrates
the
possible
(and
impossible)
traffic
flows.
The
associations
/
mappings
between
primary
and
secondary
VLANs
need
to
be
manually
configured
on
the
switch
ports.
The
final
step
is
that
it’s
also
possible
to
trunk
Private
VLANs
between
different
switches.
This
means
that
a
promiscuous
port
doesn’t
need
to
be
on
the
same
switch
as
the
host
ports.
Therefore
a
whole
isolated
section
of
your
network
can
be
created
on
different
switches.
The
promiscuous
port
doesn’t
have
to
be
a
fixed
Ethernet
port.
It’s
also
possible
to
create
a
VLAN
interface
(SVI),
which
is
the
promiscuous
port
for
that
particular
Primary
VLAN.
The
first
assignment
point
you
to
create
a
promiscuous
port
for
a
virtual 3rd party
routing appliance,
which
will
receive
all
traffic,
connected
to
Primary
VLAN
510.
As
with
all
features
within
the
NX-‐OS
platform
and
as
well
for
the
Nexus
1000V
the
Private
VLAN
feature
also
needs
to
be
activated
first,
before
any
commands
are
available
within
the
CLI.
N1kv(config)# feature private-vlan
Then
the
VLAN
needs
to
be
created
and
the
VLAN
needs
to
be
made
primary.
Which
we
do
under
the
VLAN
configuration.
N1kv(config)# vlan 510
N1kv(config-vlan)# private-vlan ?
association Configure association between private VLANs
community Configure the VLAN as community private VLAN
isolated Configure the VLAN as isolated private VLAN
primary Configure the VLAN as primary private VLAN
We
see
the
Primary
VLAN
being
created
but
without
any
ports
assigned
to
it
yet.
Next
we
ensure
that
the
routing
appliance
will
be
able
to
access
resources
and
is
assigned
to
this
VLAN.
As
the
first
comment
in
the
task
states
we
can
create
new
port-‐profiles
to
complete
questions
in
this
task,
so
we
will
create
a
new
profile
to
connect
this
routing
appliance
in
the
Private
VLAN.
N1kv1(config)# port-profile VLAN510
N1kv1(config-port-prof)# sw mode private-vlan promiscuous
N1kv1(config-port-prof)# sw acc vlan 510
N1kv1(config-port-prof)# descr "Routing appliance"
N1kv1(config-port-prof)# vmware port-group
N1kv1(config-port-prof)# state enabled
N1kv1(config-port-prof)# no shut
N1kv1(config-port-prof)#
We
don’t
have
to
create
any
mappings
yet
as
that
will
come
in
the
following
assignments.
N1kv(config)# sh vlan private-vlan
Primary Secondary Type Ports
------- --------- --------------- -------------------------------------
------
510 primary
The
next
assignment
is
a
combination
of
enabling
isolated
ports
on
the
same
switch.
Before
they
are
able
to
communicate
to
the
promiscuous
port
and
the
firewall
some
mappings
need
to
be
created.
N1kv(config)# vlan 511
N1kv(config-vlan)# private-vlan isolated
N1kv(config)# vlan 510
N1kv(config-vlan)# private-vlan association 511
N1kv(config-vlan)# exit
N1kv(config)# sh vlan private-vlan
Primary Secondary Type Ports
------- --------- --------------- -------------------------------------
------
510 511 isolated
N1kv(config)#
N1kv(config-if)# port-profile VLAN510
N1kv(config-if)# sw private-vlan ?
association Private vlan trunk association
host-association Set the private VLAN host association
mapping Set the private VLAN trunk promiscuous mapping
trunk Set the private vlan trunking configuration
After
the
creation
of
the
new
isolated
VLAN
a
mapping
needs
to
be
made
between
the
primary
and
secondary
VLANs.
This
is
done
under
the
primary
VLAN
configuration
and
under
the
promiscuous
port.
This
model
of
having
to
create
the
mapping
on
multiple
places
is
sometimes
a
bit
difficult
to
remember
every
spot
where
the
mapping
needs
to
be
done,
but
in
real
life
you
will
see
you
get
a
lot
of
flexibility
with
this
model
and
you
are
able
to
create
almost
any
topology
with
this
flexibility.
Now
the
final
step
is
to
create
the
same
mapping
on
the
isolated
host
ports.
N1kv1(config)# port-profile VLAN511
And
finally
don’t
forget
to
add
the
community
VLANs
to
the
promiscuous
port,
otherwise
they
won’t
be
able
to
communicate
with
the
firewall!.
Don’t
forget
the
‘add’
keyword
in
the
command,
otherwise
you
will
overwrite
all
current
enabled
VLANs
just
like
is
possible
with
the
trunk allowed vlan
command!
N1kv(config-if-range)# port-profile VLAN510
N1kv(config-if)# sw private mapping 510 add 512
N1kv1(config-port-prof)# sh vlan private-vlan
Primary Secondary Type Ports
------- --------- --------------- -------------------------------------
------
510 511 isolated
510 512 community
The
next
task
requires
the
use
of
so-‐called
private
VLAN
trunk
links
as
the
hosts
are
not
connected
directly
to
the
N1kv,
but
to
the
rest
of
the
network.
Private-‐VLAN
trunk
links
can
carry
traffic
for
normal
VLANs
and
private
VLANs
at
the
same
time.
The
configuration
can
be
to
transfer
primary
VLANs
to
multiple
switches
or
to
transfer
secondary
VLANs
across
multiple
switches.
In
this
task
we
configure
the
first
trunk
link
to
pass
only
primary
VLANs
as
we
want
the
rest
of
the
network
to
access
VMs,
which
are
connected
to
the
promiscuous
port.
The
N1kv
only
supports
to
transfer
Primary
VLANs
across
the
uplink
port-‐profile,
which
is
what
we
want
to
accomplish.
We
are
allowed
to
create
a
new
uplink
port-‐
profile
for
this
use.
N1kv1(config)# port-profile type ethernet UPLINK_PVLAN
N1kv1(config-port-prof)# switchport mode ?
access Port mode access
private-vlan Set port mode to private-vlan host or promiscuous or
trunk-promiscuous or trunk-isolated
trunk Port mode trunk
version 4.2(1)SV1(5.2b)
port-profile type ethernet UPLINK_PVLAN
vmware port-group
switchport mode private-vlan trunk promiscuous
switchport private-vlan trunk allowed vlan 510
switchport private-vlan mapping trunk 510 511-512
no shutdown
state enabled
N1kv1(config-port-prof)#
When
configuring
private
VLAN
trunks
you
don’t
need
to
change
the
normal
trunk allowed
vlan
command,
as
the
private
VLANs
on
the
private-vlan trunk allowed list
are
automatically
added
to
the
normal
VLAN
allowed
list.
Now
you
have
successfully
completed
task
1!
The
feature
not
only
protects
against
too
much
hosts
logging
in
to
the
same
interface,
it
also
protects
against
the
moving
of
MAC
addresses.
This
means
that
when
a
certain
host
is
learnt
or
configured
on
an
interface
and
it
is
connected
to
another
interface.
This
is
seen
as
a
violation
and
the
host
is
denied
access
or
the
interface
is
shutdown.
This
is
called
a
‘MAC Move Violation’.
This
first
question
states
that
only
10
hosts
may
be
connected
to
a
certain
port-‐profile
on
N1kv1.
The
action
that
should
be
taken
when
the
maximum
has
been
reached
is
that
the
interface
should
be
shutdown
when
another
host
is
connected.
Now
this
final
point
is
an
easy
one,
as
by
default
the
action
that
is
taken
in
case
of
a
violation
of
the
port-security
rules
is
to
shut
down
the
interface.
There
are 3
actions
that
can
be
taken
when
a
port-security
rules
are
violated.
• Shutdown
o This
action
means
that
the
interface
will
go
in
to
errdisable
state
and
the
interface
is
completely
shutdown
at
that
point.
After
it
is
re-‐enabled
it
keeps
its
port-security
configuration
without
changing
anything.
Including
the
previously
learnt
MAC
addresses.
o This
is
the
default
mode.
• Restrict
o Traffic
from
secure
MAC
addresses
is
allowed
on
the
interface,
but
traffic
from
any
unsecured
MAC
addresses
is
dropped
and
a
count
is
kept
for
the
dropped
packets
• Protect
o Traffic
from
secure
MAC
addresses
is
still
allowed,
but
the
interface
is
protected
as
MAC
address
learning
is
disabled
right
after
the
first
unsecured
MAC
address
is
seen.
This
means
that
new
MAC
addresses
are
no
longer
learnt.
Traffic
from
previously
learned
safe
MAC
addresses
can
still
pass
through
the
interface
Let’s
start
with
the
configuration
of
the
second
port-‐profile
connecting
to
VLAN
105
to
protect
it
for
10
MAC
addresses.
In
this
case
we
will
statically
configure
the
violation
again,
to
ensure
it’s
done.
Although
it’s
a
default.
You
will
never
get
points
taken
off
your
score
for
over
configuration
that
doesn’t
harm
anything
related
to
the
tasks.
N1kv1
N1kv1(config)# port-profile type vethernet VLAN105_2
N1kv1(config-port-prof)# switchport port-security
N1kv1(config-port-prof)# switchpor port-security maximum ?
<1-1025> Maximum addresses 1 to 1025
As
is
shown
in
the
show run
output.
The
violation
is
not
configured
in
the
configuration,
because
it’s
a
default.
Do
not
forget
to
enable
the
port-security
feature
by
entering
‘switchport port-
security’.
Without
this
command,
the
other
commands
related
to
it,
will
show
up
in
the
configuration,
but
the
feature
is
not
enabled
on
this
port-‐profile
and
will
not
work.
version 4.2(1)SV1(5.2b)
port-profile type vethernet VLAN105_2
inherit port-profile VLAN105
switchport port-security violation shutdown
ip flow monitor VLAN105_MONITOR input
switchport port-security
switchport port-security maximum 10
N1kv1(config-port-prof)#
With
the
following
output
you
are
able
to
check
if
it’s
correct
what
you
configured
and
what
the
current
status
of
the
connection
is.
N1kv1(config-port-prof)# do sh port-security
Total Secured Mac Addresses in System (excluding one mac per port) : 0
Max Addresses limit in System (excluding one mac per port) : 8192
--------------------------------------------------------------------------
--
Secure Port MaxSecureAddr CurrentAddr SecurityViolation Security
Action
(Count) (Count) (Count)
--------------------------------------------------------------------------
--
==========================================================================
==
N1kv1(config-port-prof)#
The
next
question
states
that
the
entries
that
are
learnt
through
this
port-‐profile
should
time-‐
out
after
a
certain
time.
By
default
when
MAC
addresses
are
learnt
through
the
interface
they
are
kept
in
the
database
forever,
as
aging
is
disabled.
You
can
change
this
behavior
by
configuring
aging.
This
can
be
done
in
two
ways.
• Absolute
o The
absolute
aging
removes
a
MAC
address
after
a
certain
amount
of
time.
After
the
MAC
address
has
been
learnt,
the
switch
starts
the
timer
and
after
the
configured
amount
of
time,
it
deletes
the
entry
from
the
database.
• Inactivity
o After
the
last
packet
received
from
the
MAC
address.
The
switch
starts
a
timer,
when
after
it
expires
the
MAC
address
is
deleted
from
the
database.
When
a
new
packet
is
received
from
the
host,
the
timer
is
reset
again.
The
question
states
that
the
MAC
address
entry
should
be
removed
after
inactivity
for
6
minutes.
This
means
we
are
going
to
use
this
option
for
aging
under
the
port-‐profile.
N1kv1
N1kv1(config)# port-profile type vethernet VLAN105_2
N1kv1(config-port-prof)# switchport port-sec aging ?
time Port-security aging time
type Type of timers
After
configuring
the
aging,
you
will
see
it
is
applied
to
the
interface.
Notice
that
this
command
can
only
be
executed
when
there
is
an
active
VM
running
on
the
port-‐profile.
N1kv1(config-port-prof)# sh port-sec int vethernet123
Configured Port Security : Enabled
Opertional Port Security : Enabled
Port Status : Secure Down
Violation Mode : Shutdown
Aging Time : 6 mins
Aging Type : Inactivity
Maximum MAC Addresses : 10
Total MAC Addresses : 0
Configured MAC Addresses : 0
Sticky MAC Addresses : 0
Security violation count : 0
N1kv1(config-if)#
The
next
question
asks
to
configure
port-security
on
another
port-‐profile
with
statically
configured
MAC
addresses.
As
soon
as
you
configure
the
static
MAC
addresses
you
should
not
forget
to
also
put
on
the
maximum
number
of
MAC
addresses.
When
you
do
not
configure
the
maximum
amount,
the
interface
will
keep
learning
MAC
addresses
indefinitely.
N1kv1
N1kv1(config)# port-profile type vethernet VLAN505
N1kv1(config-port-prof)# switchport
N1kv1(config-port-prof)# switchport port-security
N1kv1(config-port-prof)# switchport port-security maximum 5
N1kv1(config-port-prof)# switchport port-security mac-address ?
E.E.E 48 bit mac address format HHHH.HHHH.HHHH (Option 1)
EE-EE-EE-EE-EE-EE 48 bit mac address format HHHH.HHHH.HHHH (Option 2)
EE:EE:EE:EE:EE:EE 48 bit mac address format HHHH.HHHH.HHHH (Option 3)
EEEE.EEEE.EEEE 48 bit mac address format HHHH.HHHH.HHHH (Option 4)
sticky Sticky MAC address
Do
not
forget
to
enable
the
port-security
feature
on
the
interface
itself,
otherwise
it
will
not
work.
Notice
that
the
workbook
specifies
the
MAC
addresses
very
differently.
You
can
also
specify
the
MAC
addresses
in
very
different
ways
so
use
the
method
that
you
like
the
most.
After
configuring
the
5
MAC
addresses
statically
we
verify
that
configuration
is
applied.
N1kv1(config-port-prof)# show port-security
Total Secured Mac Addresses in System (excluding one mac per port) : 4
Max Addresses limit in System (excluding one mac per port) : 8188
--------------------------------------------------------------------------
--
Secure Port MaxSecureAddr CurrentAddr SecurityViolation Security
Action
(Count) (Count) (Count)
--------------------------------------------------------------------------
--
==========================================================================
==
Then
we
are
asked
to
configure
an
action
after
violating
packets
are
received.
As
previously
explained.
This
means
that
we
will
be
using
the
‘restrict’
action,
as
this
is
the
only
action
that
will
keep
the
interface
up,
but
keeps
a
packet
count
of
all
violating
packets.
Which
is
what
the
question
asks
for.
N1kv1
N1kv1(config)# port-profile type vethernet VLAN505
N1kv1(config-if)# switchport port-security violation restrict
N1kv1(config-if)#
The
next
question
is
a
tricky
one
as
we
are
asked
to
allow
5
specific
MAC
addresses
on
an
uplink
port-‐profile.
The
problem
is
that
we
cannot
use
the
port-‐security
features
on
uplink
port-‐
profiles
on
the
Nexus
1000V.
Therefore
we
need
to
come
up
with
a
more
creative
solution.
We
can
accomplish
our
goal
using
the
MAC
ACL
feature.
N1kv1(config)# port-profile type ethernet UPLINK_PVLAN
N1kv1(config-port-prof)# switchport ?
N1kv1(config-port-prof)#
Above is shown that the port-‐security feature is not available on uplink port-profiles.
N1kv1(config-mac-acl)# permit ?
E.E.E Source MAC address (Option 1)
EE-EE-EE-EE-EE-EE Source MAC address (Option 2)
EE:EE:EE:EE:EE:EE Source MAC address (Option 3)
EEEE.EEEE.EEEE Source MAC address (Option 4)
any Any source address
After
creating
the
access-‐list
we
can
apply
it
to
the
Private VLAN uplink port-profile.
N1kv1(config-port-prof)# port-profile type ethernet UPLINK_PVLAN
N1kv1(config-port-prof)# mac ?
port Port policy
Now
we
have
protected
our
uplink
profile
to
only
5
source
MAC
addresses
where
the
MAC
ACL
denies
all
other
addresses.
Next
up
is
the
configuration
of
the
port-profile
for
VLAN
514
on
N1kv1.
We
should
only
allow
up
to
25
MAC
addresses
on
this
interface
before
denying
access
to
new
ones
and
protecting
the
interface
by
stopping
the
MAC
address
learning
feature.
This
means
that
we
will
be
using
the
protect
action
after
a
violation
of
the
port-security
rules.
When
you
read
ahead
on
the
questions,
you
see
that
the
interface
should
automatically
‘remember’
all
MAC
addresses
that
are
received.
This
feature
basically
means
that
we
want
all
MAC
addresses
received
on
the
uplink port-profile
to
be
statically
configured,
except
we
don’t
want
to
configure
them
statically.
This
feature
is
called
‘sticky’.
When
a
MAC
address
is
learnt
and
this
feature
is
enabled,
it
is
automatically
saved
into
the
port-security database
and
never
aged
out.
We
start
with
the
configuration
on
the uplink port-profile.
N1kv1
N1kv1(config-port-prof)# port-profile type vethernet VLAN514
N1kv1(config-port-prof)# sw mode acc
N1kv1(config-port-prof)# sw acc vlan 514
N1kv1(config-port-prof)# vmware port-group
N1kv1(config-port-prof)# state enabled
N1kv1(config-port-prof)# no shutdown
N1kv1(config-port-prof)# switch port-security
N1kv1(config-port-prof)# switch port-sec max 25
N1kv1(config-port-prof)# sw port-sec violation protect
Now
we
configured
the
basic
security,
but
we
also
want
the
feature
enabled
to
save
the
MAC
addresses
automatically
into
the
port-security
database.
N1kv1
N1kv1(config-port-prof)# switchport port-security mac-address sticky
Now
after
the
configuration
we
see
that
the
maximum
is
correctly
configured
and
that
the
interface
is
already
learning
port-security
entries.
N1kv1(config-port-prof)# show run port-profile VLAN514
version 4.2(1)SV1(5.2b)
port-profile type vethernet VLAN514
vmware port-group
switchport mode access
switchport access vlan 514
switchport port-security
switchport port-security maximum 25
switchport port-security violation protect
switchport port-security mac-address sticky
no shutdown
state enabled
N1kv1(config-port-prof)#
After
the
configuration
we
verify
the
configuration
and
check
all
our
previous
configuration.
Now
we
finished
Task 2
and
we
will
continue
with
other
various
security
features.
Task
3:
DHCP
Snooping,
DAI,
IP
Source
Guard
The
features
discussed
in
this
chapter
are
all
used
in
conjunction
with
each
other.
They
all
use
the
same
database
to
perform
their
function.
It
all
comes
down
that
we
want
to
secure
the
switch
against
Layer
2
and
Layer
3
spoofing
attacks.
Because
most
hosts
in
a
network
are
using
DHCP
to
get
their
IP
address
it’s
very
easy
to
create
a
Layer 2 to Layer 3 mapping
on
the
switch
to
verify
a
correctness
of
the
traffic
coming
in.
When
you
are
enabling
DHCP
snooping
on
a
switch,
it
means
that
by
default
all
interfaces
are
seen
as
untrusted
and
the
only
packets
that
are
allowed
in
are
DHCP
REQUEST
packets
from
hosts.
You
can
then
enable
certain
interfaces
to
become
trusted,
which
means
that
you
are
allowing
DHCP
servers
to
be
connected
through
those
interfaces.
Be
aware
when
using
this
in
a
production
network
that
the
maximum
number
of
bindings
that
can
be
kept
on
a
Nexus
switch
is
2000.
One
other
option
what
the
DHCP
Snooping
feature
is
able
to
do,
except
for
securing
the
switch.
Is
that
it
can
insert
an
Option 82 field
in
the
DHCP
packet.
This
field
is
used
to
identify
the
user,
which
is
accessing
the
DHCP
server.
Based
on
the
connected
VLAN
and
Port
number
you
might
get
another
address
assigned
from
the
DHCP
server.
Although
this
is
usually
only
seen
in
Service
Provider
environments,
it
can
be
interesting
when
you
need
this
feature.
The
DHCP
Snooping
feature
needs
to
be
enabled
globally
and
second
it
needs
to
be
enabled
on
certain
VLANs.
Let’s
first
configure
the
DHCP
snooping
feature.
N1kv1
N1kv1(config)# feature dhcp
N1kv1(config)# ip dhcp snooping ?
<CR>
information DHCP Snooping information
verify DHCP snooping verify
vlan DHCP Snooping vlan
The
DHCP
snooping
feature
is
enabled
on
VLAN 105
and
the
DHCP
server
uses
the
newly
created
profile
on
VLAN
105
for
receiving
DHCP
Offer
messages.
Don’t
forget
to
configure
the
port
within
the
VLAN
as
the
question
states
that
the
DHCP
server
is
a
VM
connected
to
the
switch.
So
this
needs
to
be
an
access
interface
in
VLAN 105.
N1kv1(config)# port-profile VLAN105_3
N1kv1(config-port-prof)# ip dhcp ?
snooping DHCP Snooping
We
need
to
limit
the
amount
of
packets
per
second
that
are
received
from
the
DHCP
server
to
3
per
second.
This
is
done
using
the
rate
command,
which
automatically
enables
a
rate
limiter
for
DHCP
packets.
We
can
verify
that
the
features
are
enabled
in
the
correct
way
as
we
want
them
to.
N1kv1(config)# show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on the following VLANs:
none
DHCP snooping is operational on the following VLANs:
none
Insertion of Option 82 is enabled
Verification of MAC address is enabled
DHCP snooping trust is configured on the following interfaces:
Interface Trusted
------------ -------
N1kv1(config)#
The
next
question
asks
to
configure
a
verification.
The
switch
to
ensure
that
the
DHCP
packet
is
not
spoofed
can
perform
this
verification.
This
means
that
the
switch
checks
if
the
Source
MAC
address
is
equal
to
the
MAC
address
specified
within
the
DHCP
packet.
N1kv1
N1kv1(config)# ip dhcp snooping verify mac-address
N1kv1(config)#
This
concludes
the
configuration
for
the
DHCP
snooping
feature.
At
this
point
the
switch
starts
building
up
a
database
of
entries
of
clients
that
log-‐in
through
this
switch.
Every
time
the
DHCP
server
hands
out
a
lease
to
a
client,
this
information
is
stored
into
the
DHCP
snooping
database.
This
database
now
offers
a
perfect
Layer 2 MAC Address to
Layer 3 IP address mapping
on
the
switch.
Other
features
like
the
one
we
are
configuring
now
then
leverage
this
information.
Dynamic ARP Inspection (DAI)
is
a
feature
to
really
ensure
you
are
safe
against
MAC
address
spoofing
attacks.
Dynamic ARP inspection
takes
care
of
a
number
of
features.
• Source MAC spoofing
o The
Source
MAC
address
of
an
ARP
request
is
checked
against
the
DHCP
snooping
database
to
ensure
the
request
came
from
the
correct
interface
• Optimal routing of packets
o Because
the
DHCP
snooping
database
knows
where
to
find
the
ultimate
destination
of
the
ARP
request.
It
only
sends
it
out
on
trusted
interfaces
or
even
where
the
requested
address
is
located
• Checks for Valid ARP packets
o The
DAI
process
checks
if
ARP
packets
are
send
like
they
should
be
and
verified
that
there
is
no
faulty
information
in
the
packet.
Now
it’s
also
possible
to
create
exceptions
to
this
case.
You
can
create
an
Access
List
and
apply
that
to
the
DAI
process
to
ensure
that
ARP
request
sent
for
a
specific
range
of
IP
addresses
is
always
allowed.
And
finally
logging
is
a
very
important
topic.
How
long
do
you
want
to
keep
track
of
log
messages
for
this
feature.
We
start
by
configuring
the
initial
question
related
to
DAI.
We
want
to
ensure
that
VLAN 105
is
secured
for
ARP
Spoofing,
meaning
we
need
to
enable
DAI
on
that
VLAN.
There
is
one
exception
and
that
is
that
it
should
not
perform
these
checks
on
the
uplink
profiles
going
to
the
rest
of
the
network.
Let’s
configure
these
two
questions.
N1kv1
N1kv1(config)# ip arp inspection vlan 105
N1kv1(config)# port-profile UPLINK
N1kv1(config-port-prof)# ip arp inspection ?
trust Configure trust state
Vlan : 105
-----------
Configuration : Enabled
Operation State : Active
DHCP logging options : Deny
N1kv1(config-if)# show ip arp inspec interfaces
The
final
question
related
to
Dynamic ARP
inspection
is
a
feature
to
extend
the
default
verification
methods
that
it
performs.
You
can
enable
some
extended
checks,
like
previously
mentioned.
One
of
them
is
checking
for
a
Valid
IP
address.
This
means
that
the
DAI
feature
will
check
for
invalid
or
faulty
IP
addresses
in
ARP
packets
and
will
drop
these
when
it
sees
an
invalid
IP.
This
feature
is
enabled
with
a
single
command.
N1kv1
N1kv1(config)# ip arp inspect validate ip
Now
we
finished
the
DAI
configuration
and
we
can
check
if
all
our
settings
are
correctly
applied.
N1kv1(config)# show ip arp inspection vlan 105
Vlan : 105
-----------
Configuration : Enabled
Operation State : Active
DHCP logging options : All
N1kv1(config)# show ip arp inspect interfaces
Vlan : 105
-----------
ARP Req Forwarded = 0
ARP Res Forwarded = 0
ARP Req Dropped = 0
ARP Res Dropped = 0
DHCP Drops = 0
DHCP Permits = 0
IP Fails-ARP Req = 0
IP Fails-ARP Res = 0
N1kv1(config)# show ip arp inspect log
The
next
feature
tested
in
this
task
is
IP Source Guard.
This
feature
ensures
a
very
strict
IP
spoofing
security
on
a
per
interface
level.
The
only
way
a
packet
is
allowed
through
it
either
when
there
is
a
DHCP
Snooping
database
entry
for
the
IP
address
or
there
is
a
statically
configured
entry.
The
feature
is
enabled
per
interface
and
cannot
be
enabled
globally
per
VLAN.
Keep
in
mind
that
the
feature
is
only
enabled
on
VLANs
where
DHCP
snooping
is
already
enabled!
Let’s
start
by
configuring
the
first
question.
N1kv1
N1kv1(config)# port-profile UPLINK
N1kv1(config-port-prof)# ip verify ?
source IP Source Guard related commands
We
then
need
to
make
an
exception
to
interface
vEthernet145
where
a
host
with
a
statically
configured
IP
address
is
connected
to.
N1kv1
N1kv1(config)# ip source ?
Do
not
forget
to
enable
the
IP Source Guard
feature
on
interface
vEthernet145
as
well,
because
otherwise
IP
spoofing
attacks
are
still
allowed
trough
as
the
interface
is
not
protected!
Which
completes Task 3.
Now
we
can
continue
with
Task 4,
which
is
about
configuring
Access Control Lists
for
both
IP
and
MAC
addresses.
Task
4:
Access
Control
Lists
This
task
will
explore
the
possibilities
with
Access Control Lists
on
the
Nexus
1000V.
We
will
be
configuring
security
for
a
number
of
layer
3
and
layer
2
ports
and
interfaces.
ACL’s
have
been
used
since
a
very
long
time
and
has
been
available
in
IOS
since
many
years.
In
the
past
you
configured
ACL’s
with
numbers.
There
were
very
specific
reservation
for
these
ACL
numbers.
There
was
also
a
strict
distinction
between
2
types
of
ACL’s,
Standard
and
Extended.
Within
NX-‐OS
there
is
no
distinction
between
these
types
of
ACL’s
and
all
ACL’s
are
using
the
Extended
features.
Which
means
that
you
can
use
all
variables
possible.
There
are
2
types
of
ACL’s
that
are
tested
in
the
CCIE
Data
Center
lab.
In
the
previous
task
we
already
configured
an
ARP
ACL.
In
this
task
we
will
be
configuring
IP Access Lists
and
MAC
Access Lists.
The
biggest
difference
between
the
2
is
that
an
IP
ACL
can
be
used
at
almost
any
place
in
the
switch
to
match
certain
IP
traffic.
MAC
ACL’s
are
used
for
VLAN
Access
Control
Lists
(VACL).
They
offer
the
option
to
limit
certain
Layer
2
frames
based
on
MAC
addresses
to
pass
through
the
switch
or
not.
IP Access Lists
can
only
match
on
IP
addresses.
Be
very
careful
when
reading
the
questions
in
these
tasks.
The
tasks
can
be
very
difficult
in
wording,
so
read
very
well
in
which
direction
the
traffic
is
flowing.
You
also
need
to
be
prepared
for
questions
about
common
applications,
of
which
you
should
know
the
port
numbers
and
the
traffic
characteristics.
The
following
types
of
traffic
are
able
to
be
identified
through
MAC Access Lists:
• Source and/or Destination MAC address
• EtherType (Upper level protocol)
• VLAN ID
• 802.1p bits (Class of Service)
IP (version 4) Access Lists
are
able
to
match
a
lot
more
different
types
of
traffic
characteristics.
• Source IP address
• Destination IP address
• Upper level protocol (TCP,
UDP,
EIGRP,
GRE,
OSPF,
PIM,
IP-‐IP,
ESP,
etc.)
• ICMP types / codes
• IGMP types
• DSCP values
• Source TCP/UDP port
• Destination TCP/UDP port
• Packet length
• Fragmented packets
• TCP bits (SYN,
ACK,
FIN,
RST,
etc.)
With
all
this
variation
of
possible
matching
in
the
Access
List,
it
gives
you
a
lot
of
flexibility.
Be
aware
for
lengthy
Access
Lists
when
a
lot
of
different
rules
are
applied.
It’s
also
possible
to
create
Access
Lists
that
are
connected
to
a
time
range.
This
means
that
the
Access
List
is
only
applied
during
a
specified
time
range.
Which
could
be
that
Internet
traffic
is
only
allowed
during
business
hours,
or
any
other
rule.
One
important
topic
to
think
about
in
real
life
deployments
is
Logging.
When
every
match
and
deny
is
logged,
this
could
cause
a
lot
of
traffic
to
the
Supervisor
/
Control-‐Plane
as
this
might
give
thousands
of
log
messages
every
second.
In
our
lab
scenario
we
will
not
have
any
traffic
running
on
the
network,
so
we
are
safe
to
configure
any
feature
we
like.
We
start
by
configuring
our
first
IP Access Control List.
By
default,
when
you
are
configuring
an
Access Control List.
There
is
already
one
rule
inserted
into
this
list,
which
is
a
rule
that
denies
all
traffic
when
no
other
rule
has
been
specified.
The
rule
is
always
present
at
the
bottom
of
the
ACL
and
is
never
shown.
So
keep
in
mind
that
all
traffic
that
is
not
matched
by
any
other
rule
is
denied
to
pass
through.
It’s
a
common
practice,
especially
in
CCIE
scenarios
to
insert
a
deny
for
all
traffic
at
the
bottom
of
an
ACL
to
ensure
that
you
do
not
forget
about
it.
In
the
first
question
of
the
task
it’s
stated
that
we
should
secure
VLAN 50
for
traffic
that
should
not
be
there.
This
means
we
will
be
using
an
IP Access Control List.
Let’s
start
by
configuring
our
ACL
for
VLAN 509,
be
sure
to
pick
names,
which
are
easily
remembered
and
easy
to
type.
The
first
requirement
is
to
create
an
entry
for
a
host
to
be
allowed
to
the
VLAN.
If
you
read
carefully
you
will
see
that
the
questions
are
all
related
to
traffic
going
TO
the
VLAN
that
we
want
to
secure.
One
very
important
decision
to
make
when
creating
ACLs,
is
in
which
direction
the
ACL
needs
to
be
applied.
The
ACL
can
be
applied
in
inbound
and
outbound
direction.
• Inbound
o The
inbound
direction
will
match
the
traffic
that
comes
IN
to
the
interface,
from
the
layer
2
domain
/
subnet.
It
comes
IN
to
the
switch
via
this
interface
and
there
the
traffic
is
matched
• Outbound
o The
outbound
direction
will
match
traffic
that
moves
OUT
of
the
interface
onto
the
Layer
2
domain
/
IP
subnet.
This
matches
traffic
going
TO
hosts
on
the
subnet
connected
to
the
interface
For
this
task
in
this
first
Access List
configuration
we
will
be
applying
the
ACL
in
outbound
direction.
N1kv1
N1kv1(config)# ip access-list VLAN50_OUT
We
give
the
ACL
a
recognizable
name.
N1kv1(config-acl)# permit ip host 198.18.255.100 198.18.59.0 ?
A.B.C.D Destination wildcard bits
The
first
task
is
to
allow
a
single
host
(source
address)
to
send
traffic
to
the
VLAN.
We
could
apply
this
rule
to
‘any’
destination
address,
but
we
need
to
be
as
specific
as
possible.
So
we
will
configure
the
ACL
with
a
wildcard
mask,
which
complies
with
the
entire
VLAN.
N1kv1
N1kv1(config-acl)# permit ip host 198.18.255.100 198.18.59.0 0.0.0.255
N1kv1(config-acl)#
Now
the
ACL
is
not
applied
to
the
interface
yet,
but
we
will
wait
for
the
application
of
the
ACL
until
we
finished
building
all
the
rules
that
we
are
required
to
in
this
task.
Next
question
is
that
some
Secure
Web
traffic,
meaning
SSL
or
HTTPS
connections,
is
coming
from
a
certain
range.
We
need
to
ensure
that
VLAN 50
receives
this
traffic.
We
need
to
allow
a
/18
mask.
This
means
in
wildcard
masks
that
6
bits
of
the
third
octet
need
to
be
a
1,
which
totals
to
63.
N1kv1
N1kv1(config-acl)# permit tcp 198.18.128.0 0.0.63.255 eq 443 198.18.59.0
0.0.0.255 gt 1024
N1kv1(config-acl)#
The
traffic
is
coming
from
servers,
meaning
that
the
source
port
will
be
Secure
Web,
as
the
VLAN 509
will
contain
the
clients
that
used
this
port
as
the
Destination
port.
The
clients
are
using
non-‐reserved
ports,
which
means
that
they
are
using
ports
that
are
not
reserved
for
special
cases
(like
HTTPS).
The
port
range
is
all
ports
above
1024.
Luckily
NX-‐OS
foresees
in
this
and
there
is
a
operator
to
match
ports
that
are
greater
than
a
specific
number
or
range.
The
next
question
will
include
a
number
of
services
that
need
to
be
allowed,
but
we
cannot
configure
them
inside
of
the
ACL.
We
need
another
option
to
configure
applications
that
need
to
be
matched.
This
is
found
from
a
feature,
which
is
borrowed
from
the
Cisco
ASA
firewalls.
It’s
now
possible
to
combine
certain
equal
parameters
and
use
them
in
a
single
Access Control
Entry
(ACE).
This
is
just
for
ease
of
configuration
as
the
switch
then
automatically
generates
various
entries
based
on
the
grouping.
These
combinations
are
called
object-‐groups.
They
can
be
made
for
both
IP
addresses
and
for
Applications
(port
numbers).
In
this
case
we
will
need
both,
because
we
can
only
have
two
entries
in
the
ACL
to
solve
the
question.
We
cannot
use
one
entry
for
the
first
subnet
and
the
second
entry
for
the
second
subnet,
because
we
have
both
TCP
and
UDP
applications
in
this
question.
It’s
not
possible
to
create
a
TCP
and
a
UDP
match
in
a
single
entry,
so
therefore
we
will
require
2
entries.
Let’s
start
by
configuring
the
object
groups.
N1kv1
N1kv1(config)# object-group ?
ip IP Object groups
ipv6 IPv6 Object groups
N1kv1(config)# object-group ip ?
address Address object group
port IP port object group (can be used in IPv4 and IPv6 access-
lists)
N1kv1(config-ipaddr-ogroup)# 198.19.0.0/16
N1kv1(config-ipaddr-ogroup)# 198.18.192.0/24
N1kv1(config-ipaddr-ogroup)# exit
We
first
created
the
object-‐group
related
to
the
IP
subnets
that
are
matched.
Instead
of
wildcard
masks
it’s
also
possible
in
NX-‐OS
to
use
the
CIDR
notation,
making
an
ACL
much
easier
to
read.
N1kv1
N1kv1(config)# object-group ip port TASK4_PORT
N1kv1(config-port-ogroup)# ?
<1-4294967295> Sequence number
eq Match only packets on a given port number
gt Match only packets with a greater port number
lt Match only packets with a lower port number
neq Match only packets not on a given port number
no Negate a command or set its defaults
range Match only packets in the range of port numbers
end Go to exec mode
exit Exit from command interpreter
pop Pop mode from stack or restore from name
push Push current mode to stack or save it under name
where Shows the cli context you are in
N1kv1(config-port-ogroup)# eq ?
<0-65535> Port number
N1kv1(config-port-ogroup)# eq 80
N1kv1(config-port-ogroup)# eq 53
N1kv1(config-port-ogroup)# eq 110
N1kv1(config-port-ogroup)# eq 25
N1kv1(config-port-ogroup)# exit
Next
we
configure
our
applications.
Ensure
you
are
aware
of
the
port
numbers
for
these
common
services.
It’s
easy
rememberable,
because
you
will
need
these
port
numbers
in
real-‐
life
as
well
while
troubleshooting
your
network.
In
this
case
don’t
forget
to
add
DNS
to
the
group
where
TCP
will
be
matched
against,
because
DNS
uses
both
a
TCP
and
a
UDP
port
number.
N1kv1
N1kv1(config)# ip access-list VLAN509_OUT
N1kv1(config-acl)# permit tcp ?
A.B.C.D Source network address
A.B.C.D/LEN Source network prefix
addrgroup Source address group
any Any source address
host A single source host
IP Access Lists
can
be
applied
at
multiple
places.
One
of
the
more
common
points
is
the
VLAN interface
(SVI).
We
just
used
a
VACL
to
match
an IP ACL.
The
last
option
is
to
configure
the
IP
ACL
under
a
physical
Interface,
so
only
traffic
from
that
interface
is
matched
against
it.
N1kv1
N1kv1(config)# ip access-list VETH145_IN
N1kv1(config-acl)# deny tcp 198.18.51.0/24 host 198.19.0.25 eq 143
We
create
an
ACL
where
we
deny
traffic
towards
a
single
host.
The
NX-‐OS
knows
a
shortcut
for
this
in
terms
of
the
host
keyword
in
ACLs.
Again
keep
attention
to
the
direction
of
the
traffic.
In
this
case
it’s
a
client
accessing
a
server,
which
should
be
denied.
Meaning
that
it’s
the
destination
port
number,
which
is
the
application
port.
N1kv1(config-acl)# permit ip any any
Finally
we
should
only
be
securing
against
the
particular
host.
All
other
traffic
should
still
be
passed
through
this
interface.
So
we
need
to
explicitly
allow
this.
Next
step
is
to
apply
the
ACL
to
the
interface.
N1kv1
N1kv1(config-port-prof)# port-profile type vethernet VLAN501
N1kv1(config-port-prof)# sw mode acc
N1kv1(config-port-prof)# sw acc vlan 501
N1kv1(config-port-prof)# vmware port-group
N1kv1(config-port-prof)# state enabled
N1kv1(config-port-prof)# no shut
As
the
profile
does
not
exist
yet
we
first
create
it.
We
could
also
apply
the
configuration
directly
to
the
vEthernet
interface,
which
also
doesn’t
exist
yet.
When
a
new
VM
comes
online
it
could
get
the
specific
vEthernet
interface
number
and
keep
it
as
we
configured
it
for
begin
consistent.
In
this
example
we
chose
to
configure
a
port-profile
before
we
configured
the
interface.
N1kv1(config-port-prof)# interface vethernet 145
N1kv1(config-if)# inherit port-profile VLAN501
N1kv1(config-if)# ip port access-group VETH145_IN ?
in Inbound packets
out Outbound packets
As
the
traffic
is
coming
from
the
VLAN
going
towards
the
server,
we
need
to
apply
this
ACL
in
inbound
direction.
The
next
question
is
related
to
Layer
2
security.
Which
means
that
we
should
create
a
MAC
Access List
for VLAN 501.
Pay
close
attention
to
how
the
question
is
formulated.
The
access-list
should
only
match
traffic
from
the
server
farm.
Meaning
that
the
mentioned
MAC
addresses
are
used
as
source
addresses
for
the
access
list.
The
MAC access-list
is
created
in
a
very
similar
way
as
that
IP ACLs
are
created.
N1kv1
N1kv1(config-mac-acl)# permit ?
E.E.E Source MAC address (Option 1)
EE-EE-EE-EE-EE-EE Source MAC address (Option 2)
EE:EE:EE:EE:EE:EE Source MAC address (Option 3)
EEEE.EEEE.EEEE Source MAC address (Option 4)
any Any source address
Wildcard
masks
work
exactly
the
same
as
with
IP Access Lists.
In
this
case
we
chose
a
relatively
easy
mask.
N1kv1
N1kv1(config-mac-acl)# permit 0bad.c0ff.ee00 0000.0000.00ff ?
E.E.E Destination MAC address (Option 1)
EE-EE-EE-EE-EE-EE Destination MAC address (Option 2)
EE:EE:EE:EE:EE:EE Destination MAC address (Option 3)
EEEE.EEEE.EEEE Destination MAC address (Option 4)
any Any destination address
You
can
specify
which
traffic
is
allowed,
but
this
is
not
necessary
in
our
case.
N1kv1
N1kv1(config-mac-acl)# permit 0bad.c0ff.ee00 0000.0000.00ff any
N1kv1(config-mac-acl)# exit
Then
the
access-‐list
needs
to
be
applied
to
a
port-profile. The
port-‐profile
for
this
VLAN
is
already
created
so
we
can
apply
it
there.
N1kv1
N1kv1(config-port-prof)# port-profile VLAN501
N1kv1(config-port-prof)# mac port access-group VLAN501 in
N1kv1(config-port-prof)#
With
this
final
question
we
finished
the
chapter!