MANAGEMENT PLANE PROTECTION (MPP)

Management Plane Protection (MPP) is a security feature for Cisco IOS routers that
accomplishes two things:
 Restrict the interfaces where the router permits packets from network management
protocols.
 Restrict the network management protocols that the router permits.
The management plane is the logical path of all traffic related to the management of the
router. For example:
 Telnet
 SSH
 SNMP
 HTTP
 HTTPS
MPP makes it easier to protect management traffic. You need fewer access-lists because
you can restrict most of the network management traffic with MPP. It also prevents network
management packet flood attacks since it drops denied packets and does not forward them
to the CPU. It’s a good tool to permit/deny most of your network management traffic. You
can still use access-lists if you need to permit/deny specific subnets and/or IP addresses.

Configuration
Let me show you how to configure MPP. This is the topology we’ll use:

H1 is on a trusted network we use to manage R1. H2 is on a remote network that should not
be able to manage R1 with any network management protocols.
hostname H1
!
interface GigabitEthernet2
ip address 192.168.1.1 255.255.255.0
!
end

hostname H2
!
interface GigabitEthernet2
 ip address 192.168.2.2 255.255.255.0
!
end
hostname R1
!
interface GigabitEthernet2
 ip address 192.168.1.254 255.255.255.0
!
interface GigabitEthernet3
 ip address 192.168.2.254 255.255.255.0
!
end

Without MPP
Let me show you what happens behind the scenes when MPP is disabled. I’ll configure R1
so it only accepts SSH traffic on the VTY lines:

R1(config)#line vty 0 4
R1(config-line)#transport input ssh
R1#debug ip packet
IP packet debugging is on

Let’s try to telnet from H2 to R1:

H2#telnet 192.168.2.254
Trying 192.168.2.254 ... 
% Connection refused by remote host

We see that the connection is refused, this is expected because we don’t accept telnet on
the VTY lines of R1. When you look at R1 you see it sends two packets to H2:

R1#
IP: tableid=0, s=192.168.2.254 (local), d=192.168.2.2 (GigabitEthernet3), routed via FIB
IP: s=192.168.2.254 (local), d=192.168.2.2 (GigabitEthernet3), len 40, sending

R1 responds to H2, refusing the connection. Transmit enough telnet packets from H2 and
you can perform a denial of service attack on R1.

With MPP
Let’s see if we can improve this situation. First, let’s enable telnet on the VTY lines of R1:

R1(config)#line vty 0 4
R1(config-line)#transport input telnet

Now we configure MPP, it’s a subset of Control Plane Policing (COPP). so it’s under
the control-plane host command. Then use the management-interface command and
specify the interface:
R1(config)#control-plane host
R1(config-cp-host)#management-interface GigabitEthernet 2 allow ?
  beep Beep Protocol
  ftp File Transfer Protocol
  http HTTP Protocol
  https HTTPS Protocol
  snmp Simple Network Management Protocol
  ssh Secure Shell Protocol
  telnet Telnet Protocol
  tftp Trivial File Transfer Protocol
  tl1 Transaction Language Session Protocol

Above, you can see all network management protocols that MPP supports. Let’s choose
telnet:

R1(config-cp-host)#management-interface GigabitEthernet 2 allow telnet

Let’s try another telnet session. I’ll start with H1:

H1#telnet 192.168.1.254
Trying 192.168.1.254 ... Open

This is no problem, H1 connects from an interface we permit. Let’s try H2:

H2#telnet 192.168.2.254
Trying 192.168.2.254 ... 
% Connection timed out; remote host not responding

The telnet connection from H2 fails and you can see a different message, the connection
now times out. R1 silently drops the telnet packets from H2 and does not reply.
There are two useful show commands to verify your MPP configuration. Here’s the first one:

R1#show management-interface 
Management interface GigabitEthernet2
Protocol Packets processed
telnet 9

The output above gives a nice overview of the permitted interfaces and protocols. You can
also look at a “per protocol” overview:

R1#show management-interface protocol telnet

The following management-interfaces allow protocol telnet
GigabitEthernet2 Packets processed 9

That’s all there is to it!4

Conclusion
You have now learned what MPP is and how to configure it:
 MPP restricts the interfaces where the router permits network management
protocols.
 MPP restricts the network management protocols it permits.
 You need fewer access-lists because you don’t need to add them to all your
interfaces.
 MPP silently drops denied packets and does not forward them to the CPU.

COPP (CONTROL PLANE POLICING)

On our routers (or multilayer switches) we can use access-lists or firewalls (CBAC or zone
based) to permit/deny packets that go through or to the router.
We can also use policing to rate limit that goes through our router.
What if we want to police traffic that is destined to the router? There are quite some
protocols that produce packets that the router has to process:
 Routing protocols like OSPF, EIGRP, or BGP.
 Gateway redundancy protocols like HSRP, VRRP, or GLBP.
  Network management protocols like telnet, SSH, SNMP, or RADIUS.
 Packets that CEF can’t forward.
The route processor inspects packets that these protocols generate on the control plane.
When the route processor receives too many packets, it’s possible that it can’t keep up and
drops packets.
When this happens, you’ll see things like flapping neighbor adjacencies or timeouts when
you try to connect with telnet/SSH to the router.
To prevent this from happening, we have a couple of options:
 rACLs (Receive Access Control List): these are standard or extended ACL that
control traffic sent by line cards to the route processor. You only see this feature on
high-end routers like the Cisco 12000 series.
 Control Plane Policing (CoPP): allows you to use MQC (Modular Quality of
Service) framework to permit/deny or rate-limit traffic that goes to the route
processor.
 Control Plane Protection (CPPr): this is an extension of CoPP. One of the things it
does is separating the route processor into three sub-interfaces:
o Host
o Transit
o CEF exception
In this lesson, we’ll take a look at CoPP (Control Plane Policing).

Configuration
To demonstrate CoPP, I use the following topology:
Here’s what we have:
 R1 and R2 run OSPF and HSRP.
 R1 is configured for remote access through telnet.
 H1 is a host that generates ICMP and telnet traffic to test CoPP on R1.

hostname H1
!
no ip routing
!
no ip cef
!
interface GigabitEthernet0/1
ip address 192.168.1.101 255.255.255.0
!
ip default-gateway 192.168.1.254
!
end

hostname R1
!
ip cef
!
interface GigabitEthernet0/1
ip address 192.168.1.1 255.255.255.0
standby version 2
standby 1 ip 192.168.1.254
standby 1 priority 200
standby 1 preempt
!
router ospf 1
network 192.168.1.0 0.0.0.255 area 0
!
end

hostname R2
!
ip cef
!
interface GigabitEthernet0/1
ip address 192.168.1.2 255.255.255.0
standby version 2
standby 1 ip 192.168.1.254
standby 1 preempt
!
router ospf 1
network 192.168.1.0 0.0.0.255 area 0
!
end

Control plane policing uses the MQC so that means we have to use class-maps and a
policy-map. In your class-maps, it’s best to match traffic on:
 standard or extended access-lists
 DSCP or IP precedence values.
NBAR classification is not supported on all platforms and or IOS versions. The only
exception to this rule is match protocol arp
Let’s create some access-lists that match traffic on the control plane that we can use in our
class-maps:

R1(config)#ip access-list extended ICMP

R1(config-ext-nacl)#permit icmp any any

R1(config)#ip access-list extended TELNET

R1(config-ext-nacl)#permit tcp any any eq 23

R1(config)#ip access-list extended OSPF

R1(config-ext-nacl)#permit ospf any any

R1(config)#ip access-list extended HSRP

R1(config-ext-nacl)#permit udp any host 224.0.0.102 eq 1985

Let’s create class-maps that match the access-lists:

R1(config)#class-map ICMP
R1(config-cmap)#match access-group name ICMP

R1(config)#class-map TELNET
R1(config-cmap)#match access-group name TELNET

R1(config)#class-map OSPF
R1(config-cmap)#match access-group name OSPF

R1(config)#class-map HSRP
R1(config-cmap)#match access-group name HSRP
Now I can create a policy-map:

R1(config)#policy-map COPP
R1(config-pmap)#class ICMP
R1(config-pmap-c)#police 8000 conform-action transmit exceed-action transmit
R1(config-pmap-c)#exit
R1(config-pmap)#class TELNET
R1(config-pmap-c)#police 8000 conform-action transmit exceed-action transmit
R1(config-pmap-c)#exit
R1(config-pmap)#class OSPF
R1(config-pmap-c)#police 8000 conform-action transmit exceed-action transmit
R1(config-pmap-c)#exit
R1(config-pmap)#class HSRP
R1(config-pmap-c)#police 8000 conform-action transmit exceed-action transmit
R1(config-pmap-c)#exit

In the policy-map, I add policers for 8000 bps and the conform-action and exceed-action are
both set to transmit. These policers will never drop anything but there is a good reason I
configure it like this.
When you configure CoPP for the first time, you don’t know how much packets you receive
for each protocol. There is a risk that you deny legitimate traffic. It’s best to permit
everything. Once you know how much packets are exceeding, change the values and set
the exceed action to drop.
We need to attach this policy-map to the control plane. We do this with the following
command:

R1(config)#control-plane
R1(config-cp)#?
Control Plane configuration commands:
exit Exit from control-plane configuration mode
no Negate or set default values of a command
service-policy Configure QOS Service Policy

When you choose the service-policy command, you have a couple of options:
R1(config-cp)#service-policy ?
input Assign policy-map to the input of an interface
output Assign policy-map to the output of an interface
type type of the policy-map

You can enable the policy-map in- or outbound. Type can be used if you want to log
incoming packets.
I want to police incoming traffic destined to the router so let’s select the input option:

R1(config-cp)#service-policy input COPP

Once you do this, you’ll see that the feature is enabled:

R1#
%CP-5-FEATURE: Control-plane Policing feature enabled on Control plane aggregate path

Ok nice, now what? Let’s figure out if our policy-map is working or not. I’ll generate some
traffic from H1. Let’s send some pings and try telnet:

H1#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/6/10 ms

H1#telnet 192.168.1.1
Trying 192.168.1.1 ... Open

Let’s take a look at R1:

R1#show policy-map control-plane

Control Plane

Service-policy input: COPP

Class-map: ICMP (match-all)

5 packets, 570 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: access-group name ICMP
police:
cir 8000 bps, bc 1500 bytes
conformed 5 packets, 570 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
transmit
conformed 0000 bps, exceeded 0000 bps

Class-map: TELNET (match-all)

17 packets, 1026 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: access-group name TELNET
police:
cir 8000 bps, bc 1500 bytes
conformed 17 packets, 1026 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
transmit
conformed 0000 bps, exceeded 0000 bps

Class-map: OSPF (match-all)

25 packets, 2318 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: access-group name OSPF
police:
cir 8000 bps, bc 1500 bytes
conformed 25 packets, 2318 bytes; actions:
transmit
 exceeded 0 packets, 0 bytes; actions:
transmit
conformed 0000 bps, exceeded 0000 bps

Class-map: HSRP (match-all)

56 packets, 5094 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: access-group name HSRP
police:
cir 8000 bps, bc 1500 bytes
conformed 56 packets, 5094 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
transmit
conformed 0000 bps, exceeded 0000 bps

Class-map: class-default (match-any)

6 packets, 1544 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any

The output above is looking good; we see some matches in every class-map that we
configured and all traffic is conformed. In my lab, there isn’t much traffic.
In a production network, you might want to run it like this for a few days to see how much of
your traffic is conformed or exceeded.
What about the class-default class-map?  This includes all layer two protocols. The only
layer two protocol you can assign to a different class-map is ARP. Everything else is
assigned to class-default.
Our policy-map is up and running but even exceeding traffic is permitted. Let’s change the
exceed action for our ICMP traffic:
Let’s add a policer to the ICMP class-map:

R1(config)#policy-map COPP
R1(config-pmap)#class ICMP
R1(config-pmap-c)#police cir 8000 conform-action transmit exceed-action drop

The police rate is only 8000 bits so even some simple pings will be rate limited. Let’s
generate some traffic from H1:

H1#ping 192.168.1.1 repeat 50

Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!
Success rate is 94 percent (47/50), round-trip min/avg/max = 2/4/13 ms

Let’s take another look at the policy-map:

R1#show policy-map control-plane input class ICMP

Control Plane

Service-policy input: COPP

Class-map: ICMP (match-all)

55 packets, 6270 bytes
5 minute offered rate 1000 bps, drop rate 0000 bps
Match: access-group name ICMP
police:
cir 8000 bps, bc 1500 bytes
conformed 52 packets, 5928 bytes; actions:
transmit
exceeded 3 packets, 342 bytes; actions:
drop
conformed 1000 bps, exceeded 0000 bps/code>
Above we can see that three packets exceeded and got dropped. You have now seen
everything you need to create control plane policing policy-maps for your routers.

hostname H1
!
no ip routing
!
no ip cef
!
interface GigabitEthernet0/1
ip address 192.168.1.101 255.255.255.0
!
ip default-gateway 192.168.1.254
!
end

hostname R1
!
ip cef
!
class-map match-all TELNET
match access-group name TELNET
class-map match-all OSPF
match access-group name OSPF
class-map match-all ICMP
match access-group name ICMP
class-map match-all HSRP
match access-group name HSRP
!
policy-map COPP
class ICMP
police cir 8000 conform-action transmit exceed-action drop
class TELNET
 class OSPF
class HSRP
!
interface GigabitEthernet0/1
ip address 192.168.1.1 255.255.255.0
standby 1 ip 192.168.1.254
standby 1 priority 200
standby 1 preempt
!
router ospf 1
network 192.168.1.0 0.0.0.255 area 0
!
ip access-list extended HSRP
permit udp any host 224.0.0.102 eq 1985
ip access-list extended ICMP
permit icmp any any
ip access-list extended OSPF
permit ospf any any
ip access-list extended TELNET
permit tcp any any eq telnet
!
end

hostname R2
!
ip cef
!
interface GigabitEthernet0/1
ip address 192.168.1.2 255.255.255.0
standby 1 ip 192.168.1.254
standby 1 preempt
!
router ospf 1
network 192.168.1.0 0.0.0.255 area 0
!
end

Conclusion
You have now learned how to use CoPP (Control Plane Policing) to rate limit packets to and
from the route processor on the control plane.
 For classification, use:
o standard or extended access-lists
o DSCP or IP precedence values
o Don’t use NBAR except to match ARP packets.
 It’s best to set the conform-action and exceed-action both to transmit, so you don’t
drop legitimate traffic. Once you know how much packets are exceeding, change the
values and exceed action to drop.

AAA and 802.1X Authentication

When it comes to securing the network, AAA and 802.1X authentication are two powerful
tools we can use. Let me show you an example why you might want this for your switches:

Network users might bring their own wireless router from home and connect it to the switch
so they can share wireless internet with all their colleagues. An access point like this is
called a rogue access point and this is something you DON’T want to see on your
network. It’s hard to detect because on the switch you’ll only see one MAC address. The
router is doing NAT so you will only see one IP address, this is something you can’t prevent
with port security.
One way of dealing with issues like this is to use AAA.
AAA stands for Authentication, Authorization and Accounting:
 Authentication: Verify the identity of the user, who are you?
 Authorization: What is the user allowed to do? what resources can he/she access?
 Accounting: Used for billing and auditing.

The idea behind AAA is that a user has to authenticate before getting access to the
network. The fa0/1 interface on SW1 will be blocked and you are not even getting an IP
address. The only thing the user is allowed to do is send his/her credentials which will be
forwarded to the AAA server. If your credentials are OK the port will be unblocked and you
will be granted access to the network.

802.1X is the mechanism that will block or unblock the interface. It’s called port-based

control. In the picture above an unknown user plugged in a cable to the switch.

All traffic is being dropped with the exception of EAPoL (Extensible Authentication

Protocol over LAN). EAP is what we use to exchange authentication information. Once the
user has authenticated and everything is OK she is granted access to the network.
In the picture above you see the terminology that 802.1X uses. The user device is called
the supplicant; it “supplies” authentication information. The switch is called
the authenticator because it accepts the authentication information and passes it along to
the authentication server. User information is stored on the authentication server.
There are two types of authentication servers:
 RADIUS
 TACACS+
The most common authentication server is RADIUS (Remote Authentication Dial In User
Service). It’s a protocol that has been standardized by the IETF. TACACS+ (Terminal
Access Controller Access-Control System) does a similar job but its Cisco proprietary.
There are many different RADIUS servers you can use, for example:
 Cisco ACS (Cisco’s RADIUS and TACACS+ server software)
 Microsoft IAS (you can install it on Windows server 2003 or 2008).
 Freeradius (very powerful and free)
 Integrated in network devices (Cisco’s Wireless LAN controller have RADIUS server
software for example).
You now have an idea what the components are in a AAA 802.1X authentication setup. In
the next lesson I will give you a configuration example how to implement this on a Cisco
Catalyst Switch.

AAA configuration on cisco switch

In this lesson we will take a look how to configure a Cisco Catalyst Switch to use AAA and
802.1X for port based authentication. If you have no idea what AAA (Authentication,
Authorization and Accounting) or 802.1X are about then you should look at my  AAA and
802.1X Introduction first. Having said that, let’s look at the configuration. I will use the
following topology:
I will show you an example of 802.1X with a RADIUS server. I am going to use Elektron
RADIUS server as the authentication server because it’s easy to install and has a nice GUI.

RADIUS Server Configuration

Using a RADIUS server like Elektron will save you the time of hassling with installing
Windows Server, configuring Active Directory and checking many checkboxes or messing
around with Freeradius on Linux. When you configure a RADIUS server you will need to
create a shared password:

I’m going to use “radiuspass” to keep things simple. Hit Next and you will see this:
There are different methods for authentication, for example:
 Only username and password.
 Username, password and a digital certificate on the server.
 Username, password, digital certificate on the server AND on the clients.
In a production network you might already have a certificate authority within your network. I
don’t care about certificates for this demonstration but we’ll generate them anyway in case
you want to play with them sometime in the future. The next steps will let you configure a
name for your RADIUS server and if you want the digital certificate, you will get some
questions about it. Once you are done you will be in the main screen of Elektron:
By default everything should work out of the box so we don’t have to touch anything. Let’s
start and add a user account:
I want to create a new user account. Click on authentication, Elektron accounts and then on
the big green plus symbol in the menu.

My new user account will be for Alice. My password will be “safe” and I don’t need her to be
member of any groups. Click on OK.
By default Elektron will check Windows usernames instead of its own database. We need to
configure it so the local database is used. Click on “Authentication Domains” and then on
“Default Authentication Domain”.

Change it to “Elektron Accounts” and click on OK. That’s all you have to do on the Elektron
RADIUS server, we’ll look at the switch now!

SWITCH CONFIGURATION
First I need to make sure SW1 and the Elektron RADIUS server can reach each other. We’ll
use the management interface (VLAN 1) and configure an IP address on it:

SW1(config)#interface vlan 1
SW1(config-if)#ip address 192.168.1.100 255.255.255.0

Now we should enable AAA:

SW1(config)#aaa new-model

This is an important command. Use aaa new-model to unlock all the different AAA
commands that we need. Let’s configure the RADIUS server:
SW1(config)#radius-server host 192.168.1.101 auth-port 1812 acct-port 1646 key
radiuspass

We configure SW1 with the IP address of the Elektron RADIUS server. I also have to
specify the shared secret “radiuspass” that I configured previously here. Make sure to use
the correct port number.

SW1(config)#aaa authentication dot1x default group radius

This is how we configure SW1 to use the RADIUS server for authentication for 802.1X
enabled interfaces. You can create multiple groups with RADIUS servers if you want.
Besides 802.1X you can use AAA for many things:

SW1(config)#aaa authentication ?
arap Set authentication lists for arap.
attempts Set the maximum number of authentication attempts
banner Message to use when starting login/authentication.
dot1x Set authentication lists for IEEE 802.1x.
enable Set authentication list for enable.
eou Set authentication lists for EAPoUDP
fail-message Message to use for failed login/authentication.
login Set authentication lists for logins.
nasi Set authentication lists for NASI.
password-prompt Text to use when prompting for a password
ppp Set authentication lists for ppp.
sgbp Set authentication lists for sgbp.
username-prompt Text to use when prompting for a username

For example:
 Privileged mode (enable): Instead of using a enable password/secret on your device
your credentials will be checked at the authentication server.
 Login: You can also check credentials for telnet or SSH access.
Our last step on the switch is to enable 802.1X on the interface that connects to the
computer:

SW1(config)#dot1x system-auth-control
SW1(config)#interface fa0/1
SW1(config-if)#dot1x port-control auto

We need to use the dot1x system-auth-control command globally before 802.1X works. On
the interface level we need to use the dot1x port-control auto command.

SW1#
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to
down

After typing in those 802.1X commands you’ll see that the interface to H1 will go down. It’s
time for some authentication! I will use Windows XP as an example for the client.

Client Configuration
I’m using a Windows XP machine to test this. First you need to enable AAA authentication:

802.1X doesn’t always work out of the box so we need to check if a certain service is
running. Press “start”, click on “run” and type “services.msc”.
Look for the “Wired Autoconfig” service and start it if it’s not running.

Now go to Network connections and open the properties of your network card.
By default it will have 802.1X authentication enabled and PEAP is selected. Press “Settings”
to continue.
Disable the checkbox for “Validate server certificate”. Normally you can use this so the
client can check the authenticity of the RADIUS server. Click on the “Configure” button to
continue.

Disable the checkbox here or it will use your Windows credentials by default to authenticate.
Click on OK on all windows until they all disappear.
Click on the pop-up and you’ll be asked for your credentials.

Type in the username and password that you configured in Elektron RADIUS server and
press OK. You should now be connected!

That’s all you have to do to configure AAA and 802.1X Authentication on a Cisco Catalyst
Switch for client authentication. I hope this lesson was useful to you!

AAA Authentication on Cisco IOS

Locally configured usernames and passwords can become an administrative nightmare if
you have a network with many network devices. Each time you want to add a username or
change a password, you have to log in each device one-by-one to add or change
something. It’s a better idea to work with a central AAA server for authentication. On this
server, you add all your usernames and passwords. You configure your routers and
switches to use this AAA server for authentication.
On Cisco IOS, you can configure precisely how you want to use the AAA server for
authentication. You can use it for console or VTY access but also for enable (privileged)
mode and some other options like PPP authentication.
In this lesson, I will show you how to configure AAA authentication on a Cisco IOS router.
We will use a RADIUS server with the FreeRADIUS software. FreeRADIUS is (as the name
implies) free and easy to configure. Once everything is configured, a user that wants to
access the console and use privileged mode will be authenticated by the RADIUS server.

Configuration
Here is the topology that I will use:

We have a router and the RADIUS server. Let’s start with the configuration of FreeRADIUS.

FreeRADIUS
FreeRADIUS runs on Linux and most Linux distributions have it in their repositories. I’m
using a Ubuntu server and you can use apt-get to install it:

# apt-get install freeradius freeradius-utils

Once installed, we have to make some changes to the default configuration files. The first
thing to do, is add a new client (our router). Edit the clients.conf file with your favorite text
editor:

# vim /etc/freeradius/clients.conf

And add an entry at the bottom that looks like this:

client 192.168.1.1 {
secret = MY_KEY
nastype = cisco
shortname = router
}

My client has an IP address of 192.168.1.1 (the router) and the secret is “MY_KEY”. We will
later configure this on the router.
Let’s add a user account, this will be used by the admin that wants access to the router.
Open the users file:

# vim /etc/freeradius/users

And at the end of this file, create an entry that looks like this:

REMOTE_ADMIN Cleartext-Password := "MY_PASSWORD"

Service-Type = NAS-Prompt-User

This allows user account “REMOTE_ADMIN” to log in with password “MY_PASSWORD”.

We will also add an entry for enable (privileged) mode:

$enab15$ Cleartext-Password := "REMOTE_ENABLE"

Service-Type = NAS-Prompt-User

The password to access enable mode will be “REMOTE_ENABLE”. Save the users file and
exit.
Now we have to (re)start FreeRADIUS to apply these changes:

# /etc/init.d/freeradius restart
freeradius stop/waiting
freeradius start/running, process 18145
FreeRADIUS runs as a service but when you are testing things in a lab, it’s easier to run it
in debug mode. This allows you to see incoming authentication requests and debug when
things go wrong. If you want to do this, you first have to stop the service:

# /etc/init.d/freeradius stop
freeradius stop/waiting

And now you can start it in debug mode:

# freeradius -X

It will produce some messages and then shows you that it’s ready to process requests:

Listening on authentication address * port 1812

Listening on accounting address * port 1813
Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel
Listening on proxy address * port 1814
Ready to process requests.

Whenever a client asks FreeRADIUS for authentication, it will now show up on the console.

Cisco IOS
Our router is configured by default to use no or local authentication. That’s something
we have to change. First you need to enable the AAA commands:

R1(config)#aaa new-model

This gives us access to some AAA commands. Let’s configure the RADIUS server that you
want to use:

R1(config)#radius server MY_RADIUS

R1(config-radius-server)#address ipv4 192.168.1.200 auth-port 1812 acct-port 1813
R1(config-radius-server)#key MY_KEY
You can pick whatever name you want for the RADIUS server, I’ll call mine “MY_RADIUS”.
We do have to configure its IP address and it’s a good idea to specify the authentication
(and accounting) port(s). The official ports for RADIUS authentication and accounting are
1812 and 1813. Before IANA allocated these ports, port number 1645 and 1646 were used
unofficially, many RADIUS servers/clients still use these ports.

Older versions of Cisco IOS use the radius-server command to add new RADIUS servers.

Now we can configure the router to use our RADIUS server for authentication. Let’s check
the aaa authentication command:

R1(config)#aaa authentication ?
arap Set authentication lists for arap.
attempts Set the maximum number of authentication attempts
banner Message to use when starting login/authentication.
dot1x Set authentication lists for IEEE 802.1x.
enable Set authentication list for enable.
eou Set authentication lists for EAPoUDP
fail-message Message to use for failed login/authentication.
login Set authentication lists for logins.
password-prompt Text to use when prompting for a password
ppp Set authentication lists for ppp.
sgbp Set authentication lists for sgbp.
suppress Do not send access request for a specific type of user.
username-prompt Text to use when prompting for a username

There is quite some stuff that we can use the RADIUS server for. Login and enable is what
we are going to. Dot1x is another popular choice on switches for per-port authentication.
That’s something I covered in another lesson.
Let’s look at the login options:

R1(config)#aaa authentication login ?

WORD Named authentication list (max 31 characters, longer will be
rejected).
 default The default authentication list.

Here we have to choose an authentication list. Cisco IOS uses the default list for the
console, VTY lines (telnet or SSH) and the AUX port. If you want to use AAA authentication
for all these methods then you can use the default list. If you only want to use AAA
authentication for the console and not for the VTY and AUX port then it might be better to
use a new authentication list.
I will use the default authentication list so that AAA authentication is used for the console
and AUX port. I’ll show you how I can exclude the VTY lines.
Let’s look at the options of the default list:

R1(config)#aaa authentication login default ?

cache Use Cached-group
enable Use enable password for authentication.
group Use Server-group
krb5 Use Kerberos 5 authentication.
krb5-telnet Allow logins only if already authenticated via Kerberos V
Telnet.
line Use line password for authentication.
local Use local username authentication.
local-case Use case-sensitive local username authentication.
none NO authentication.
passwd-expiry enable the login list to provide password aging support

R1(config)#aaa authentication login default group ?

WORD Server-group name
ldap Use list of all LDAP hosts.
radius Use list of all Radius hosts.
tacacs+ Use list of all Tacacs+ hosts.
We only have one RADIUS server configured so let’s go for all RADIUS hosts. If you have a
lot of RADIUS servers then it’s also possible to create a server group that contains the
RADIUS servers you want to use. Let’s continue:

R1(config)#aaa authentication login default group radius ?

cache Use Cached-group
enable Use enable password for authentication.
group Use Server-group
krb5 Use Kerberos 5 authentication.
line Use line password for authentication.
local Use local username authentication.
local-case Use case-sensitive local username authentication.
none NO authentication.
<cr>

Besides the RADIUS server, we can choose a fallback option. If our RADIUS server is
unreachable, do you want all authentication to fail or perhaps fall back to some local
usernames and passwords of the router? Let’s add local fall back authentication:

R1(config)#aaa authentication login default group radius local

Don’t forget to add a local username and password in case your RADIUS server is
unreachable:

R1(config)#username LOCAL_ADMIN password MY_PASSWORD

AAA authentication is now configured for the console, AUX port and VTY lines. Let me
show you to exclude the VTY lines. I will configure a new authentication list called “VTY”
that uses local authentication:

R1(config)#aaa authentication login VTY local

Now we apply this list to the VTY lines:

R1(config)#line vty 0 4
R1(config-line)#login authentication VTY

Next time you try to login with telnet or SSH, the router will look for local usernames.
Let’s also configure the router to use the RADIUS server when we want to enter enable
(privileged) mode:

R1(config)#aaa authentication enable default group radius enable

The command above tells the router to use the default authentication list and all available
RADIUS servers. When the RADIUS server is unavailable, we fall back to using a local
enable password. Let’s make sure there is a local enable password:

R1(config)#enable password LOCAL_ENABLE

Verification
Everything is in place, let’s see if it works. On Cisco IOS, you can use the  test command to
check if AAA authentication is working. For example, here’s how to check if username
“REMOTE_ADMIN” and password “MY_PASSWORD” works:

R1#test aaa group radius REMOTE_ADMIN MY_PASSWORD new-code

User successfully authenticated

User authentication is working so let’s try to access the console of the router:

R1#exit

And enter the username that is only available on the RADIUS server:
R1 con0 is now available

Press RETURN to get started.

User Access Verification

Username: REMOTE_ADMIN
Password:

R1>

I was able to log in. If you left FreeRADIUS in debug mode then you will see the incoming
messages there. Let’s try enable mode:

R1>enable
Password:

R1#

After typing the enable password that is only available on FreeRADIUS, I am able to enter
privileged mode.

hostname R1
!
enable password LOCAL_ENABLE
!
aaa new-model
!
aaa authentication login default group radius local
aaa authentication login VTY local
aaa authentication enable default group radius
!
aaa session-id common
!
ip cef
!
username LOCAL_ADMIN password 0 MY_PASSWORD
!
interface GigabitEthernet0/1
ip address 192.168.1.1 255.255.255.0
!
radius server MY_RADIUS
address ipv4 192.168.1.200 auth-port 1812 acct-port 1813
key MY_KEY
!
end

Conclusion
You have now learned how to configure your Cisco IOS router (or switch) to use a remote
AAA RADIUS server for console, VTY, AUX and enable authentication.

VLAN Access-List (VACL)

VLAN access-lists (VACL) are very useful if you want to filter traffic within the VLAN. Let me
give you an example:
Let’s say I want to make sure that the two computers are unable to communicate with the
server. You could use port-security to filter MAC addresses but this isn’t a very safe
method.
I will show you how to configure a VACL so that the two computers won’t be able to reach
the server. First we have to create an access-list:

SW1(config)#access-list 100 permit ip any host 192.168.1.100

First step is to create an extended access-list. Traffic from any source to destination IP
address 192.168.1.100 should match my access-list. This might look confusing to you
because your gut will tell you to use “deny” in this statement…don’t do it though, use the
permit statement!

SW1(config)#vlan access-map NOT-TO-SERVER 10

SW1(config-access-map)#match ip address 100
SW1(config-access-map)#action drop
SW1(config-access-map)#vlan access-map NOT-TO-SERVER 20
SW1(config-access-map)#action forward

Next step is to create the VACL. Mine is called “NOT-TO-SERVER”.

  Sequence number 10 will look for traffic that matches access-list 100. All traffic that
is permitted in access-list 100 will match here. The action is to drop this traffic.
 Sequence number 20 doesn’t have a match statement so everything will match, the
action is to forward traffic.
As a result all traffic from any host to destination IP address 192.168.1.100 will be dropped,
everything else will be forwarded.

SW1(config)#vlan filter NOT-TO-SERVER vlan-list 10

Last step is to apply the VACL to the VLANs you want. I apply mine to VLAN 10. Let’s see if
this works or not…

C:Documents and SettingsH1>ping 192.168.1.100

Pinging 192.168.4.4 with 32 bytes of data:

Request timed out.

Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.4.4:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

H1 is no longer able to reach the server.

You can use VACLs to do some cool stuff, maybe you want to block IPv6 traffic for all hosts
within a VLAN:

SW1(config)#mac access-list extended NO-IPV6

SW1(config-ext-macl)#permit any any 0x86DD 0x000
First I’ll create a MAC access-list that filters on ethertypes. 0x86DD is the ethertype for IPv6
traffic.

SW1(config)#vlan access-map BLOCK-IPV6 10

SW1(config-access-map)#match mac address NO-IPV6
SW1(config-access-map)#action drop
SW1(config-access-map)#vlan access-map BLOCK-IPV6 20
SW1(config-access-map)#action forward

 Sequence number 10 will match traffic that is defined in MAC access-list “NO-IPV6”.
It will match on Ethernet frames with ethertype 0x86DD as defined in the MAC
access-list. The action is to drop traffic.
 Sequence number 20 does not have a match statement so everything will match.
The action is to forward traffic.
As a result IPv6 traffic will be dropped and all other traffic will be forwarded.

SW1(config)#vlan filter BLOCK-IPV6 vlan-list 20

Don’t forget to enable it on an interface. I’ll activate it on VLAN 20 this time.

hostname SW1
!
mac access-list extended NO-IPV6
permit any any 0x86DD 0x0
!
vlan access-map NOT-TO-SERVER 10
action drop
match ip address 100
vlan access-map NOT-TO-SERVER 20
action forward
vlan access-map BLOCK-IPV6 10
action drop
match mac address NO-IPV6
vlan access-map BLOCK-IPV6 20
action forward
!
vlan filter NOT-TO-SERVER vlan-list 10
vlan filter BLOCK-IPV6 vlan-list 20
!
access-list 100 permit ip any host 192.168.1.100
!
end

IPv6 PACL (Port ACL)

The IPv6 PACL (Port Access Control List) is basically a regular IPv6 access-list that is
applied to a switchport (L2 interface). They only work inbound.

Configuration
Let’s look at quick example. Here’s the topology we’ll use:

We will use R1 and R2 to generate some IPv6 traffic and on SW1 we’ll configure the PACL.
Let’s configure some IPv6 addresses on R1 and R2:

R1(config)#interface FastEthernet f0/0

R1(config-if)#ipv6 address 2001:DB8:0:12::1/64

R2(config)#interface FastEthernet 0/0

R2(config-if)#ipv6 address 2001:DB8:0:12::2/64

Let’s enable HTTP server so that we have something to connect to:

R2(config)#ip http server

Without an ACL, I can connect to the telnet server (enabled by default) and the HTTP
server:

R1#telnet 2001:DB8:0:12::2
Trying 2001:DB8:0:12::2 ... Open
R1#telnet 2001:DB8:0:12::2 80
Trying 2001:DB8:0:12::2, 80 ... Open

Let’s create an access-list that denies telnet traffic and permits everything else:

SW1(config)#ipv6 access-list NO_TELNET

SW1(config-ipv6-acl)#deny tcp any host 2001:DB8:0:12::2 eq 23
SW1(config-ipv6-acl)#permit ipv6 any any

We can see the access-list we created with the show ipv6 access-list command:

SW1#show ipv6 access-list

IPv6 access list NO_TELNET
deny tcp any host 2001:DB8:0:12::2 eq telnet sequence 10
permit ipv6 any any sequence 20

You can also use show access-list without “ipv6” and it will show up.

Let’s activate the access-list on the GigabitEthernet 0/1 interface that connects to R1:

SW1(config)#interface GigabitEthernet 0/1

SW1(config-if)#ipv6 traffic-filter NO_TELNET in

Now, from R1 I’ll try to connect to the telnet and HTTP server on R2:

R1#telnet 2001:DB8:0:12::2
Trying 2001:DB8:0:12::2 ...
% Connection timed out; remote host not responding
R1#telnet 2001:DB8:0:12::2 80
Trying 2001:DB8:0:12::2, 80 ... Open

As you can see, telnet traffic is no longer permitted.

Unfortunately, hits don’t show in the access-list:

SW1#show ipv6 access-list

IPv6 access list NO_TELNET
deny tcp any host 2001:DB8:0:12::2 eq telnet sequence 10
permit ipv6 any any sequence 20

There is the debug ipv6 access-list command but it doesn’t seem to work for PACLs, it only
works when you apply an access-list to a routed (L3) interface.

hostname R1
!
ip cef
!
interface FastEthernet0/0
ipv6 address 2001:DB8:0:12::1/64
!
end
hostname R2
!
ip cef
!
interface FastEthernet0/0
ipv6 address 2001:DB8:0:12::2/64
!
ip http server
!
end

hostname SW1
!
interface GigabitEthernet0/1
ipv6 traffic-filter NO_TELNET in
!
interface GigabitEthernet0/2
!
ipv6 access-list NO_TELNET
deny tcp any host 2001:DB8:0:12::2 eq telnet
permit ipv6 any any
!
end

Conclusion
You have now learned how to configure the IPv6 PACL (Port ACL) on a Cisco switch. I
hope you enjoyed this lesson. If you have any questions feel free to leave a comment!
Cisco Storm-Control Configuration
One security issue that has to do with flooding is called a broadcast storm. When we have
an excessive amount of broadcast traffic on the network then all devices within the
broadcast domain will suffer. The switch has to flood all broadcast frames to interfaces in
the same VLAN, hosts within the VLAN might have to process these frames (ARP requests
for example).
Too much broadcast traffic could be caused by malicious software but also by a
malfunctioning NIC. To protect ourselves against this, Cisco switches offer the storm-
control feature. We can configure a threshold on interfaces to set a limit to the number of
broadcast, multicast or unknown unicast traffic and an action when the threshold is
exceeded.
Here’s an example how to configure this:

SW1(config-if)#storm-control ?
action Action to take for storm-control
broadcast Broadcast address storm control
multicast Multicast address storm control
unicast Unicast address storm control

We can set an action and threshold for broadcast, multicast or unknown unicast traffic. Let’s
take a look at broadcast traffic:

SW1(config)#interface FastEthernet0/1
SW1(config-if)#storm-control broadcast level ?
<0.00 - 100.00> Enter rising threshold
bps Enter suppression level in bits per second
pps Enter suppression level in packets per second
I have a couple of options here…when you use the rising threshold then the value you enter
is a percentage of the interface bandwidth. The other two options are BPS (bits per second)
or PPS (packets per second). Let’s start with a simple example:

SW1(config-if)#storm-control broadcast level 30

Whenever broadcast traffic exceeds 30% of the interface bandwidth, we will take action. I
didn’t configure any action yet but the default action will drop exceeding traffic.
Let’s look at an example for multicast:

SW1(config-if)#storm-control multicast level bps ?

<0.0 - 10000000000.0>[k|m|g] Enter rising threshold

Now I can select a threshold in BPS. You can use K,M or G to indicate Kbps, Mbps or
Gbps. Let’s pick something:

SW1(config-if)#storm-control multicast level bps 10m

Once multicast exceeds 10Mbps, it will be dropped. In the previous examples I only
configured a rising threshold. This means that once we exceed the threshold, the traffic
will be dropped. Once we are below this threshold it will be permitted. We can also use
a falling threshold:

SW1(config-if)#storm-control unicast level pps 30m 20m

Here’s an example for unknown unicast traffic and PPS. The rising threshold is 30Mbps,
once we get above this then the traffic will be dropped. The falling threshold is 20Mbps
which means that the amount of traffic has to be below 20Mbps before we permit it again.
Last but not least, we can change the action:

SW1(config-if)#storm-control action ?
 shutdown Shutdown this interface if a storm occurs
trap Send SNMP trap if a storm occurs

By default the exceeding traffic is dropped but we can also choose to shutdown the
interface or to send a SNMP trap.

SW1(config-if)#storm-control action trap

To verify our work we can use the show storm-control command:

SW1#show storm-control
Interface Filter State Upper Lower Current
--------- ------------- ----------- ----------- ----------
Fa0/1 Forwarding 30.00% 30.00% 0.00%

This only gives us the information for broadcast traffic. If we want to verify our settings for
unicast or multicast traffic then we have to add a parameter:

SW1#show storm-control multicast

Interface Filter State Upper Lower Current
--------- ------------- ----------- ----------- ----------
Fa0/1 Forwarding 10m bps 10m bps 0 bps
SW1#show storm-control unicast
Interface Filter State Upper Lower Current
--------- ------------- ----------- ----------- ----------
Fa0/1 Forwarding 30m pps 20m pps 0 pps

These commands are also useful to see the current traffic levels. These will help to make
up a baseline for the thresholds that you want to use.

hostname SW1
!
interface FastEthernet0/1
 storm-control broadcast level 30.00
storm-control multicast level bps 10m
storm-control unicast level pps 30m 20m
storm-control action trap
!
end

DHCP Snooping
DHCP snooping is a technique where we configure our switch to listen in on DHCP traffic
and stop any malicious DHCP packets. This is best explained with an example so take a
look at the picture below:

In the picture above I have a DHCP server connected to the switch on the top left. At the
bottom right you see a legitimate client that would like to get an IP address. What if  the l33t
hacker script kiddy on the left would run DHCP server software on his computer? Who do
you think will respond first to the DHCP discover message? The legitimate DHCP server or
the script kiddy’s DHCP server software?
On larger networks you will probably find a central DHCP server somewhere in the server
farm. If an attacker runs a DHCP server in the same subnet he will probably respond faster
to the DHCP discover message of the client. If this succeeds he might assign the client with
its own IP address as the default gateway for a man-in-the-middle attack. Another option
would be to send your own IP address as the DNS server so you can spoof websites etc.
The attacker could also send DHCP discover messages to the DHCP server and try to
deplete its DHCP pool. So what can we do to stop this madness? DHCP snooping to the
rescue! We can configure our switches so they track the DHCP discover and DHCP
offer messages. Here’s how:

Interfaces that connect to clients should never be allowed to send a DHCP offer message.
We can enforce this by making them untrusted. An interface that is untrusted will block
DHCP offer messages. Only an interface that has been configured as trusted is allowed to
forward DHCP offer messages. We can also rate-limit interfaces to they can’t send an
unlimited amount of DHCP discover messages, this will prevent attacks from depleting the
DHCP pool.
When a Cisco Catalyst Switch receives a DHCP Discover, it will only forward it on trusted
interfaces. This prevents rogue DHCP servers on untrusted interfaces from receiving it in
the first place.
Let’s see how we can configure DHCP snooping…

Configuration
I will use the following topology:

Interface fa0/1 is connected to a client that would like to get an IP address from the DHCP
server connected to interface fa0/2. There’s an attacker connected to fa0/3 that is running
DHCP server software. Let’s see if we can stop him…

SW1(config)#ip dhcp snooping

First you need to enable DHCP snooping globally.

SW1(config)#no ip dhcp snooping information option

By default the switch will add option 82 to the DHCP discover message before passing it
along to the DHCP server. Some DHCP servers don’t like this and will drop the packet. If
you client doesn’t get an IP address anymore after enabling DHCP snooping globally you
should use this command.

SW1(config)#ip dhcp snooping vlan 1

Select the VLANs for which you want to use DHCP snooping.

SW1(config)#interface fa0/2
SW1(config-if)#ip dhcp snooping trust

Once you enable DHCP snooping all interfaces by default are untrusted. Make sure
interfaces that lead to the DHCP server are trusted.

SW1(config)#interface fa0/1
SW1(config-if)#ip dhcp snooping limit rate 10

Optionally you can rate-limit the number of DHCP packets that the interface can receive.
I’ve set the fa0/1 interface so it can’t receive more than 10 DHCP packets per second.

SW1#show ip dhcp snooping

Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
1
DHCP snooping is operational on following VLANs:
1
DHCP snooping is configured on the following L3 Interfaces:

Insertion of option 82 is enabled

circuit-id format: vlan-mod-port
remote-id format: MAC
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Verification of giaddr field is enabled
DHCP snooping trust/rate is configured on the following Interfaces:

Interface Trusted Rate limit (pps)

------------------------ ------- ----------------
FastEthernet0/1 no 10
FastEthernet0/2 yes unlimited

Use the show ip dhcp snooping command to verify your configuration.

SW1#show ip dhcp snooping binding

MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ----
--------------------
00:0C:29:28:5C:6C 192.168.1.1 85655 dhcp-snooping 1
FastEthernet0/1

Once your client receives an IP address from the legit DHCP server you can see SW1
keeps track of the MAC to IP binding. DHCP offer messages from the DHCP server on the
untrusted interface will be dropped. I hope this lesson has been useful for you to understand
DHCP snooping.

hostname SW1
!
ip dhcp snooping vlan 1
no ip dhcp snooping information option
ip dhcp snooping
!
interface FastEthernet0/1
ip dhcp snooping limit rate 10
!
interface FastEthernet0/2
ip dhcp snooping trust
!
interface Vlan1
ip address dhcp
!
end

IP Source Guard (IPSG)

IP Source Guard prevents IP and/or MAC address spoofing attacks on untrusted layer two
interfaces.
When IP source guard is enabled, all traffic is blocked except for DHCP packets. Once the
host gets an IP address through DHCP, only the DHCP-assigned source IP address is
permitted. You can also configure a static binding instead of using DHCP.
Source guard is not a standalone tool. It relies on the information in the DHCP
snooping database to do its work. You can only use this on layer two (access and trunk)
interfaces and it only works inbound.

Configuration
Let’s see how we can configure IP source guard. I’ll use the following topology:
  H1 is a legitimate host that receives its IP address through DHCP.
 H2 is an attacker that tries to spoof its source IP address.
 S1 is a server with a static IP address.
 R1 assigns IP addresses through DHCP.
 SW1 is pre-configured with DHCP snooping. We will configure IP source guard on
this switch.

hostname H1
!
ip cef
!
interface FastEthernet0/0
ip address dhcp
!
end

hostname H2
!
ip cef
!
interface FastEthernet0/0
ip address 192.168.1.2 255.255.255.0
!
end

hostname S1
!
ip cef
!
interface FastEthernet0/0
ip address 192.168.1.200 255.255.255.0
!
end

hostname R1
!
ip dhcp pool MY_POOL
network 192.168.1.0 255.255.255.0
!
ip cef
!
interface FastEthernet0/0
ip address 192.168.1.254 255.255.255.0
!
end
hostname SW1
!
ip dhcp snooping vlan 1
no ip dhcp snooping information option
ip dhcp snooping
!
interface GigabitEthernet0/1
switchport mode access
spanning-tree portfast
!
interface GigabitEthernet0/2
switchport mode access
spanning-tree portfast
!
interface GigabitEthernet0/3
switchport mode access
spanning-tree portfast
!
interface GigabitEthernet0/4
switchport mode access
spanning-tree portfast
ip dhcp snooping trust
!
end

Let’s take a look at what we have. H1 receives an IP address through DHCP from R1:

H1#show ip interface brief | include DHCP

FastEthernet0/0 192.168.1.1 YES DHCP up up

We can see a binding in the DHCP snooping binding table:

SW1#show ip source binding

MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ----
--------------------
00:1D:A1:8B:36:D0 192.168.1.1 86316 dhcp-snooping 1
GigabitEthernet0/1
Total number of bindings: 1

This information is important. We need it to make IP source guard work.

DHCP Binding
Let’s configure IP Source guard. We’ll start with the interface that connects to H1. To enable
this, you only need a single command:

SW1(config)#interface GigabitEthernet 0/1

SW1(config-if)#ip verify source

We can verify that it is enabled for the interface that connects to H1:

SW1#show ip verify source

Interface Filter-type Filter-mode IP-address Mac-address Vlan Log
--------- ----------- ----------- --------------- ----------------- ---- ---
Gi0/1 ip active 192.168.1.1 1
disabled

SW1 now only permits source IP address 192.168.1.1 on the GigabitEthernet 0/1 interface.
The MAC address field is empty so right now, the switch only checks the source IP address.
We can also check the source MAC address though. IP source guard uses port-security for
this. Here’s how to enable it:

SW1(config)#interface GigabitEthernet 0/1

SW1(config-if)#switchport port-security
SW1(config-if)#ip verify source port-security
First, we enable port-security and then we add the port-security parameter to our ip
verify source command. The MAC address now shows up in the table:

SW1#show ip verify source

Interface Filter-type Filter-mode IP-address Mac-address Vlan Log
--------- ----------- ----------- --------------- ----------------- ---- ---
Gi0/1 ip-mac active 192.168.1.1 00:1D:A1:8B:36:D0 1
disabled

SW1 now only permits the source IP address and source MAC address that we see in the
table above. Let’s do a quick test, let’s see if H1 can still ping R1:

H1#ping 192.168.1.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

This is working, great. Let’s add the exact same commands on H2:

SW1(config)#interface GigabitEthernet 0/2

SW1(config-if)#switchport port-security
SW1(config-if)#ip verify source port-security

H2 has a static IP address. Let’s check the table on SW1 again:

SW1#show ip verify source

Interface Filter-type Filter-mode IP-address Mac-address Vlan Log
--------- ----------- ----------- --------------- ----------------- ---- ---
Gi0/1 ip-mac active 192.168.1.1 00:1D:A1:8B:36:D0 1
disabled
Gi0/2 ip-mac active deny-all deny-all 1
There is no known source IP and/or MAC address known on the GigabitEthernet 0/2
interface so SW1 will drop everything. Let’s see if this is true, we can see it in action with a
debug:

SW1#debug ip verify source packet

Ip source guard debug packet debugging is on

Let’s send an IP packet from H2 to R1:

H2#ping 192.168.1.254 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.1.254, timeout is 2 seconds:
.
Success rate is 0 percent (0/1)

This ping fails and SW1 will show us the following output:

SW1#
DHCP_SECURITY_SW: validate port security packet, recv port: GigabitEthernet0/2, recv
vlan: 1, mac: 0017.5aed.7af0, invalid flag: 1.

Great, this proves that IP source guard is working for us.

Static Binding
What about that server? It’s a legitimate device but it has a static IP address. Fortunately,
we can create a static binding. Let’s check the MAC address of S1:

S1#show interfaces FastEthernet 0/0 | include bia

 Hardware is MV96340 Ethernet, address is 0016.c7be.0ec8 (bia 0016.c7be.0ec8)

We can use this to create a static binding for the IP address and MAC address of S1.
Here’s how:

SW1(config)#ip source binding 0016.c7be.0ec8 vlan 1 192.168.1.200 interface

GigabitEthernet 0/3

Let’s add the same commands we used for H1 and H2 on the interface that connects to S1:

SW1(config)#interface GigabitEthernet 0/3

SW1(config-if)#switchport port-security
SW1(config-if)#ip verify source port-security

Now check the table on SW1:

SW1#show ip verify source

Interface Filter-type Filter-mode IP-address Mac-address Vlan Log
--------- ----------- ----------- --------------- ----------------- ---- ---
Gi0/1 ip-mac active 192.168.1.1 00:1D:A1:8B:36:D0 1
disabled
Gi0/2 ip-mac active deny-all deny-all 1
Gi0/3 ip-mac active 192.168.1.200 00:16:C7:BE:0E:C8 1
disabled

This is looking good, we have a matching entry for the IP address of S1. Let’s try a quick
ping:

S1#ping 192.168.1.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Excellent, this proves our static binding is working!

hostname H1
!
ip cef
!
interface FastEthernet0/0
ip address dhcp
!
end

hostname H2
!
ip cef
!
interface FastEthernet0/0
ip address 192.168.1.2 255.255.255.0
!
end

hostname S1
!
ip cef
!
interface FastEthernet0/0
ip address 192.168.1.200 255.255.255.0
!
end
hostname SW1
!
ip dhcp snooping vlan 1
no ip dhcp snooping information option
ip dhcp snooping
!
interface GigabitEthernet0/1
switchport mode access
switchport port-security
spanning-tree portfast
ip verify source port-security
!
interface GigabitEthernet0/2
switchport mode access
switchport port-security
spanning-tree portfast
ip verify source port-security
!
interface GigabitEthernet0/3
switchport mode access
switchport port-security
spanning-tree portfast
ip verify source port-security
!
interface GigabitEthernet0/4
switchport mode access
spanning-tree portfast
ip dhcp snooping trust
!
ip source binding 0016.C7BE.0EC8 vlan 1 192.168.1.200 interface Gi0/3
!
end
Conclusion
You have now learned how IP Source Guard prevents IP and/or MAC address spoofing
attacks on layer two switch interfaces. I hope you enjoyed this lesson. If you have any
questions feel free to leave a comment!

DAI (Dynamic ARP Inspection)

Dynamic ARP Inspection (DAI) is a security feature that protects ARP (Address Resolution
Protocol) which is vulnerable to an attack like ARP poisoning.
DAI checks all ARP packets on untrusted interfaces, it will compare the information in the
ARP packet with the DHCP snooping database and/or an ARP access-list. If the information
in the ARP packet doesn’t matter, it will be dropped. In this lesson I’ll show you how to
configure DAI. Here’s the topology we will use:

Above we have four devices, the router on the left side called “host” will be a DHCP client,
the router on the right side is our DHCP server and on top we have a router that will be
used as an attacker. The switch in the middle will be configured for dynamic ARP
inspection.

Configuration
We’ll start with the switch, first we need to make sure that all interfaces are in the same
VLAN:
SW1(config)#interface range fa0/1 - 3

SW1(config-if-range)#switchport mode access

SW1(config-if-range)#switchport access vlan 123

SW1(config-if-range)#spanning-tree portfast

Now we can configure DHCP snooping:

SW1(config)#ip dhcp snooping

SW1(config)#ip dhcp snooping vlan 123
SW1(config)#no ip dhcp snooping information option

The commands above will enable DHCP snooping globally, for VLAN 123 and disables the
insertion of option 82 in DHCP packets. Don’t forget to make the interface that connects to
the DHCP server trusted:

SW1(config)#interface FastEthernet 0/3

SW1(config-if)#ip dhcp snooping trust

The switch will now keep track of DHCP messages. Let’s configure a DHCP server on the
router on the right side:

DHCP(config)#ip dhcp pool MY_POOL

DHCP(dhcp-config)#network 192.168.1.0 255.255.255.0

That’s all we need, let’s see if the host is able to get an IP address:

HOST(config)#interface FastEthernet 0/0

HOST(config-if)#ip address dhcp
A few seconds later we see this message:

%DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 192.168.1.1,

mask 255.255.255.0, hostname HOST

Let’s check if our switch has stored something in the DHCP snooping database:

SW1#show ip dhcp snooping binding

MacAddress IpAddress Lease(sec) Type VLAN
Interface
------------------ --------------- ---------- ------------- ----
--------------------
00:1D:A1:8B:36:D0 192.168.1.1 86330 dhcp-snooping 123
FastEthernet0/1
Total number of bindings: 1

There it is, an entry with the MAC address and IP address of our host. Now we can continue
with the configuration of DAI. There’s only one command required to activate it:

SW1(config)#ip arp inspection vlan 123

The switch will now check all ARP packets on untrusted interfaces, all interfaces are
untrusted by default. Let’s see if this will work or not…I’ll configure the IP address of our
host on our attacker:

ATTACK(config)#interface FastEthernet 0/0

ATTACK(config-if)#ip address 192.168.1.1 255.255.255.0
Now let’s see what happens when we try to send a ping from the attacker to our DHCP
router:

ATTACK#ping 192.168.1.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.254, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

The ping is failing…what does our switch think of this?

SW1#
%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Fa0/2, vlan 123.
([0017.5aed.7af0/192.168.1.1/0000.0000.0000/192.168.1.254/01:20:08 UTC
Tue Mar 2 1993])
%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Fa0/2, vlan 123.
([0017.5aed.7af0/192.168.1.1/0000.0000.0000/192.168.1.254/01:20:10 UTC
Tue Mar 2 1993])
%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Fa0/2, vlan 123.
([0017.5aed.7af0/192.168.1.1/0000.0000.0000/192.168.1.254/01:20:10 UTC
Tue Mar 2 1993])
%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Fa0/2, vlan 123.
([0017.5aed.7af0/192.168.1.1/0000.0000.0000/192.168.1.254/01:20:10 UTC
Tue Mar 2 1993])

Above you can see that all ARP requests from our attacker are dropped. The switch checks
the information found in the ARP request and compares it with the information in the DHCP
snooping database. Since it doesn’t match, these packets are discarded. You can find the
number of dropped ARP packets with the following command:
SW1#show ip arp inspection

Source Mac Validation : Disabled

Destination Mac Validation : Disabled
IP Address Validation : Disabled

Vlan Configuration Operation ACL Match Static ACL

---- ------------- --------- --------- ----------
123 Enabled Active

Vlan ACL Logging DHCP Logging Probe Logging

---- ----------- ------------ -------------
123 Deny Deny Off

Vlan Forwarded Dropped DHCP Drops ACL Drops

---- --------- ------- ---------- ---------
123 0 5 5 0

Vlan DHCP Permits ACL Permits Probe Permits Source MAC Failures
---- ------------ ----------- ------------- -------------------
123 0 0 0 0

Vlan Dest MAC Failures IP Validation Failures Invalid Protocol Data

---- ----------------- ---------------------- ---------------------

Vlan Dest MAC Failures IP Validation Failures Invalid Protocol Data

---- ----------------- ---------------------- ---------------------
123 0 0 0

Above you see the number of drops increase. So far so good, our attacker has been
stopped. We still have one problem though, let me first shut the interface on our attacker
before we continue:

ATTACK(config)#interface FastEthernet 0/0

ATTACK(config-if)#shutdown

Let me show you what happens when we try to send a ping from the host to our DHCP
router:

HOST#ping 192.168.1.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.254, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

This ping is failing but why? We are not spoofing anything…here’s what the switch tells us:

SW1#
%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa0/3, vlan 123.
([0016.c7be.0ec8/192.168.1.254/001d.a18b.36d0/192.168.1.1/01:24:48 UTC
Tue Mar 2 1993])
%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa0/3, vlan 123.
([0016.c7be.0ec8/192.168.1.254/001d.a18b.36d0/192.168.1.1/01:24:50 UTC
Tue Mar 2 1993])
%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa0/3, vlan 123.
([0016.c7be.0ec8/192.168.1.254/001d.a18b.36d0/192.168.1.1/01:24:52 UTC
Tue Mar 2 1993])
%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa0/3, vlan 123.
([0016.c7be.0ec8/192.168.1.254/001d.a18b.36d0/192.168.1.1/01:24:54 UTC
Tue Mar 2 1993])
%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa0/3, vlan 123.
([0016.c7be.0ec8/192.168.1.254/001d.a18b.36d0/192.168.1.1/01:24:56 UTC
Tue Mar 2 1993])
Our switch is dropping ARP replies from the DHCP router to our host. Since the DHCP
router has no idea how to reach the host, the ping is failing:

HOST#show ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.1 - 001d.a18b.36d0 ARPA FastEthernet0/0
Internet 192.168.1.254 0 Incomplete ARPA
DHCP#show ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.1 0 001d.a18b.36d0 ARPA FastEthernet0/0
Internet 192.168.1.254 - 0016.c7be.0ec8 ARPA FastEthernet0/0

Why is the switch dropping the ARP reply? The problem is that the DHCP router is using a
static IP addresses. DAI checks the DHCP snooping database for all packets that arrive on
untrusted interfaces, when it doesn’t find a match…the ARP packet is dropped. To fix this,
we need to create a static entry for our DHCP router:

SW1(config)#arp access-list DHCP_ROUTER

SW1(config-arp-nacl)#permit ip host 192.168.1.254 mac host 0016.c7be.0ec8

First we create an ARP access-list with a permit statement for the IP address and MAC
address of the DHCP router. Now we need to apply this to DAI:

SW1(config)#ip arp inspection filter DHCP_ROUTER vlan 123 ?

static Apply the ACL statically

We use the ip arp inspection filter command for this but you have to be careful…if you
use the “static” parameter then we tell the switch not to check the DHCP snooping
database. It will only check our ARP access-list and when it doesn’t find an entry, the ARP
packet will be dropped. Make sure you add the filter without the static parameter:
SW1(config)#ip arp inspection filter DHCP_ROUTER vlan 123

There we go. The switch will now check the ARP access-list first and when it doesn’t find a
match, it will check the DHCP snooping database. Let’s try that ping again:

HOST#ping 192.168.1.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.254, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms

Excellent our ping is now working because of the static entry for the DHCP router. Another
way to deal with this issue is to configure the interface as trusted. DAI will allow all ARP
packets on trusted interfaces:

SW1(config)#interface FastEthernet 0/3

SW1(config-if)#ip arp inspection trust

Anything else we can do with DAI? There are some additional security checks you can
enable if you want:

SW1(config)#ip arp inspection validate ?

dst-mac Validate destination MAC address
ip Validate IP addresses
src-mac Validate source MAC address

Here’s what these options mean:

 dst-mac: checks the destination MAC address in the Ethernet header against the
target MAC address in the ARP packet. This check is performed for ARP replies.
ARP replies with different MAC addresses will be dropped.
  ip: checks for invalid and unexpected IP addresses. For example 0.0.0.0,
255.255.255.255 and multicast addresses.
 src-mac: checks the source MAC address in the Ethernet header against the
sender’s MAC address in the ARP packet. This check is performed for both ARP
requests and replies. ARP packets with different MAC addresses will be dropped.
 You can only enable one of these options at the same time. Here’s an example how
to enable the dst-mac check:

SW1(config)#ip arp inspection validate dst-mac

Last but not least, we can also configure ARP rate-limiting. By default there is a limit of 15
pps for ARP traffic on untrusted interfaces. Here’s how you can change it:

SW1(config)#interface FastEthernet 0/1

SW1(config-if)#ip arp inspection limit rate 10

This interface now only allows 10 ARP packets per second.

Conclusion
That’s all we have for DAI (Dynamic ARP Inspection). It’s a nice security feature but  make
sure that you have ARP access-lists in place for all devices with static IP addresses before
you enable this. You don’t want to block most of your traffic after enabling this.

hostname SW1
!
ip dhcp snooping vlan 123
no ip dhcp snooping information option
ip dhcp snooping
ip arp inspection vlan 123
ip arp inspection validate src-mac
!
interface FastEthernet0/1
switchport access vlan 123
switchport mode access
ip arp inspection limit rate 10
spanning-tree portfast
!
interface FastEthernet0/2
switchport access vlan 123
switchport mode access
spanning-tree portfast
!
interface FastEthernet0/3
switchport access vlan 123
switchport mode access
ip arp inspection trust
spanning-tree portfast
ip dhcp snooping trust
!
arp access-list DHCP_ROUTER
permit ip host 192.168.1.254 mac host 0016.c7be.0ec8
!
ip arp inspection filter DHCP_ROUTER vlan 123
!
end

hostname HOST
!
interface FastEthernet0/0
ip address dhcp
duplex auto
speed auto
!end

hostname ATTACK
!
interface FastEthernet0/0
ip address 192.168.1.2 255.255.255.0
shutdown
duplex auto
speed auto
!
end

hostname DHCP
!
ip dhcp pool MY_POOL
network 192.168.1.0 255.255.255.0
!
interface FastEthernet0/0
ip address 192.168.1.254 255.255.255.0
duplex auto
speed auto
!
end

How to configure port-security on Cisco Switch

By default there is no limit to the number of MAC addresses a switch can learn on an
interface and all MAC addresses are allowed. If we want we can change this behavior
with port-security. Let’s take a look at the following situation:
In the topology above someone connected a cheap (unmanaged) switch that they brought
from home to the FastEthernet 0/1 interface of our Cisco switch. Sometimes people like to
bring an extra switch from home to the office. As a result our Cisco switch will learn the
MAC address of H1 and H2 on its FastEthernet 0/1 interface.
Of course we don’t want people to bring their own switches and connect it to our network so
we want to prevent this from happening. This is how we can do it:

Switch(config)#interface fa0/1
Switch(config-if)#switchport port-security
Switch(config-if)#switchport port-security maximum 1

Use the switchport port-security command to enable port-security. I have configured port-

security so only one MAC address is allowed. Once the switch sees another MAC address
on the interface it will be in violation and something will happen. I’ll show you what
happens in a bit…
Besides setting a maximum on the number of MAC addresses we can also use port security
to filter MAC addresses. You can use this to only allow certain MAC addresses. In the
example above I configured port security so it only allows MAC address aaaa.bbbb.cccc.
This is not the MAC address of my computer so it’s perfect to demonstrate a violation.

Switch(config)#interface fa0/1
Switch(config-if)#switchport port-security mac-address aaaa.bbbb.cccc

Use the switchport port-security mac-address command to define the MAC address that

you want to allow. Now we’ll generate some traffic to cause a violation:

 C:\Documents and Settings\H1>ping 1.2.3.4

I’m pinging to some bogus IP address…there is nothing that has IP address 1.2.3.4; I just
want to generate some traffic. Here’s what you will see:
 SwitchA#
%PM-4-ERR_DISABLE: psecure-violation error detected on Fa0/1, putting
Fa0/1 in err-disable state
%PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused
by MAC address 0090.cc0e.5023 on port FastEthernet0/1.
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed
state to down
%LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to down

We have a security violation and as a result the port goes in err-disable state. As you can
see it is now down. Let’s take a closer look at port-security:

 Switch#show port-security interface fa0/1

Port Security              : Enabled
Port Status                : Secure-shutdown
Violation Mode             : Shutdown
Aging Time                 : 0 mins
Aging Type                 : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 1
Configured MAC Addresses   : 1
Sticky MAC Addresses       : 0
Last Source Address:Vlan   : 0090.cc0e.5023:1
Security Violation Count   : 1
Here is a useful command to check your port security configuration. Use show port-
security interface to see the port security details per interface. You can see the violation
mode is shutdown and that the last violation was caused by MAC address 0090.cc0e.5023
(H1).

Switch#show interfaces fa0/1

FastEthernet0/1 is down, line protocol is down (err-disabled)

Shutting the interface after a security violation is a good idea (security-wise) but the problem
is that the interface will stay in err-disable state. This probably means another call to the
helpdesk and you bringing the interface back to the land of the living! Let’s activate it again:

Switch(config)#interface fa0/1
Switch(config-if)#shutdown
Switch(config-if)#no shutdown

To get the interface out of err-disable state you need to type “shutdown” followed by “no
shutdown”. Only typing “no shutdown” is not enough!
It might be easier if the interface could recover itself after a certain time. You can enable
this with the following command:

Switch(config)#errdisable recovery cause psecure-violation

After 5 minutes (300 seconds) it will automatically recover from err-disable state. Make sure
you solve the problem though because otherwise it will just have another violation and end
up in err-disable state again. You can speed this up by changing the timer. Let’s set it to 30
seconds:

SW1(config)#errdisable recovery interval 30

Instead of typing in the MAC address ourselves we can also make the switch learn a MAC
address for port-security:

Switch(config-if)#no switchport port-security mac-address aaaa.bbbb.cccc

Switch(config-if)#switchport port-security mac-address sticky

The sticky keyword will make sure that the switch uses the first MAC address that it learns
on the interface for port-security. Let’s verify it:

Switch#show run interface fa0/1

Building configuration...
Current configuration : 228 bytes
!
interface FastEthernet0/1
switchport mode access
switchport port-security
switchport port-security mac-address sticky
switchport port-security mac-address sticky 000c.2928.5c6c

You can see that it will save the MAC address of H1 in the running-configuration by itself.
Shutting the interface in case of a violation might be a bit too much. There are other options,
here’s what you can do:

Switch(config-if)#switchport port-security violation ?

  protect   Security violation protect mode
  restrict  Security violation restrict mode
  shutdown  Security violation shutdown mode

There are other options like protect and restrict.

 Protect: Ethernet frames from MAC addresses that are not allowed will be dropped
but you won’t receive any logging information.
 Restrict: Ethernet frames from MAC addresses that are not allowed will be dropped
but you will see logging information and a SNMP trap is sent.
  Shutdown: Ethernet frames from MAC addresses that are not allowed will cause the
interface to go to err-disable state. You will see logging information and a SNMP trap
is sent. For recovery you have two options:
o Manual: recover the interface yourself with a “shutdown” and “no shutdown”.
o Automatic: use the errdisable recovery commands to enable and tune
automatic recovery.

hostname Switch
!
interface fastEthernet0/1
switchport port-security
switchport port-security maximum 1
switchport port-security mac-address sticky
switchport port-security violation shutdown
!
errdisable recovery cause psecure-violation
!
end

Private VLAN (PVLAN) on Cisco IOS Switch

In a previous lesson, I explained the protected port feature on Cisco Catalyst Switches. This
time we will look at the private VLAN which I can best describe as protected ports on
steroids. If you have no idea what a protected port or VLAN is, I highly recommend to read
my previous lesson first. Having said that, let’s get started with a nice topology picture:
Many network students believe private VLANs are very complex when they see this for the
first time. I’m going to break it down and explain to you how it works.
The private VLAN always has one primary VLAN. Within the primary VLAN you will find
the promiscuous port. In my picture above you can see that there’s a router connected to a
promiscuous port. All other ports are able to communicate with the promiscuous port.
Within the primary VLAN you will encounter one or more secondary VLANs, there are two
types:
 Community VLAN: All ports within the community VLAN are able to communicate
with each other and the promiscuous port.
 Isolated VLAN: All ports within the isolated VLAN are unable to communicate with
each other but they can communicate with the promiscuous port.

The names for these secondary VLANs are well-chosen if you ask
me. In a community, everyone is able to talk to each other. When you
are isolated you can only talk to yourself or in case of our private
VLANs…the promiscuous port.

Secondary VLANS can always communicate with the promiscuous port but they can never
communicate with other secondary VLANs! Are you following me so far? If so…good! If
you are still a little fuzzy, don’t worry. I’m going to show you the configuration and
demonstrate to you how this works.
Configuration
First let me show you the topology that I will use for this demonstration:

Let me sum up what we have here:

 The primary VLAN has number 500.
 The secondary community VLAN has number 501.
 The secondary isolated VLAN has number 502.
 I just made up these VLAN numbers; you can use whatever you like.
 H1 and H2 in the community VLAN should be able to reach each other and also the
server connected to the promiscuous port.
 H3 and H4 in the isolated VLAN can only communicate with the server on the
promiscuous port.
 The server should be able to reach all ports.

Let’s get started!

SW1(config)#vtp mode transparent

Setting device to VTP TRANSPARENT mode.

Configuring private VLANs requires us to change the VTP mode to Transparent.

SW1(config)#vlan 501
SW1(config-vlan)#private-vlan community
SW1(config-vlan)#vlan 500
SW1(config-vlan)#private-vlan primary
SW1(config-vlan)#private-vlan association add 501

Let’s start with the configuration of the community VLAN. First I create VLAN 501 and tell
the switch that this is a community VLAN by typing the private-vlan community command.
Secondly I am creating VLAN 500 and configuring it as the primary VLAN with the private-
vlan primary command. Last but not least I need to tell the switch that VLAN 501 is a
secondary VLAN by using the private-vlan association command.

SW1(config)#interface range fa0/1 - 2

SW1(config-if-range)#switchport mode private-vlan host
SW1(config-if-range)#switchport private-vlan host-association 500 501

Interface fa0/1 and fa0/2 are connected to H1 and H2 and belong to the community VLAN
501. On the interface level I need to tell the switch that these are host ports by issuing
the switchport mode private-vlan host command. I also have to use the switchport
private-vlan host-association command to tell the switch that VLAN 500 is the primary
VLAN and 501 is the secondary VLAN.

SW1(config)#interface fa0/24
SW1(config-if)#switchport mode private-vlan promiscuous
SW1(config-if)#switchport private-vlan mapping 500 501

This is how I configure the promiscuous port. First I have to tell the switch that fa0/24 is a
promiscuous port by typing the switchport mode private-vlan promiscuous command. I also
have to map the VLANs by using the switchport private-vlan mapping command. Here is the
output for FastEthernet 0/1:

SW1#show interfaces fastEthernet 0/1 switchport

Name: Fa0/1
Switchport: Enabled
Administrative Mode: private-vlan host
Operational Mode: down
Administrative Trunking Encapsulation: negotiate
Negotiation of Trunking: Off
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: 500 (VLAN0500) 501 (VLAN0501)
Administrative private-vlan mapping: none

We can verify our configuration by looking at the switchport information. Interface fa0/2 has
the same configuration as fa0/1.

SW1#show interface fa0/24 switchport

Name: Fa0/24
Switchport: Enabled
Administrative Mode: private-vlan promiscuous
Operational Mode: private-vlan promiscuous
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: 500 (VLAN0500) 501 (VLAN0501)

Here is the switchport information for fa0/24 (our promiscuous port). You can see the
mapping information.
SW1#show vlan private-vlan
Primary Secondary Type Ports
------- --------- -----------------
-----------------------------------------
-
500 501 community Fa0/1, Fa0/2, Fa0/24

The show vlan private-vlan command gives us valuable information. You can see that VLAN
500 is the primary VLAN and 501 is the secondary VLAN. It also tells us whether the
VLAN is a community or isolated VLAN the ports.

If everything is OK we should now have a working community VLAN…let’s find out!

C:Documents and SettingsH1>ping 192.168.1.2

Pinging 192.168.1.2 with 32 bytes of data:
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128

H1 is able to reach H2.

C:Documents and SettingsH1>ping 192.168.1.254

Pinging 192.168.1.254 with 32 bytes of data:
Reply from 192.168.1.254: bytes=32 time<1ms TTL=128

H1 can also reach the server behind the promiscuous port.

C:Documents and SettingsS1>ping 192.168.1.2

Pinging 192.168.1.2 with 32 bytes of data:
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128

The server is able to reach H2. Great! Our community VLAN seems to be up and running.
Let’s continue with the configuration of the isolated VLAN.
SW1(config)#vlan 502
SW1(config-vlan)#private-vlan isolated
SW1(config-vlan)#vlan 500
SW1(config-vlan)#private-vlan primary
SW1(config-vlan)#private-vlan association add 502

The configuration is the same as the community VLAN but this time I’m using the private
vlan isolated command. Don’t forget to add the association between the primary and
secondary VLAN using the private-vlan association add command. The private-vlan primary
command is obsolete because I already did this before, I’m just showing it to keep the
configuration complete.

SW1(config)#interface range fa0/3 - 4

SW1(config-if-range)#switchport mode private-vlan host
SW1(config-if-range)#switchport private-vlan host-association 500 502

This part is exactly the same as the configuration for the community VLAN but I’m
configuring interface fa0/3 and fa0/4 which are connected to H3 and H4.

SW1(config)#interface fa0/24
SW1(config-if)#switchport mode private-vlan promiscuous
SW1(config-if)#switchport private-vlan mapping 500 502

I already configured fa0/24 as a promiscuous port but I’m showing it here as well to keep

the configuration complete. I do need to create an additional mapping between VLAN 500

(primary) and VLAN 502 (secondary).

Let’s verify our work!

SW1#show interfaces fa0/3 switchport
Name: Fa0/3
Switchport: Enabled
Administrative Mode: private-vlan host
Operational Mode: down
Administrative Trunking Encapsulation: negotiate
Negotiation of Trunking: Off
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: 500 (VLAN0500) 502 (VLAN0502)
Administrative private-vlan mapping: none

Looking good…we can see the host-association between VLAN 500 and 502.

SW1#show interfaces fastEthernet 0/4 switchport | include host-as

Administrative private-vlan host-association: 500 (VLAN0500) 502 (VLAN0502)

A quick look at fa0/4 shows me the same output as fa0/3.

SW1#show interfaces fa0/24 switchport

Name: Fa0/24
Switchport: Enabled
Administrative Mode: private-vlan promiscuous
Operational Mode: private-vlan promiscuous
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: 500 (VLAN0500) 501 (VLAN0501) 502
(VLAN0502)

We can now see that VLAN 501 and VLAN 502 are mapped to primary VLAN 500.

SW1#show vlan private-vlan

Primary Secondary Type Ports
------- --------- ----------------- -----------------------------------------
-
500 501 community Fa0/1, Fa0/2, Fa0/24
500 502 isolated Fa0/3, Fa0/4, Fa0/24

Here’s a nice clean overview which shows us all the VLANs, the mappings and the
interfaces.

SW1#show vlan private-vlan type

Vlan Type
---- -----------------
500 primary
501 community
502 isolated

Or if you only care about the VLAN numbers and the VLAN type this is what you need.
What will the result be of our hard labor?

C:\Documents and Settings\H3>ping 192.168.1.254

Pinging 192.168.1.254 with 32 bytes of data:
Reply from 192.168.1.254: bytes=32 time<1ms TTL=128

H3 can reach the server behind the promiscuous port.

C:\Documents and Settings\H4>ping 192.168.1.254
Pinging 192.168.1.254 with 32 bytes of data:
Reply from 192.168.1.254: bytes=32 time<1ms TTL=128

H4 can also reach the server behind the promiscuous port.

C:\Documents and Settings\H3>ping 192.168.1.4

Pinging 192.168.1.4 with 32 bytes of data:
Request timed out.
Ping statistics for 192.168.1.4:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

There is no reachability between H3 and H4 because they are in the isolated VLAN.
What about reachability between VLAN 501 and VLAN 502? Let’s give it a try:

C:\Documents and Settings\H1>ping 192.168.1.4

Pinging 192.168.1.4 with 32 bytes of data:
Request timed out.
Ping statistics for 192.168.1.4:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

This is H1 in VLAN 501 trying to reach H4 in VLAN 502. As you can see this isn’t possible.
You are unable to communicate between different secondary VLANs.

hostname SW1
!
vtp mode transparent
!
vlan 500
 private-vlan primary
private-vlan association 501-502
!
vlan 501
private-vlan community
!
vlan 502
private-vlan isolated
!
interface FastEthernet0/1
switchport private-vlan host-association 500 501
switchport mode private-vlan host
!
interface FastEthernet0/2
switchport private-vlan host-association 500 501
switchport mode private-vlan host
!
interface FastEthernet0/3
switchport private-vlan host-association 500 502
switchport mode private-vlan host
!
interface FastEthernet0/4
switchport private-vlan host-association 500 502
switchport mode private-vlan host
!
interface FastEthernet0/24
switchport private-vlan mapping 500 501-502
switchport mode private-vlan promiscuous
!
end

That’s all I have for now about the configuration, anything else you need to know about
private VLANs?
Private VLANs can be carried over 802.1Q links so it’s possible to span your configuration
over multiple switches. In the picture above I expanded our configuration to SW2. The
configuration on SW2 will be the same as SW1. You just need to make sure that VLAN 500,
501 and 502 can be carried over the trunk between SW1 and SW2. Don’t forget that
because of VTP transparent mode, VLAN information is not synchronized between the two
switches. You’ll have to create the VLANS yourself on the other switches.
Let me give you a short overview of what you have learned by now:
 Devices within a community VLAN can communicate with each other AND the
promiscuous port.
 Devices within an isolated VLAN cannot communicate with each other and can
ONLY communicate with the promiscuous port.
 The promiscuous port can communicate with any other port.
  Secondary VLANs are unable to communicate with other secondary VLANs.
 Private VLANs can be spanned across multiple switches if you use trunks.

Introduction to Cisco IOS Access-Lists

In a perfect world where we can trust anyone and nobody makes a mistake we don’t need
security. In real life however bad things happen to our network so we’ll need to protect it.
This lesson is an introduction to access-lists and you’ll learn the difference between
standard and extended access-lists.
Access-lists work on the network (layer 3) and the transport (layer 4) layer and can be used
for two different things:
 Filtering
 Classification

Filtering is used to permit or deny traffic reaching certain parts of our network. Without
filtering traffic can go anywhere, if you look at the picture above you probably don’t want IP
packets from the internet to freely enter your network. You can also use an access-list to
block IP packets from 3.3.3.0 /24 going to 1.1.1.0 /24 or something else.
Classification does not drop IP packets like filtering does but we use it to “select” traffic. 
Let’s take a look at an example:
In the picture above we have a VPN that encrypts traffic between the two routers.
Whenever we create a VPN we can use an access-list to “select” what traffic should be
encrypted. Perhaps I want traffic from network 192.168.2.0 /24 to be encrypted but traffic
from 172.16.2.0 /24 not. We can use an access-list to “select” traffic, this is called
classification.
Let’s take a closer look at filtering. After creating an access-list there are 3 spots where you
can place them:

You can put them inbound on the interface which means that all packets that reach your
router will hit the access-list and will have to be checked against the access-list.

Another option is to put the access-list outbound. In this case IP packets will go through
the router and once they are leaving the interface they will be checked against the access-
list. When you place an access-list outbound, this is what your router will do:
 1. IP Packets will enter your router.
2. Your router will check if it knows about the destination by looking in its routing table.
3. If there is no entry in the routing table the IP packet will be discarded.
4. If there is an entry in the routing table it will select the correct outgoing interface.
5. If there is no access-list the IP packet will be sent out of the interface.
6. If there is an access-list we’ll have to check our IP packet and compare it with the
access-list.
7. If the IP packet is permitted it will be forwarded, otherwise it will be discarded and go
to IP heaven.
The third option is applying it to the VTY line. We can use this to secure telnet and/or SSH
traffic.

Let me give you an example of what an access-list looks like:

Router#show access-lists
Standard IP access list 1
10 permit 192.168.1.0, wildcard bits 0.0.0.255
20 permit 192.168.2.0, wildcard bits 0.0.0.255
30 permit 172.16.0.0, wildcard bits 0.0.255.255

Access-lists work by using statements. In the picture above you can see access-list
number 1 has 3 statements, number 10, 20 and 30. Whenever a packet hits the access-list
this is what will happen:
 Access-lists are processed top-down so we first check if the packet matches
statement 10.
 If it doesn’t match statement 10, we’ll check if it matches statement 20.
 If it doesn’t match statement 20, we’ll check if it matches statement 30.
 If it doesn’t match statement 30, the packet will be dropped.
If a packet does match a certain statement then there is immediate action. The packet will
either be permitted (forward) or denied (discarded). For example, if we have a packet that
matches statement 10 then the router will not check if it “also” matches statement 20.
At the bottom of every access-list there is a deny any which means if you didn’t explicitly
permit something it will be dropped anyway. You don’t see this deny any but it’s there!

Access-lists work in a similar way as if you are at the

airport. If you are looking at the departures sign you’ll
check all the information for your flight number.
Once you have spotted your flight number you will take
action by going to the correct gate and you won’t look if
you see your flight number somewhere else on the
display.

Don’t forget about the deny any at the bottom of this access-list! It’s just like checking your
flight number on the departure sign, if you don’t see your flight you are going nowhere!
There are two types of access-lists we can use:
 Standard access-lists
 Extended access-lists
Let’s start with the standard access-list:

The standard access-list is very basic since it can only check for source IP addresses.
You can’t do anything more specific than that.

Our extended access-list gives us many more options. Not only can you check
for source and destination IP addresses but you can also match on transport layer (layer
4) information like TCP or UDP port numbers.
Does this mean that standard access-lists suck? Well no since sometimes source IP
addresses are all we care about…If you want an access-list to select which networks should
be translated with your VPN then a standard access-list will do the trick just fine.
How can we recognize the standard and extended access-list? Let me show you the table
below:

IPv4 ACL Type Number / Identification

Standard 1-99 or 1300-1999

Extended 100-199 or 2000-2699

Named Pick any name you like

If you want a standard access-list you need to use a number between 1-99 or 1300-1999.
For the extended access-list you need to pick a number between 100-199 or 2000-2699.
If you don’t like numbers you can also use named access-lists by choosing a name, this
works for both standard and extended access-lists.
Before we continue let me give you some guidelines when setting up access-lists:
  First we create an access-list globally and then we assign it to an interface.
 You can only have a single ACL per direction, so it’s impossible to have 2 inbound
access-lists.
 Put the most specific statements at the top of your access-list because if a packet
matches a statement the router doesn’t check if it matches any other statements.
 Don’t forget the last statement is deny any. You don’t see it but it’s there.
That’s all I wanted to show you for now. In another lesson we’ll take a look at how to
configure access-lists on a Cisco IOS router. If you enjoyed this lesson please leave a
comment!

Standard access-list example on Cisco Router

Let’s configure some access-lists so I can demonstrate to you how this is done on Cisco
IOS routers. In this lesson we’ll cover the standard access-list. Here’s the topology:

Two routers and each router has a loopback interface. I will use two static routes so that the
routers can reach each other’s loopback interface:

R1(config)#ip route 2.2.2.0 255.255.255.0 192.168.12.2

R2(config)#ip route 1.1.1.0 255.255.255.0 192.168.12.1

If you choose to use a routing protocol to advertise networks, be careful that your access-
list doesn’t block your RIP, EIGRP or OSPF traffic…

Now let’s start with a standard access-list! I’ll create something on R2 that only permits
traffic from network 192.168.12.0 /24:

R2(config)#access-list 1 permit 192.168.12.0 0.0.0.255

This single permit entry will be enough. Keep in mind at the bottom of the access-list is a
“deny any”. We don’t see it but it’s there. Let’s apply this access-list inbound on R2:

R2(config)#interface fastEthernet 0/0

R2(config-if)#ip access-group 1 in

Use the ip access-group command to apply it to an interface. I applied it inbound with

the in keyword.

R2#show ip interface fastEthernet 0/0

FastEthernet0/0 is up, line protocol is up
Internet address is 192.168.12.2/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing access list is not set
Inbound access list is 1

You can verify that the access-list has been applied with the show ip interface command.
Above you see that access-list 1 has been applied inbound.
Now let’s generate some traffic…

R1#ping 192.168.12.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Our ping is successful; let’s check the access-list:

R2#show access-lists
Standard IP access list 1
10 permit 192.168.12.0, wildcard bits 0.0.0.255 (27 matches)

As you can see the access-list shows the number of matches per statement. We can use
this to verify our access-list. Let me show you something useful when you are playing with
access-lists:
R1#ping 192.168.12.2 source loopback 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
U.U.U
Success rate is 0 percent (0/5)

When you send a ping you can use the source keyword to select the interface. The source
IP address of this IP packet is now 1.1.1.1 and you can see these pings are failing because
the access-list drops them.

R2#show access-lists
Standard IP access list 1
10 permit 192.168.12.0, wildcard bits 0.0.0.255 (27 matches)

You won’t see them with the show access-list command because the “deny any” is dropping
them.
What if I wanted something different? Let’s say I want to deny traffic from network
192.168.12.0 /24 but permit all other networks? I can do something like this:

R2(config)#access-list 2 deny 192.168.12.0 0.0.0.255

R2(config)#access-list 2 permit any
I’ll create a new access-list and the first statement will deny network 192.168.12.0 /24. The
second statement is a permit any. Because of this permit any nothing will ever hit the
invisible “deny any” with the exception of 192.168.12.0 /24. Let’s apply the new access-list:

R2(config-if)#no ip access-group 1 in
R2(config-if)#ip access-group 2 in

Now it’s active, let’s give it a test run:

R1#ping 2.2.2.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

R2#show access-lists 2
Standard IP access list 2
10 deny 192.168.12.0, wildcard bits 0.0.0.255 (11 matches)
20 permit any

These pings are hitting the first statement and are dropped….
R1#ping 2.2.2.2 source loopback 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
R2#show access-lists 2
Standard IP access list 2
10 deny 192.168.12.0, wildcard bits 0.0.0.255 (11 matches)
20 permit any (15 matches)

And pings from the loopback0 interface of R1 are hitting the second statement and are
allowed.
If I want to remove a statement from an access-list, you will await a nice surprise:

R2(config)#no access-list 2 deny 192.168.12.0 0.0.0.255

Let’s say I want to remove the statement above. I’ll type no access-list and this is what
you’ll discover:

R2#show access-lists 2

The whole access-list is gone…ouch! You can’t use no access-list to remove a statement.
Your router will just accept “no access-list 2” and remove the whole access-list. Fun to
discover in a lab, not so much fun on a production network. I’ll show you how to deal with
this in a bit.
Besides applying an access-list inbound or outbound you can also apply them to the VTY
lines. This is useful if you want to secure telnet or SSH access to your router. Let’s
configure R1 so telnet access is only allowed from network 192.168.12.0 /24:

R1(config)#access-list 3 permit 192.168.12.0 0.0.0.255

R1(config)#line vty 0 4
R1(config-line)#access-class 3 in

Above you can see that I created access-list 3 but I used the access-class command on
the VTY lines. On interfaces we use the “access-group” command but on VTY lines you
need to use “access-class” to apply them.
Let’s try to use telnet:

R2#telnet 192.168.12.1
Trying 192.168.12.1 ... Open

Password required, but none set

[Connection to 192.168.12.1 closed by foreign host]

It says “open” which means that it connects. The connection is closed because I didn’t
configure a password for telnet but the access-list should work:

R1#show access-lists
Standard IP access list 3
10 permit 192.168.12.0, wildcard bits 0.0.0.255 (2 matches)

You can see that the packets have matched the statement in access-list 3.

hostname R1
!
interface FastEthernet0/0
ip address 192.168.12.1 255.255.255.0
!
interface Loopback0
ip address 1.1.1.1 255.255.255.0
!
ip route 2.2.2.0 255.255.255.0 192.168.12.2
!
access-list 3 permit 192.168.12.0 0.0.0.255
!
line vty 0 4
access-class 3 in
!
end

hostname R2
!
interface FastEthernet0/0
ip address 192.168.12.2 255.255.255.0
ip access-group 2 in
!
interface Loopback0
ip address 2.2.2.1 255.255.255.0
!
ip route 1.1.1.0 255.255.255.0 192.168.12.1
!
access-list 1 permit 192.168.12.0 0.0.0.255
access-list 2 deny 192.168.12.0 0.0.0.255
access-list 2 permit any
!
end